The life cycle of vulnerabilities isn’t always linear, but there are common themes that emerge, which we will explore through a discussion of the phases of this cycle. We’ll talk about these in four stages that often overlap and or begin their execution simultaneously, as shown in the following figure:
Figure 1.9 – The stages rarely follow a specific order, but they are consistent through the inception and depreciation of vulnerabilities
Let’s explore each stage in detail over the next few sections.
Inception
The first stage we’ll cover is inception. In the life cycle, vulnerabilities get introduced through malicious or non-malicious activities during the inception stage. For example, developers might write insecure code, system administrators could deploy weak configurations, or malicious actors may purposefully embed vulnerabilities and back doors into the software. Understanding inception at times is difficult due to the various paths that vulnerabilities take when they’re introduced.
For software and systems to be deployed securely, engineers need to know how to securely write code and deploy systems, or they should receive guidance from security practitioners. Security literacy, or rather the lack of it, may be why vulnerabilities get introduced, but it’s not usually the only contributing factor. Developing software and maintaining operations is expensive, and organizations often seek to save money through various practices meant to accelerate product deployment. As a result, software developers and operation engineers are often stretched thin on projects, and products are rushed to get features and functionality embedded to acquire new customers or satisfy current customers. This pressure combined with poor security culture and/or education in the organization can often lead to outcomes where steps are skipped or security is placed on hold to ensure the product makes it to market. Remember, security always comes at a cost, and that cost often gets cut when businesses push to get applications or features to customers quickly.
Another factor to consider is the complexity of software systems and their deployed or supported infrastructure. If a system is complex, there are more opportunities for weaknesses to be introduced into the configuration and code.
Finally, malicious actors inserting vulnerabilities into code isn’t as uncommon as one might think. It can take a few different forms. Attackers are often aided by an insider threat, such as a disgruntled employee who sells access to attackers. In other instances, sophisticated state-sponsored attacks often gain a foothold into the software of companies they seek to exploit. In 2020, such a campaign made worldwide headlines when attackers targeted the business software, SolarWinds Orion, resulting in CVE-2020-10148. This vulnerability identified highly sophisticated actors implementing a trojan in the Orion software, which was then deployed thousands of times to customers. While these types of attacks and their impact are difficult to quantify, many believe the full effects of this kind of vulnerability are often unseen and potentially have catastrophic outcomes when exploited by attackers.
Discovery
During the discovery phase, vulnerabilities are discovered through security research, where motivated actors seek to understand whether something is vulnerable. They do this by using various methods that test the software for the types of vulnerabilities mentioned in the common vulnerabilities section. The motivations for discovery can vary. Some people are simply looking to discover vulnerabilities to improve the security of software, while others seek to exploit software with other goals in mind.
Depending on the actor’s motivations, the discovery stage presents the researchers with a choice to make. First, they need to decide how and whether they’ll communicate their vulnerabilities to responsible parties. Once discovered, researchers would notify the software publisher directly in ideal circumstances. Once informed, the publisher can begin work on fixing the problems in the remediation stage. Unfortunately, disclosing and determining the next steps for vulnerabilities is rarely this simple or rewarding.
In many cases, the vulnerabilities are never communicated to software publishers. It’s worth mentioning that disclosure decisions (if made at all) sometimes take an ethically questionable path. For example, there are some cases where security researchers decide to sell vulnerability research to security firms. Some of these firms specialize in the acquisition of vulnerabilities and operational exploits. These firms will buy exploits to incorporate into their security toolsets that they, in turn, sell to other software vendors, the original software vendor, or even nation-states that can incorporate these exploits in their cyber arsenals.
Exploitation and remediation
The exploitation and remediation stages can occur shortly after discovery. These two are linked in our life cycle and appear depending on how things unfold after discovering the vulnerability.
In some cases, a vulnerability is discovered, and then the researchers who found the vulnerability will inform vendors of their findings. Vendors will then create remediation plans or even software patches that they’ll publish to customers that patch the security vulnerability.
Suppose information or software patches are released but they do not directly mention how the vulnerabilities work. In these cases, researchers sometimes try to reverse engineer the vulnerability based on the documentation or patches through careful observation to build functional exploits. This is quite common for security researchers working on or studying popular software products such as the operating system Windows. For example, with the disclosed vulnerability CVE-2019-0708, commonly known as BlueKeep, Microsoft released a patch in May 2019. Researchers reverse-engineered the patch to construct a working exploit in July, with the mainstream exploit kits receiving a working exploit later in the year during the month of September.
In other cases, some bug hunters can immediately release the exploitation information about their vulnerabilities to the public – sometimes for free and sometimes as something sold, as previously discussed in the discovery phase. Vulnerabilities that receive immediate releases can (and have) lead to widespread exploitation events.
Modern attack patterns typically show mass exploitation isn’t far behind when vulnerabilities are discovered and information about them is released. Bad actors often begin scanning public resources on the internet for vulnerable software versions that match the vulnerability discovery. Provided exploitations are created and reliable, they’re often added to hacker tools that can exploit the vulnerability.
Perhaps one of the most troubling attributes of this is how the public learns about these vulnerabilities. Even in the ideal circumstances of a researcher reaching out and sharing vulnerability information with companies, these actions, if not carried over public channels, can result in the vendor patching problems without any notice to the public or users about the impacted software and the risks associated with using outdated software. Unfortunately, this practice is insidiously common in the industry.
Deprecation
Much like in any life cycle, things end. Over time, software and vulnerable versions of that software will fall away from usage. Patches or remediations are provisionally added to newer versions. Eventually, legacy vulnerabilities will fall out of the purview of hackers, vulnerability scanners, or people looking for vulnerabilities.
Keep in mind that the process of eventual deprecation can take a lot of time, and older vulnerabilities should always be thought of and considered when reviewing technology. For example, the common bug Shellshock or CVE-2014-7169 is commonly found almost a decade after its public release. The vulnerability had been present in the software for over 30 years before being discovered, and the software is widely deployed throughout the worldwide technology ecosystem.
Another culprit for long deprecation cycles is unsupported but required services or systems. Consider for a moment the healthcare industry. Hospitals and healthcare organizations will often invest in blood chemistry analyzers, the hardware used for X-rays, and other imaging technology such as MRIs. These investments can amount to millions of dollars. Unfortunately, healthcare software publishers may not support the software on these devices for as long as a hospital intends to use the equipment it made investments in. These gaps can lead to issues where investments are not protected against exploitation, or exploitation is handled with other mitigating factors. Anecdotally, it’s not uncommon to see software that is 15 to 20 years old on large equipment or major technology investments such as industrial control systems that power critical infrastructure deployments in the public sector.
Hopefully, this has helped you understand the life cycles of vulnerabilities and what you can expect when a vulnerability eventually appears in software.