From the course: CompTIA Security+ (SY0-701) Cert Prep

Analyzing scan reports

From the course: CompTIA Security+ (SY0-701) Cert Prep

Start my 1-month free trial

Analyzing scan reports

“

- [Instructor] As a cybersecurity analyst, you'll likely spend a good amount of your time analyzing reports from vulnerability scans. One of your primary responsibilities will be sorting through the results of these scans, and presenting information from them to a variety of audiences. You'll need to provide engineers, developers, and administrators with the technical detail that they need to correct issues. You'll need to explain trends and high-level risk ratings to business leaders, and you'll need to present security management with a picture of how well the organization is doing at managing risk. As you interpret the results of any scan report, you should first focus on the five factors that we've already discussed: the severity of the vulnerability, the criticality of the systems affected, the sensitivity of information involved, the difficulty of remediation, and environmental variables such as the exposure of the system with the vulnerability. These five factors will help you triage the various vulnerabilities that you face, and feed the right priorities into your vulnerability remediation workflow. You'll need to evaluate them based upon the potential impact in your organization and industry, as well as your organization's risk tolerance. Before you request remediation of a vulnerability, it's important to validate the vulnerability. This is where you go beyond the information provided by the vulnerability scanner, and add some of your own security expertise to confirm that the vulnerability exists, and that it was properly rated in the prioritization process. The first thing that you should check during vulnerability validation is that the vulnerability actually exists as stated in the report. Vulnerability scanners do produce false positive reports for a variety of reasons. It could be that the scanner is using a signature that's not well-defined, or that the scanner is not able to detect the presence of a security control that mitigates the vulnerability. In any case, you should carefully review vulnerabilities, especially those that require extensive or disruptive remediation to verify that the problem they describe actually exists. The best way to do this is to review the details on the scan report. Remember the section that shows the output of the vulnerability scanner's test? Reviewing this section is a great way to figure out why the scanner reported a vulnerability, and whether it might be a mistake. For example, this report is showing a critical vulnerability in the version of the Ubuntu Linux kernel running on a host on the network. Clearly, this is important to address if it's true. The CVSS score is 10.0, and there's all sorts of dire language in this report about how an attacker could take control of the system. If I look at the output section of this report, I see that the scanner is providing me with the specific name of the package that's causing the vulnerability. To validate this report, I would want to review the alerts described in the report, understand the issue, and then log onto the system to confirm that it's running an affected version of the Ubuntu Linux kernel. Sometimes false positives are easy to clear. If I see a report that a Window server is missing a macOS patch, I can probably safely assume that it's a false positive report. It's still a good idea to dig in, and figure out why the report is occurring, but these things happen. In other cases, the organization might have already acknowledged that a vulnerability exists on a system and implemented a compensating control, or decided to accept the risk. Be sure to track these exceptions in your scanner, or in a configuration management database. You don't want to report a vulnerability that everybody already knew about. And it's very important to detect false positive reports and exceptions before escalating vulnerabilities for remediation, because you risk losing credibility if you become the cybersecurity analyst who cried wolf. If engineers and developers begin to doubt your thoroughness in screening vulnerability reports, they're much less likely to take your concerns seriously when you raise them in the future. As you prepare for the exam, you should be familiar with the four possible outcomes for any vulnerability report. If the vulnerability scanner reports a finding, and the vulnerability really exists, that's a true positive report. If the vulnerability scanner reports a finding, and the vulnerability does not really exist, that's a false positive report. There are also two outcomes that can occur, the vulnerability scanner does not report a finding. If there is no finding, and there was no vulnerability, that's a true negative report. But if the vulnerability scanner misses an actual vulnerability, that's a false negative report. You might find questions on the exam asking you to classify vulnerability findings using these terms.

Contents