By Byron V. Acohido
DevOps is now table stakes for any company hoping to stay competitive. Speed and agility is the name of the game. And everyone’s all-in.
Related: A firewall for microservices
DevSecOps arose to insert security checks and balances into DevOps, aiming to do so without unduly degrading speed and agility.
If you’re thinking that speed and security are like oil and water, you’re right. At RSA 2020, I had an eye-opening discussion with Rohit Sethi, CEO of Security Compass, about this. Sethi walked me through some of the limitations of DevSecOps, as well as the approach Security Compass is taking to help shore it up. For a full drill down on our discussion, please give the accompanying podcast a listen. Here are key takeaways:
The speed imperative
Software has become the life blood of virtually all industries. As companies have come to realize how pivotal software is, an urgency has arisen to develop code as quickly as humanly possible.
Fail fast. That’s become the mantra of DevOps. Pour everything into quickly deploying minimally viable software to learn where it works or fails, and then iterate and remediate on the fly. Fail fast has replaced the methodical, linear approach to developing software, which sought to achieve a perfect product.
Add in the mainstreaming of cloud computing, as well as the emergence of practices like continuous integration, and the result is ever faster cycles of “develop, deploy, get feedback and make changes,” Sethi observes.
“The ability to ship software out quickly has become an imperative for almost all businesses, meaning, ‘If you don’t do this, your competitors will, and your business will be at risk,’” he says.
Fast-and-risky
DevOps has forced a philosophy shift at large companies accustomed to top down decision making. Keep in mind, software security was an afterthought when legacy software development processes first took shape. Over the years processes, training and tooling to account for data privacy and data integrity have been woven in, driven by data breach lawsuits and the rise of data handling regulations.
Enter DevOps. In the frenzy to move quickly, legacy privacy-by-design and security-by-design security best practices got tossed out and replaced by what Sethi describes as “the fast-and-risky approach to securing software.”
Sethi
“How this works is when you build software, you employ a whole series of automated, reactive processes to make sure that it’s secure. And if you find something, you go back and fix it,” Sethi told me. “The problem is some of those failures are architectural in nature, and they’re not easy to fix. The other problem is that some things just can’t be detected by a reactive process.”
Sethi says fast-and-risky characterizes much of what DevSecOps consists of today. This, in turn, has given rise to fresh tiers of unprecedented vulnerabilities – flaws that motivated hacking groups have nothing better to do than to locate and exploit, just ask Equifax or Capital One.
Fast-and-risky leaves little room for legacy software development best practices, things such as developer training, threat modeling, risk assessments and quality assurance reviews, Sethi observes.
Automating security-by-design
There is one thing DevOps can’t get around: compliance with data handling rules and regulations. New laws, like Europe’s GDPR and California’s CPPA, established regulations like HIPPA, Sarbanes Oxley as well as industry standards like PCI-DSS do not mesh well with fast-and-risky.
Heavily regulated industries, like financial services and healthcare, simply won’t get past auditors, while companies in other sectors risk post-breach lawsuits, and the specter of plaintiff attorneys pointing out how they failed to meet general best practices. Companies attuned to this exposure are having to go “safe-and-slow,” Sethi says, and forego the vaunted speed and agility and DevOps.
Security Compass’ mission is to help bridge that gap. It does this by essentially feeding privacy-by-design and security-by-design best practices into the swiftly moving, iterative software development processes of today. Here’s how Sethi describes what Security Compass brings to the table:
“These proactive processes tend to follow a pretty standard workflow, in which a set of experts goes and gathers information about some software that they’re building. They analyze that information, come up with some recommendations and build a prototype that does certain things. They then they track it and report on it.
“We automate that whole process. We automate the information gathering, we automated the generation and integration of recommendations into the development process, and we automate tracking things in the ticketing systems that the developers use.
“We integrate security into the reactive processes companies use. So, for instance, you may have had a security best practice that you needed to follow. We can check whether or not a scanner looked for it, and whether the scanner found an issue or not. So we’re essentially taking all of your proactive processes, automating significant portions of them and integrating security best practices, so you can continue develop quickly, but you no longer are neglecting security-by-design principles.”
Security Compass is seeking to greatly enhance, and not necessarily replace DevSecOps, Sethi told me. Reactive testing will continue to have an important role to play. “We really want to help with getting products out to the market fast, but in a responsible way,” he says.
Makes sense. I’ll keep watch.
Acohido
Pulitzer Prize-winning business journalist Byron V. Acohido is dedicated to fostering public awareness about how to make the Internet as private and secure as it ought to be.
(LW provides consulting services to the vendors we cover.)
