What would you expect to see when confronted with a vulnerability in a vulnerability management service? The answers vary of course. However, there are fundamental data and knowledge that shouldn’t be missed when representing a vulnerability;
- The vulnerability name
- Generic knowledge defining the vulnerability category in detail
- The severity of the vulnerability
- The asset that has the vulnerability
- Specific details of the vulnerability that shows the way to exploit or retest (though much of the time especially developers use this piece to write black lists, unfortunate)
- Helpful mitigation techniques
- Current status of the vulnerability. Is it open or closed or in a status of recheck?
Ok, these are the defaults. What else?
- A risk score using severity of the vulnerability and the priority of the related asset. The sole severity of a vulnerability doesn’t show its risk. That’s infosec 101.
- Who is responsible to fix the vulnerability? This is really helpful if you don’t have the expertise to multiplex a security bug to the right authority.
- The SLA mitigation period of the vulnerability compared to other vulnerabilities with the same severity.
- The assets that have the same vulnerability category.
- The history of the actions applied to this vulnerability from the very beginning.
With the data comes the knowledge and it’s important to show it eminently.