The path is starting to get steeper now as we climb to ML2. It is time to start defining a vulnerability management program with objectives and goals. This program is expected to grow and evolve over time as the organization grows and evolves.
Document the requirements
Start by documenting what is in place now and what objections the organization is trying to reach.
Define the stakeholders
The stakeholders should come from multiple departments within the organization. For example, you will need buy-in from:
- IT
- Executive and Senior management
- Legal
- Security and/or Compliance teams
- Critical service and system owners
Obtain business priority endorsement
For the program to be successful, senior management must endorse and fund it as a business priority. There will be personnel and budget costs to implement and run the program, so these resources need to be allocated. If the program is not a well-funded priority for the organization, the likelihood of failure is high.
Questions to ask
The vulnerability management process should start by answering some basic questions: 1. What are the roles and responsibilities?
-
- Who runs the tool(s) used to find vulnerabilities?
- Who is responsible for the remediation of any vulnerabilities that are found?
2. How often will assets be evaluated? 3. How and when are the results being communicated? 4. What are the standard remediation timelines? 5. How are exceptions handled? 6. How is success measured? 7. What metrics will be tracked to make sure the program is working?
-
- When are the metrics being reviewed?
- Who is the owner for each metric?
8. Does the business need to adhere to any special regulations that will impact the program? (PCI, SOX, HIPAA, etc.)
Getting started
Starting a program from scratch may seem like a daunting task, but your security vendors should be ready to help you create one or assist you in modifying an existing program. US-CERT has a good guide to help get you started. Now that you have the program started, it is timely to look at the other changes which take place in ML2.
Assessment schedule
In this phase, ad-hoc assessments cease and scheduled assessments are conducted to ensure that all assets are evaluated at a normal cadence. The evaluation frequency for assessments should be weekly for critical assets and monthly for non-critical assets, at a minimum. The timing of assessments should take when your vendors release patches into consideration. For example, Microsoft releases patches the second Tuesday of each month, Oracle releases quarterly patches while Cisco releases them every 6 months. Be aware that high importance or critical patches may come out between the normal cycles. You must be ready to run assessments at any time should any critical vulnerabilities be revealed, but planning your assessments around normal patch cadences helps keep the assets current and reduces out-of-band emergency patching. At this point in the climb, the major focus is on the critical systems in the environment. By now, these critical systems should be identified, and the full inventory of hardware and software should be documented. Vulnerability assessments should be running at least every week, and the vulnerabilities should be remediated in a timely manner.
Final thoughts for ML2
Keep working on the vulnerability program and making sure the critical systems are secure. Base Camp is not far away.
FURTHER READING ON CLIMBING THE VULNERABILITY MANAGEMENT MOUNTAIN:
Mastering Security Configuration Management
Master Security Configuration Management with Tripwire's guide on best practices. This resource explores SCM's role in modern cybersecurity, reducing the attack surface, and achieving compliance with regulations. Gain practical insights for using SCM effectively in various environments.
