Division of Responsibilities | General Requirements

The basic division of responsibility can be critical for meeting compliance and audit requirements in a large institution. The primary concern is to avoid having the vulnerability check parameters changed by a group or an individual with a vested interest in not appearing vulnerable. In addition to concealing vulnerabilities, this behavior is not unlike the age-old accounting problem where a business unit reports better results from one quarter to the next by changing the accounting rules. In the security realm, this leads to an overall security weakness that can threaten a large portion of an organization since vulnerability audit parameters can be applied globally.

Divided responsibility may not only have a compliance component, but a simple operational excellence one as well. In the delivery of IT services to the business, various groups are accountable and yet dependent upon other groups. This is no less true for the role of VM in the delivery of IT services. For example, the network group may have service level agreements (SLAs) to maintain that may be impacted by vulnerability scans. Those service levels are subject to change, depending on internal customer requirements, and may have many complex elements. The internal service provider, which may be a network group or server platform group, will need to exercise some control over when a vulnerability assessment takes place and perhaps how much of the provided service’s resources are consumed in the process. The network team may be concerned with how much bandwidth is consumed on a particular WAN link during an active scan.

A server team, however, may be concerned about the system resources required to operate an agent in different modes. Perhaps during an active assessment of the host, the agent consumes an excessive amount of CPU or conflicts with a single business-critical application service. So, limited control of the auditing process may be necessary, while control over the quality elements should be restricted to security and/or compliance.

A virtual machine environment can amplify the impact of an agent where multiple guest OS instances will require the operation of multiple vulnerability assessment agents. Also, the impact risk on multiple OSs simultaneously is increased by the fact that the host OS running a hypervisor may also have an agent running. Regardless of the group managing the resource scheduling for an assessment, given the testing and management required for certain activities, a single security group may not want to have this responsibility when there are already knowledgeable individuals who would prefer to take ownership.

In summary, the message here is that each group in an IT organization is accountable for the services it provides. The introduction of a new IT function has an impact on operations in other groups. Inclusion of representatives from the affected groups will be instrumental in identifying the impacts and requirements of the VM product. One good tool to facilitate the identification of these requirements is the process dependency diagram. Figure 1 shows an example diagram where the VM service is the focal point. However, this diagram can be expanded to identify dependencies that may be created for other services where their requirements may change.

 
Figure 1: Identifying VM system requirements.

From Figure 1, we should be able to quickly identify requirements for the VM system that not only achieve the objectives of identifying vulnerabilities, but also enhance the service levels of the affected systems. In this diagram, Network Services has provided requirements that affect the existing service levels:

• audit scheduling around business hours;
• bandwidth consumption requirements per site or other grouping such as source network; and
• simultaneous network connections to minimize impact on routers and firewalls.

The Business Applications Services group, however, has requirements that not only affect the performance of the applications, but also a requirement to perform certain types of vulnerability checks. This is a common result of enhancing SLAs to reflect the security of a system. An SLA for an application services group may specify that tests will be performed on every new release for cross-site scripting and SQL injection vulnerabilities. The VM system has, then, not only generated service delivery burdens for a particular IT service, but has also enabled enhancements to existing SLAs through an operational level agreement (OLA) arrangement.