Software professionals know that the working relationship between developers and security teams can be complicated. Most security professionals feel it’s part of a programmer’s role to write code securely, but most developers get next to no support to do it.
Despite this dynamic between developers and security architects becoming part of IT lore, the fact remains that these technical teams are two sides of the same coin. Like the head and tail, developers and security specialists have alternative perspectives, which means they don’t always possess clear visibility or awareness of what the other is doing – even though they are working towards the same goal.
The fundamental issue boils down to communication. The predominant siloed approach to software development, with engineering and design coming first and security second, has turned security into an artificial barrier to deployment and increased the risk of vulnerabilities being built into software because security is positioned as a bolt-on feature.
The “shift left” concept was coined 20 years ago and was designed to encourage sooner-than-later testing during development. But it’s my belief that we need to evolve the development and security culture further to “start left”. If we start left with cyber security then it means protection can be baked into product design from the get-go, so both development and security teams would be invested and have a better understanding of process and execution.
Bridging the gap between software development and security
The age-old development process has been the cycle of build, test, fix, build, test, fix. This pattern keeps development and security in siloes and creates frustration among both parties that isn’t conducive for a trusted and collaborative working environment. It also leads to bad outcomes on the product development side, delaying the time to deployment and inevitably resulting in software vulnerabilities that can’t be spotted in post-production.
It is therefore common sense to shift security earlier in the design process. In my experience, one of the major barriers to adopting this approach has been the belief that developers either don’t care or are incapable of adopting cyber security practices in development. This is a myth. All teams want strong, secure products and an easier path to deployment.
What has been missing are the tools for developers to use to implement security into software design, without requiring them to completely re-train as security professionals and without the constant oversight of the security team. This is where the practice of threat modeling has the potential to change the relationship between developers and security professionals and create the ultimate goal of DevSecOps: truly cross-functional teams.
The Threat Modeling Manifesto, a consensus document from 15 threat modeling practitioners published last year, defines it as “analyzing representations of a system to highlight concerns about security and privacy”. In simple terms, threat modeling is a means of visualizing and identifying potential threats in software during the design stage, even before a line of code has been written, and then through development.
Threat modeling doesn’t have to be an elaborate process. Adam Shostack coined the Four Question frame for threat modeling which boils the process down to just four steps:
1. What are we working on?
2. What could go wrong?
3. What are we going to do about it?
4. Did we do a good job?
By asking these four questions at the beginning of the design process, developers can identify threats (50% of which are created during design and cannot be detected by scanning tools) and their planned response to them during the development process. This threat model becomes part of the software documentation and ideally part of the code itself, so that the discoveries made during the exercise and the decisions made are recorded for future iterations.
If done right, threat modeling is embedded into an organization’s existing working practices and the tools engineers use to make security an enabler, rather than a blocker. By working with tools they are familiar with, engineers should be able to generate their own threat models and introduce security independently. At this point their consultation with the central security team can begin and each department will then have more joined-up awareness of what the other is working on in real-time, rather than later when a defective project will need a major overhaul.
Driving DevSecOps forward
Building an apartment block and realizing it is missing fire exits when construction has ended will cause untold delays, additional expenditure to resolve the situation and endless frustration – particularly if measures could be taken earlier to mitigate this. These pains are similar when software builds go through security testing, only for vulnerabilities to be revealed at what should be the final stage.
While the practice of DevOps combines development and operations together to speed up deployment of applications, companies can level up further still. The benefits of identifying security issues earlier include lower expenses to rectify threats, time savings, enhanced internal collaboration and faster delivery to market.
If we are to truly bake in the security function as standard, making it an integral component of the company for all, then DevSecOps within enterprises is what we as an industry should work towards.
Credit: Source link
