By using the approach listed below, VerSprite provides continuous vulnerability management to eliminate false positives, deliver custom remediation information to your environment, and address newly discovered issues:
Does the vulnerability make sense in the given environment? The issue can be quickly identified as a false positive if the scanner incorrectly detected the OS or server software installed (e.i. Apache vulnerability detected on IIS system).
Does the system have frequent false positives? For example, RHEL systems with backported security patches often trigger vulnerability scanners based on version numbers even though the issue may be patched.
Does the scanner provide output that shows the issue was exploited? With the right output it is often possible to determine the validity of an issue right away. If the scanner does not provide much output or simply detected the issue based on version number, then testing is required.
Can the issue be recreated manually?
Use manual techniques and non-scanner tools to confirm the issue.
Can the software and version be confirmed?
Manually fingerprint the affected host/service and compare the exact version numbers to known vulnerable versions.
Is the remediation suggestion given by the scanner accurate?
These suggestions can often be incorrect, outdated, or irrelevant to the specific system. Further research may need to be done to produce accurate information.
Is the remediation suggestion tailored to the environment?
The canned suggestions given by the scanner are often only relevant to one software stack. For instance, most suggestions provide guidance for remediating issues in Apache, but not IIS, Tomcat, or nginx.
Who should receive the remediation guidance?
Find out who owns the asset. Find out if developers need to be brought in. Find who has permissions to make and deploy changes.
Is the remediation guidance in terms the asset owner will understand?
Some asset owners are more technical than others. Some are technical but only in their specific niche. Tailor the remediation guidance by using terms that the asset owner will understand.
What is the best way to deliver the guidance?
The issue might need to be emailed out, put into a ticketing system, opened in a code management system, or some combination of all these options.
Did the issue appear in the next scan?
If the issue did not appear in the next scan, then this is a good indication that the issue no longer exists.
Does the issue warrant a manual retest?
Critical, high severity, or difficult to patch issues may warrant a manual retest to ensure the remediation was implemented correctly. These suggestions can often be incorrect, outdated, or irrelevant to the specific system. Further research may need to be done to produce accurate information.
Interested in learning more about VerSprite’s Continuous Vulnerability Management Service?
In this blog, we dive into and show how attackers could combine the 0day CVE-2020-0986 with the 0day in IE browser to achieve privilege escalation and then execute code remotely. Now, Maddie Stone, a security researcher on Google's Project Zero team, found that an attacker can still trigger CVE-2020-0986 and elevate kernel privileges by sending an offset instead of a pointer.