The modern organization’s tech stack is a lurid mix of bespoke configurations and commercially-available applications. New and innovative solutions crop up every few months, uniquely solving decade-old business challenges. However, the speed at which these applications are developed may be leaving gaping holes in your company’s defenses. Solid patch prioritization and RASP security can now free you from the ever-expanding grip of software flaws.
Software Vulnerabilities Are Out Of Control
2021 marked yet another year of sky-high rates of software flaws. A record-breaking 28,695 flaws were published throughout the year – a staggering increase from 2020’s 23,269. Of 2021’s flaws, more than 4,000 allowed cybercriminals to remotely run code via a public exploit – while also having a patch available.
While this is promising on the surface, compare the 4,100 remotely exploitable bugs with CISA’s known exploited vulnerabilities catalog. This decade-long list of exploitation risks discovered in the wild only contains 360 major issues. One component to the rapidly-expanding list of vulnerabilities is the very apps that you rely on day-to-day. Taking a peek behind the scenes of app development reveals a frantic, high-speed race between security demands and time to market. This rapid development process has seen entire workflows shifted to better accommodate its pace. Instead of traditional waterfall development – which sees devs design, build, and finally ship an application – an agile workflow now allows for high-frequency iterations and releases.
An agile environment often translates to a wildly dynamic build structure, as new modules are regularly crafted and added to the app throughout the entire software development life cycle. Constant iteration, even after release, allows the app to switch course often – in reaction to both customer demands and security issues. This process gives us a revelatory insight into the cause of these flaw explosions: though addressing problems early on sounds great for security, this process is entirely reactive. Modern production code now leaves a trail of thousands of victims in its wake.
Why Patching Isn’t Working: The Case Of Log4j
Continuing from the statistic of over 4,000 remote code execution (RCE) bugs, researchers clarified that organizational risk can be reduced by 86% by prioritizing patching based on severity.
However, the patching process is easier said than done – both for your security teams and the developers creating these patches. Once a zero-day vulnerability is discovered, developers must first clarify the attack path and then code a fix. Towards the tail-end of 2021, the world first caught a glimpse of the highly dangerous vulnerability within Log4J, an open-source logging function used by just about every cloud service and enterprise network on the market. This highly-critical vulnerability risk enabled RCE through an incredibly simple exploit path.
The developers quickly released an update to patch the RCE flaw and urged all users to install it immediately. One week later, researchers started reporting on at least two vulnerabilities in this patch. Attackers had already begun actively exploiting one or both of them against real-world targets who have already applied the update. The initial patch had been completed so hastily that the developers ended up releasing an incomplete fix, only worsening the ensuing security nightmare.
The initial patch – specifically 2.15.0 – made it possible for attackers to perform denial-of-service attacks, which in turn paved the way for attackers to take vulnerable services completely offline until victims reboot their servers. Shortly after the denial-of-service vulnerability was discovered, researchers returned with even more grim news. 2.15.0 also included a serious information disclosure flaw that allowed for data to be remotely downloaded from affected servers.
Eventually, one week after the initial patch came along, 2.16.0 was released, fixing almost all of the aforementioned issues – and adding a brand new Denial of Service attack vector.
With three patches that failed to completely secure the lookup function, the developers’ battle to cut out fresh vulnerabilities remained only one-half of the issue – it’s still necessary for organizations to apply each patch. This process saps an incredible amount of time and resources from your company: organizations spend 321 hours a week on average – the equivalent of about eight full-time employees – managing the vulnerability response process.
Lengthy patch processes aren’t the only cause for organizations lagging behind. Delays in patching are often caused by security and IT teams having very different views of relevant applications and assets. Another major obstacle is the resource drain that the vast quantities of patches exacerbate.
Managing Vulnerabilities At Scale
Manual patching is incredibly resource-intensive. The recent 2022 AppSec Progress Report has suggested that making a distinction between genuine vulnerabilities and their false positive counterparts can help streamline patch prioritization. By focusing on the attackable vulnerabilities, your security teams can focus on genuine weaknesses in the tech stack. Data from the report saw a 97% reduction in false-positive tickets once attack ability was taken into account.
Defining attack ability involves assessing whether the flawed package is loaded by the application; whether the package is in an attacker-controlled path, and whether it is accessible via data flows. In essence, it’s a process of threat modeling open source vulnerabilities, in order to manage the spiraling demands placed upon security teams.
For applications containing critical flaws, virtual patches can further aid in large-scale vulnerability risk management. Application-specific options include Web Application Firewalls (WAFs), which monitor an app’s external connections. By sitting at the perimeter of a vulnerable app, a WAF will prevent the app from connecting to malicious third-party command and control servers. While a WAF controls its connections, a Runtime Application Self Protection (RASP) solution monitors the behavior and inner workings of the application. If RASP detects the app making unexpected queries, it automatically reports and shuts down the process. These solutions – combined with your own understanding of the attack surface – empower a proactive and efficient vulnerability response process. Future-proof your vulnerability management process with a holistic and efficient approach.
