CyberKsen Blog

You need to start somewhere. And if your goal is too much too soon according to time and resources, then the dev team will correctly push back and find their way! Maturity models offer a way to define a set of intermediate goals to increase the maturity, in this case of the security champion programme. But what is a security champion? really anyone that is willing to talk about security, at least at the beginning, communication and mutual trust is key. Dev teams have to receive added value from security practices, not impediments. Closer team collaboration is also key for DevSecOps programmes. Here is an example, the first phase is really to find the people to talk and have mutual trust with...and in structured organizations may be as well challenging.  Here's a Wardley Map about the maturity evolution and dependencies of the security champion "assets". Note: Vertical axis represent visibility, low to high. The horizontal axis represents maturity: Weak to Expert.

The idea is simple, yet very much needed. Defining coding standards for dev teams risks to become an sterile exercise of creating a confluence page that can be soon forgotten. Better than that is to invest in a secure coding training. Yet,usually, secure coding training, as well as many other resources are very generic, in both terms of field (web applications) and in term of languages (not even talk about specific frameworks. It results also in defining coding standards as apply OWASP TOP 10 and some SEI CERT coding standards . But what about a non-web application? Should you really care about XML External Entities (XXE) or Cross Site Scripting XXS? Imposing such a list on developers that are not dealing with XML or web applications will not make them feel understood and helped, and you will not be able to expect that those coding standards will improve the security of the project  code.  Here's an approach that may improve the maturity of the definition of secure coding stand

Observability and metrics paradox. It is also about observability: ”If a tree falls in a forest and no one is around to hear it, does it make a sound?” …or… What is the return value (in dollars number) of having a better SDL in place if your company wasn’t shaken by cybersecurity incidents? I see a little paradox here, after spending big budget into security you cannot measure the returns, even more, the returns are less visible: you don’t have incidents in the first place…and if they happen then “someone saves you”, you may have prevented 9/10 of incidents but it is difficult to make a counterfactual argument at that point. Oh yes, if you had big problems in the past you can then see the statistical improvements over time, Microsoft did. From:  https://www.owasp.org/images/9/92/OWASP_SwSec5D_Presentation_-_Oct18.pdf Microsoft case teaches Microsoft had a nice market position and did deal with security in the early 2000s. Not any company has a de facto monopoly in the ma

Secure development lifecycle in more dimensions SDL is complex and always different for every company. Applying the right strategy requires having a better idea of what is the real state of the SDL. Looking at it in more "dimensions" or aspects can unleash real effectiveness in SDL implementation. Of course looking at the same thing from many points of views may lead to some overlapping or redundancies (see pic 4) but definitely helps to have a more complete picture, understanding and finally drive action plans in the correct direction. Imagine looking only at one the lateral projection of the following object: Picture 1: Projections are aspects or dimensions of the real object. Obviously looking at more dimension of the same reality helps to comprehend it better, despite occasional redundancies. Also, the more complex the object is the more dimension are needed to have a better understanding. Fortunately, many frameworks address SDL: SAMM, Microsoft SDL

When dealing with complex, hierarchical organizations made up of 10s or 100s of different teams/projects, of course, management needs to be able to track security issues and risk. To just document somehow what is the "criticality of a bug" without the right concepts in place, is not a problem, is an organizational catastrophe. As a developer who got involved in security, one of the biggest challenges in performing training is to align on the same languages with dev teams. That happens, of course, as well when implementing security practices into the SDL (Secure Development Lifecycle). Not having the right set of concepts, and their related accepted shared unique terms, is both a symptom and a cause of lack of security management in a vicious spiral. This lack of concepts/term structure, sometimes called thesaurus, is reflected in tools like development issue tracker, first of all, Jira. Jira, on the other way, offers enough flexibility to structure of the concepts I'