Why Patching Won’t Eliminate All of Your Security Vulnerabilities - Atomicorp - Unified Security Built on OSSEC

Why Patching Won’t Eliminate All of Your Security Vulnerabilities

By Scott Shinn

Vulnerability patching is crucial but not a cure-all. Patching all your known software vulnerabilities in a timely manner may seal off specific backdoors but alone it represents a reactive, whack-a-mole approach to holistic vulnerability management. Go beyond patching: Detect and address backdoors and malware that patching won’t stop, and defend against whole categories of attack methods and threats that patching programs can’t cover.

Why patching won’t eliminate all vulnerabilities

Unpatchable IT and software vulnerabilities extend across numerous categories. Important subcategories include:

  • WontFix is a vulnerability sub-category or status in which the vendor won’t fix the vulnerability. Reasons often include that the version of the software is end of life or has no actual licensed users, or the flaw is too difficult or financially tolling to fix. In some cases, the vendor or software developer really can’t fix the issue. 
  • Configuration vulnerabilities. These are things like ports left open by default and other configuration settings that decrease security over an enterprise’s hosts and networks. Other configuration vulnerabilities include open permissions, inadequate protection of superuser privileges, and return error messages that reveal too much information, offering data a hacker will use in the next attempt. 
  • “It’s supposed to work that way” vulnerability. Developers, marketers, or bullish users might argue that a risky function is a feature, not a bug. In these situations, however, it’s critical to turn off vulnerable features, harden insufficient software vendor settings and defaults, and detect malware rapidly to prevent exploitation of connective, communicative, and transactional tools. Also be cognizant of junk DNA that may be in your software, that is, questionable software components. Be able to audit the composition of your software and determine if each element has a contributing function or represents a potential back door.
  • Obsolete (insecure protocol, cipher, etc). Cybercriminals and adversaries evolve. Older or EOL software versions, including in IoT appliances, past releases of HTTPS and TCP/IP protocols such as Telnet and FTP, and encryption and AV software, can leave organizations wide open against attack. Organizations and agencies need a nondisruptive (low bandwidth) way to detect expired security certificates, EOL software, and associated CVEs and other vulnerabilities across the software and security software they use or have accumulated.
  • Unknown vulnerability. The software vendor doesn’t even know it has a vulnerability to patch because the vulnerable component slipped in undetected through the commercial or open source software supply chain and the software package provider lacks adequate vulnerability detection of its own. For example, the multi-headed Sunburst SolarWinds attack involved exploitations of Microsoft and VMware vulnerabilities, and malware insertion into SolarWinds’ Orion IT monitoring software, and wasn’t discovered until months later by a third party security vendor which was also impacted.

There are also crucial vulnerabilities that go beyond software and into the physical world, into humans and human processes. (By the way, you can’t technically patch these vulnerabilities but you can reduce them through common weakness and enumeration [CWE] management and end user security training.) These physical world exposures take the form of:

  • Human vulnerabilities and vectors. In these cases, it’s not the software that is exploited at first; it’s an attack on human vulnerabilities such as naivety and lack of vigilance, using methods such as social engineering, rubber hose attacks, blackmail, bribery, and well-orchestrated and drawn-out psychological attacks like in the XZ attack (categorized as CVE-2024-3094), where the victim, a volunteer developer, was virtually browbeaten and then duped into taking action to allow backdoors in previously trusted open-source code. XZ compromised liblzma compression library, OpenSSH, the open source implementation of SecureShell (SSH), and might have made it into new Ubuntu and Red Hat Enterprise releases had it not been detected by a Microsoft developer running micro-performance tests.
  • Physical attacks. This subcategory might mean a compromise on the premises or in a cloud farm through insider involvement or intruder infiltration, resulting in data exfiltration, theft, sabotage, and even destruction of facilities. These attacks do happen, beyond fictitious mirroring in movies and TV shows, with the stealing of ‘smart’ card credentials and the impersonation of support staff representing real threats. In 2018, for example, a coordinated team of thieves stole servers and tech gear worth nearly $2 million from cryptocurrency mining data centers across Iceland, apparently to use the equipment for their own mining. Eleven arrests were made, including a security guard, but the heist’s mastermind subsequently escaped a low-security prison and disappeared into Sweden. 
  • Untrained end users. Employees, contractors and their equipment represent a promising entry point for hackers and cyber-adversaries. When left untrained, these oft-targeted humans might not be inherently tech savvy enough to recognize the telltale signs of identity or IP spoofing, social engineering, or emotional triggering. They might also click on, and click through, what looks familiar, trust too quickly, and too easily get duped into taking an action that results in financial loss or cyber or physical harm.

 

Vulnerability patching limitations and what you can do about it

Scan memory. Unlike a file system level scanner, a memory scanner will watch everything that utilizes the operating system. The advantage is better, deeper, real-time AV and antimalware coverage, and with Atomic OSSEC detection engine it’s not a big drain on memory or on processing power.

Identify vulnerabilities beyond known categories. Your vulnerability scanner should find things that aren’t CVEs. This means global threat intelligence (GTI) and the ability to identify MITRE CWEs and additional security flaw categories, which makes your security team better and gets them out in front of that frustrating ‘whack a mole’ mode.

Extend protection, and take some of the vulnerability out of the hands of end users. Get at those wide-ranging weaknesses through elimination of an entire class of web attack methods. For example, you can employ an advanced WAF to preempt social engineering and phishing attacks and reduce patching. Atomicorp’s web application firewall product, Atomic WAF, tackles the MITRE CWE category and more, enabling you to eliminate a weakness used by multiple attack methods, block malicious senders, addresses, and hidden malware, taking some of the pressure off your workforce. 

Never assume that zero vulnerabilities detected equals everything’s okay. This approach doesn’t account for those vulnerabilities that aren’t CVEs, that haven’t been discovered yet, or aren’t known except by the individuals that built them in. 

Address MITRE CWEs, CVEs, NIST NVD Guidance, and Other Vulnerabilities

Learn more about the extended detection, response and compliance capabilities from Atomicorp. 

Visit the Atomic OSSEC page.

Schedule a demonstration.

Check out our Atomic ModSecurity Rules offerings for the web application firewall ruleset or WAF solution that’s right for you.

Visit the Atomic WAF page.

Start a monthly ModSecurity Rules subscription (hosted)