Organizations seeking to improve performance and their bottom line need look no further than improving their DevOps implementation. Based on survey results from more than 27,000 respondents over six years, organizational performance is directly correlated to how well the organization implements a DevOps culture.[1]
DevOps yields efficiency and productivity gains which go beyond simple transparency in cross-functional collaboration. DevOps methods and workflows lead to rapid, and even continuous deployment, necessitating a culture shift throughout the organization. Organizations that implement this culture shift well develop a production feedback loop across all organizational stakeholders and clients. As the DevOps implementation matures, the feedback loop leads to higher profitability and increased market share.
Despite, however, the well-established benefits of DevOps, only 27% of organizations have embraced it. Fewer still have achieved a mature implementation. Nonetheless, most agree that the benefits of rolling out DevOps outweigh the challenges and that DevOps is worth doing well. Where most organizations are challenged, though, is not in the cost-benefit analysis or applying lean production theory to combining development and operations teams. The challenge is to integrate security into the mix adequately.
The difficulty arises because the “get it to market fast” pressures which motivate an adoption of DevOps tend to be more acutely felt by organizations than the security team’s “deploy it securely” mandate. When organizations are driven by the bottom line – and what for-profit organization is not – the “fast to market” pressures simply win out over the “securely” drivers. [2]
After all, production is a profit center, whereas for most organizations security is a cost center. If organizations are going to do DevOps well, it requires a cross-functional collaboration across all three functions: development, operations, AND security. Focusing only on two of the three is like building a 3-legged stool with just two legs.
However, there is a fantastic opportunity here for organizations to seize. That is, security teams can be transformed from a cost center to a value center, even a value driver. The inflection point in this transformation may be realized simply by a modest change in the tactical paradigm practiced by security teams. Making this slight tactical modification will – almost effortlessly – bring security into the organization’s family of cross-functional collaboration, which will significantly improve the implementation of the DevOps culture throughout the organization.
Security Teams: Stop DOING security to gain cross-functional collaboration
Each year the State of DevOps survey report demonstrates that the single most significant predictor of IT success – and thus organizational success – is deployment frequency. Likewise, the primary predictor of failure is deployment pain. [3] Anyone following the DevOps movement already knows this, of course.
However, what few people openly discuss – the elephant in the room as it were – is that the number one cause of deployment pain is a failure to integrate DevOps and security seamlessly. When the cross-functional collaboration is limited to just the operations and development teams, the organization inherently limits the realizable benefits from their DevOps implementation.
The challenge to integrate security with DevOps is tactical, not strategic or theoretical. The way in which security and QA are traditionally done simply cannot be applied to a rapid or continuous deployment environment. For years organizations have tried to remediate that situation by using – at significant cost, no less – automated security scans wherever possible. Automated scans are wonderful – to a point. They can both save tremendous amounts of labor and create production consistencies. [4]
The downfall to automated solutions, though, is that they cannot by themselves improve an organization’s DevOps implementation. SAST and DAST, for example, have been employed efficiently for years to identify internal coding bugs. Consider, though, that since 2004 more than 74,000 security vulnerabilities have been disclosed by the NVD – yet SAST and DAST can only identify a handful of the most common types.
Moreover, according to the NSA, only about 14% of application problems can be identified with SAST tools. Furthermore, both DAST and SAST are weak in identifying open source code vulnerabilities. [5] If automated solutions were the answer to cross-functional collaboration, DevOps implementations would be straightforward.
To make matters worse, SAST and DAST have virtually no capacity to identify the more significant potential issues. For application architecture and design can also contribute to security defects. [6] Automated tools cannot touch these issues – they require security team expertise and experience. There is no substitution for human intelligence.
Thus, the challenge cannot be addressed with better automation and scanning tools. Nor can executive mandate improve matters. The challenge of generating genuine cross-functional collaboration between security and DevOps teams boils down to scalability.
Most IT professionals are aware that there is a severe shortage of qualified cybersecurity professionals. However, even if this were not so, asking security to provide secure code reviews for the same application 300 times per day would be incredulous for one simple reason: The way security typically DOES security is slow and unscalable. If organizations are going to improve their DevOps implementation with true cross-functional collaboration, security must stop DOING security.
Leverage and Scale Security Expertise through a Self-Serve Solution
The only way to produce genuine cross-functional collaboration at the speed and scale of the DevOps teams is for security to empower DevOps teams through a self-serve solution. Then, the DevOps teams can access security’s expertise when and where they need it, allowing the security team’s expertise to scale to the entire DevOps portfolio. When done correctly, DevOps will not even be aware that they are working for the security team – they will just be going about their typical workflow without any additional tasks.
It may sound like significant additional work – implementing a self-serve security solution. Who needs yet one more initiative to manage? Interestingly, though, the proper solution may reduce the overall DevOps tasks to get a product to market.
Architecturally-based threat modeling – utilizing a solution whereby the project architect can whiteboard the project during the design phase – automatically inserts security into the far-left of the SDLC. Additionally, the proper threat modeling solution will provide immediately actionable outputs to coders before they begin their sprints. Developers thus have access to specific threats and mitigating controls, sorted by risk and architectural components as they work.
Click here to schedule a live demo and learn how ThreatModeler can improve your organization’s cross-functional collaboration.
[1] Forsgren, Nicole. “2017 State of DevOps Report.” DevOps Research and Assessment (DORA). Puppet: Portland. 2017.
[2] “Application Security and DevOps: What is the true state of security in DevOps?” Hewlett-Packard Enterprise Development LP: Palo Alto. October 2016.
[3] Forsgren, Nicole. “2016 State of DevOps Report.” DevOps Research and Assessment (DORA). Puppet: Portland. 2016.
[4] Delgado, Rick. “The Key to Merging DevOps with Security.” Tripwire. Tripwire, Inc: Portland. May 9, 2017.
[5] Bals, Fred. “Did SAST and DAST fail Equifax?” Black Duck. Black Duck Software, Inc: Burlington. October 4, 2017.
[6] McGraw, Gary. “McGraw on the IEEE Center for Secure Design.” TechTarget. TechTarget: Newton. August, 2014.