Scheduling | Vulnerability Management

In the previous section, we discussed how audit scheduling may be a requirement. This granular requirement is the specification of the type of controls needed on the assessment process. Related to the previous discussion, the timing and resource controls available to a scanner or agent can vary considerably from one vendor to the next. For example, the ability to set the time of day and day of week for an active scan is pretty standard. But, the business cycles of your firm may require that the assessment be performed at the same time each week and, if that schedule is missed for any technical reason, the assessment is performed on the next available day at the same time. Such a requirement is not uncommon in a busy financial environment where compliance is continuously monitored. Following is a list of considerations for other scheduling requirements:

• Time of day, day of week: A pretty common scheduling method, selecting a day of the week or a time of day is very typical. Generally speaking, this setting should be adjustable for a particular time zone.
• Day of month (first, last, particular day): This schedule is most useful in business operations where the targets must be assessed on a workday but the exact date cannot be reliably determined. Instead, the day of the week or day of the month would be specified. So, the parameter could be the first workday of the month, last workday, or even the last Monday. Some business cycles require that assessments only take place monthly or weekly on a certain day. For example, a retailer may perform collection of critical sales data on Monday mornings. In this case, it may be desirable to perform vulnerability assessment on Mondays after 12:00 noon (weekly) or on the last workday of the week (weekly) or the last Friday of the month (monthly).
• Only during/after local work hours: The assessment of desktop computers generally needs to happen during work hours when the computers are switched on. It is increasingly important to have this level of control with the focus of companies towards curtailing energy consumption.
• Start/suspend/resume during a time/date window: This is useful when an assessment requires more time than is available during a certain time window. For example, if a scan must be performed during work hours but needs more than 12 hours to complete, the assessment should be paused for the night and resumed on the next work day. The process should continue until the assessment is complete. If the schedule for the assessment overlaps with the next assessment, the next one should be deferred for one cycle. This may sound like a complex requirement but it is not uncommon and is currently not well-addressed by the products available.
• For all scheduling of assessments, the date and time parameters should be adjusted for local time zone. There are varying methods of implementation; however, the result should be that if an assessment is supposed to start at 10:00 a.m. on Monday in New York, the same parameter applied to San Francisco would be 10:00 a.m. Pacific Time or 1:00 p.m. Eastern Time. This becomes even more critical for large, globally distributed environments. I have seen systems perform all scheduling to Coordinated Universal Time (UTC) to accommodate deficiencies in local scheduling capabilities. Assuming the network is in the same time zone, a very good approach is to specify the time zone for the target network or host. Then, the schedules applied can have a parameter, which indicates whether or not the time zone of the target should be respected.
• If all of a network segment is not in the same time zone, then it would be prudent to divide the network definition by time zone logically in the VM system. This will allow the system to scan on an optimal schedule for each part of the network segment. If this is not possible, then it may be necessary to confine the scan window to a common time frame during which all hosts are available.

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.