Our recent survey found that over 50% of companies admit to cutting back on security measures to meet a business deadline or objective. As long as companies are willing to sacrifice security at the altar of speed, the long-held dream of marrying DevOps and security simply won’t become reality.
To speak to the issue, Threat Stack’s Head of Operations, Pete Cheslock, and PagerDuty’s Senior Application Security Engineer, Franklin Mosley, joined the SANS Institute for a recent webinar. You can listen to the full webinar here or read the major takeaways below.
Sacrificing Security for Speed
More than half of companies (52%) admit to cutting back on security measures to meet a business deadline or objective. It seems the pressure often comes from on high, with 68% of companies stating that their CEOs demand DevOps and security teams not do anything to slow the business down. Sixty-two percent say their operations teams push back when asked to deploy secure technology, and 57% say those teams push back on security best practices.
These findings are in line with the current trend of a separation between security and DevOps. While the advent of the cloud now means that operational resources can be deployed within minutes rather than weeks, the view of security as a roadblock remains constant. Security teams sometimes block developers from making progress in order to implement better security measures. Conversely, security teams can be left out of the loop during development cycles, which leaves them struggling to catch up or demanding DevOps teams slow down for security.
The tradeoff of operating at such a rapid pace in the cloud is that it’s far too easy to introduce security flaws. It’s vital that security become better aligned and integrated into development processes. This will enable decisions to be made that don’t sacrifice security for the sake of speed. Integrating security, however, requires buy-in from executives and DevOps teams, which is easier said than done when speed to market is the top priority.
In order to get executives on board, security teams should look at current events, sharing security issues that appear in the news with their teams on a weekly basis. Demonstrating that these concerns have real-world consequences can help emphasize the importance of security. Executives will often see risk to a company’s reputation and loss of customer confidence, in addition to higher costs, as powerful drivers to action.
In the case of DevOps, it’s important for security teams to show that they can minimize risk without making the jobs of developers more difficult. Nothing is worse than bogging down developers with a bunch of false positives, so start with a small project that produces high-confidence results in order to build trust and get buy-in for future security projects.
Intent vs. Reality
While 85% of companies say that employing SecOps best practices is an important goal for them, only 35% say that SecOps is an established practice at their organizations. So, why the gap between intent and reality?
While companies are making the effort to employ SecOps, security is still effectively siloed. At 38% of organizations, security is a completely separate team that is only brought in “when needed.” Meanwhile, 44% of developers have not been taught to code securely, and 42% of operations staff admit that they are not trained in basic security practices.
Much like the move to DevOps, adopting SecOps requires major organizational changes. Among them is a cultural shift toward shared knowledge. Without increased knowledge sharing, however, engineers become separated from their software’s security, and quality falls.
A Change in Mindset
In order to better employ SecOps best practices and integrate with DevOps, it’s necessary to foster a culture of shared responsibility, where all stakeholders own the health and safety of a platform. If engineers don’t learn how to apply security best practices, they won’t feel responsible for the security of their code.
An approachable security team can aid developers in leveling up their security skills, offering in-person training and lunch-and-learns, for one, in place of less effective computer-based training. Conversely, security teams should become familiar with the tools that developers are already using. A security team that learns to use configuration code, for example, can integrate new security products directly into the development process.
It takes a change in mindset to get all members of an organization on the same page. It’s important to consider the needs of all involved:
- Developers want to release new features early and often.
- Operations wants a stable and reliable environment.
- Security teams want to minimize risk and remediate vulnerabilities quickly.
Once all these needs are understood, it’s possible for the various factions to work together toward the same goal of a secure, stable, and feature-rich product — and thus realize the dream of SecOps.
Bridging the Gap
Because of the culture shift that is required, the integration of security and DevOps won’t happen overnight. It takes an investment of time and resources to train developers and security teams to bridge the gap. Automation goes far in easing the process, and a platform like Threat Stack can help integrate security tools with DevOps. Adopting SecOps takes ongoing commitment and a great deal of work, but the payoff is a company that works seamlessly to put out better, more secure software — and this translates into a strong competitive edge.
Bridging the Gap Between SecOps Intent and Reality
This report examines why the vision for SecOps hasn’t become a reality at most organizations.