Vulnerability Management – Reporting

It is the third post in the Enterprise Vulnerability Management series, Vulnerability Reporting. As usual, I have highlighted that not all suggestions here can fit every possible situation. However, fear not! We can tweak and adapt these recommendations to cater to your needs.

The Vulnerability Reporting is crucial in conveying information and insights in today’s fast-paced world. It communicates between organizational stakeholders, providing a comprehensive overview of various activities and performance metrics. When it comes to preparing and presenting reports, several key factors must be considered. Once the data has been collected, it is essential to structure the report logically and coherently. To enhance the report’s readability, we can include visual aids such as charts, graphs, and tables. These visual representations not only make the information more digestible but also help to highlight key trends, patterns, and insights.

In the preceding article, we delved into creating a well-defined scan schedule. With this present discourse, we shall focus on the crucial aspect of scan results. Following the completion of scans, the vulnerability scanning platform undertakes results processing, making them readily accessible for customers to leverage. The outcomes are conveniently furnished through a user interface (UI) and API interfaces, rendering them effortlessly consumable. Notably, in select cases, the scanning platform also offers pre-existing integrations with prominent reporting or visualization tools. Alternatively, organizations may devise their reporting mechanisms and seek integration accordingly, relying on the capabilities and available resources.

Let’s now learn about processes and reporting formats which will be helpful.

• Reporting Schedule : The standard should define how should frequently the vulnerability reports should be produced. If the organization has yet to accept a dynamic/aggressive scanning schedule, the organization can opt for a weekly or slower reporting schedule. But as a strategist, we must also think about ad-hoc scans. If a slower reporting schedule has been opted for, how can the daily ad-hoc/remediation scans report be ingested into the reporting platform?
• Report Attributes : When we are working on the report templates, we should ensure we are capturing the required attributes and also making sure that we are not overloading the reports. Let’s list them below:
  • IP Address
  • FQDN : DNS address of the asset.
  • Port : Port on which service was listening. A server can have a service running on multiple ports in a few scenarios. For example, an Apache server could serve different applications on ports 8080, 8085, and 443. A vulnerability can be present in the application serving on 443 but not in the application serving on 8080. So, if the port information is shared, the patch responsible team will know which application to fix.
  • Protocol : The protocol of the service detected.
  • Vulnerability Information
    • Unique ID
    • Name
    • Remediation : This should contain details about fix.
    • Detection Output : This should contain details about the vulnerability detection. Example: Path of vulnerable executable/configuration file etc. If the vulnerability is detected remotely then service response.
    • Patch Available : If a patch is available for the mentioned vulnerability.
  • Severity
    • It could be Critical, High, Medium, Low etc. Few scanning platform also provide informational vulnerabilities which can be used to complement the insights about the assets vulnerability posture. Some information vulnerabilities also help with the troubleshooting scans like below ones:
      • Scan Information
        • Scanner : The scanner IP which was used to scan the asset.
        • Scan Launch Time : The timestamp when scan started on the asset.
        • Scan Template
      • Enumerated Ports/Services
      • Credential used for authentication
      • Authentication Success
    • The severity assignment should also be carefully reviewed. Usually, the scanning platform assigns the severity based on the CVSS calculator and also provides an advanced scoring system that includes the exploitability ease/availability and patch days. Tenable has VPR, an enriched version of the CVSS scoring—for example, Qualys, ORCA Security. Few organizations adopt their scoring mechanism by leveraging Temporal Score & Environmental Score. Since each asset is assigned a score against CIA components and network hosting, it helps to fine-tune the final applicable severity score.
  • State
    • The state of the vulnerability. Typically scanning platform adopts categories like
      • New : The vulnerabilities which have been found for the first time on the asset.
      • Active : The vulnerabilities which were found during previous scans and have not been fixed yet.
      • Fixed : The vulnerabilities which were found to be no longer active on the asset in the recent scan.
      • Reopened : The vulnerability which was fixed during previous scan but has been found again on the asset.
        • This is quite frustrating for the patching team but we need to understand that it could happen for multiple reasons.
          • The applied patch/workaround has been removed.
          • The detection logic available to the scanner has been modified. This can also result in fixing of the vulnerabilities.
  • Remediation Timeline
    • We need to include the remediation timeline as per the adopted standards. We can consider either of the 3 date as the first day.
      • The date on which Vulnerability was made public. Usually this information is available in CVE details.
      • The date on which the vulnerability was found on the assets.
      • The date on which patch was made available.
    • The remediation duration can be selected based on industry standard as well as organization own’s risk appetite.
      • Critical – If the vulnerability has been considered as emergency, the patching should be done at the earliest typically ranging from same day to 7 days. If the vulnerability is yet not being exploited or exploit is not public, aim to fix within 15 days.
      • High – Aim to fix within 30-45 days.
      • Medium – Aim to fix within 3 months.
      • Low – Aim to fix within 6 months.
  • Good to Have Attributes
    • MAC Address
    • Operating Systems
    • Vulnerability Exposure
      • Public Vulnerability : This information will be enriched with the asset inventory attributes, or if the scan is running in a context-aware scenario, then the scan naming convention could be used to attach a relevant tag.
      • Exploit Available
      • References : Vendor/3rd Party links discussing vulnerability remediation or exploit scenarios can be helpful to the responsible team in understanding the remediation or the ongoing exploit attempts.
    • To learn more about different severity levels and remediation, please refer here.
  • Relevant Timestamps
    • First Found At : The timestamp when the vulnerability was first found on the asset.
    • Last Found At : The timestamp when the vulnerability was recently found at.
    • Last Fixed At : The timestamp of the most recent scan when the vulnerability was fixed.
    • # of times Vulnerability found : The number of times, the vulnerability was detected on the assets.
    • Last Reopened At : If the vulnerability was re-opened then the timestamp of the detection.
    • Last Scan : The timestamp of the most recent completed scan.
    • Last Authenticated Scan : The timestamp of the most recent successful authenticated scan.
  • Patch Compliance
    • If still under accepted remediation timeline?
    • If exception approved?
    • If false positive request approved?
