DevOps Security Tools for Enterprise DevSecOps Teams
This blog was originally published by Vulcan Cyber here.
Written by Rhett Glauser, Vulcan Cyber.
DevOps has revolutionized the pace at which new iterations of applications are released to meet the needs of customers. By nature, security teams are focused on securing company assets and data, which others may see as a roadblock to productivity. The tension between these two groups can sometimes be palpable.
Both teams play important roles, and eliminating the friction between them can only benefit the organization as a whole. Let’s take a look at four tips that can help reduce the friction between DevOps and security.
Align business and security needs with SLAs and policies.
Vulnerabilities should be grouped by vulnerability type, severity level, and affected systems. Each grouping should have an SLA and policy attached to it. The SLA determines how quickly the vulnerability needs to be addressed, while the policy dictates what actions are needed and which teams need to act. By having predetermined SLAs and policies to go by, both security and DevOps teams will have a clear framework to follow. The shared understanding allows for both teams to work off the same set of response standards to meet expectations and is a practical tool to evaluate the urgency of security versus development.
Speak the same language as the DevOps team.
Breaking down security vulnerabilities and CVEs into language and terms that are clear to the Ops team goes a long way into reducing friction. Rather than providing a list of CVEs to be remediated, security teams should provide context of each CVE that meets remediation criteria. Remember, you can’t expect DevOps to prioritize security on their own. Their job is development, yours is security. Approach any security issue from their point of view. This means that security teams ought to conduct prior research on how to solve the vulnerabilities effectively and try to supply the solution that will resolve the problem. You can start looking for these solutions by checking out different solutions at different vendor repositories, as well as tech forums like GitHub and StackOverflow.
Not all vulnerabilities need to be fixed.
The number of vulnerabilities that are released each month is staggering and can be overwhelming. Last year, on average, about 58 critical or high vulnerabilities were found each week. As Zane Lackey points out, “every development methodology that we’ve ever had is gonna have vulnerabilities, bugs are functionally infinite, we’re always going to have them. Systems that rely on saying, ‘let’s eliminate all the bugs’ are not a reality.”
With so many vulnerabilities to deal with, it’s important to prioritize risk based on criticality and exploitability. It’s also helpful to define criteria to determine the value of each platform as critical, medium, or low. Embracing this methodology will lead security teams to bring up the most relevant vulnerabilities and enable DevOps to focus on the ones that truly threaten your environment.
Once the DevOps teams begin to see the efforts made by security teams to only bring relevant vulnerabilities it will build a foundation of trust and appreciation for the value of time and effort between the groups.
Show trends and benchmarks
The ability to measure and demonstrate how security risks change over time is crucial to showing the value security brings to the organization as a whole. The ability to compare an organization’s cyber efforts with peers is also important. Measuring against a set of peer benchmark data opens dialog and discussions about where improvements can be made and as well as where the security process is strong. Benchmarking can provide answers to questions like, ‘Where are we exposed?’ and ‘How effective have we been in reducing exposure over time?’. Just as the security team learns to speak the DevOps language, presenting the industry benchmarks to DevOps allows them to better understand the security component.
About the Author
Rhett has been running corporate marketing and demand generation functions in the enterprise infrastructure and security markets for a really long time. Prior to Vulcan Cyber Rhett spent more than two decades with SaltStack, ServiceNow, Symantec and Altiris.
Sign up to receive CSA's latest blogs
This list receives 1-2 emails a month.