Vulnerabilities / Threats

1/10/2018
02:00 PM
Kevin E. Greene
Kevin E. Greene
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

'Shift Left': Codifying Intuition into Secure DevOps

Shifting left is more than a catchy phrase. It's a mindset that emphasizes the need to think about security in all phases of the software development life cycle.

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:

  • Guide product teams in making good design decisions regarding security features of the systems.
  • Assist developers in understanding the consequences of their refactoring or development activities when implementing the design in code.
  • Develop situational awareness about security threats and risks that can be used to guide more targeted and efficient security testing (achieving security "at-speed") throughout the software development life cycle.

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

  • Leverage Common Architectural Weakness Enumeration (CAWE) in formulating good user stories about new features and functionality. CAWE has been recently added into MITRE's CWE 3.0 release
  • For user stories, crosswalk CAPEC and ATT&CK to codify intuitions in the development of misuse/abuse cases to better understand ways in which the system can be compromised and attacked.
  • Once the security design has been validated and verified, use CWE to understand how to correctly implement the security design, along with the features and functionality into code. 

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:

Kevin Greene is a thought leader in the area of software security assurance. He currently serves on the advisory board for New Jersey Institute of Technology (NJIT) Cybersecurity Research Center, and Bowie State University's Computer Science department. Kevin has been very ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
KevGreene_Cyber
50%
50%
KevGreene_Cyber,
User Rank: Author
1/13/2018 | 2:41:51 PM
Re: Design-time Security Engagement: Still Coming
Yes, this isn't an new problem. I wanted to present the issue in a way to get developers and security folks to think differently about software security; especially with the rise of DevOps and the ongoing issues with security tools clogging up CI pipelines. Do it early and do it often is the name of the game. Thanks for commenting and reading the article.
Brook S.E.S308
50%
50%
Brook S.E.S308,
User Rank: Apprentice
1/10/2018 | 8:00:43 PM
Design-time Security Engagement: Still Coming
As I point out in the intro to my last book, Securing Systems, the first standards reference to design-time security requirements that I managed to find was NIST 800-14, 1996! My chapter in Core Software Security describes early aat inception engagement followed by full participation in creation of the the structure (architecture) that will be built.  Of course, IEEE Center For Secure Design's "Avoiding The Top 10 Security Design Flaws" reiterates the same message (I'm a co-author). 

Talking about early engagement for security requirements is not new. It amazes me that we have to keep reiterating this as though it were something new. Why? because such engagements are still too rare, unfortunately. 

Still, within the 4 security architecture practices that I've lead, we have achieved early engagment. Part of whatever success I and my teams have enjoyed has depended upon security people becoming fulll participants in the entire development process. When seen as a key subject matter expert (SME) develop teams are quick to integrate their security members right from inception. I call it, "developer-centric security".

As I've become more involved in DevOps (as I spoke about at RSA SF '16), it's become clear to me that just as the software/system needs security architecture, so does the DevOps chain, as early as possible: same deal.

the problem with DevOps is that it often begins organically as experiments. But the tipping point to production and canonization, architecting DevOps with security deeply engaged has the promise of fulfilling the "shift left" imperative.

/brook schoenfield
White House Cybersecurity Strategy at a Crossroads
Kelly Jackson Higgins, Executive Editor at Dark Reading,  7/17/2018
The Fundamental Flaw in Security Awareness Programs
Ira Winkler, CISSP, President, Secure Mentem,  7/19/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-14492
PUBLISHED: 2018-07-21
Tenda AC7 through V15.03.06.44_CN, AC9 through V15.03.05.19(6318)_CN, and AC10 through V15.03.06.23_CN devices have a Stack-based Buffer Overflow via a long limitSpeed or limitSpeedup parameter to an unspecified /goform URI.
CVE-2018-3770
PUBLISHED: 2018-07-20
A path traversal exists in markdown-pdf version <9.0.0 that allows a user to insert a malicious html code that can result in reading the local files.
CVE-2018-3771
PUBLISHED: 2018-07-20
An XSS in statics-server <= 0.0.9 can be used via injected iframe in the filename when statics-server displays directory index in the browser.
CVE-2018-5065
PUBLISHED: 2018-07-20
Adobe Acrobat and Reader 2018.011.20040 and earlier, 2017.011.30080 and earlier, and 2015.006.30418 and earlier versions have a Use-after-free vulnerability. Successful exploitation could lead to arbitrary code execution in the context of the current user.
CVE-2018-5066
PUBLISHED: 2018-07-20
Adobe Acrobat and Reader 2018.011.20040 and earlier, 2017.011.30080 and earlier, and 2015.006.30418 and earlier versions have an Out-of-bounds read vulnerability. Successful exploitation could lead to information disclosure.