- play_arrow What's New for Users in JSA Vulnerability Manager 7.4.0
- play_arrow Installations and Deployments
- Installations and Deployments
- Vulnerability Backup and Recovery
- Ports Used for Communication Between JSA and JSA Vulnerability Manager Managed Hosts
- Options for Moving the Vulnerability Processor in Your JSA Vulnerability Manager Deployment
- Options for Adding Scanners to Your JSA Vulnerability Manager Deployment
- JSA Vulnerability Manager High-availability Scans
- Extending the JSA Vulnerability Manager Temporary License Period
- JSA Vulnerability Manager High-availability Scans
- play_arrow Overview Of JSA Vulnerability Manager
- play_arrow Vulnerability Scanning Strategy and Best Practices
- Vulnerability Scanning Strategy and Best Practices
- Scan Policy Types
- Scan Duration and Ports Scanning
- Tune Your Asset Discovery Configuration
- Tune Your Asset Discovery Performance
- Web Application Scanning
- Scanner Placement in Your Network
- Dynamic Scanning
- Network Bandwidth for Simultaneous Asset Scans
- Network Interface Cards on Scanners
- Vulnerability Management for Asset Owners
- Vulnerability Scan Notifications
- Triggering Scans of New Assets
- Configuring Environmental Risk for an Asset
- External Scanning FAQs
- play_arrow Scan Configuration
- play_arrow Authenticated Patch Scans
- play_arrow Scanning on Windows-based Assets
- Scanning on Windows-based Assets
- Configuring an Authenticated Scan Of the Windows Operating System
- Remote Registry
- Enabling Remote Registry Access to Assets on the Windows Operating System
- Assigning Minimum Remote Registry Permissions
- Configuring WMI
- Setting Minimum DCOM Permissions
- Setting DCOM Remote Access Permissions
- Administrative Shares
- Enabling Administrative Shares
- Disabling Administrative Shares
- Manually Configuring NTLMv2 Authentication to Prevent Scan Failures
- play_arrow Vulnerability Exception Rules
- play_arrow Scan Investigations
- Scan Investigations
- Searching Scan Results
- Including Column Headings in Asset Searches
- Managing Scan Results
- Republishing Scan Results
- Asset Risk Levels and Vulnerability Categories
- Asset, Vulnerability, and Open Services Data
- Viewing the Status Of Asset Patch Downloads
- Vulnerability Risk and PCI Severity
- Troubleshooting Scan Issues
- Emailing Asset Owners When Vulnerability Scans Start and Stop
- play_arrow Management Of Your Vulnerabilities
- Management Of Your Vulnerabilities
- Common Vulnerability Scoring System (CVSS)
- Investigating Vulnerability Risk Scores
- Custom Risk Classification
- Searching Vulnerability Data
- Vulnerability Instances
- Network Vulnerabilities
- Asset Vulnerabilities
- Open Service Vulnerabilities
- Investigating the History Of a Vulnerability
- Reducing the Number Of False Positive Vulnerabilities
- Investigating High Risk Assets and Vulnerabilities
- Prioritizing High Risk Vulnerabilities by Applying Risk Policies
- Configuring Custom Display Colors for Risk Scores
- Identifying the Patch Status Of Your Vulnerabilities
- Removing Unwanted Vulnerability Data
- Configuring Vulnerability Data Retention Periods
- play_arrow Vulnerability Remediation
- play_arrow Vulnerability Reports
- play_arrow Scanning New Assets That Communicate with the Internet
- Scanning New Assets That Communicate with the Internet
- Creating an Asset Saved Search for New Assets
- Creating an On-demand Scan Profile
- Creating a Policy Monitor Question to Test for Internet Communication
- Monitoring Communication Between New Assets and the Internet
- Configuring an Offense Rule to Trigger a Scan
- play_arrow Security Software Integrations
- play_arrow IBM Security SiteProtector Integration
- play_arrow Vulnerability Research, News, and Advisories
- play_arrow JSA Vulnerability Manager Engine for OpenVAS Vulnerability Tests
False Positives Management
Commonly, false positives in vulnerability scanning occur when the scanner can access only a subset of the required information, which prevents it from accurately determining whether a vulnerability exists.
To help reduce the number of false positives, you must configure your scanners with the appropriate credentials. The scans need access to all of the asset information required information from assets so that you can accurately determine whether a vulnerability exists.
Why do False Positives Occur?
A false positive might occur when the scanner can read only the configuration information from service banners. For example, a scanner that reads an Apache banner can detect that only version 2.2.15 is installed from the HTTP banner, even when version 2.2.15-39 is also installed and that the version contains a software fix that was backported.
Another example is when the scanner reads the banner and detects the version of SSH that is installed, but can't detect the patch level or the operating system. If the scanner detects that SSH-2 is installed but can't determine the operating system, the scanner can't accurately determine whether a vulnerability exists in some instances. The vulnerability might be correctly identified on one asset but is a false positive on the other asset because SSH vulnerabilities on Red Hat SSH might not be the same for other Linux operating systems.
Why Don't Scanners Retrieve All the Required Information
Vulnerability scanners can't always access the information that they need to accurately determine whether a vulnerability exists. This limitation commonly results in false positives.
Scanner can't authenticate--
If the scanner can't authenticate on the end point, the scanner must rely on the limited information from anonymous network services probing such as the information retrieved from reading banners.
Banners might contain incorrect versions and outdated patch-level information, which results in false positives. However, if the scanner can authenticate, it can determine the full version of the operation system and patch-level information, and then suppress any false-positive vulnerabilities.
Best practices about banners --
Use these best practices about banners when you set up vulnerability scanning in your network:
Don't include detailed or sensitive information in a banner because a hacker can get crucial information about the applications and services that are running on an asset and then use known vulnerabilities to exploit them.
Know the type of information that is available anonymously in banners. Assess the likely attempted attack vectors. This information is helpful for assessing your network security, and for gathering network information.
Flag vulnerability information that is read from banners as false positives by tagging the vulnerability as an exception from tabs such as the Vulnerability Instances pane of the Asset Details window or the Vulnerability History window.
Tune scans by enabling or disabling tools in scan policies that can prevent these scans from starting.
Authenticated Windows Based Scan Techniques
Authenticated Windows based scanning uses the following two techniques to detect vulnerabilities:
Registry scanning where the scanner needs access to the registry.
OVAL scanning where WMI (Windows Management Instrumentation) must be configured correctly.
If either of these two techniques fail, then the scan result is prone to false positives.
You must enable the remote registry service for the scanner to access the registry.
Misconfiguration of WMI (Windows Management Instrumentation) can generate false positives.
Identify Authentication Failures
If a scan does not authenticate successfully, hover your cursor over the warning symbol see why the scan encountered issues. For example,
The last scan of this asset failed STATUS_LOGON_FAILURE
Therefore the vulnerability may not be accurate
Other examples of warnings messages include, SSH logon failure, remote registry
service not started, and no WMI access.
