General rule of thumb for KPI and reporting
See the page SLA / KPI for real examples
Use accepted levels
Work with the client and agree at accepted levels. Then report how the numbers compare to this. This is much better to find a good level and measure if the company do to much or less.
The accepted levels can be Risk level (ex. TruRisk), time to patch specific type of vulnerabilities, exposure time etc.
Use trends
In many cases a number alone is hard to evaluate. But if the trend are visible its easier to evaluate if the general trend are good or bad
Use TruRisk
Qualys TruRisk number include many great factors in one number and are in general a really good number to work around.
Focus on a score per asset
Report a number per system, or per system per group. In this way it's easier to see how the trend goes. This eliminate the problem related to counting number of vulnerabilities - where the number of assets otherwise will impact number of vulnerabilities.
If Qualys are used, the TruRisk score per asset is a meaningful number. This includes enough factors to alone tell the state of security of the asset. This number is the most relevant to use. And focus on trends
Use system criticality - even if they do not exist
It should be normal to consider the criticality of the asset when prioritizing. This is obvious. but often client dont have the system criticality.
But see if you can create a system criticality anyway. You might know the important systems/functions - see Crown Jewel definition at google.
And then add the following as higher criticality:
Valdemar is working on a dashboard that can be imported and serve as first overlay on client to show how we suggest to prioritize
More critical:
-
AD / identity systems
- Access management systems, like VPN concentrators
- Security devices/systems that has the function to manage/protect the environments
- Virtualization platform management
- Internet facing systems
- Systems holding important/critical company or client data, ex. Database servers
- Workstations belonging to users with broad admin privilegies
- Workstations used by developers (often more sw, old libraries and more access)
- Backup servers
Less critical:
- Test systems without live data
Don't count number of vulnerabilities
I's not a meaningful number. We are trying to get client to overcome a huge burden of vulnerabilities by only patching the relevant ones. So we would in general be ok with a large number open or no change. This also goes if selecting only high+critical as example.
The number of vulnerabilities will also fluctuate wits the full number of assets - and with the #days after patch Tuesday.
Don't use CVSS Score
The CVSS score are in general wrong about the criticality of a vulnerability. Often this is example the ability to exploit the vulnerability. And as a result way too many vulnerabilities are scored too high. Tenable created a study in 2020 ago that concluded that IT would waste 76% of their time by using a CVSS 7+ rating and at the same time missing 44% risky vulnerabilities. Everything is about focusing on vulnerabilities that have exploit available or will most likely get. For Qualys the QDS score will include those factors. Tenable call it VPR. If no systems, at least consider adding the CISA known exploit rating and/or the EPSS score.
Dont mess up scores that measure the current security/risk and scores that are operational efficiency
Be mindfuld what you report. Some numbers like time to patch are mostly to determine if the operation works ok and does not tell anything about the security. Where others only are the current state of security.
Those numbers often has different stakeholders. A operational team should mostly be measures on how fast the patch the vulnerabilities assigned, where security mostly should be measure if the risk are at an acceptable level (and the trend)