In cybersecurity, there are three essential measurements every CISO tracks: coverage, time to remediate, and ROI. As a CISO, the pressure to show your board that your decisions and investments positively affect these measurements is so immense that a quarter of all CISOs only lasts a year in the role. Let’s look at each of these to understand why the pressure is so high and how we can address them.
Coverage today: Plugging holes in multiple dams
Using your finger to plug a leak in a dam is a metaphor for what CISOs face daily. The difference is that CISOs are not responsible for just one hole but hundreds to thousands.
Since large organizations are now leveraging approximately 175 applications, how is the security team supposed to be able to protect every one of them? Quite simply, they believe they can’t, so they focus most of their attention on the highest-risk applications. The organization then considers the other applications that don’t receive special attention as lower risk. Any protection is minimal, such as a WAF that scans only for specifics already listed in RegEx.
That said, higher-risk applications don’t get off the hook. Rapidly changing codebases generate new vulnerabilities. Like a house of cards, each time a new vulnerability appears, it requires more changes, continuing the cycle. This frustrating part of the process is due to an increased rate of deployments. 83% of security professionals experience an increase in security regressions. Looking at the analogy, this is akin to them plugging the same leaks in the dam repeatedly. That is not an effective use of time and effort for anyone.
Coverage alternative: One-to-many
In taking a declarative approach with Security-as-Code, CISOs can free up additional resources traditionally tasked with managing only the highest risk applications to expand security to all applications in their network. The Security-as-Code process leverages machine-readable definition files, using high-level descriptive coding to apply immutable and continuous security behavior. This approach focuses on fixing the code at the code layer. The cost to run it hardware-wise is almost nonexistent. By drastically reducing the reliance on human intervention, Security-as-Code grants security teams autonomy while allowing engineers to focus on development rather than vulnerability remediation. Do it once, do it well and make it so for all.
Time to remediate: We’re still working on it
Only 10% of vulnerabilities are remediated each month. That metric is a recipe for disaster in a world of ever-expanding threats and newly discovered vulnerabilities. Look at Log4J as a typical example, although it received arguably way more coverage than your average vulnerability. Despite debuting in December 2020, if you Google the term “Log4J vulnerability” under the news tab, you will see just how much coverage it is still getting. Yet despite all the hype, articles were published a full four months after the discovery stating that thousands of applications were still vulnerable. Why is that? The reasons are multiple, but the main ones relate to the ability to discover the vulnerabilities and the need for staff/resources to address them. It is not an easy fix today, but could it be?
Time to remediate: Immediate with runtime protection
The irony with declarative security for instant remediation of vulnerabilities is that you don’t even need to know if you have any of those vulnerabilities in your network. You can apply policies to address the OWASP Top 10 and SANS 25 CWEs. The policy kicks in and fixes any vulnerabilities discovered. If we think back to the analogy earlier about plugging a hole in a dam, leveraging this Security-as-Code approach means you no longer need to look for and patch any cracks in the dam. Instead the dam plugs intself instantly and continuously before a drop of water has a chance to drop. CISOs now show auditors and their company board of directors that they have checked that box to apply necessary policies to address known vulnerabilities like Log4J and unknown vulnerabilities.
ROI: How long until we see it?
Many decisions circle back to the budget. Cyber security is a double-edged sword because, in some ways, it’s a necessity for doing business. On the other hand, some begrudgingly view it as sunken costs you will never see again. Knowing this, smart CISOs began calculating ROI, sometimes referred to as “RISO” in the security space (Return On Security Investment), to show value in their budget spending. While this helped justify their requests, CISOs still faced questions on how long it would take to get operational to claim that ROI. The average time to deploy a SIEM solution is over six months. So the pressure on CISOs is not only to show a favorable ROI but also to show the board that what they have spent their budget on is fully operational.
ROI: We’re already seeing it!
Multiple factors come into play when calculating the ROI on a Security as Code investment. Aside from the standard risk reduction you receive from almost any security investment, Security-as-Code increases that factor by removing the requirement to fix the vulnerabilities discovered manually. Security-as-Code (SaC) is not an approach where your investment acts only as an alarm for your team to respond. It actually remediates vulnerabilities in running applications with 100% accuracy. Security-as-Code fully deploys in hours instead of weeks or months. Companies leveraging SaC experience a lower impact in the case of a breach since rules deploy instantaneously without redeployment.
Be prepared
The bottom line is that every CISO knows it’s impossible to fully protected against every possible scenario 100% of the time. It’s not realistic. Things change, new risks emerge, and most importantly, our employees are all human beings. But we can do as much as possible to plan for the worst and hope for the best. The Security-as-Code approach lowers risk and helps prepare for that next board meeting.