• Report Format
  • Full Export : Helpful for the patching team as it provides full information about the vulnerability as well as the asset information
  • Executive Format : The report prepared for the leadership or executive team will have only high-level information with a trend attached to understand the success of the program.. Few of them are listed below
    • Total Assets Scanned
    • Total Authenticated Assets
    • Assets/Vulnerabilities by Operating Systems
    • Total Open Vulnerabilities & By Severity
    • Total Fixed Vulnerabilities & By Severity
    • Top 10 Open Vulnerabilities By Severity
    • % Patch Compliance
    • Top 3 Vulnerable Environments/Units on Assets/Vulnerabilities
    • Top 10 Publicly Exposed Services

Once the report is available for consumption, the patching team starts analyzing the information and fixing the vulnerabilities, but in some scenarios, they face hurdles in applying the fix.

False Positive : Since scanning platform detection is not always fool-proof, there are chances that a vulnerability has been falsely detected on the assets. In such cases, the patch team returns to the VM team and clarifies the fixing strategy. During initial troubleshooting, we leverage the detection output, part of the report to verify why this vulnerability was detected on the asset. If it doesn’t look conclusive, we reach out to the scanning platform support group to understand under what context the platform is seeing the vulnerability and compare that with the vendor advisory. If there is conflict and it looks conclusive that the asset is unaffected, we process the exposure as a false positive. Based on the scanning platform capability, we can mark this as a false positive or include it to ignore it while creating reporting.

Exception : There are also some scenarios where the patch team can not implement a fix because of the inability to deploy patches or obtain downtime approval for installing the patch and restarting the services. Hence, they would request an exception to relax the remediation timeline. Based on the organization’s risk appetite and the vulnerability & asset exposure, the security team can review and approve the exception. The approved vulnerability can be dropped from the reporting.
This post helped to learn about the reporting aspects of the EVM process. In the next post, we will discuss another part of reporting, i.e., the Dashboard. We will also talk about how to monitor the progress and continuously make an improvement.