Vulnerability Management Program/Strategy

[d46j48fx]

Hi community! 

I would greatly appreciate some guidance on crafting a vulnerability management program (including policy doc) that extends beyond "run Nessus and do what it recommends." 😊  My current experience is limited to drafting a patch management policy and scheduling cadence meetings to ensure we're doing what we said we would do, but nothing "deeper"/more structured.

Any assistance in this endeavor would be much appreciated!

[fiedlertodd]

We're pretty fractured still but here's what we are doing. First, background, we're smallish and have limited staff and financial resources so we focus on making incremental improvements, rather than sweeping changes that we can neither afford financially or organizationally accomplish.

We've got the requisite policies, and we patch at least monthly, more frequently for systems in the UK, and whenever critical severity patches come out that impact us, and we track all of it in our service desk. We also have a master calendar which I use to ensure we regularly review the tools that provide our various layers.  We also wrote a vulnerability management handbook that lays out what we do and refers back to our policies. 

I'd like so see us take a more active threat hunting tack but we just don't have the people to do it. Instead we rely upon technology and overlap of technologies, to act as our boots on the ground.

We have also recognized other vulnerabilities, such as vendor risk and we've implemented vendor risk management processes in an attempt to get that better under control. Other vulnerabilities we seem to be dealing with constantly are change related, and even though our policies require all non-standard changes to go through change management, there are always failures in that practice. If I could focus on one area to improve, it would be controlling change more effectively. Example, people create changes but don't provide any narrative around the change or worse, perform the change and then document the request. This is a combination of management failures to discipline but also a product of keeping the lights on. 

[luisantonio]

My recommendation is to focus on the core assets or data you are aware of. Think about what may affect them (for example typical weaknesses), and start working there. This is when Nessus can help, but probably I would not follow blindly its recommendations.

Hope this helps.

Luis.

[Steve-Wilme]

It may be an older document but its worth re-reading NIST SP800-40.  You'll need

1. An accurate asset inventory and where they sit in your enterprise architecture

2. A repository of OEM support contracts

3. Details of the product lifecycle for the components of the assets in your inventory

4. Details from either your BCP/IT DR team or Service Management as to the critical IT assets to your organisation.

With that you should be able to answer the questions:

1. What do I need to protect?

2. What's most exposed to external attack?

3. How critical is it to continuing operations?

4. Is it still under support (patches available)?

5. Is it soon to become unpatchable?

6. What is the cadence of OEM patch releases?

Then your vulnerability scanner should answer the questions on what state your IT estate is in and the remediation required.

[tmekelburg1]

A few resources:

Vulnerability Management Program Basics: A Getting-Started Guide (rapid7.com)

CREATING A PATCH AND VULNERABILITY MANAGEMENT PROGRAM

CRITICAL CYBERSECURITY HYGIENE: Patching the Enterprise 

[denbesten]

Vulnerability management does not really exist in a bubble separate from risk management because staffing is generally a zero-sum game.  The more time spend "patching", the less there is for "hardening" and "prepping".  

From a strategy perspective, focus on consistency and automation for routine tasks, such as applying patches.  Also, have a routine schedule, such as "IT staff PCs on day 1, rest of staff starting on day 5, servers day 8, money-making equipment day 12.

With respect to patching, you might also use an industry "Vulnerability Criticality Rating" (VPR, CVSS, MS Rating, etc.) to you figure out what patches to deploy first and when the schedule needs to be expedited.  For example, our policy requires "critical" vendor updates to be installed in a shorter timeframe than "low". 

Figuring out how to reduce staff-hours dealing with the routine allows them to focus on reducing the impact of vulnerabilities: 

• Enable on-demand privilege escalation, instead of having giving "admin access" to user accounts.
• Protect user credentials behind strong authentication, especially when off-site on non-corporate assets, etc.
• Segment dissimilar assets and control access between them.  Notably, PCs used for browsing the Interwebs should not have admin access to the equipment that makes you money.
• Turn off unused services and uninstall unneeded software ("hardening").
• Sync (dropbox, one-drive, etc) *all* data on laptops to facilitate rebuild after loss; use off-line backups to protect against ransomware.
• Consider user-experience factors to dissuade users from "working around you"

[Steve-Wilme]

It's also worth agreeing upfront that there will be maintenance windows for patching and routine maintenance on server based systems, as these can be cancelled if not needed, but can be difficult to negotiate on a case by case basis.  Another option with Cloud IaaS is to use Infrastructure as Code to shutdown and recreate infrastructure every couple of days from off line machine images that have been patched.  The automation will take away a lot of the pain of applying the patches and you should be confident that you'll never be very far behind on applying patches.  Then your conversations become solely about emergency patches for vulnerabilities that are being actively exploited.  

[Until_then]

You can reference many NIST pubs such as NIST SPs 800-128 and 800-161. Vulnerability Management can connect to many other related disciplines such as SCRM and Configuration Management. 

Use of numerous automated tools can also be added to your write-up.

[Until_then]

After reviewing the other posts/comments above, I think we are all missing something here. Risks and associated vulnerabilities come in all shapes and forms. It's not just limited to the virtual world. We tend to forget there is also the physical aspects of risks and vulnerabilities. Just like in RMF, this needs to be taken from a holistic approach. 

As mentioned above, what is it that you're trying to protect? What attack vectors or methods can be exploited in order for the enemy to gain an advantage?

Holistically, I would look at this from a 50K ft view then gradually focus on the finer details. Break everything down into five parts: 1. Software/Systems/Applications or other data storage 2. Hardware 3. Access control (physical/virtual) 4. IoT and other small devices that pose risks to INFOSEC 5. COMSEC

Above, we have discussed things like patch management and supply chain. What about people, e.g, insider threats, physical access to buildings, authentication? And when it comes to authentication, what about Zero Trust (NIST SP 800-207)? As mentioned, privileged access is a huge one as that helps to mitigate insider threats and associated vulnerabilities with that. All these are just as if not more important than software updates or vendor/supply management. As you can see, vulnerabilities are everywhere. 

[mgorman]

After reading some of the replies, my first question is what do YOU mean by vulnerability management?  Are you just thinking of an ongoing program to scan and report vulnerabilities in your current services as a security operations task?  Or are you looking more broadly into the risk management areas as described by others?

From a limited and purely practical sense, we consider vulnerability management to be what I described above, an ongoing process of checking our currently deployed systems for identified threats and reporting on them for remediation if found out of policy.  To achieve this, we define our systems as production and non production, first.  Our policy is that no production system can have a High or Medium vulnerability (CVSS Score ranges).  If found, High's must be remediated within 30 days (hopefully faster), and Mediums within 60 days.

We use the Greenbone Security Assistant to do our scans, and it is all automated.  We have a Python script that automates the collection of the assets (AWS, Azure, GCP based), creation of the targets, and runs of the scans.  The final report is parsed and a summary pushed to Slack/Mattermost (in transition) of the environment and summary results.  The security team reviews these and engages the asset owners if something is out of policy and needs to be remediated.  We are in the process of automating the last piece to push an issue in our GRC tool, rather than have to pull the information, as it can be forgotten, lost between people, etc. 

Our policy doc requires that it be performed, and lists the environment types, levels, and remediation timelines.  It is short and sweet, as we see vulnerability scanning as a control, and limit the scope of the term intentionally.