'Shift Left': Codifying Intuition into Secure DevOps

Continuous delivery (CD) is becoming the cornerstone of modern software development, enabling organizations to ship — in small increments — new features and functionality to customers faster to meet market demands. CD is achieved by applying DevOps practices and principles (continuous integration and continuous deployment) from development to operations. There is no continuous delivery without implementing DevOps practices and principles. By that, I mean strong communication and collaboration across teams, and automation across testing, build, and deployment pipelines. But often achieving continuous delivery to meet market demands presents numerous challenges for security. 

While DevOps principles and practices acknowledge the need for security, many organizations struggle to find the right fit and speed for integrating security into DevOps. In a study conducted by HP Enterprise, 99% of respondents say that while DevOps culture offers the opportunity to improve application security practices, only 20% of respondents say that secure systems development life cycle (SDLC) testing is done throughout their development process. (Read "Software Assurance: Thinking Back, Looking Forward.")

Security is still trying to catch up with all the innovative software being developed, tested, deployed, and delivered without slowing or bogging down the process. Security has to be intrinsic and transparent yet visible enough in the process that it is a "shared" responsibility at the heart of DevOps practices and principles. So when a product owner describes new features and functionality that need to be added to the next release, everyone thinks about ways in which those features and functionality can be designed and implemented securely to reduce exposures and vulnerabilities. This is what it means to "Shift Left."

I often hear that slogan in the industry: "Shift Left." Most of the time the term is used in reference to moving security testing into continuous integration. While I agree that security testing as part of continuous integration is important, it's way too late at that point in time. "Shift Left" must go far left, past continuous integration into the requirements and design phases. "Shift Left" to me is a mindset that thinks about security from the onset and is pervasive throughout the software development process. This is what it means to build "security in."

When you start far left, you have the opportunity to embed the appropriate security lexicon and security considerations into the requirements phase. Starting with really solid security requirements allows organizations to codify their intuitions into design; it enables organizations to make sound design decisions up front that will help eliminate technical debt and reduce the cost to maintain software.

Codifying intuitions is a concept I got from a colleague of mine, David Molnar, a security researcher from Microsoft, in a talk about what security can learn from AI. The concept of "codifying your intuitions" was used in a larger context to the security domain, but also, specifically, to defending against adversarial activity and advanced persistent threats in a talk by security researcher Taesoo Kim. I like the concept because it reinforces the need to think like an adversary and infer some of our intuitions and assumptions not only into security design but also into developers' daily activities. Kim gives an example in his talk about what led Jung Hoon Lee, a notable bug bounty hunter, to find vulnerabilities at the Pwn20wn 2016 hacking contest. Lee attributes the discovery of exploitable vulnerabilities to his "intuition." 

The Gift of Intuition
Experience in the trenches working in security, developing software, breaking software, and protecting software forms patterns in our minds that provide a solid foundation from which we can train our minds and mental capacities to recognize and be more aware. I tend to look at intuition as the revelations about the mental patterns we accumulate over time; intuition forms from the right hemisphere of the brain (the creativity region) and inspires ingenuity. As with many complex problems in cybersecurity, solutions to those problems often require some level of curiosity and creativity to decompose complexity. This same level of curiosity and creativity is what often motivates attackers. It must be applied to software development to help organizations shift their "security-minded thinking" all the way left.  

One of the keys to shifting left is figuring out how to codify intuitions into threat models that can be used to guide secure software development. This could be in the form of user stories and misuse/abuse cases that help organizations better understand how to securely design and implement features and functionality into software. These threat models can be used to:

To help organizations formalize threat modeling activities into their SDLC, organizations should consider adopting the following practices and standards:

Shifting left is a mindset, a philosophy that emphasis the need to think about security (codify your intuitions) in all phases of the SDLC.  

Related Content: