CySA+ domain #6: analyzing vulnerability scan results
Introduction
Being able to both understand, configure and properly use vulnerability scanning tools is one thing, but being able to properly analyze vulnerability scan results is quite another.
This article will detail how to analyze reports from a vulnerability scan and how to validate results and correlate other data points. This article corresponds to the CySA+ certification objective 2.2, and by the time you are done reading this article you will have a solid understanding of the material covered by this sub-domain.
Analyze reports from a vulnerability scan
Vulnerability scans often provide cybersecurity analysts with a high volume of information that you will need to know how to read to understand the report. After reading these report findings, it is commonly expected for cybersecurity analysts to conduct their own investigations to confirm that the vulnerability exists and its severity. External data sources may be used to help assist with this process.
The following factors should be considered by cybersecurity analysts as they analyze vulnerability scan results.
Identifying false positives
While vulnerability scanning tools are very useful, they aren’t foolproof. False positives are vulnerabilities listed in the vulnerability scan results that do not really exist. One example of a false positive is when a vulnerability scan picks up an IIS web server vulnerability on a Linux system that is running Apache.
Unfortunately, the causes of false positives are legion. Some of these include the scanner not having sufficient access to a system to confirm a vulnerability, or simply having an error in one of its plug-ins that generated the erroneous report.
Cybersecurity analysts should take the time and effort to verify each vulnerability that their report lists. They should use their combined knowledge and expertise in cybersecurity to confirm whether the vulnerability is a legitimate vulnerability (Read more...)
*** This is a Security Bloggers Network syndicated blog from Infosec Resources authored by Greg Belding. Read the original post at: http://feedproxy.google.com/~r/infosecResources/~3/oNsL7aWNlWU/