Automation Technology

Automating as much of the VM process as possible will go far to having it embraced by the organization. The automation must take the form of integrating with existing systems and providing a virtually invisible footprint. More out-of-the-box integration is called for, using well-established standards rather than labor-intensive customer programming. Standards such as XML and RPC are very useful items to look for.

1 Ticket Generation

The creating of change or incident tickets is a key area for automation. The system should be able to interface with the ticketing system in a way that all of the required fields are supplied or synthesized, and also supply the most relevant information to the ticket recipient. Make a list of the items your ticketing system requires and verify that all of those items are available in a ticketing interface or that they can be easily created. For example, some ticketing systems require a user ID of the person who created the ticket. If it is acceptable to the ticketing system users, a “vuln-system” user or equivalent can be created to accept entries from the system. Alternatively, perhaps the interface from the VM system can provide the target owner name or network owner name as a user ID. Small details like this will quickly derail your plans unless they are all spelled out.

Completing the VM process is support for remediation. Once a ticket has been accepted and the remediation completed, a provisional closing of the ticket should be performed. This event should then automatically notify the VM system that the remediation has been completed and verification should take place. A follow-up scan can either be immediately performed or performed at the next scheduled time. If the target is free of the vulnerability, then the ticket can either automatically complete closure, or the VM system can send a message to the ticketing system to close the ticket. If the vulnerability has not been properly remediated, then the ticket should be reopened or a new one generated, depending on the internal process requirement.

Involving the owner of the ticketing system in the product selection process is an important factor if you are considering integration. The amount of work required for the integration should be accurately assessed since it could be expensive, depending on the flexibility and ease of use of system interfaces. Besides, one can never expect the integration to take place without the support of the system owner.

2 Process Integration

Any VM system should have some flexibility in integrating with existing IT processes. Although some of these processes may not be present in an organization prior to acquisition of hardware or software, the basic idea of a VM process is unavoidable. Vulnerabilities are detected, analyzed, and remediated. Even though each step may not be thorough or well-documented, they will nevertheless probably exist and should be documented to the extent necessary to validate requirements against system capabilities. In many cases, it may be easier to re-engineer the process into a more standard form. Remediation through patch management is an area significantly impacted by process and technology integration, and this demands greater flexibility as well.

3 Process and System Flexibility

Some VM systems are built around a specific and relatively rigid process. During the sales cycle, vendors often tout this process at the outset to demonstrate excellence of the product in how it delivers consistent results. Unless the buyer of these products is very flexible, efficient, and adaptive to changing critical and ingrained organizational processes, the tool will consistently deliver poor results.

This can become a limitation on the tool’s effectiveness rather than an enhancement to the vulnerability state of your organization. Having a rigid process around which the tool is built helps the product developer because it simplifies design and coding and it also simplifies the tool for the end user. But, organizations requiring easy cultural and technological integration have much more to gain if the tool can be molded to their requirements. Following is a list of types of flexibility required in technology:

• Provide reports in the format suitable to your environment and culture. Some companies are averse to logging into a system and selecting parameters to receive a report. This is usually because users are so busy that they cannot include a process and system change in their daily routine. A great method for getting the important data in front of them is to send it automatically to the right manager. E-mail is a common delivery mechanism that everyone already uses.
• Alternatively, some IT managers have Web portals that they use daily in their routine. Some critical information about their networks would be useful on their personalized home page. For example, a “top-10 hosts” report showing the hosts with the worst scores in their network will help them quickly assess and assign remediation tasks. For more senior managers, a “top-10 networks” or “vulnerability trend” report would help to quickly show where problems might exist with a 10-second review.
• Allow for individual IT managers to set up and perform audits of their area of responsibility outside of the standard, agreed-upon schedules. In active scanning, this is known as scan-on-demand. It is a valuable remediation verification tool that can minimize error in remediation. Engineers sometimes remediate the wrong vulnerability, or misunderstand and incorrectly remediate one. Another common mistake is failure to reboot after installing certain patches. The verification process, driven by the system owner or IT manager, can enhance the quality of remediation results.

4 Patch Management Support

Patch and change management interfaces have already been discussed. If the related processes are present in your organization, then some basic data requirements should be met. But the VM system should also provide an interface that is sufficiently flexible to respond to processes. For example, internal processes may not perform a verification audit of the vulnerability and wait until the next audit. Although the change process may have completed and, in doing so, have informed the VM system, a verification scan should have the flexibility to be performed as part of the next, regularly scheduled audit. Anything else may demonstrate too much rigidity in the workflow of the tool.

Professional services are typically required for customization. Beware of this challenge and look deeply into the implementation requirements for your process adaptation. If the product vendor informs you that customization is only reliable or most reliable with the use of professional services, then the cost of the deployment may be deceptively low. Include with the purchase the delivery on specific process integration requirements.

Hardware: The Appliance Model

The hardware appliance model is exactly that: hardware with built-in software to perform the desired vulnerability scans. The devices are typically placed throughout a network and report back to a central server. The scanning appliances are usually complete but simple computer systems. A typical design has an operating system (OS), supporting software modules, and the specialized code written by the developers to perform scans and communicate results. Some vendors use open-source tools and others will use a commercial OS and components.

One major advantage of a hardware-based system is that the vendor will have in-depth knowledge about the configuration of the host. The vendor takes responsibility for the maintenance and stability of that configuration. Any failure of the software to perform as advertised should be addressed in the client–vendor relationship.

In deployment, the hardware approach has the disadvantage of having to be shipped to the location and installed by someone who may not be qualified to do so. In most cases, however, deployment is not so complex. If the local technologist can configure a typical host computer, he or she can configure a vulnerability scanner. If you are uncertain about the capabilities of local personnel, then you may be well-advised to preconfigure the device and provide simple installation instructions.

In most designs, each scanner will report back to a central server. The vulnerability and compliance information collected will be transmitted back to the server for analysis and reporting. Devices will also receive assessment instructions over the network. Those instructions may be delivered by polling, on-demand connection, or through reverse polling. The impact of these strategies will be minimal but important, depending on your network security architecture.

Polling is the process of taking a poll of the vulnerability scanners associated with a central server. Each scanner is typically contacted through a TCP port with special authentication methods that keep the entire conversation encrypted. The devices that are polled may be only those for which the server has a job prepared or in progress. The server checks the status to see if any data is available or if the unit is ready to accept a job. This approach can be cumbersome but has the advantage of only requiring a connection originating from the server. In some cases, not all scanners are polled unless there is scheduled work that can result in not knowing the status of a scanner until that time. Most vendors that poll will poll all scanners. Figure 1 illustrates the simple polling approach.

 
Figure 1: The simple polling approach.

Reverse polling is the process whereby each scanner contacts the server on a regular basis. Should there be a job scheduled for the scanner, it would then be provided. The same strong authentication and encryption methods apply. The scanner will send the results of the scan back to the central server either during the scan or at the conclusion, depending on the software designer’s choice. This approach has the added advantage of allowing the scanner to complete a local job even if the connection with the server is lost. The scan results may simply be cached until a connection can be re-established.

Reverse polling also has an advantage when deployed in a secure zone where in-bound communications to the scanner may be undesirable in order to limit possible external connections. This is also a disadvantage should the scanner be deployed outside the organization’s boundaries because accommodations must be made in the security infrastructure for connections from the scanner.