The Value of CWE vs CVE in Securing Devices
By Dave Stuart, Sternum
Continual patching is an age-old approach and a persistent problem for smart device manufacturers and users alike — but that’s about to change. Exploit prevention will revolutionize how we secure IoT.
The IoT cybersecurity problem is vast
There are over 29 billion connected IoT devices, sensors, and actuators currently installed across the globe. That’s a large attack surface ripe for exploitation. It is estimated that more than half of these IoT-enabled devices are potentially vulnerable to low or high-security risks and attacks.
Attackers often exploit common vulnerabilities and exposures (CVEs) to get into a device, and then use that foothold to launch other attacks as they go about their attack objectives. The Unit 42 “2022 Incident Response Report” found exploiting software vulnerabilities was the second most commonly used attack method by hackers. In fact, nearly one in three, or 31%, of the incidents they analyzed were the result of an attacker gaining access to the enterprise environment by exploiting a software vulnerability. These attacks can have significant and far-reaching consequences – it’s estimated cybercrime costs the global economy about $1 trillion (more than 1% of global GDP).
So, what can device manufacturers do to try to close this large attack opening? We’ve come to the conclusion the answer doesn’t lie with trying to patch vulnerabilities after they have been discovered, but rather with preventing common software and hardware weaknesses from being exploitable in the first place. That way it doesn’t matter what vulnerabilities exist (both known and unknown) because they can’t be used to get into a device.
Endless Patching is Not Working
The 2021 Attack Surface Management Threat Report revealed attackers often start scanning for vulnerabilities within 15 minutes of a CVE being announced. When the vulnerabilities are significant enough, it’s not unusual to see scanning by attackers practically coincide with the announcement of the vulnerability. This doesn’t give manufacturers much (any) time to issue a patch and even less time for customers to deploy that patch to protect their environment. That’s assuming a patch is even feasible.
The hands of device developers are often tied if the vulnerability is within any of the third-party software libraries they rely on for communications, encryption, authentication, OTA updates, and other basic functions. Without visibility into this third-party source code (it’s often delivered in binary form), developers have no way of understanding how to create a viable patch to protect the overall device.
Developers are further hampered by the sheer mix of technologies – old and new operating system versions, code bases, etc. – that make up their fleet. Building and issuing patches for all the different device profiles in play can be extremely time-consuming and costly (going into the millions). For some of these devices, it’s impossible, as they can’t be reached or taken offline at all, given their location or criticality (e.g., pacemaker).
It’s clear patching isn’t effective or fast enough to shut down the risks posed by IoT device vulnerabilities. What’s needed is something that can fight the exploits themselves – something that can prevent attacks regardless of what the underlying vulnerabilities are. This is what can be accomplished if you focus on combating common weakness enumerations (CWEs), which is what Sternum does to fight exploits in real-time.
CWE Mitigation: Blocking the Exploit Path
Blocking exploits as they occur is a more sustainable approach. Most attacks against device vulnerabilities share common exploitation methods – such as memory overflow – as a prerequisite step. Therefore, if we stop memory overflow, we stop all identical exploitation against numerous similar memory vulnerabilities regardless of attack path, operating system, device type, etc. Doing the same for the other CWE categories provides comprehensive protection and secures the device from both known and unknown (zero-day) attacks.
CWEs, originally defined by MITRE, are common families of vulnerability types. These include memory corruption (heap and stack buffer overflow) and in-memory vulns (use after free, double free, etc.), command injection, and execution flow disruption that can be immediately halted, and hence prevented.
Other CWEs comprise vulnerabilities for suspect activities (such as DDoS indicators, brute force login attempts, data theft or known malicious IP accesses that are familiar security threats) that can be detected by Sternum and then dispatched based on rules/policies configured by the user.
Sternum EIV protects from CWEs and not CVEs, deterministically blocking vulnerabilities in bulk
Sternum EIV works by embedding integrity verification checks at every point of a device’s memory operation and autonomously inspecting and validating those operations at runtime to ensure the firmware and code are only doing what they are designed to do. Any deviation is immediately prevented in real-time. This enables device manufacturers to get out of the vulnerability rat race, preventing whole classes of threats by stopping exploits (CWEs) from being used by bad actors to perpetrate their assaults.
Vulnerabilities become less critical – an unexploitable vulnerability can no longer be used to gain a foothold. By ensuring the code is only doing what it should, manufacturers have a precise, deterministic security solution for their IoT devices that works every time and place the code executes.
Testing this approach showed its effectiveness – against benchmarking tools (RIPE) it achieved a 95% prevention rate and full coverage of all top IoT vulnerability classes (OWASP Top 10, MITRE Top 25).
ROI of Exploit Prevention
Exploit prevention reduces the need for patchwork. One medical device manufacturer who implemented Sternum saw nearly a 25% reduction in their patch volume and had labor savings in the millions of dollars. Their fleet, numbering over 100K devices, became safe from common known and unknown vulnerabilities, which allowed a more regular cadence/orderly role out of planned software releases. FDA certification was also streamlined since Sternum did not change the code structure or device function. Their engineering teams were freed to do more valuable work.
As of this writing, there are 1,327 CWEs across 352 categories (source: MITRE). By contrast, there are thousands of individual vulnerabilities (CVEs) disclosed monthly. It’s simple math to realize the effectiveness of prevention by halting CWE exploitation versus trying to win the endless patching race.
To see for yourself how to get out of endless patching and into self-healing devices that can prevent the exploitation of both known and unknown vulnerabilities and weaknesses that may exist, check out Sternum IoT Security.
