You have a vulnerability scanner, but where’s your process?
Most organizations are rightly concerned about possible vulnerabilities in their systems, applications, networked devices, and other digital assets and infrastructure components. Identifying vulnerabilities is indeed important, and most security professionals have some kind of scanning solution in place. But what is most essential to understand is that a vulnerability scan represents just a single snapshot of your infrastructure at a fixed moment in time. Figure 16-1 illustrates Operation tasks that must now be accomplished in order to make this a repetitive sustainable process.
Figure 16-1 Operating a successful vulnerability management program
The fact is, your infrastructure is constantly changing, and vulnerabilities may appear at any time. Attackers may appear at any time, as well. That’s why you need to build a comprehensive vulnerability management plan that ensures frequent coverage of your environment – but also includes a sustainable process for analyzing, prioritizing, and remediating vulnerabilities when they are found. This covers the Production loop of the life cycle as illustrated in Figure 16-2.
Figure 16-2 Vulnerability management production portion life cycle
Only with a consistent, repeatable vulnerability management process that covers all assets and provides regular reporting so that informed decisions can be made quickly – shortening the window during which you are vulnerable – can you be assured your solution is providing the protection you expect. As a part of the assessment step however, we need to explore Discovery, Analysis, and Reporting (not shown) as three sub steps. Remediation and Measure complete the lifecycle before any exit paths are considered.
Discovery
In terms of discovery, the question is how often you should scan? Again, that will depend on the size and nature of your digital assets. At the very minimum, low-risk or low-value assets should be scanned at least once a quarter. At the opposite end of the spectrum, high-risk/high-value assets can be scanned as often as several times a day. It all depends. There are other factors to consider as well; for example, patches from some vendors are released on the 1st of every month and others the 15th of the month like Microsoft. That is, therefore, a good time to schedule scans of servers and sensitive hosts based on remediation availability and in order to meet SLAs.
The scope and frequency of scanning should be well defined and documented as responsibility for the ongoing assessment is passed over to the vulnerability engineers. At this point, it is up to the vulnerability engineer to schedule and validate scan job health, performance, and that remediation activities are proceeding on schedule.
Analysis
The challenge here is that you might be generating an enormous amount of data through your scanning solution, and being able to analyze it in an efficient way is essential for remediation activities. This is a key capability of a robust vulnerability management solution, as there will be too much information to sift through it all manually. You need to be able to configure a solution to identify the highest-value information that each scan yields. Through ongoing collaboration with the security teams, information technology teams, asset owners and auditors, the vulnerability team can work to ensure appropriate levels of reports are delivered to the “right” people, at the “right” time. This is an analysis and reporting excerise and benefits the most from threat intelligence.
Reporting
The reporting sub step is where the data becomes actionable. The vulnerability assessment process will generate a variety of reports, focusing on such things as threat analysis, service-level agreement status, regulatory compliance, and exceptions and expiration dates. Reports should be reviewed by the security team, system owners, and system administrators, all of who will work to create a schedule of what actions must be taken and what the priority of each action should be. The vulnerability engineer must ensure that the appropriate levels of reports are being generated and distributed accurately and on a timely basis. This includes not sending the same list of 10,000 vulnerabilities to all asset owners every week. This is when reports and emails get ignored. Filter the reports and only send asset owners vulnerabilities for which they are responsible. For example:
Vulnerabilities on Desktops to the Desktop team
Vulnerabilities on Windows Servers to the Windows team
Vulnerabilities on Unix Servers to the UNIX team
Vulnerabilities in the DevOps staging area to the Development and QA teams
Vulnerabilities on the Web Servers and databases to the application team responsible for those assets
Vulnerabilities on network devices to the appropriate network teams
Remediation
This leads to the second major step in production, remediation. Depending on the asset and the vulnerabilities found, remediation can be done quickly and remotely, or it may require a more complex, hands-on fix that may require taking some systems offline, using redundant systems, and implementing additional components. As noted earlier, such contingencies should be identified in advance so there is no delay in eliminating the vulnerability. Ultimately the decision to remediate or accept risk should be made by the asset owner and coached by the security team. The vulnerability team must ensure that appropriate steps are followed to mark exceptions within the vulnerability solution to ensure appropriate risk, audit, and service level agreement reporting are all documented.
Measurement
Finally, measuring the overall vulnerability attack surface and effectiveness of the remediation processes is a critical component of any successful program. Measurement is used to ensure risks fall within accepted levels, ensures that compliance mandates are not violated, and can be used to provide positive (and negative) motivation for information technology and asset owners responsible for remediation and other supporting activities.
During the operational phase of the vulnerability management system, it is likely that asset owners will require, and demand, specific and sometimes custom reports to report on risk and streamline remediation activities with existing processes. Successful vulnerability management programs are the ones where the vulnerability engineers work with the various stakeholders to understand their information needs to try and optimize the process. Here are some recommendations:
Do not send the same raw vulnerability report to all stakeholders and ask them to filter and find what they need.
Understand what assets, what vulnerabilities, and what level of detail that each stakeholder requires and provide pre-canned reports to simplify and automate the process.
If possible, automate report generation and allow self-service reporting at the technical, management, and executive levels.
Select a vulnerability scanner that provides a flexible reporting framework that enables customization to satisfy incoming requests.
Do not attempt to satisfy ongoing report requests manually. That is, do not get into a routine of hand jamming spreadsheets and other reports for stakeholders. As the number of refinements increases, more and more time will be spent trying to keep up with incoming requests, increasing the overall cost of the program and delaying access to critical risk information.