Reports | Vulnerability Management

Reporting is an important part of vulnerability management and managing any process that can be measured. Before completing your evaluation of any vendor, a clear understanding among the key people involved in VM should be in place as to how the process of identifying and remediating vulnerabilities should be conducted. Then, ask critical questions about what managers, engineers, administrators, auditors, and risk managers need to know to perform their part of the process and get the most out of the system. This will lead to a definition of the reports needed. Consider distributing sample reports to stakeholders to make sure they are acceptable. Those reports have the following high-level requirements:

• Scheduling (frequency with which the reports will be needed): In some cases, reports are needed weekly to remediate the latest vulnerabilities, and in other cases, monthly to evaluate the security posture of the organization. In still other cases, reports may be needed every time a certain event occurs such as a threshold being reached on total risk to a critical target. Having an idea about the timing and frequency of all the reports will reveal what kind of scheduling flexibility is needed in automated reporting.
• Objective: Knowing the exact purpose of the report will often help identify whether the right report is present in the system or needs to be developed. Some reports produced by a system are titled differently but still may meet the objective. On the other hand, it is possible that the reverse may happen. A report may be titled “Audit Review,” which seems intended for the use of auditors; however, close observation may show that the report will not meet your specific auditor’s role definition. An ancillary point here may be that you should not be too quick to check a requirements box until you have verified the details of the reports.
• Format: Most reports are not very customizable. The order of the columns, sorting and filtering options, and header and footer content may be unsuitable for your organization. The latter requirement can be a significant problem. If a vulnerability report does not have the company-required document classification statement in the footer, and company logo or department name in the header, some concerns could arise with auditors looking for compliance in document handling. Also, the utility of a report can vary greatly with the sorting and filtering capabilities. If a scan results report can only be sorted by IP address and not by severity, perhaps the prioritization process cannot be efficiently conducted.
• Customization: When appropriate canned reports are not available, some access needs to be given to the database and schema to allow reports to be generated that simply aren’t available in the core product. This can also be provided with a report writer add-on. Any such add-on will have to be equally vetted with the requirements. Also, one must consider that additional products or consulting used will raise the overall cost of the system.
• Types: The most common critical areas for reporting are remediation, security posture, and process monitoring. The type of reports you will need will naturally depend on how your process works. Remediation reports should specifically facilitate the methods by which your process remediates. This sounds obvious but it is not. For example, a company may have a different group remediate vulnerabilities in each city or office network. So, the reports should be available by location.
  Alternatively, your organization may remediate by device type. For example, server administrators may all work for a global server group. Vulnerabilities for those servers would be assessed and prioritized, and work allocated by a central group. This may be the case even though the audit of those servers by the system took place as an audit of the overall network.
• Triggers: Some reports need to be generated when a certain set of conditions are met. These reports are typically e-mailed or copied to a specific location for retrieval. The triggering event can be when the vulnerability score or a particular target reaches a certain level or when a critical host has a certain severity of vulnerability. These reports would then be automatically e-mailed to specified persons who are necessarily authorized users of the reporting system.
• Roles: Any report should be configurable to be viewed or modified by specific roles. Those roles would be defined as system administrator, network owner, network group owner, or system (target) owner. There are two purposes for specifying which roles or combination of roles are permitted to access or modify a report:
  • Separation of duties: This assures that reports cannot be manipulated for a favorable outcome and contradict any performance penalty that may be weighed against a responsible party who fails to remediate systems.
  • Confidentiality of the data: Each report contains a potential gold mine of information to a hacker that could surely be used to assess targets and attack vectors.

• The most flexible approach to implementing roles is to allow the VM system administrator to create the roles and assign the users and user groups to those roles. More about role definitions later.

• Control: The reports should be filterable by network, IP range, system type, scanner, application, or network owner. You will quickly find that once the availability of good data is known by managers and engineers, they will ask for more. Having in-depth knowledge of the structure of local networks, network managers may ask for particular subnet reports and IP ranges even though the audit process takes place on all IP addresses that can be found. Essentially, what is audited for vulnerabilities is a superset of the reports requested by the network owners.
  Owners of applications may ask for reports showing the vulnerability state of the systems supporting their applications. This may include a combination of routers, firewalls, database servers, application servers, and Web servers. This may be especially important for SOX compliance or limited PCI audits. Large organizations with very limited PCI exposure will need to assess the vulnerability of any systems directly or indirectly related to payment processing. Being able to readily identify and audit those systems without clouding reports with vulnerability data from irrelevant systems can save time and cost in an audit. The same principle holds true for non-PCI financial systems. SOX compliance should not be seen as a reason to accept or reject functionality from the VM system; however, it can be helpful in evaluating controls related to financial systems. Public companies should carefully consider the real requirements of SOX in accordance with the 2007 SEC guidance on the topic. Vendors would be hard-pressed to provide solid advice and rationale directly related to SOX compliance and their products.