Building DevSecOps culture – no one said it would be easy without a Threat Modeling program

DevSecOps is a common term in nowadays software development. It defines not only the mandate to consider security as part of your DevOps-oriented development principles, it often comes with cultural changes, increased automation, and raising satisfaction of the development community. And, it is a good means to jumpstart your DevOps adoption if done right.

Leveraging the manual process of thread modeling to jumpstart a DevSecOps program where it is all about automation, does that sound counterintuitive? The reason why it should not, we will elaborate in this article.

Before we review how threat modeling can be of help, let us first ensure we have a common understanding of DevSecOps. DevSecOps deals with the fact that nowadays the software release cycles have drastically reduced. Without automation and tight integration, security would become the bottleneck.

DevSecOps comes with the benefits of:

Cost-effectiveness: applying the principle - doing it once is OK, doing it twice it should be at least documented, doing it the third time it needs to be automated - the technical expert will always select the momentary effort for automation capabilities over continuous manual activities.

Proactive security: it is common sense that a late finding in development or even maintenance is most costly. DevSecOps assures it is minimally invasive at the time of development and efficient if something arises later.

Improved patch cycle: it is not only due to the high open source adoption that the mean-time-to-exploit for critical flaws is now down to days instead of weeks or months. Thereby timely identification, assessment, fixing, and patching your installed base is crucial. The automation and rapid delivery capabilities of DevOps are the key driver also for security.

DevOps are the key driver for security.

Ensuring repeatability: whenever you are planning to deploy your solution or any change that is applied to the stack, reproducibility and reliable results are essential. The preference of code instructions over manual instructions makes it easy to validate what state was active at which time. Thereby it raises the acceptance by the developers, ensures efficiency, and a proper audit track.

DevSecOps does so by:

Applying shift-left principles: it is the application team which understands the business purpose and implementation; it is the security team which understands compliance requirements and the security architecture and controls. Only if security enables the team right at the time of blueprinting, will it be able to drive the development efficiently with the right tools and processes in place.

Providing security awareness and up-skilling: the initial goal of a development team is to deliver functionality fast to the market. Giving developers the perspective of what can go wrong, and how it can hinder the success of the solution will lead to the consideration of security aspects. Training and awareness campaigns will ensure the development team will have the right skillset.

Establish clear processes: non-standardized processes can cause the project to fail, initiatives to be lost in chaos. Defined processes like a security correction process, event monitoring process, patch process ensures solutions are properly implemented and the required parties being involved.

Established frameworks: establishing processes nearly in all cases comes with tools and/or full-blown security management frameworks. While this may be partly there, DevSecOps reviews it under the criteria of efficiency, drives a self-service approach and aims for the best ease of adoption.

Establish communication: an incident is best handled if all parties know each other and have the right expectations. Having an ongoing exchange before the incidents arise ensures the organization is robust also to unforeseen scenarios.

So, how does threat modeling play into that?

First and foremost, threat modeling is people-centric. When conducted right, a threat modeling workshop is like a design thinking workshop – just raising the question “What can go wrong?”. The interaction from a threat modeling workshop normally lasts and allows the interaction between the security team and the application team way beyond. Based on my experience working in fortune 500 companies for more than two decades and working with the development workforce of several 10.000 people, it is the interaction which lays the foundation for efficient, security changes and stronger collaboration when timely resolution is key.

Secondly, it incorporates security considerations at the stage of software development where automation is not yet the factor. The most value by threat modeling is gained when it is used to define a secure architectural right at the beginning and outlines the required security evaluation for tight integration before the first line of code is written.

There is another crucial factor that also plays into the hand of DevSecOps. As part of ramping up the threat modeling program a normalization process normally takes place. Threat modeling reviews used processes, frameworks, defines architectural concepts leading for example to the development of a service mesh, and re-defines the right toolset. The normalization often does not remain in the realms of security, only. The wisdom gathered during the normalization process is what is then applied during the workshops at scale - making the security expert becoming a mentor on general technology concepts applied in the organization.

Ensure to make your life easier when you are planning to build up your DevSecOps program by tying it closely up with the existing threat modeling program!