HomeServicesTvmContinuous Vulnerability Management

Continuous Vulnerability Management

Eliminate False Positives and Address Discovered Issues

SPEAK TO AN EXPERT
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /

VerSprite, Delivers Custom Remediation Information to Your Environment

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.

  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /
  • /

Manual Testing

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.

Remediation Guidance

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.

Retesting

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.