3 KPIs Most Important To Your Vulnerability Scanning Program
Out of all the infrastructure you have, what percentage is actually getting scanned? Many security teams take this for granted that they have 100% scan coverage. In reality, there are often new servers, instances, even AWS accounts and Azure subscriptions that security teams are not aware of. Top reasons for poor scan coverage are:
- Scannable inventory is entered manually into a tool like Nessus or Qualys and is not up to date. This issue is particularly painful for those with high inventory turn overs such as auto-scaled workloads and spot instances.
- Scanning solution cannot reach the host but at least knows about its existance. This happens due to disconnected networks, firewall rules, and poor VPC configuration.
- Cloud provider has blocked scanner for violating terms of service. This happens when you do not file proper paperwork with AWS, Azure or GCE.
- End-User has uninstalled scanning agent or scanning agents is in degraded health.
A CMDB like Cloudaware reconciles your infrastructure inventory with your scan results from multiple data sources and can show you which servers have not been scanned.
OK! Say you got to 95% scan coverage, what now? Odds are your developers are pushing new code close to every day that means your vulnerability profiles change every day too. What about scanning. There are two reasons to scan frquently:
- Economical. You’ve paid for the licenses for the full year. Use them. Run those scanners as often as you can without disrupting application health.
- Security. Your vulnerability profile changes all the time. That means scans must be frequently as well.
Cloudaware CMDB for example tracks the number of days each infrastructure endpoint has NOT been scanned so you get your finger on the pulse of how frquently you’re scanning.
OK! Say you got to 95% scan coverage, scan age under 14 days. Beautiful! But you’re not any more secure technically speaking. Third KPI is how fast your teams are actually remediating the issues.
Cloudaware Threat Center consumes data from Whitehat, Nessus, Qualys, Nexpose and TrendMicro to not only build a unified view of vulnerabilities but also measure the speed with which teams are addressing those vulnerabilities.