Not a single scan, or how to build a vulnerability management process in 9 steps

On July 4, we held a large seminar on vulnerability management . Today we publish a transcript of a speech by Andrei Novikov from Qualys. He will tell you what steps you need to go through to build a vulnerability management workflow. Spoiler: before the scan, we will only get to the middle of the path.







Step # 1: Determine Maturity Level of Vulnerability Management Processes



At the very beginning, you need to understand at what level your organization is in terms of the maturity of vulnerability management processes. Only after that you will be able to understand where to move and what steps you need to take. Before embarking on scans and other events, organizations need to conduct internal work and understand how your current processes are arranged in terms of IT and information security.



Try to answer the basic questions:









Step # 2: Provide Full Infrastructure Coverage



You cannot protect what you do not know. Unless you have a complete picture of what your IT infrastructure consists of, you cannot protect it. Modern infrastructure is complex and is constantly changing quantitatively and qualitatively.

Now the IT infrastructure is based not only on a stack of classical technologies (workstations, servers, virtual machines), but also on relatively new ones - containers, microservices. The information security service in every possible way escapes from the latter, since it is very difficult for them to work with them using existing toolkits, which consist mainly of scanners. The problem is that any scanner cannot cover the entire infrastructure. For a scanner to reach any node in the infrastructure, several factors must coincide at once. The asset must be inside the perimeter of the organization at the time of scanning. The scanner must have network access to the assets, their accounts, in order to collect complete information.



According to our statistics, when it comes to medium or large organizations, approximately 15-20% of the infrastructure is not captured by the scanner for one reason or another: the asset has moved outside the perimeter or never appears in the office at all. For example, the laptop of an employee who works remotely, but at the same time has access to the corporate network, or the asset is located in external cloud services such as Amazon. And the scanner, most likely, will not know anything about these assets, since they are out of its visibility.



To cover the entire infrastructure, you need to use not only scanners, but a whole range of sensors, including passive listening technology to detect new devices in your infrastructure, an agent-based method of collecting data to receive information - allows you to receive data online, without the need for scanning, without highlighting credentials.







Step # 3: Categorize Assets



Not all assets are equally useful. Determining which assets are important and which are not is your task. Not a single tool, the same scanner, will do it for you. Ideally, information security, IT and business analyze infrastructure together to highlight business critical systems. For them, they define acceptable metrics for availability, integrity, confidentiality, RTO / RPO, etc.



This will help prioritize vulnerability management. When your specialists receive vulnerability data, this will not be a sheet with thousands of vulnerabilities throughout the infrastructure, but granular information, taking into account the criticality of the systems.







Step # 4: Assess the infrastructure



And only in the fourth step we come to assess the infrastructure in terms of vulnerabilities. We recommend that you at this stage pay attention not only to software vulnerabilities, but also to configuration errors, which can also be a vulnerability. Here we recommend the agent method of collecting information. Scanners can and should be used to assess perimeter security. If you use the resources of cloud providers, then you also need to collect information on assets and configurations from there. Pay special attention to the analysis of vulnerabilities in infrastructures using Docker containers.







Step # 5: Set Up Reporting



This is one of the important elements within the vulnerability management process.

First point: no one will work with multi-page reports with a random list of vulnerabilities and a description of how to fix them. First of all, it is necessary to communicate with colleagues and find out what should be in the report and how it is more convenient for them to receive data. For example, some administrator does not need a detailed description of the vulnerability and only needs information about the patch and a link to it. To another specialist, only the vulnerabilities found in the network infrastructure are important.



The second point: by reporting I mean not only paper reports. This is an outdated format for obtaining information and a static history. A person receives a report and can not in any way affect how the data will be presented in this report. To get the report in the right form, the IT specialist must contact the information security specialist and ask him to rebuild the report. Time goes by, new vulnerabilities appear. Instead of transferring reports from department to department, specialists in both areas should be able to observe the data online and see the same picture. Therefore, in our platform we use dynamic reports in the form of custom dashboards.







Step 6: Prioritize



Here you can do the following:



1. Creating a repository with golden images of systems. Work with golden images, check them for vulnerabilities and correct configurations on an ongoing basis. This can be done using agents that will automatically report the appearance of a new asset and provide information about its vulnerabilities.



2. Focus on those assets that are critical to the business. There is no organization in the world that can address vulnerabilities in one go. The process of fixing vulnerabilities is long and even dreary.



3. Narrowing the surface of attacks. Clean your infrastructure from unnecessary software, services, close unnecessary ports. We recently had a case with one company in which about 40 thousand vulnerabilities were found on 40 thousand devices related to the old version of the Mozilla browser. As it turned out later, Mozilla was introduced into the golden image many years ago, no one uses it, but it is the source of a large number of vulnerabilities. When the browser was removed from computers (it even stood on some servers), these tens of thousands of vulnerabilities disappeared.



4. Rank the vulnerabilities based on the intelligence database. Consider not only the criticality of the vulnerability, but also the presence of a public exploit, malware, patch, external access to the system with the vulnerability. Assess the impact of this vulnerability on critical business systems: can it lead to data loss, denial of service, etc.







Step # 7: Agree on KPI



Do not scan in order to scan. If nothing happens with the found vulnerabilities, then this scan turns into a useless operation. To prevent vulnerabilities from becoming a formality, consider how you will evaluate its results. IS and IT should agree on how the work to eliminate vulnerabilities will be built, how often scans will be performed, patches will be installed, etc.

On the slide you see examples of possible KPIs. There is also an extended list that we recommend to our customers. If it is interesting, please contact, I will share this information with you.







Step 8: Automate



Back to scanning again. At Qualys, we believe that scanning is not the most important thing that can happen today in the process of managing vulnerabilities, and that first of all it is necessary to automate it as much as possible so that it can be performed without the participation of an information security specialist. Today, there are many tools that allow you to do this. It is enough that they have an open API and the required number of connectors.



An example that I like to give is DevOps. If you implement a vulnerability scanner there, you can simply forget about DevOps. With old technologies, which is a classic scanner, you simply will not be allowed into these processes. Developers will not wait until you scan and give them a multi-page inconvenient report. Developers expect vulnerability information to be sent as bug information to their code building systems. Security should be seamlessly integrated into these processes, and it should be just a function that is automatically called by the system used by your developers.







Step # 9: Focus on the essentials



Focus on what really benefits your company. Scans can be automatic, reports can also be sent automatically.

Focus on improving processes so that they are more flexible and convenient for all involved. Focus on ensuring that security is embedded in all contracts with your contractors who, for example, develop web applications for you.



If you need more detailed information on how to build a vulnerability management process in a company, please contact me and my colleagues. I'll be glad to help.










All Articles