Software professionals know that the working relationship between developers and security teams can be complicated. Most security professionals think it’s part of a programmer’s role to write code safely, but most developers have little or no assistance in doing so.
Despite this dynamic between developers and security architects becoming an integral part of the IT tradition, the fact remains that these technical teams are two sides of the same coin. Like head and tail, developers and security specialists have alternate perspectives, which means they don’t always have clear visibility or awareness of what the other is doing, even if they are working. for the same purpose.
The basic question comes down to communication. The prevalent siled approach to software development, with engineering and design first and security second, has turned security into an artificial barrier to deployment and increased the risk of integrating vulnerabilities into software because the security is positioned as a bolt-on feature.
The concept of “left shift” was invented 20 years ago and was designed to encourage testing sooner rather than later in development. But I think we need to further shift the culture of development and security to ‘start on the left’. If we start from cybersecurity, it means that protection can be built into the product design from the start, so that the development and security teams would be invested and have a better understanding of the process and execution. .
Bridging the gap between software development and security
The age-old development process has been the build, test, fix, build, test, fix cycle. This model keeps development and security in silos and creates frustration between the two parties that is not conducive to a working environment of trust and collaboration. It also leads to poor results on the product development side, delaying deployment time and inevitably leading to software vulnerabilities that cannot be detected in post-production.
So it makes sense to move security earlier in the design process. In my experience, one of the biggest barriers to adopting this approach has been the belief that developers don’t care or are unable to adopt cybersecurity practices in development. It is a myth. All teams want strong, secure products and an easier deployment path.
What was missing are the tools developers can use to implement security into software design, without requiring them to retrain themselves completely 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 Manifesto on threat modeling, a consensus document of 15 threat modeling practitioners released last year, defines it as “analyzing representations of a system to highlight concerns about security and privacy.” Simply put, threat modeling is a way to visualize and identify potential threats in software during the design phase, even before a line of code has been written, and then throughout development.
Threat modeling does not have to be an elaborate process. Adam Shostack invented the Four Questions Framework for Threat Modeling, which narrows 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 early in the design process, developers can identify threats (50% of which are created at design time and cannot be detected by scan tools) and their expected response during the design process. development. This threat model becomes part of the software’s documentation and ideally the code itself, so that discoveries made during the exercise and decisions made are recorded for future iterations.
If done right, threat modeling becomes part of an organization’s existing work practices and the tools engineers use to make security a catalyst 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 a more common knowledge of what the other is working on in real time, rather than later when a faulty project needs attention. major overhaul.
Building a building and realizing that there are missing emergency exits once construction is complete will lead to untold delays, additional expense to resolve the situation, and endless frustration – especially if action could be taken sooner to mitigate that. These difficulties are similar when software versions are subjected to security testing, only for vulnerabilities to be revealed at what should be the final stage.
As the practice of DevOps combines development and operations to accelerate application deployment, there is still room for improvement. The benefits of identifying security issues earlier include less expense to rectify threats, time savings, improved internal collaboration, and faster delivery to market.
If we are serious about integrating the security function as standard, making it an integral part of the business for everyone, then DevSecOps within the enterprise is what we as an industry should be working towards.