We are constantly updating and evolving our deliverables in an effort to provide more context around our security services. With that in mind we have been tracking some metrics since 2020 that allow us to see why organizations remain vulnerable to compromise. One of the metrics we’ve been working on tracking the past few years is something called security debt. We define security debt as the age of the vulnerabilities that are present on your network(s). Knowing how old your vulnerabilities are is easy to track and will inform your decision making and future planning regarding cyber security. This is accomplished by being able to see what type of older vulnerabilities are being deployed (hint, it’s not usually missing patches anymore).
Let’s say you deploy a new device in 2022, nice new hardware and a fresh install of whatever platform is needed to support the use case for which it was purchased. If this device was using secure sockets layer (SSL) version 2 or 3 then it was deployed with a vulnerability that is over 6,100 days old. That’s 6,100 days to develop working exploits; the longer a vulnerability has been published, the longer the bad guys have to develop ways to take advantage of it. SSL V2/3 would also be a CVSS 10, or critical severity rating, and is also not commonly used for attackers to gain a foothold; This severity rating would also be a factor in regulatory compliance. A better example of an old vulnerability that is more commonly leveraged is SMB signing not required. This vulnerability is a 5.0 medium according to CVSS and would typically fall beneath the threshold for compliance (internal) and may possibly get overlooked in your vulnerability scans while you focus on critical and high severity vulnerabilities. The SMB vulnerability is also the second most common vulnerability our team exploits to gain a foothold during a penetration test and is over 3,800 days old. How are vulnerabilities over 10 years old that are commonly exploited getting on modern networks?
The simple answer is that organizations have become so focused on doing patching well that deploying hardened configurations has not gotten the attention it deserves. We track this in a remediation category called “configuration management”; categorizing the vulnerabilities helps an organization see where they are doing well and where they need improvement. It also lets you know where to best put resources like time, money, training, and equipment. While patches can also be a source of security debt, it is poor configurations being deployed that is the biggest problem in today’s networks. The graphic below shows aggregated data from the year 2020 and it’s quite evident that misconfigurations lead the way in vulnerabilities present.
Our penetration testing and risk assessments over the past 10 years are showing that the process management around patching and upgrades is largely successful in our clients. When we do find a missing patch they are also usually from 2017 or older which does contribute to your security debt. We still encounter unpatched systems, but it is no longer the primary vector where our teams gain a foothold or find a compliance deviation. Learning to deploy assets with hardened configurations will help reduce the organization’s security debt by eliminating old vulnerabilities from being present. Accomplishing this involves developing a process, selecting tools, and regularly checking for misconfigurations in your environment. If you could reduce your average security debt age to under 90 days that would mean your organization is not deploying old vulnerabilities and is keeping on top of new vulnerabilities as they are being revealed. Getting at least the critical and highs under control would be a great start.
The process will need to include identifying what services are needed for your business case, disabling services that are not needed, configuring specific software (E.G. HTTP servers) to use only secure services and ciphers, and regularly checking for updates needed internally for your use cases. Check https://www.cisecurity.org/cis-benchmarks/ where you can find suggestions for hardening most IT platforms. These will be a great start in developing a hardened configuration for deployment; once you have your “gold” configuration you can deploy a technology like Acronis Snap Deploy (https://www.acronis.com/en-us/products/snap-deploy/) or Macrium Reflect (https://www.macrium.com/reflectfree) that can rapidly deploy this configuration to the target devices.
To sum up, if you’re like the typical environments we see, you’re probably deploying old vulnerabilities on your networks and you’re probably doing a good job of patching. Regardless of the commons statistics it will benefit your organization to develop processes that remove old vulnerabilities from being deployed in your environment. Part of the process is learning how much security debt you have then developing a plan to reduce that debt. Once the plan has been agreed on, testing it in a sand box or small network segment will let you know if you’re on the right track. If that is successful you can roll it out to all networks and start reducing security debt.
Recent Comments