The way we identify, prioritize, and mitigate software vulnerabilities was built in reverse order. Why did it happen? How can we make things different?
What are we trying to solve with vulnerability management products?
Well, when it comes to software vulnerabilities, the problem is simple: there’s a vulnerable piece of code running somewhere in your organization. We need to find it and mitigate it.
There are 3 types of security vulnerabilities that build the organizational threat landscape:
- Source code weaknesses - application security problems that exist in APIs or web apps developed by the business either to provide external or internal functionality. These kind of threats can be remediated using code changes, open-source libraries upgrades, and remote deployments.
- Binary level vulnerabilities - a compiled software you have installed on your endpoints, data centers, IoT devices, etc. There's no way to access the code behind those apps, so the only mitigation strategies are software and firmware upgrades, patching, and software retirement.
- Configuration problems - the last piece in the organizational attack surface is the wrongly configured assets and software (basically the wires that connect the devices and the software beneath it). Often times it's certain components that were left activated for no reason. (For example, the WannaCry ransomware vulnerability, attacking devices with ancient Microsoft Windows shared folders interface open mostly for no reason.)
The main purpose of vulnerability detection is to keep the cybersecurity and IT teams informed about their security posture and to fix problems as fast as possible.
How does the process look and why?
Nowadays, the process of tracking and remediating vulnerabilities is divided between 3-4 different security measures and between the security and IT teams.
1 - Vulnerability assessment tools
the industry standard is to have a network security tool that scans a given subnet for security issues. Those scans are performed in an on-demand manner and require the scanned assets to be online when it happens.
Why are we doing it? Who's in charge?
Network security tools are much easier to integrate than agents, for example, the more bold reason is that from the vendor side it's easier to sell and maintain something which doesn't sit on the end-user device or server. In times where the infrastructure is very simple - no WFH, only local networks, no cloud providers - a vulnerability scanner is a solid choice.
The team in charge - Security!
2 - Vulnerability prioritization tools
So we just fetched a huge list of vulnerabilities from our scanner. Now our CISO is completely depressed. Well done scanner! Prioritization tools, aka RBVM (Risk-Based Vulnerability Management), narrow down the number of handled vulnerabilities and removes stress from the never-ending battle between IT, who wants things to be quiet, and security, who wants things to be patched (and as an unwanted outcome, shakier). RBVM tools usually aggregate data from the scanner and some other sources to try and make sense of the vulnerability chaos.
Why are we doing it? Who's in charge?
In a perfect world, we probably wouldn't prioritize vulnerabilities. The holistic solution would be to patch and fix everything. Sadly, the current management tools and security controls are far from being effective, so the main reason to prioritize threats is to reduce (reduce, not eliminate) the tension between the security team and the IT team.
The team in charge - Security!
3 - Patch management, configuration systems, and code changes
So, we scanned for vulnerabilities and prioritized them. Remediation time is here! Depending on the nature of the threat, the remediation paths can be either sending it back to the R&D team for review, changing firewall configuration, or upgrading software versions.
The team in charge - the team in charge of the last (traditional) part of the vulnerabilities lifecycle is surprisingly not the information security team but the IT!
4 - Orchestration platforms
As if the process is not messy enough, there's another management component to make it even messier! The last, and somehow most advanced, part of the vulnerability remediation hassle are the platforms that connect all of the products we previously discussed with connector APIs and "push the buttons" for you rather than managing three different dashboards.
The team in charge - Security & IT!
The Good, the Bad, and the Ugly
The Bad
60% of the attacks involved unpatched vulnerabilities. Despite all of the spending, products, labor, and sweat, the vulnerability management processes still don't work. Malware, data breach, brand damage, and much more - they all start with the vulnerability that was pushed to line 11 when we decided to mitigate only the top 10. It's that user who forgets his VPN is open while he runs a vulnerable SMB with the wrong port open. It leads to many angry stakeholders, and the CEO to lose his job. As far as vulnerability tracking, the devil is in the detail.
The Ugly
The way we're discovering and mitigating software vulnerabilities was not built with the basic notion of, "I have a piece of vulnerable code running somewhere, and I'm going to mitigate it". It was built around two things:
1. Simple network architecture that was commonly used 10-15 years ago. With it, all the devices connect to an internal network; no cloud services, no remote devices, no COVID.
2. No innovation introduced as companies in this field became too profitable. Network vulnerability scanning companies generate $6.1B a year! Why move to a more robust, agent-based architecture when you have this magnificent money machine?
The Good
Like most of the fields in IT and security, the massive growth in SaaS services and the increased attack surface made it mandatory to add automation and AI to almost any business process. With 300 newly discovered vulnerabilities every week, startups that are looking to disrupt the vulnerability management process are on the rise. The change is imminent!
A Path for Vulnerability Remediation Automation
To conclude, the solutions to the challenges of automated vulnerability remediation are the following:
1. Consolidation
When you have 3-4 products that don't speak the same language, it's hard to understand the threat landscape and the mitigation paths. When it comes to vulnerability remediation, we need to remove management overhead as much as we can. And in that case, we need to have consolidation over orchestration.
2. Immediate feedback and responsibility
In a fast-paced world where threats and the digital landscape are changing almost every second, on-demand scanning is no longer effective. We need a real-time, risk-based, and metric-based tool that will inform us about threats, tell us when and how they are mitigated, and help us understand the impact of different mitigation paths we should or shouldn't take.
3. Proactivity over reactivity
The vulnerability discovery process in the public domain is completely reactive. One needs to discover a weakness, validate it with NVD, and only after a few months of grace for the vendor to release a fix does the customer become aware of it (aware doesn't mean he detected it on his assets). It's not enough to sharpen and automate the traditional vulnerability tracking process. We also need to explore ways to proactively look for vulnerabilities even before they become known to the world (we had a good webinar about it) and mitigate them on the spot, without waiting for the vendor's next version release (another interesting webinar). It's time for our security services and toolkits to get an update—not just the vulnerable software.
I invite you to join our journey @ Vicarius to change the world of Vulnerability Management. Feel free to contact me with any questions on my LinkedIn account or email.
LIVE! On Security Weekly
The boys join Paul for a rootin' tootin' good time!
