My next class:
Security Culture for LeadersAmsterdamOct 7th - Oct 11th 2024

An Approach to Vulnerability Management

Published: 2016-06-23. Last Updated: 2016-06-23 23:44:25 UTC
by Russell Eubanks (Version: 1)
13 comment(s)

No need to do anything to make your auditor happy than to purchase the most popular scanning tool
 
No need to worry, when the scan is over and the report has been produced - you are all done
 
No need to ever leave your cube and speak directly with your system administrators
 
No need to ever test the scanner on a non-production network in advance
 
No need to worry, a clean scan means you are both compliant and secure
 
No need to ever leave your cube and speak directly with your application developers
 
No need to ever let anyone know when your scan starts, after all an attacker is not going to do that so why should you
 
No need to worry, if something becomes unavailable during a scan it is totally not your problem
 
 
No need to show good stewardship after the purchase by producing metrics such as the percentage of findings that have been fixed as a percentage of all the findings
 
No need to seek data that demonstrates your scanner could serve as a platform to improve your security posture
 
No need to keep your boss informed of your progress, s/he would not understand 
 
No need to divert any of your time from finding things to fixing things
 
No need to ever think that your scanning tool is every anything but spot on accurate
 
No need to hold back, it would be great if you shared your Vulnerability Management “best practices" in our comments section below
 
 
Russell Eubanks
13 comment(s)
My next class:
Security Culture for LeadersAmsterdamOct 7th - Oct 11th 2024

Comments

Here's how I'm doing it:
- scan time is agreed by sysadmins (day of week, not friday, and time window)
- scan runs weekly, a report is sent to the sysadmins directly with all details
- expectations: don't solve everything (it's not possible), but focus on one most important finding (be it a host or a vulnerability). If they solve something every week, that's already a huge success.
- expectation 2: do not solve things right away, but at least provide feedback that flows back into the next report:
a) false positive
b) mitigation planned (but it will take x weeks to implement)
c) risk accepted (not relevant in context, or work as designed)
d) risk accepted (no mitigation planned)
- If I'm not happy with the provided feedback, it goes to (business) risk management. Business has to provide ressources to solve the issues -> "get out of jail" card for the sysadmins
- Monthly KPI to management to show progress and feedback status. If red, management has to discuss with team to understand why they can't progress (ressource, priority, etc...)
No need, you pretty much nailed it. The question that needs answered is "why" the vulnerability scanner was bought.

If it was for audit and compliance, particularly if it was the result of an audit finding, just accept all of the risks, collect your paycheck and press on. Heck, you're probably on salary exempt status so you get paid the same amount whether you're working or not, right?

You will have far less stress in your life, you will cause far less stress in others and your performance reviews will be great because you get along with everyone. Heck, you might even get a raise for doing nothing but closing audit findings quickly!

(I really love audit findings because I can spend lots of unbudgeted money without really having to do much. Just make excuses and push the deadline out on the hard ones that require someone else to act. You know, because they're so busy.)
Steph,

You had several great ideas. I especially like the

designated time to scan

recognizing there is not a quick and one time fix

My favorite for sure is to take a risk based approach

Thanks for supporting the ISC!
Russell
Interesting observation - "you will have far less stress in your life, you will cause far less stress in others".

If only for compliance reasons, I suppose just having and never using a scanner could be adequate and would certainly never threaten your relationship with others, since that type of Vulnerability Management program would never make them look bad or disrupt their respective systems.

Russell
Steph's comments are very interesting and it's an interesting topic in general.

Setting the expectations of "don't solve everything (it's not possible)" and "do not solve things right away, but at least provide feedback that flows back into the next report" are excellent.

I've (unfortunately) been in organisations where an automated scanner has been used. The issues are sent to the admin teams with instructions of "we need everything fixed within 1 week!". Panic sets in. People do silly things, let process and procedure slip. Potentially causing more harm. I've even seen admin teams sweeping the issues under the carpet, turning off a service or firewalling something temporarily whilst another scan is completed and the team running the scan is simply looking for a tick in the box, then turning the service back on whilst backs are turned.

Collaboration. Collaboration. Collaboration. Personally I think that's key to vulnerability management.
DR,

I agree - successful Vulnerability Management requires a long term view that ideally show improved progress over time.

Thanks for supporting the ISC
Russell
Several great comments and observations so far on the topic of Vulnerability Management - keep them coming in!

No need to discredit any organization, rather by adding to the conversation we can all learn from each other in the discipline of Vulnerability Management.

Russell
No need to prioritize remediation
No need to do a risk assessment of each detected vulnerability
No need to second-guess your scanner's vulnerability rating
No need to model realistic threats to your organization
No need to tune defenses to match current vulnerabilities
PhilBAR,

Very excellent additions to our list. My favorite is "No need to second-guess your scanner's vulnerability rating". As much as we depend on our scanning vendors, it is up to us as security practitioners to adapt and adjust the tool to our respective environments.

Thanks for supporting the ISC!
Russell
A bit of a generic reply, but try and get your sysadmin team some security training. Too often I've seen sysadmins and security butting heads because they're so focused in their own fields that they don't know how to cross-talk or how the other side does things. A lot of sysadmins don't understand how CVEs and impact ratings work, and a lot of security guys don't understand what backporting is.

I suppose I have a more unique viewpoint due to working both sides of the field.

Diary Archives