Ruslan Rakhmetov, Security Vision
Quite often news about another discovered vulnerability appears on IS resources, and the media picks up reports about another new cyber threat. Those who are somehow connected with the IT and IS industries are familiar with well-known vulnerabilities, some of which were even given catchy names to emphasise their danger and importance: Heartbleed (CVE-2014-0160), Shellshock (CVE-2014-6271), EternalBlue (CVE-2017-0144), PrintNightmare (CVE-2021-34527), Log4Shell (CVE-2021-44228), Downfall (CVE-2022-40982) and others. In this article we'll understand what vulnerabilities are, why some of them are given their own names, what CVE identifiers mean and how they are assigned, consider the most popular web application vulnerabilities, and talk about building a competent vulnerability management process in a company.
So, first of all, we need to understand the basics and terminology of vulnerability management. Modern operating systems and programmes are based on millions of lines of source code: for example, the current Linux kernel contains almost 30 million lines of code, Windows 11 contains about 50 million lines of code (the estimate is presumed due to the closed nature of the Windows operating system), and modern PC games contain several million lines of code on average. Of course, with such volume of software development, programming errors cannot help but occur - back in 2012 it was estimated that there is an average of 1 programming error per 1000 lines of source code of Open Source projects. Thus, large applications and operating systems inevitably have bugs, some of which are used by attackers for cyberattacks.
However, a vulnerability is not only a development error, it is also a flaw in a security tool, information system configuration (settings) or even organisational processes in a company. In general, vulnerability is a flaw in the creation, configuration, application, protection of an information asset that can negatively affect the security of the information being processed. If we refer to regulatory documentation, then, for example, in the ISO/IEC 27000:2018 standard, vulnerability is defined as a weakness of an asset or means of control and management that can be exploited (used) by attackers. The domestic standard GOST R 56546-2015 states that vulnerability is a flaw in a software and hardware asset or information system as a whole that can be exploited to realise information security threats.
The same Russian standard lists different types of possible vulnerabilities:
- code vulnerability - a vulnerability that appeared in the process of software development;
- configuration vulnerability - a vulnerability that appeared in the process of software and hardware configuration;
- architecture vulnerability - a vulnerability that appeared in the process of designing an information system;
- organisational vulnerability - a vulnerability related to shortcomings in organisational measures, such as non-compliance of employees with system operation rules or requirements of regulatory documents;
- multifactor vulnerability - a vulnerability resulting from a combination of several vulnerabilities of the listed types.
Each vulnerability is characterised by the degree of danger - a comparative value that determines the susceptibility of the information system to this vulnerability and its impact on the violation of confidentiality, integrity, availability of information in the system. In order to take into account the vulnerability discovered by software developers or security researchers, it is assigned an identifier with the prefix CVE (foreign classification of Common Vulnerabilities and Exposures of MITRE organisation, contains more than 220 thousand vulnerabilities and is constantly updated) or BDU (threatdatabase of FSTEC of Russia, contains more than 53 thousand vulnerabilities and is constantly updated). As a result, a confirmed vulnerability receives a unique identifier CVE-YYYYYY-NNNNNN (where YYYYY is the year the vulnerability was discovered and NNNNNN is its sequence number) or BDU:YYYYY-NNNNNN (where YYYYY is the year of discovery and NNNNNNNN is the sequence number of the vulnerability).
As part of the vulnerability analysis, in addition to assigning an identifier to the vulnerability, its characteristics are analysed to determine the risk of exploitation using the CVSS (Common Vulnerability Scoring System) metric. The current version is CVSS version 4: this methodology takes into account the complexity of exploitation, the prerequisites for the system to successfully exploit the vulnerability and the privileges required by the attackers, the presence of a ready-made exploit (a type of malware that uses a particular vulnerability to subsequently run code or programmes under the control of the attackers), evidence of vulnerability exploitation in real attacks (literally ‘in the wild’), and the impact of the vulnerability on privacy properties, As a result of this calculation, a vulnerability is given a score from 0 to 10, where 10 is the maximum hazard value for a particular vulnerability. If a vulnerability is actively used in large-scale attacks with severe consequences or such a scenario is predicted, researchers who have discovered such a critical vulnerability assign it a catchy name (for example, Shellshock or PrintNightmare) to attract the attention of the IS community to the problem.
There are also terms such as Zero-Day (0-Day) and N-Day vulnerabilities:
- Zero-Day is a vulnerability that developers and IS researchers are not yet aware of and for which no fixes (updates, security patches) have been released, but which is already being exploited by hackers in real attacks;
- N-Day is a vulnerability for which a patch has already been released by the software vendor, but companies using vulnerable software versions have not yet had time to install the update (for example, installing the update requires restarting a server that performs business-critical tasks).
As we've already established, a vulnerability is a bug in the software code, a lack of security measures, or an insecure configuration of the software. However, some types of vulnerabilities are more dangerous due to their nature - first of all, these are web application vulnerabilities. This is easy to explain: in order to exploit web vulnerabilities, attackers do not need to breach perimeter defences, they only need to attack a web resource that is accessible to everyone on the Internet. Because of this accessibility, web resources are at a higher risk of exploiting vulnerabilities found by hackers, the successful exploitation of which can lead to the leakage of data from the website (e.g., user databases with logins, passwords, and personal information), unauthorised changes to the appearance of the website (so-called ‘defacement’), the placement of malicious or fraudulent content on the website without the owner's knowledge, and the compromise of information resources to which the web server has access (e.g., DBMS or other related systems). Due to the high risk of web vulnerabilities, the OWASP (Open Worldwide Application Security Project) was created to monitor and manage web application vulnerabilities. Since 2003, the project has regularly released lists of the 10 most common web vulnerabilities.
The latest version of this OWASP Top 10 list was released in 2021 and contains vulnerabilities such as:
- Broken Access Control (Broken Access Control);
- Cryptographic Failures;
- Injection, including XSS, SQL injection, injection of OS commands, injection of XPath and XQuery expressions, etc.;
- Insecure Design;
- Security Misconfiguration;
- Vulnerable and Outdated Components;
- Identification and Authentication Failures;
- Software and Data Integrity Failures;
- Security Logging and Monitoring Failures;
- Server-Side Request Forgery.
In addition to the above list of the 10 most common web application vulnerabilities, the OWASP project also releases a list of the 10 most popular bugs in API interaction development. This list is called the OWASP Top 10 API Security Risks, with the latest version released in 2023.
Next, let's move on to describing the Vulnerability Management (VM) process - one of the basic IS processes. When building a Vulnerability Management programme, it is important to follow the basic rules of the process approach and maximise the use of automation tools to reduce the time window for attackers to exploit vulnerabilities for which patches have already been released or known workarounds that involve either disabling the vulnerable component or manually reconfiguring it before an official patch is released in order to prevent exploitation of the vulnerability. When implementing a process approach, it is important to ensure a continuous cycle of scanning for vulnerabilities, analysing the results, comparing the criticality of the vulnerabilities and the criticality of the asset on which they are found, making a decision to mitigate the risk of vulnerability exploitation (installing a patch, disabling or restricting network access to the vulnerable component, applying compensating measures such as virtual patching or special configuration of the firewall, or agreed and documented risk acceptance if other measures cannot be performed). Once a decision has been made, a task to remediate the vulnerability should be automatically generated to the appropriate department (usually the IT department in the company), a task SLA should be set depending on the criticality of the vulnerability and the properties of the asset, and the result should be verified by rescanning the asset.
To form a coherent and clear vulnerability management process, it is necessary to develop and approve an appropriate internal regulatory document (e.g., vulnerability management regulations). When developing it, you can use the methodological document of the FSTEC of Russia dated 17 May 2023 ‘Guidelines for Organising the Vulnerability Management Process in a Body (Organisation)’, which provides detailed explanations on the implementation of the following main stages of the vulnerability management process:
- Monitoring of vulnerabilities and assessment of their applicability;
- Assessing vulnerabilities;
- Determining methods and priorities for remediation of vulnerabilities;
- Remediation of vulnerabilities;
- Control of vulnerability remediation.
In addition to the above document, it is possible to use the methodological document of FSTEC of Russia dated 28 October 2022 ‘Methodology for assessing the level of criticality of vulnerabilities of software and hardware-software means’, which provides a methodology for assessing the level of criticality and calculating temporary SLA norms for vulnerability remediation depending on their characteristics and properties of the information system on which they are detected. Vulnerability scanner results should also be integrated with data from asset management systems to provide enriched, contextualised information about the security status of the infrastructure and to make informed decisions about how to handle a particular vulnerability.
When building the Vulnerability Management process, you can also be guided by foreign publications - for example, the document NIST SP 800-40 Rev. 4 ‘Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology’. This publication describes the software vulnerability management lifecycle and provides practical guidance on developing an enterprise vulnerability management plan - we've covered this document in detail previously. Another useful reference resource is a list of vulnerabilities actively exploited by hackers: this list is maintained by the US government's Cybersecurity and Infrastructure Security Agency (CISA) and can be used to prioritise remediation of discovered vulnerabilities.
