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.
