Compliance and Governance | Vulnerability Management

Eventually, the progress in remediation has to be monitored by someone to maintain good governance. In an organization of less than 10,000 hosts, it is often sufficient for this individual to be the person responsible for scanning. However, in larger organizations, it is preferable to have a compliance group perform this function. Additionally, Compliance would monitor the configuration and operation of the system on a regular basis.

Figure 1 shows how the compliance organization uses the current operations documentation, process documentation, and scan results to verify compliance. These three pieces of data have an important relationship. Operations documentation tells the compliance group what activities were undertaken by the VM group. Compliance should verify that VM activities are conducted in accordance with policy.

 

Figure 1: Compliance data flow.

Process documentation defines in unambiguous detail the steps to perform the VM function. It is against this documentation that the compliance function will verify the operations activities and supporting output documents. The process documentation itself should be checked against policy to assure conformity. In some cases, this step is not necessary in the compliance monitoring function because compliance may be a part of the creation of the VM process. In that case, an external audit is occasionally warranted.

Finally, the scan results data is detailed in reports from the vulnerability scans. These reports should reflect the level of compliance achieved by each IT group responsible for remediation. Later, we will discuss in some detail the content of these reports and their relevance in a mature, successful VM program.

1 System Audit

Another critical step in the governance of VM is auditing. During an annual audit of security mechanisms, it is advantageous to have an external party review the configuration and operation of the system. The elements of any audit should include the following:

• Process: Auditors should verify that there are no critical flaws in the scanning, remediation, and verification processes. The auditor should provide recommendations on improvements.
• Scope: With an understanding of the structure and application of existing network segments, auditors must verify that a complete and appropriate set of targets is scanned. Depending on the program charter and policy, the list of targets may include vendors or business partners. In addition to existing targets, it is important to recognize that organizations, systems, and networks are dynamic. Changes to the environment will change the scope of scan targets. Processes and configurations of scanners should be sufficient to adapt to this changing environment.
• Training of operators: Those working on the technical details of the system must be sufficiently well-versed in its operation. Not only must they understand operations, they also have to understand how vulnerabilities work, the threats associated with them, and the risks posed to a company realizing those threats. Knowledge of operating systems, networks, protocols, and various relevant applications is highly desirable.
• Policy alignment: Do the VM operations align with current policy? As we discussed earlier, VM processes are derived from policy, which is derived from program charter or business objectives. Over time, policy can drift and no longer meet the program requirements. This is not through negligence but a natural tendency of individuals to adapt to a changing environment without the perspective of overall impact to the program charter.

As circumstances gradually change in networks and systems to respond to the changing business environment, the business needs will no longer be reflected in the policy. For example, the business may typically sell its products through personal sales contacts. Therefore, there are no policies regarding proper use of encryption or handling of customer financial data. Then, they discover untapped markets that are accessible online. The current policy may state that electronic payment data must be exchanged through bank transfers and not through company systems. However, in the newly adopted online sales model, customers provide payment information, which is handled by company computer systems. Now, numerous vulnerability and compliance issues in encryption, network design, and system configuration arise. Since the policy has never been amended, it is difficult to discover and remediate compliance problems in these systems. Furthermore, the systems in question may be out of scope for VM altogether.

New Policy | Policy and Information Flow

VM compliance policy is sometimes necessary for enforcement of remediation activities. Depending on your organization, a policy that directs IT managers to make remediation a priority is helpful. The policy should provide for the following:

• Prioritization of vulnerabilities: The vulnerabilities found will be prioritized. In many cases, more vulnerabilities are found than can possibly be fixed in a reasonable amount of time. You will have to specify what gets done first. It is even possible that you may want a policy statement of the circumstances under which systems administrators should drop everything they are doing and remediate or shut down the system in question.
• Valuation of assets: Every system is a company asset. It has to be given a value, which can be used in the prioritization process. 
• Time limits: Depending on the severity and type of vulnerability, time limits for remediation must be set. This is, in effect, an SLA for the organization. You will have to consider the risk or threat to the organization based on several criteria. Those criteria, however, would be left to a supporting standard.

1 Usage Policy

Another important type of policy pertains to the usage of the VM system itself. This policy would highlight key operational constraints. Among the types of constraints necessary are the following:

• Types of systems exempt from scanning: This can include other security devices or critical network devices that are known to be adversely affected by scanning.
• Operational requirements for scanning approval: One must have consent of a system owner and/or administrator.
• SLA parameters: This requirement specifies what parameters must be included in any scan specification for a given network or group of targets. This might include time of day, bandwidth limitations, operational impact assessment, and scan termination request response time. These parameters in particular are important to maintaining a healthy relationship with system owners. If scans interfere with the systems and their operating environment, system owners are not likely to grant ongoing permission to continue scanning.

2 Ownership and Responsibilities

Once a system proves itself to be a powerful tool in managing a critical part of the enterprise, questions such as “who is responsible for the scanning schedule?” and “who decides what gets scanned and when?” are likely to arise. These questions are reasonable, given the insecurity that comes with what is perceived as an invasive activity. The best thing to do is avoid contention over these issues by getting it all decided in advance. Be forewarned that ambiguity is the enemy of process.

The first step in establishing clear ownership is to build it into the policy. The roles for key functions in the process should be clearly specified in the title. At a minimum, these roles must at minimum include the following:

• Scan parameters definition: The business and technical parameters used for scanning must be defined and carefully controlled. Although others may participate in the process of scanning, careless changes to parameters can cripple a host or an entire network.
• Scan scheduling: The schedule for a scan has a lot of thought built into it. These considerations should not be trifled with. A change in a schedule can have as big an impact on business operations as a change in parameters.
• Report distribution: Vulnerability reports are confidential data. In the wrong hands, these reports can be very damaging. For a hacker or motivated, disgruntled employee, a vulnerability report is a road map to trouble.
• Local host remediation: When a host cannot be patched or fixed through an enterprise host management tool, it has to be remediated by a local administrator or other individual appropriate to your organization.
• Global remediation: Conversely to local host activities, global tools also remediate hosts over a network. One or more organizations are responsible for this remediation. For example, the desktop team may be responsible for general host patching and the security group may have to keep anti-virus and encryption programs updated. All such organizations should be identified in advance and made active participants and contributors to VM process development.