As Amazon Web Services Senior Manager Steve Andrews blogged in July, “Leaving security out of DevOps is asking for trouble.” It was evident at the recent RSA Conference in San Francisco that increasing numbers of IT and development managers are coming around to Andrews’ way of thinking.
The rapid rise of a security-aware version of DevOps, called DevSecOps by many (and SecDevOps by others), seemed to be gaining steam at the conference, with numerous sessions and product announcements devoted to the topic. Conference organizers even designated March 3 as “DevSecOps Day at RSA,” devoting an entire day’s worth of sessions and speakers to the integration of security into the DevOps framework.
“There are no development or operations (DevOps) staff who don't make mistakes with respect to security in applications or cloud environments,” says Ron Herardian, co-founder and CEO
of Basil Security, a start-up focused on developing enterprise software products that enable security policy management and enforcement for IT processes, applications and data. Basil chose the RSA event to debut its “policy-as-code” platform that provides “stateful security policy enforcement over arbitrary code execution, APIs, and data access.” The company claims that its platform can be used to prevent errors, block insider cyberattacks, and guarantee accountability.
“Without security policy enforcement, DevSecOps is only a more sophisticated set of best practices,” Herardian says. A policy-as-code platform such as Basil’s lets security teams describe the specific actions that developers or operations staff members can or cannot take, thus preventing erroneous or malicious actions.
In traditional waterfall or even agile development environments, an application security architect typically “specifies some design requirements and security features up front in the software development process, and then moves on to work on a different project,” says Synopsys Principal Scientist Sammy Migues. Often there’s an assumption that “if penetration testing done months later doesn't show any issues, then the architect's design guidance was probably followed. The fact that penetration testing may not find design flaws is lost on too many organizations.”
In a DevOps environment, however, relegating security considerations to the beginning and end of a development cycle is no longer sufficient. Security needs to become a continuous and systemic part of the process. “All that ‘Sec’ knowledge that was driving efforts that used to happen outside of the development process -- efforts that were human-driven and labor-intensive -- now must be automation-driven, frictionless, and happen inside the development process,” Migues says. “That's the huge change required to put Sec in DevOps.”
PagerDuty, another RSA exhibitor with designs on the emerging DevSecOps market, chose the event to announce its PagerDuty for Security Operations offering, a solutions portfolio for security, development and operations teams to work together on a common platform for automating triage and remediation activities when critical security vulnerabilities, threats, or breaches are detected across their infrastructure and applications.
One of the third-party developers participating in PagerDuty’s security ecosystem announcement at RSA was Signal Sciences, whose integration with PagerDuty claims to provide security visibility and real-time incident alerts to support faster, better informed decisions for managing and resolving security incidents.
“With the shift to DevOps and cloud, security needs to go from being a blocker to an enabler,” says Zane Lackey, co-founder and CSO of Signal Sciences. “DevOps means teams can be changing code and launching new versions of software as fast as every week or every day. This fundamental shift provides a good model for the direction security also needs to go.
“Security needs to be in real time, and not bolted on at the end as a gatekeeper -- which it has been for the most of the past 15-20 years. It has to be baked into the process from the very beginning and must focus on bringing security capabilities directly to development and DevOps teams,” Lackey says. “What this means to IT managers and others is that we want those teams to become security self-sufficient so they can innovate faster.”