DON'T shortchange remediation.
Surprisingly, organisations will perform vulnerability scans, or hire someone to conduct a scan, get a report and then not follow through. They may cherry-pick one or two critical items and neglect the rest. The result is that the organisation has spent time and money without doing much for its security.
"Some organisations stop at detection as an end point," says Chenxi Wang, a principal Forrester analyst. "That tells you where you are, but doesn't do much for your risk posture."
Vulnerability and configuration management has to be remediated within a well-defined change-control process, supported by your vulnerability management tool and tied in to your control mechanisms, such as your ticketing system. The tool should support the process not only through vulnerability and error detection, but also through risk assessment based on the severity of the threat and the value of the vulnerable system. The process is not complete and the ticket can't be closed until a re-scan is conducted to verify that the remediation has taken effect (that is, the patch has been successfully applied or the configuration error corrected).
"Some organisations are very proactive, some are reactive," says Shaheen Abdul Jabbar, a security consultant. "I've seen security personnel perform scans, let the IT department know, but not go back and check if they were remediated until the next audit cycle."
DO use scanning services.
If you are subject to regulations that require periodic third-party scanning, you don't have a choice anyway. In that case, don't limit yourself to meeting the minimum regulatory requirements. Follow through with your remediation process, good auditors will insist on it.
Regardless of regulatory obligations, software-as-a-service (SaaS) and managed services are viable options for vulnerability management. Several of the top vendors are heavily or even exclusively focused on services, allowing them to serve as alternatives or supplements to in-house scanning. SaaS offerings, by their nature, are focused on public-facing systems; for more comprehensive scanning, service providers will put black box appliances on customer networks and report the results.
Some organizations have been leery of allowing all that data the scans collect to be shared outside the organization. Make sure you are satisfied that the data is protected by strong encryption with solid key management and that only your authorized personnel and no vendor employees, has access to that data.
Also, make sure that credentials for authenticated scanning are tightly secured, either through the vendor's own technology or a good privileged identity management vault product.
Vulnerability management as a service can save money on capital expenditure, management overhead and headcount.
In addition, consider bringing in consultants or service providers, at least periodically, to complement your internal scanning. Using a disinterested outsider protects against any in-house biases or self-protecting omissions from reports.
DO insist on usable reporting.
This applies at a number of levels. At the highest levels, of course, you want trending and overall status reports for management. At a security level, the vulnerability management tool should provide information on the severity of the flaw, based on standards such as the Common Vulnerabilities and Exposure (CVE) list or the Common Vulnerability Scoring System (CVSS) and weighted by the value the organisation places on the asset. The reporting should tell you what is vulnerable, how it is vulnerable and how high the risk is. Operational reports for those charged with remediation should be straightforward and task-oriented.
Patching and configuration change is usually going to be performed by network operations personnel and systems administrators. They are not security professionals, so the report and instructions should be described in terms of patches and configuration changes, not vulnerabilities.
Audit reports should clearly demonstrate that the vulnerability or configuration error was detected, the risk was assessed, a ticket was opened, the ticket was closed after the issue was remediated, and the remediation was validated by a final scan.
Finally, the reports should be able to repurpose the same data for different uses, reports for different parts of the organisation and types of audiences, reports for different sets of regulations, and so on.
"In the old days you ran new scan for every report," says Gary Davis, senior group manager for risk and compliance at McAfee, "but what you want is scan-once-report-many model that disassociates scanning from reporting."
DO integrate vulnerability management with other security tools.
Security information and event management (SIEM) heads the list. Vulnerability management is a critical source of information for SIEM as part of your overall risk management program. As soon as a vulnerability or configuration issue is detected, the information should be fed to the SIEM tool to correlate with information from other sources, such as firewalls and intrusion protection systems.
Vulnerability management also integrates well with intrusion protection systems, which can use asset inventory and vulnerability information to determine which attacks represent real threats and which can be safely ignored.
If the vulnerability management tool includes application scanning, the results can be used to create or modify protection rules for Web application firewalls.