Given a scenario, implement an information security vulnerability management process.

CompTIA Cybersecurity Analyst (CySA+) Certification Exam Objectives Version 3.0

Identification of Requirements

One of the key parts of managing vulnerabilities is knowing what the enterprise is trying to achieve.  The first set of requirements often come from regulatory bodies.  Some of these are listed below.  It is important to know what applies to the enterprise’s line of business.

• Health Insurance Portability and Accountability Act (HIPPA) – applies to any business that deals with Protected Health Information (PHI).
• Payment Card Industry Data Security Standard (PCI DSS) – applies to the protection of credit card information and how it is exchanged between merchants, processors and financial institutions
• Sarbanes Oxley (SOX) – Applies to all publicly traded companies in the United States.  It’s goal is to establish standards for maintaining secure and accurate financial records.

The corporate policy also helps to define the requirements for vulnerability management.  Policy can establish what risks and vulnerabilities the corporation are willing to have and what mitigations must be in place.  Exceptions to general security posture should be defined in a corporate policy.  Data classification can also be part of a corporate policy.  Different classifications of data may be subject to more or less control.

A final component of the requirements for vulnerability management is to establish an inventory of the assets being protected.  Assets may be hardware or software and will have varying levels of importance.  Each asset can be rated as critical or non-critical or may be assigned a numeric value of ranked importance.  More important assets will have different technical controls than lesser assets.

Establish Scanning Frequency

The scanning for vulnerabilities in an enterprise must be done repeatedly.  The frequency of these scans is determined by several factors.  First, the risk of scanning must be taken into consideration.  The more often a scan is done, the more likely a vulnerability is found before it is exploited.  Unfortunately though vulnerability scans can also cause problems as some vulnerabilities can cause a denial of service.  These competing interests are balanced by the corporation’s risk tolerance. 

Regulatory requirements will also play a role in choosing the frequency of vulnerability scans.  Some may require yearly or quarterly scans.  

Technical constraints often play into the frequency of scans.  An organization may not have the technical equipment or knowledge to do scans themselves.  This will often limit scan frequencies as it must be paid for using outside analysts and equipment.

Configure Tools to Perform Scans

Once the requirements and frequency are determined, the actual scan must be configured.  There are several options to consider for the actual vulnerability scan.  First, you must determine the sensitivity of the scan.  This involves determining a balance between thoroughness and not causing issues in production systems through the scan.  Some modules and scanners may cause adverse effects so it is important to understand what each does and what you are scanning.

Vulnerability scanners often update themselves through feeds.  These feeds offer new signatures and vulnerabilities to test.  Some organizations automatically include these new items, but often it is best to have a plan for reviewing them before allowing them to be added to an existing scan definition.  

Similarly to defining the scope of penetration testing, vulnerability scans should have a defined scope.  This may be used to help limit potential adverse effects on critical systems posed by automated scans.  This scope can be defined by IP address.  Also part of the scope is whether to use credentialed (authorized accounts) to scan or to only use scans that do not require credentials.

Once the scope and requirements are established, the software for the scanning must be chosen.  This can come in two forms, server-based or agent-based.  Server based scan hosts over the network while agent based scans take place internally on a host through a software agent.  A combination of these may be used as well.

It is also important to remember that vulnerability scanning tools need to be updated too.  The Security Content Automation Protocol (SCAP) is used by many tools to provide a method to update vulnerability databases and plugins.

Report Generation

After the tools are done with the vulnerability scanning, reports must be made to relay the information found.  These may be done either automatically or manually.  Regular scans may be automatically reported on, but sometimes additional work by analysts may need to be done before the reports are given to management.  This work is to help interpret the results and provide suggestions based on what the scan discovered.

Remediation

Often the vulnerability scan is just the beginning of the process of vulnerability management.  Once the reports have been produced there must be a process on how to respond.  The first step is to prioritize the vulnerabilities found.  This can be done by the criticality of the vulnerability and the importance of the asset.  The difficulty to implement the resolution is also taken into account.  It may be determined that some remediations won’t be done because of various barriers.

These barriers may consist of many things.  Service Level Agreements (SLAs) in place with business stakeholders may restrict how much downtime may be incurred.  Another restriction may be from the organization’s governance bodies that may choose not to risk the system changes necessary.  The possibility of degrading functionality or performance of a system to the end users is another barrier to remediation.