On July 4th, we held a major . Today we publish the transcript of Andrei Novikov's speech from Qualys. He will discuss the steps needed to establish an effective vulnerability management workflow. Spoiler: we will only reach scanning by the halfway point.
Step 1: Determine the maturity level of your vulnerability management processes
At the very beginning, you need to understand what level your organization is at regarding the maturity of vulnerability management processes. Only after that can you determine your direction and the steps you need to take. Before delving into scanning and other activities, organizations need to conduct internal work and understand how their current processes are structured from an IT and information security perspective.
Try to answer the basic questions:
- do you have processes for inventorying and classifying assets;
- how regularly is your IT infrastructure scanned and is all the infrastructure covered; do you have a complete picture;
- are your IT resources monitored;
- have any KPIs been implemented in your processes, and how do you know they are being met;
- are all these processes documented.
Step 2: Ensure complete coverage of infrastructure
You cannot protect what you do not know. If you don’t have a complete picture of what makes up your IT infrastructure, you cannot protect it. Modern infrastructure is complex and continually changes in both quantity and quality.
Now, the IT infrastructure is based not just on a stack of traditional technologies (workstations, serversinfrastructure, including virtual machines and relatively new technologies like containers and microservices. The information security service generally shies away from the latter, as it finds it very challenging to work with them using the existing toolsets, which mainly consist of scanners. The problem is that no scanner can cover the entire infrastructure. For a scanner to reach any node in the infrastructure, several factors must align. The asset must be within the organization's perimeter at the time of scanning. The scanner must have network access to the assets and their accounts to collect comprehensive information.
According to our statistics, when it comes to medium or large organizations, approximately 15-20% of the infrastructure is not covered by the scanner for various reasons: the asset has moved beyond the perimeter or never appears in the office at all. For example, an employee's laptop that works remotely but still has access to the corporate network, or an asset that is located in external cloud services like Amazon. The scanner is likely unaware of these assets as they are outside its visibility.
To cover the entire infrastructure, it is necessary to use not only scanners but a whole set of sensors, including passive traffic listening technologies to detect new devices in your infrastructure, and an agent-based data collection method to obtain information in real-time without the need for scanning or credential provisioning.
Step 3: Categorize Assets
Not all assets are equally useful. Identifying which assets are important and which are not is your task. No tool, including scanners, will do this for you. Ideally, cybersecurity, IT, and business teams jointly analyze the infrastructure to highlight business-critical systems. For these, they define acceptable metrics for availability, integrity, confidentiality, RTO/RPO, and others.
This will help determine priorities in the vulnerability management process. When your specialists receive data on vulnerabilities, it will not be a sheet filled with thousands of vulnerabilities across the infrastructure, but rather granular information taking into account the criticality of systems.
Step 4: Assess the Infrastructure
Only at the fourth step do we assess the infrastructure in terms of vulnerabilities. We recommend paying attention not only to vulnerabilities in software but also to configuration errors, which can also be a vulnerability. Here, we suggest using an agent-based method for information gathering. Scanners can and should be used to evaluate perimeter security. If you are utilizing resources from cloud providers, it is important to gather information on assets and configurations from there as well. Pay special attention to analyzing vulnerabilities in infrastructures that utilize Docker containers.
Step 5: Set Up Reporting
This is one of the important elements within the vulnerability management process.
First, no one will work with multi-page reports that have a disorganized list of vulnerabilities with descriptions of their remediation. First and foremost, it is necessary to communicate with colleagues to find out what should be included in the report and how they prefer to receive the data. For example, a certain administrator might not need a detailed description of the vulnerability and only require information about the patch and a link to it. Another specialist may only be interested in vulnerabilities found in the network infrastructure.
Second, by reporting, I mean not just paper reports. This is an outdated method of obtaining information and a static history. A person receives a report and cannot influence how the data will be presented in that report. To obtain the report in the desired format, an IT specialist must contact the cybersecurity specialist and ask them to restructure the report. Time passes, new vulnerabilities emerge. Instead of passing reports from one department to another, specialists from 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 customizable dashboards.
Step 6: Prioritize
The following can be done here:
1. Create a repository of golden images of systems. Work with golden images, continuously checking them for vulnerabilities and configuration accuracy. This can be done using agents that will automatically report the emergence of a new asset and provide information about its vulnerabilities.
2. Focus on the assets that are critical to the business. There is not a single organization in the world that can eliminate vulnerabilities in one go. The vulnerability remediation process is long and can even be tedious.
3. Narrow the attack surface. Clean your infrastructure of unnecessary software and services, and close unneeded ports. Recently, we had a case with a company that had around 100,000 vulnerabilities related to an old version of the Mozilla browser found on 40,000 devices. It later turned out that Mozilla had been embedded in the golden image many years ago, it was not in use, yet it was a source of a large number of vulnerabilities. Once the browser was removed from the computers (it was even installed on some servers), those tens of thousands of vulnerabilities disappeared.
4. Rank vulnerabilities based on threat intelligence data. Consider not only the criticality of the vulnerability but also the existence of a public exploit, malware, patch, and 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 KPIs
Don't scan just for the sake of scanning. If nothing is done with the identified vulnerabilities, the scanning becomes a futile operation. To ensure that working with vulnerabilities doesn’t turn into a formality, think about how you will evaluate the results. InfoSec and IT must agree on how the vulnerability remediation process will be structured, how often scans will be conducted, patches will be applied, etc.
On the slide, you can see examples of possible KPIs. There is also an expanded list that we recommend to our clients. If you're interested, feel free to reach out, and I will share this information with you.
Step 8: Automate
I'll return to scanning again. At Qualys, we believe that scanning is the least important aspect of vulnerability management today, and that it should be maximally automated so that it can be carried out without the involvement of an InfoSec specialist. Today, there are many tools that allow this to be done. They just need to have an open API and the necessary number of connectors.
An example that I often provide is DevOps. If you are going to implement a vulnerability scanner there, you can simply forget about DevOps. With older technologies, such as a classic scanner, you will not be allowed into these processes. Developers will not wait for you to scan and deliver a bulky, multi-page report. Developers expect that vulnerability information will be delivered as bug reports into their code compilation systems. Security must be seamlessly integrated into these processes and should just be a function automatically triggered by the system used by your developers.
Step #9: Focus on the Essentials
Concentrate on what brings real benefits to your company. Scans can be automated, and reports can also be sent out automatically.
Focus on improving processes to make them more flexible and convenient for all participants. Ensure that security is integrated into all contracts with your contractors who, for example, develop web applications for you.
If you need more detailed information on how to establish a vulnerability management process in your company, feel free to contact me and my colleagues. I would be happy to help.
Source: habr.com
