In the realm of vulnerability management, many services chase volume. More scans in less time often equate to more profit. But this race can lead to a maze of false positives, repetitive issues, and a clog in your vulnerability management pipeline.
At Asteros, we prioritize clarity over quantity. As part of our suite of services, we offer both point-in-time and ongoing Threat & Vulnerability Management. Our methodology is meticulously crafted to minimize false positives. By providing relevant context to developers and asset owners, we ensure security issues are addressed and resolved swiftly.
Here’s an overview of our approach:
Initial Discovery
- Is the security issue relevant in the given environment? The vulnerability may be quickly eliminated as a false positive if the source scanner incorrectly detected the operating system or installed server software (e.g. An Apache vulnerability detected on a system running Nginx.).
- Does the system have frequent false positives? For example, Linux systems with backported patches often trigger vulnerability scanners based on version numbers even when the issue has already been patched.
- Does the source scanner provide evidence that a given vulnerability is exploitable? It is often possible to determine the validity and risk of an issue prior to reporting if a proof of concept exploit was successfully recorded.
Additional Testing
- Can the issue at hand be manually recreated? Manual testing techniques are often needed to confirm an issue exists, asses the severity, and gather information needed to determine appropriate remediation guidance.
- Can software names and versions be validated? Manually fingerprinting the affected host/service and comparing the exact version numbers to known vulnerable versions can help confirm the issue when other techniques are not possible.
Determining Risk
- Does the severity level assigned by the detection tool apply to your enterprise? Vulnerability scanners give severity ratings using the information available when the plugin was added. Scanners are not able to consider industry specific concerns and conditions change – public exploits may be released, or it may be discovered that initial fears surrounding the issue were unfounded.
- Does a risk-based assessment of the vulnerability call for an escalation or de-escalation of the assigned severity in the given environment? A thorough understanding of the organization and the specific risks is needed to correctly identify the threat level.
Remediation Steps
- Is the remediation suggestion given by the scanner accurate? As with vulnerability information, data from detection tools is often incorrect, outdated, or irrelevant to the system in question. Additional research may be needed to determine accurate remediation guidance.
- Is the given remediation guidance tailored to the environment? The default suggestions given by tools are often only relevant to certain software stacks. For instance, remediation steps may be given for Apache when the issue was detected on an IIS server.
Reporting
- Who should receive the vulnerability and remediation information? Traditional reporting may not reach all those needed to sufficiently make system or application changes. Asset owners, developers, and managers are brought in as necessary.
- Is the remediation guidance in terms the audience will understand? Some audiences are more technical than others. Some individuals may only be experts in their specific niche. Reports are tailored as much as possible to those receiving it.
- What is the best way to deliver the guidance? Large PDF reports or tool exports are often intimidating and go unread. To see an issue through to remediation it may need to be emailed out to certain teams, filed into a ticketing system, assigned via an issue tracker, or a combination of reporting methods.
Retest
- Did subsequent scans contain previously reported vulnerabilities? If so, remediation may have stalled, and escalation may be required.
- Does the issue warrant a manual retest? Issues of critical or high severity may warrant special attention to confirm proper remediation. Others may be difficult to patch and need checks to ensure remediation was implemented properly.