Virtualization Technology News and Information
Article
RSS
VMblog's Expert Interviews: Chef Talks Compliance Assessment and Remediation Survey Results

interview-chef-survey 

Chef recently fielded a survey to learn more about security, developer and operations team dynamics around compliance assessment and remediation. VMblog spoke with Julian Dunn, director of product marketing at Chef, to learn more about the findings.

VMblog:  Why do a survey on compliance?

Julian Dunn:  Earlier last year, we commissioned a survey focused on how cross-functional teams manage speed, efficiency and risk. You can view our report on the findings here. There was one finding in particular that we wanted to dig into more - that compliance automation presents a large opportunity for efficiency gains. So, we conducted a second survey to determine practitioners' top concerns, team behaviors and implementation practices, specifically around compliance assessment and remediation. 

VMblog:  What were the most important findings from the survey?

Dunn:  The biggest finding is that most organizations haven't automated compliance processes - and frankly that many organizations still need to learn to do them properly. This was something that Chef already knew (it's why we built InSpec!), but the ubiquity of this pattern was surprising. To cite from the survey: 

Prior to reaching production, most teams (74 percent) assess software for compliance manually. Once violations and vulnerabilities are discovered, half of respondents still remediate manually instead of automating the process.

Compliance is an important component to software development workflow. It affects everyone - developers, operators and security professionals - and every application that an organization supports. Everyone knows it's important. And yet it's getting left behind. People are still using only scanners or having people comb through systems and applications manually.

The alarming thing about this is that poor processes affect how quickly organizations can remediate vulnerabilities. Our survey showed that application and infrastructure teams need days (31 percent) or weeks (19 percent) to remediate security issues once they have been detected. Only 18 percent of respondents remediated in hours.

Think about the implications of those percentages for things for something like Spectre or Meltdown. It has been a month since those vulnerabilities were revealed. If 19 percent of application and infrastructure teams need weeks to remediate vulnerabilities, that means that organizations are only just finishing fixing issues related to those breaches now. And because Intel, Microsoft and others tell us there will be more patches to come, organizations that don't have automated processes for vulnerability detection and patch application may simply forget to fix some issues.

VMblog:  So why do you think organizations still manually assess for compliance?  Do teams not view compliance as important?

Dunn:  Compliance assessment and remediation is one of the key problems that surface as companies adopt DevOps. If it's done manually after the rest of the software development process has become automated, it becomes the thing that slows everyone down, causing tension within developers and operators. Organizations find themselves choosing between delivering software quickly or being compliant with regulation. No CTO wants a data breach, let alone one where the exploited vulnerability was several weeks old, but they also have a mandate to innovate quickly. It's a tough spot to be in and compliance often gets ignored or overridden by the business demands.

For this to change, a couple of shifts need to occur. First, governments need to understand technology better and put more helpful regulations in place. Our customers often have to push back on auditors who expect them to comply with regulation that doesn't make any sense for their environment. This happens because the regulations in place are often vague or unhelpful - so there is work to do at the government level to mandate the appropriate things from organizations. Thankfully, we are seeing this pain point improve as more government representatives become educated about infrastructure and cloud technologies.

Second, security teams need to start viewing themselves as part of the DevOps process. (Many people are terming this evolution "DevSecOps.") Right now they operate as a separate team, and this can create hiccups in workflow. Developers and operators find themselves getting pulled into meetings and arguing with their security teams about the various policies in place. If security teams can become more engrained into the DevOps process, they will be able to start to speak the same language as developers and write policies that make sense for the whole team rather than throwing scan reports over the wall that often contain false positives.

And finally, to my point above: teams need to automate compliance like they have automated DevOps. Compliance assessment needs to move faster or else it will drag everything down.

VMblog:  What other findings surprised you?

Dunn:  To me, the most surprising finding was that the number of people that think they are subject to regulatory controls seemed to be proportional to how many servers they run. This has zero bearing in reality. If you are processing credit card information, regulators don't care how many servers you have. You are still subject to PCI/DSS. To me, this showed just how poor processes lead to compliance being deprioritized or ignored.

VMblog:  Any closing thoughts you'd like to share with readers?

Dunn:  We talked a lot about how automation can solve some of the problems associated with compliance. At Chef, we've encapsulated our beliefs about security & compliance into InSpec, an open-source language for writing and assessing compliance. Using InSpec with Chef Automate enables teams to detect and correct issues continuously, both on premises and in the cloud. Anyone interested in learning more about that may want to check out a webinar we're doing around automating compliance with AWS OpsWorks for Chef Automate. 

##

Published Monday, February 12, 2018 7:31 AM by David Marshall
Filed under: ,
Comments
There are no comments for this post.
To post a comment, you must be a registered user. Registration is free and easy! Sign up now!
Calendar
<February 2018>
SuMoTuWeThFrSa
28293031123
45678910
11121314151617
18192021222324
25262728123
45678910