This article attempts to give an overview of how IT vulnerabilities are categorized during their life-cycle. Understanding the terms related to the various stages of IT security vulnerabilities can allow a better understanding of what a proper security policy framework should include. First lets cover the stages:
- Unknown – vulnerabilities that exist but nobody knows about them. The vulnerability is not designed in put into the software or hardware by a malicious actor. These vulnerabilities are caused by poor implementation. Software coding standards and software development guidelines attempt to prevent these types of vulnerabilities from happening, but complex constructs in software programming languages are difficult to implement properly can be a large source of vulnerabilities. Unknown vulnerabilities may be discovered through static code analysis and “fuzzing” (automated testing) by malicious actors, bug hunters, or security threat hunters.
- Known – once the vulnerability has been discovered, it may fall into one or more of the following categories:
- Undisclosed – vulnerabilities that exist but are not publicly disclosed. Some small organizations or individuals may know about the vulnerability but security authorities do not know about them. There are no regulations similar to data-breach disclosure laws stipulating that software vendors must disclose any vulnerabilities they find in their software.
- Disclosed – once vulnerabilities have been publicly disclosed, either by a security research organization or the original software vendor, it can be known and mitigation against attack can be implemented. One important source of vulnerability disclosure information are the Common Vulnerability Exposure (CVE) database / National Vulnerability Database (NVD) and VulnDB. However, not all disclosed vulnerabilities are are given a CVE-ID and VulnDB was shown to include more vulnerabilities than CVE/NVD [1] and the active status of the vulnerability is not included in the CVSS severity score [2].
- Disclosure Policy – refers to a researchers action upon discovery of a vulnerability. Full-disclosure policy is a policy to make disclosure as early as possible, accessible to everyone without restriction. Coordinated-disclosure policy is a tiered approach to disclosure under which researchers report to a coordinating authority, which passes the information to the product vendor, tracks, fixes and mitigates, and coordinates the disclosure process with the various stakeholders and public.
- Zero day – According to WikiPedia (externally referenced): “The term “zero-day” originally referred to the number of days since a new piece of software was released to the public, so “zero-day” software was software that had been obtained by hacking into a developer’s computer before release. In that sense, “zero-day” vulnerabilities that have been discovered but disclosure may not be publicly available.
- Actively exploited – security researchers actively track known vulnerabilities by both the the availability of published exploit kits (malware) and by monitoring and consolidating attack data. This data sharing happens at the government level by National Cybersecurity Agencies such as CISA’s Critical Infrastructure Threat Information Sharing Framework and Security as a Service (SECaaS) providers such as IBM’s Threat Intelligence Force X reports. If the vulnerability is found have available available exploit kits to be exploited “in the wild”, it falls into this category of “actively exploited”. Some research in 2019 attempted to discern what number of total known exploits had been found to be actively exploited.
- Patched – software products that have had vulnerabilities uncovered and fixed can be classified as patched. However, those patches need to be installed in the client instances. By doing software updates regularly, end-users can increase their security against vulnerabilities without having to be actively aware of the vulnerabilities. However one trade off of blind updating is that software patches or updates can occasionally also render software inoperable. To mitigate this additional risk caused by updating software, a “patch management” or “change management” process can be used to test updates in a testing environment before they are implemented or “rolled out” to the production environment.
Leave a comment