DevSecOps: A More Deterministic Approach

is security an inhibitor to devops agility?

to answer this question we would need to take a quick look at differences between devops, qa, and security when it comes to automation issues.

for those of us who have been involved on the frontlines of traditional appsec activities such as penetration testing, and dynamic or static code analysis, it may be obvious that the traditional tools and techniques we use were built more for waterfall-native rather than devops-native environments. yet for executives who came to security from infrastructure, networking, or development domains, and have never run a security scan, the challenges of bringing traditional toolsets and practices into the new velocity expectations of devsecops may not be so obvious.

today, it is common for many security executives to come from non-security domains -- in large part due to the shortage of security professionals. to understand the differences between the domains, we should first take a look at outcomes and measures of traditional security compared to other work. with this understanding, we can foster more empathy and then work on improving collaboration between the domains.

one key difference between devops, qa, and security is that the first two are very much deterministic, while the latter is not. for security professionals, traditional approaches to determining risks or recommending directions to mitigate risks often require human decisions rather than machine-based actions.

the picture below helps to illustrate this point:

in the case of architecture review and threat modeling, which are two other important appsec activities that are often required by compliance standards such as soc 2, hipaa or pci, it becomes even more non-deterministic, because the results of the analysis could be absolutely unpredictable and very much determined by an assessor’s background.

needless to say that automation is nowhere close to this type of activity. the best we can do here is to get rid of unnecessary complexity, pseudo-scientific approaches to evaluating risks (e.g. dread), and describe the threats in a simple threat table with severities that everybody would easily understand, i.e. "low", "medium", "high".

not understanding this simple truth leads to euphoria and to setting up wrong expectations. for example, a ciso who came from the networking domain might say that a good networking appliance is all that is needed to completely automate security, while a ciso with a developer’s background might say that writing a lot of code will make security operate at devops-native speeds. while both approaches may help accelerate more deterministic forms of security checks, relying on these approaches alone will introduce blind spots where humans are best suited to make the right decisions. for those ciso’s who solely rely on deterministic approaches to security, their tenure may be cut short when their ceo or cto understands that their promises to completely automate security will never materialize.

does it mean that there is nothing we can do to automate security and make it faster? of course not. as security engineers, we can and we should look for new ways to benefit from automation and more deterministic security approaches. these concepts are not new and have been catching on in recent years. personally, i’ve been talking about these practices for almost three years by now: first at lascon 2015 , “how traditional appsec needs to change,” then at appseccali 2016 , “making security agile,” and just recently at rsa 2017 devops , “getting security up to speed.”

information security has the opportunity to be less of an inhibitor to devops practices when the right approach is taken. that said, we should always take into consideration the non-deterministic nature of some necessary security practices and set the expectations right when talking to executives.

the bottom line, security is seen as an inhibitor to devops' agility because it is an inhibitor in many ways. humans efforts cannot always be automated, but there are opportunities to improve it by researching new approaches. in this regard, my big hope is that we’ll see a deeper penetration of ai and machine learning into the security domain. it won’t be easy, but the progress in the intrusion detection systems/intrusion prevention systems (ids/ips) space makes me think that it will eventually help automating traditional appsec activities as well.

want to learn more about devsecops?

this blog is one of seven in a series providing expert commentary and analysis on the results from sonatype’s 2017 devsecops community survey. for access to all of the blogs in this series and the survey report, please visit www.sonatype.com/2017survey .