Vulnerability Scan Reports: Tired of Marking False Positives?

The dreaded false positive exhaustion experienced by analysts brings with it numerous issues. Analysts begin ignoring reports, reviewing a false positive takes time and money, and incident response and threat hunting are affected. Scanning vendors continuously improve their procedures to better prevent false positives, but they still continue to have an impact on IT operations. The impact of false positives can be severe when benign reports create exhaustive overhead for your analysts. Worse yet, explaining to auditors why some items were marked can be tricky.

Contents:

1. The Effects of False Positives on the Organization
2. Why Do False Positives Appear in Linux Kernel Scanning?
3. How Does KernelCare Enterprise Address the False-Positive Issue for Linux Kernel CVE Scanning?
4. What is Included with KernelCare Enterprise to Make Enterprise Vulnerability Management Flawless?

The Effects of False Positives on the Organization

The initial step in patch management is scanning servers and devices for information about their currently installed operating system and software versions. Ideally, the scanner has the proper permissions that tell banners to return the information needed to complete the scan, but misconfigurations can lead to incomplete or incorrectly returned data.

Scanners use a database of Common Vulnerabilities and Exposures (CVEs) and compare results to the reported versions on a server. If an outdated version is found, then the server is flagged for patching and marked as vulnerable. For a large organization, this automated system significantly improves the cybersecurity posture of the enterprise, reduces overhead on administrators, and keeps the company compliant with regulatory standards.

Issues arise when the scanner can’t poll the operating system fully. If scanners do not return accurate information or the operating system itself isn’t returned to the scanner, it reports the server as potentially vulnerable. This creates a false positive and requires administrator intervention. For an enterprise with hundreds of servers reporting false positives, the issue causes alert fatigue, which is a common phenomenon in analysts positions when vulnerability scanners inefficiently deal with false positives.

In a recent Ponemon report, 58% of respondents indicated that their Security Operations Center (SOC) was ineffective, and 49% of these respondents said that the reason behind inefficiencies is too many false positives. In addition to false positives causing inefficiencies, 42% of respondents also indicated that false positives interfered with threat-hunting teams. The number one recommendation from respondents was to better improve automation tools and analyst workflows.

Why Do False Positives Appear in Linux Kernel Scanning?

The most common reason for false positives is authentication or authorization issues. Giving a vulnerability scanner open access to the network with full privileges also has its own issues. Unauthenticated scans are also an option, but this increases the network attack surface by allowing anyone access to verbose server information. Unauthenticated scans provide attackers with enough information to exploit server software with known vulnerabilities.

Scanners perform banner grabbing to get current software versions. System banners contain the software name and version, and scanners need access to this information to report accurate data. This information can be critical and disclose server vulnerabilities, so it’s often protected with authentication rules. However, if scanners don’t have access, a banner could return vague or incorrect information. For instance, a banner could return “Unknown Linux” to a scanner and trigger a false positive as the scanner is unable to determine if the operating system is fully patched.

Scanners need authenticated access but authentication could cause issues, so what should administrators do? Here are some best practices to avoid false positives:

• For unauthenticated scans, do not provide critical information such as software or kernel versions.
• Know what information is returned from authenticated and unauthenticated scans. Review banner information using initial tests.
• Train vulnerability scanners by marking false positives in the software so that they are suppressed in the future.
• Finely tune scanners by configuring and testing them to return banner information using least privilege standards.

How Does KernelCare Enterprise Address the False-Positive Issue for Linux Kernel CVE Scanning?

KernelCare works with automation and scanning software to patch Linux without risky reboot requirements. Rebootless Linux patching benefits large enterprise networks with critical servers that can’t be reboot indiscriminately. KernelCare performs patches by fixing security issues in the source code, generating binary blobs with secured code, and replacing insecure binary code in a running kernel with the secure version.

While patching the security vulnerabilities, KernelCare doesn’t change the kernel version. The end result is that the currently running kernel will be fully patched, in memory, from the security perspective, yet /proc/version will continue to show the vulnerable version of the kernel.

Qualys and other vulnerability scanners don’t verify the actual presence of a vulnerability in the kernel by trying to exploit it. Instead, they detect the running kernel version by collecting server information from the /proc/version file. After detection of the kernel version, vulnerability scanners check their own database of vulnerabilities against the reported kernel version. As a result, even after KernelCare patching, Qualys will see the vulnerable version of the kernel and assume that that version still has security vulnerabilities, even though they were fixed in memory at runtime.

To help deal with this issue, KernelCare provides vendors with kcarectl –uname command-line utility that shows the patched version of the kernel, representing the security level of the kernel up to the reported patched version. Additionally, KernelCare provides a report by running kcarectl –patch-info (and through API) that presents the CVEs that were patched in the currently running kernel by KernelCare.

What is Included with KernelCare Enterprise to Make Enterprise Vulnerability Management Flawless?

KernelCare Enterprise is made for powerhouse organizations with 1000 or more servers. Without automation tools, these organizations would suffer from costly overhead involved with manual patching and scanning. Monitoring servers for patch updates, testing, and performing the actual patching would be a full-time job for multi-team staff.

To facilitate faster and more efficient patching, KernelCare Enterprise directly integrates with scanners and automation tools, provide better control of your patching server, and gives you better round-the-clock support.

KernelCare Enterprise (KCE) provides:

• Integration: KCE is ready-made for all the popular automation tools including Ansible, Chef, and Puppet. It also integrates with vulnerability scanners such as Nessus, Qualys, and Rapid7, and with cloud monitoring tools such as DataDog.
• High-End Support: We give our enterprise clients priority support 24 hours a day, 365 days a year, including a live chat option
• More Control: KernelCare Enterprise includes our secure ePortal server, which is a configurable patch server that runs behind your firewall. You take control of the ePortal server, manage and audit it whenever you need to.

Conclusion

Alert fatigue and analyst burnout are real issues that create employee turnover, severe overhead for administrators, and costly inefficiencies. KernelCare Enterprise can help reduce excessive false positives and perform rebootless patching to keep critical servers patched for the latest CVEs.

Learn more about KernelCare Enterprise offering.

Get a FREE 7-Day Supported Trial of KernelCare