CySA+ Domain #5: Vulnerability Management Process
Vulnerability management is an essential aspect of cybersecurity analysis. After all, tracking down, identifying and resolving vulnerabilities is something that cybersecurity analysts do on a near-daily basis.
This article will detail the vulnerability management process that will appear on the CompTIA CySA+ certification exam. It will guide you through this relatively straightforward, albeit still important, domain of knowledge.
Vulnerability management process at a glance
The vulnerability management process, as reflected in CySA+ objective 2.1, is the following:
- Identification of requirements
- Establish scanning frequency
- Configure tools to perform scans according to specification
- Execute scanning
- Generate reports
- Ongoing scanning and continuous monitoring (Please note: As this step is basically a rehash of previous steps, it does not need to be covered in depth)
Identification of requirements
Knowing what your organization is trying to achieve is key to creating a vulnerability management process. Regulatory bodies are the first requirements looked at, and it is necessary to know which ones apply to your organization. You may need to consider:
- Health Insurance Portability and Accountability Act (HIPAA): This applies to organizations that deal with Protected Health Information, or PHI
- Payment Card Industry Data Security Standard (PCI-DSS): Protects credit card information and governs how it is exchanged between parties (merchants, processors and financial institutions)
- Sarbanes-Oxley (SOX): Establishes standards for maintaining accurate and secure financial records for publicly traded companies
Other factors affecting the identification of requirements are:
- Corporate policy: Can establish what vulnerabilities are acceptable, exceptions to general security posture and how different classification of data are handled
- Inventory of protected assets: Lays out which, if any, assets have different technical controls than others. More-critical assets have tighter controls than less-critical assets
Establish scanning frequency
Organizations must perform scans repeatedly. The frequency that scans must be run is determined by several factors, including:
- Risk of scanning: This is determined by the organization’s risk tolerance. The more scans are run, the more vulnerabilities are found. The problem is that some vulnerabilities may cause a denial of service. An organization’s risk tolerance should balance competing interests like these
- Regulatory requirements: May determine scanning frequency (e.g., quarterly, annually)
- Technical constraints: May restrain how often scans are performed, especially if the organization does not have the technical ability to perform scans on their own and has to outsource their scanning responsibilities
Configure tools to perform scans according to specification
Before you can scan, you need to configure your scanning tools. The steps to configure these tools to scan according to specification are:
Determining scanning criteria
- Sensitivity levels: Balancing the competing interests of thoroughness of scanning and not disrupting the production environment. You need to understand what adverse effects your scans may cause
- Vulnerability feed: Updates for vulnerability scanners are normally performed through feeds. These updates include new signatures and vulnerabilities. While some have automated this feed update process, it’s smart to have a plan in place for reviewing these changes before you add them to your scan definitions
- Scope: Similar to pentesting, vulnerability scans should be constrained by scope. This is done to limit adverse effects to critical systems. A good way to manage the scope of your scan is to define it by IP address
- Credentialed vs. non-credentialed: Whether scans are performed with required credentials or not is based upon organization need
- Types of data: Scans can be configured to only reach certain types of data
- Server-based or agent-based: Server-based run host scans over the network while agent-based scans run within hosts via a software agent. Organizations may opt to use a combination of the two methods if need be
Tool updates and plug-ins
It is important to remember to update your vulnerability scanning tool and to add any applicable new plug-ins available. The Security Content Automation Protocol (SCAP) provides an updating method for vulnerability scanner databases and plug-ins.
While this may seem like the easiest of all the steps, it is actually one of the most crucial. Remember that scans can have a wide-spread, negative effect on your network if your scan touches the production environment during production hours.
I personally have seen a scan performed by a less-than-careful individual shut down a production server which had the effect of nearly closing the office down for an entire day. Had she been more cautious, the automated scan could have been scheduled during off-hours, thereby preventing the problem.
For many, the pièce de résistance of vulnerability management is the report itself. Reports may be generated on an automatic or manual basis. Manual report generation is normally required when you need to perform extra work before the report is distributed. From my own experience, I have seen manual report generation most often when adding extra formatting (to make the report more visually appealing to managers) and when a data corruption occurs within the report itself.
The vulnerability scan itself is often just the start of the vulnerability management process (believe it or not!). Factors to consider for remediation include:
Prioritizing your remediation tasks is crucial to the vulnerability management process. Considerations include:
- Criticality: The criticality of the vulnerability and the importance of the specific asset itself
- Difficulty of implementation: It may be determined that some remediation actions may not be performed due to various barriers
Difficulty of implementation is not the only barrier to potential remediation changes. Other barriers include:
Change management may prove to be a bureaucratic obstacle to making the required remediation changes. Cybersecurity analysts need to work within the organization framework to gain the approval and support of the organization for said changes.
Service-level agreements, or SLAs, can sometimes be the determining factor in whether appropriate remediation changes are allowed to be performed. One example is how much downtime is acceptable due to vulnerability scans. The unfortunate truth is that SLAs are often the governing authority for changes like these, so cybersecurity analysts need to ensure that any changes made do not violate their SLA.
Organization’s governance bodies
Different organizational governance bodies may not incur the risk of your remediation changes from time to time. This may be due to degrading functionality of systems which would adversely impact endpoint users within an organization.
Overzealous cybersecurity analysts need to realize that while they may have a more educated and informed opinion about making remediation changes, they work for the organization and are therefore bound by what their decision-makers will allow.
Without a doubt, the vulnerability management process is an integral part of an organization’s overall cybersecurity strategy. Despite this, the process itself is relatively straightforward and is often guided by well-founded common sense (such as not disturbing the production environment during production hours). When preparing for the CySA+ certification exam, use this article as your guide and you will be well on your way to earning a passing score.
- CompTIA CySA+ Objective 2.1, Pack IT Forwarding
- CompTIA Cybersecurity Analyst (CySA+) Certification Exam Objectives, CompTIA