10 Rules for Vulnerability Management
Rules for Vulnerability Management
Below is a list of items and requirements based on client discussions in the case of delivering decent vulnerability management to clients both big and small.
From Visibility to API integration, from Validation to Developer support the items below are what you should consider when deploying a vulnerability management program.
1. Coverage is king, Both depth, Breadth and Frequency. Both authenticated and public.
2. Full stack vulnerability intelligence is key as "Hackers don't give a Shit" where your vulnerability is at.
2. Keeping pace with development. As change occurs, vulnerability management should detect and assess the changes. DevSecOps / Development pipeline Integration is required.
3. False Positives are an evil waste of time even if handled by automation. - Validation is important.
4. False Negatives are evil-er. - Scanner tuning is important so we don't miss anything.
5. Situational Awareness is required. Alerting and custom events are key to knowing what matters & when.
6. API's are expected and required so we can automate, invoke, integrate & consume
7. Visibility is key - Asset profiling is paramount. Whats my attack surface?
8. Developer support is paramount. Vulnerability management is as much about mitigation as it is discovery.
9. Vulnerability Metrics are required to help improvement: Peer relativity, Time-to-fix, Vulnerabilities by type, layer, risk are all important.
10. Asset Categorization, Tagging, Vulnerability Risk Acceptance and Retesting on demand are required.
Comments
Post a Comment