Although frequently overlooked or treated as an afterthought check box, custom development is a significant area for specifying requirements. Very often, those who implement VM initiatives discover too late that significant customization is needed to maximize the potential of their security systems. This can happen when there are change management systems, often custom-developed, around which entrenched internal processes are built. Since it is unlikely that a new change management system will be purchased, the ability to efficiently extract information from the VM system and initiate a change and/or incident process is critical.
At a high-level, as previously described, when interfacing to a change or incident management system, the following items will need to be managed by the interfaces:
- Extract vulnerability data from the VM system.
- Initiate a change or incident in the internal system while retaining the reference provided by the VM system.
- Take a provisional closure of the incident and update the VM system. This will optionally start a verification assessment.
- An event from the VM system will trigger closure of the incident or reinitiation of the incident, depending on the outcome of verification.
Depending on the process and systems in your enterprise, these steps can vary the data structures and processing required in the interface code. A clear understanding of the interface capabilities of the candidate vulnerability systems is essential prior to purchase. Once understood, assess what coding requirements there will be for each candidate. This will help highlight any potential shortcomings that may significantly limit overall effectiveness. For example, the planned internal VM processes may require that detailed recommendations on remediation be transmitted from the VM system to the change management system. If this critical data element is not provided in the ticket generation process, then this may cause a critical gap in achieving IT security service goals.