Practical and Extended Vulnerability Management Process (Alexander Leonov)
| February 21st, 2020Level: Technical
Abstract:
In this presentation, I will show how infrastructural Vulnerability Management looks from the point of view of:
- Information Security theorists
- Vulnerability Management vendors
- IT and IT Security guys in particular organizations
I will share my opinion on the vulnerability management process, which should include controls for:
- Critical Networks and Assets
- Local Admin credentials
- Installation of Software (especially of Security Agents)
- Compliance and asset configuration
Full description:
Historically, the infrastructural Vulnerability Management is understood primarily as a process of detecting and fixing (patching) known software bugs that theoretically can be used in attacks on organizations. Documents written by information security theorists from NIST, PCI, CIS, mainly contain formal recommendations: if your VM solution detects a vulnerability with a high enough CVSS base score, then such vulnerability must be fixed in a certain time. Vulnerability Management vendors share a similar position. They offer solutions that detect hundreds and thousands of vulnerabilities using some formal criteria, and they are not really interested in how these vulnerabilities will be fixed in real organizations. Only now they began to propose approaches such as Predictive Prioritization, which can (with some probability) filter out the most critical and exploitable vulnerabilities from the overall set.
In a real organization, the implementation of a VM process will cause a negative attitude from IT. Constantly updating infrastructure requires a lot of resources. For example, critical Linux kernel vulnerabilities appear every week. And usually IT departments are not ready for this. The problem could be solved through the automation of update processes. But for this, it is necessary to perform advanced automatic testing procedures after each update (especially for applications), which is also often impossible to implement. As a result, the VM process will either be sabotaged by IT (there are many ways to do this) or limited to a very small scope. In the second case, compensatory measures and justifications of why this or that vulnerability is not critical will be actively used. Which, of course, distorts the very idea of VM.
This is often facilitated by the fact that information security practitioners do not see a real danger in most of the existing vulnerabilities, in all but those that can be simply exploited by attackers in the organization (for example, EternalBlue, vulnerabilities in rdp, ssh, etc.). Such vulnerabilities usually become widely known and their patching does not require a regular process and can be performed as one-time events. At the same time, in every large organization, there are tasks that require control and automation even more critical than control of patch management. And they should be the basis of the practical and advanced Vulnerability Management process (since they directly affect the potential attack):
- If we do not know and do not control some hosts, especially those accessible from the Internet, this is a vulnerability.
- If we see that some Security Agents are not installed or configured on the hosts (in accordance to the policies), this is a vulnerability.
- If we have unknown accounts on servers or users with unnecessary local admin permissions on the desktops, this is a vulnerability.
- If there are hosts with installed software that is not necessary for work – this is a vulnerability. This also includes control over software updates and OS patching, but only as a subtask.
- If the host is not configured in accordance with security requirements – this is a vulnerability.
And much more, leaving aside control over abnormal host activity (SOC tasks) and control over internal development (AppSec tasks).
Regarding the control over updates, I recommend to show the problem (a lot of hosts with critical vulnerabilities) and develop a policy for the organization based on this: take the risks, patch some particular vulnerabilities, change the patch management and application testing process, etc.
Bio:
Alexander Leonov is an Information Security Automation specialist with 10 years of experience in Vulnerability Management: from creating security content for Vulnerability Scanners to practical implementations of VM processes in the organizations.
Blog: