When we look at the sector today, we see that the security concept is divided into dozens of areas. A wide range of professional areas have emerged, from teams that monitor alarms triggered by malware, to those who try to find company-related information from intelligence sources, to those who hunt for malicious behavior in past activity logs, or to penetration testers who try to infiltrate the company before malicious people do. A simple event lies at the core of the diversification of all these areas of professionalism: a vulnerability within a system. The alarms are monitored, intelligence is collected, or penetration tests are carried out to prevent malicious individuals from infiltrating the company using this vulnerability. So, vulnerabilities are the most essential part of what cyber security professionals do.
Every year, companies invest millions of dollars in security to protect[] themselves against vulnerabilities. This investment includes purchasing security products, establishing and training security teams, conducting security tests, and fostering a culture of security awareness. But the question remains: how do organizations effectively deal with these vulnerabilities?
We will discuss a standard management method that addresses this challenge in the following section.
To have a healthy and effective vulnerability management lifecycle, being familiar with all the devices in your environment is a must. The first step in vulnerability management is knowing precisely what is happening in your environment. Every device you don't know about may contain a significant vulnerability, and failure to detect it may make these devices an easy target in the event of a possible attack. As the company size increases, the management of devices becomes more complex, and more serious steps are taken, such as inventory management. The more serious the inventory management is, the stronger the vulnerability management will be.
Figure 1: Stages of Vulnerability Management [1]
In the second stage, vulnerabilities are revealed by scanning the devices in this inventory. Next, assessment results are reported to the users, and the process for remediation is initiated. And after remediation is completed, the fifth and final step of the verification process is performed by scanning again. This is basically how a vulnerability management process works.
Now, let's examine the following statistics pertaining to the number of CVEs (Common Vulnerabilities and Exposures) over the years. This chart has been generated using data from the National Institute of Standards and Technology (NIST).
Figure 2: CVE Counts by Year
We see the number of vulnerability IDs published in the last four years by year. It can be seen that there has been an increase over the years. Hence, this table tells us that with each passing day, we need to resolve more vulnerabilities in our environment. In the state of being worried and overwhelmed by the sheer number of vulnerabilities, we can find ourselves asking the following questions.
Unfortunately, none of these will provide a permanent solution.
This is where the need to manage this risk. The vulnerabilities in your environment should be mitigated in a planned manner within the scope of a procedure and made into a process.
Considering the statistics highlighted earlier, where the number of vulnerabilities is increasing rapidly, it is infeasible to apply standard vulnerability methods to all vulnerabilities and try to solve them. According to a recent study, companies can only fix %5-20% of their vulnerabilities. Then, we can say that we should fix not all the vulnerabilities in our environment but the ones that are most important to us. So we have to prioritize some of them. So which ones are our priority?
To find the vulnerabilities that are a priority for us, many studies have been carried out for a long time and various frameworks have been created.
To evaluate vulnerabilities among themselves, some frameworks can assign levels such as low, medium, high, or critical to vulnerabilities or score them, and while doing this, they can use many parameters, from the existence of an exploit to its applicability.
The Common Vulnerability Scoring System (CVSS) is the most well-known one. Before assigning a score and value to a vulnerability, CVSS looks at information such as its complexity, authorization requirement, location of the attacker, and the impact it may have on the target system.
Figure 3: Common Vulnerability Scoring System Vector Parameters [2]
Another example would be the Exploit Prediction Scoring System (EPSS). EPSS can score whether a vulnerability can be exploited based on the information about the published vulnerability and the exploit status in the field.
Figure 4: Exploit Prediction Scoring System Variable Importance [3]
Or, CISA's listing of actively exploited vulnerabilities in a catalog called Known Exploited Vulnerabilities (KEV) provides valuable information to prioritize the vulnerabilities among themselves.
Figure 5: CISA's Known Exploited Vulnerabilities Catalog
Yes, each of these frameworks offers valuable information for prioritization, but unfortunately, it is not enough to prioritize based only on the value of the vulnerability.
Just as the vulnerabilities are different from each other, the devices with vulnerabilities also differ in importance. And these differences play a more significant role in prioritizing vulnerabilities. The company best determines the value of a device to a company. An outsider can estimate possible critical devices based on specific parameters, but the most accurate information belongs to the actual owner of that device. In some companies, machines with internally developed software code. In others, web servers serve the internet, and in others, remote working client machines are of the most critical importance. Therefore, it is not possible for this to be calculated with 100% accuracy by a framework. Of course, it is possible to detect situations such as the services running on it or whether it is open to the internet, and it can be a preliminary step in determining the criticality of the device. Still, at the end of the day, that organization will indicate most accurately how valuable this device is for the business. When determining the criticality of this device, organizations can make their assessments by looking at the type of device, its location, its value to the business, and whether it contains sensitive data.
When the critical vulnerabilities found on a device are combined with the device's value for that company or business, it is determined how much risk that device poses for the company. For example, a machine with a critical vulnerability without network access poses a low risk. A device with a less critical vulnerability and is directly open to the internet is much more risky. The most effective vulnerability management method is applied by calculating these risks separately, finding the riskiest devices, and taking action according to their risk value.
Today, in vulnerability management, evaluations are generally made according to the criticality of a vulnerability, but the risk that vulnerability poses to the organization is not considered or is tried to be planned by spending individual efforts. By adapting the risk-based approach to the entire vulnerability management process, many problems experienced in the past will be overcome and the most efficient and effective solution process will be implemented.
Attack Surface Management (ASM), as the name suggests, is based on detecting and analyzing an organization's attack surface. So, what does attack surface mean? When we look at it from the perspective of attackers, it refers to the surface area on which they can attack. This surface area is all the assets belonging to that company. There are two main methods: external and internal.
For an external attacker, company assets include domain information, external IP addresses, web applications on IPs, cloud services, and certificates. It even includes user and company details on social media. For an attacker located internally, assets can be end-user machines, servers, network devices, databases, security devices, user accounts, software, etc., and include objects within the company topology's boundaries.
Each of the assets here is a possible source of vulnerability; in this case, it is only a matter of time before it becomes the target of an attacker. For this critical reason, all these assets must be managed, constantly monitored, analyzed, and improved. What we call ASM is the security solution that does exactly this management job.
Figure 6: Attack surface management steps
After this part of the article, we will go over internal ASM, also known as Cyber Attack Surface Management (CAASM), due to its closeness to the subject.
Now, when we look at the systems with assets, we can see that they all operate some ASM. Various EDR or vulnerability management tools reviewed recently can collect asset information from machines with an agent installed or authenticated scans, display them in their interfaces, and establish relationships between them. While EDR gathers information about the systems on which agents are installed, vulnerability scanners can collect information about the systems detected as a result of scanning the subnets defined on them. So, can we install agents on all our machines or scan all systems without missing any devices? The answer to this question is, of course, no. ASM can prevent problems by taking a completely different position in this structure.
Figure 7: ASM architecture
ASM's working mechanism is similar to today's companies. They apply ASM on all assets without owning any assets. It is interesting. Yes, that's exactly how they work. These products do not have direct asset information, but they continue their functions by collecting information from systems that have this information through APIs, etc. They aggregate the data collected from different points and present it to the user by performing various analyses.
We would like to explain in a few steps what advantages or benefits ASM may have:
Asset inventory: No company can fully know all its assets. Various methods are used to find out, but it is difficult for devices managed by different teams to come to a common point. At this point, ASM aims to collect every asset in various locations within its structure using the power of integrations. In this respect, ASM can have the most substantial asset inventory.
Aggregation: Aggregation is the backbone of ASM. It stores the asset information it collects from different points by establishing relationships with each other. It aggregates the information you will learn by looking at two interfaces into a single interface. For example, while EDR can detect that a machine is open to the internet, the vulnerability scanner tool can tell that this machine has never been scanned for vulnerabilities. With aggregation, you can directly find machines open to the internet that have not been scanned for vulnerabilities.
Insight: By using this aggregated data coming from different sources, it becomes possible to create many different metrics, or in other words, insights. You can perform gap analysis by looking at which systems an asset comes from, measure user/device risks, track policy distribution throughout the company, etc.
Risk calculation: Business context provides us with basic information in calculating the risk of an asset. By combining the business data provided by the user with the asset value created using its own metrics, ASM enables risk calculation to be made more clearly and accurately.
Continuous: With the configured scheduled fetching process, the current data of all assets is continuously retrieved and aggregated. In this way, the time to detect and intervene in the risk is improved. In addition, historical data is also created by periodically capturing this data, and based on this, various insights or dashboards can be created through graphical representations.
Reporting: The metric and insight outputs created can be reported in a custom structure with various graphical representations. It can be used directly in presentations to superiors or compliance teams by editing it as the user wishes.
With all these capabilities, ASM is perfect for vulnerability management. Because it is compatible with the vulnerability management steps mentioned at the beginning of the article and provides a strong improvement in implementing each of them, it also allows prioritization with a risk-based approach by calculating the risk values of vulnerabilities.
Vulnerabilities are described as assets in ASM and are treated as such. With the integrations made, vulnerabilities within the entire company are gathered under the roof, aggregated, evaluated, and reported.
Let's examine the vulnerability management stages using ASM through an example scenario:
You are responsible for vulnerability management in a company. You have a product that scans for vulnerabilities. This product scanned the subnets you defined, detected a certain number of machines, and found some vulnerabilities. Using the CVSS score information provided by that product, you can see the most critical ones and complete the vulnerability management process by remediating them.
Let's approach this environment using ASM. You integrate your EDR product into ASM with this vulnerability scanner tool. When you look at the results, you confirm that the EDR agent is installed on all machines in this environment, but you realize that you have not gone through the vulnerability scanning process of C and D hosts, and you include them in the scanning program. You also strengthen your inventory while closing the gaps in your vulnerability scanner.
In addition to the vulnerabilities you detected after the scan (white ones), other vulnerabilities (green ones) detected by the EDR product are added to complete the vulnerability aggregation. The problem of different results in different vulnerability detection systems, which is very common today, is also eliminated.
The same vulnerabilities detected on the vulnerability scanner and EDR are enriched by aggregation regarding their information. This way, information about whether an exploit exists is added to the existing vulnerabilities.
With third-party integration, all existing vulnerabilities are re-enriched with information from the threat intelligence source, and all values that can be used in risk calculation are added.
Using the algorithm defined on ASM, the risk that each vulnerability may cause is calculated separately.
The user determines which assets are more critical by merging the data provided by ASM with their asset information.
Using all this information, the vulnerability that is the most risky for the company is eliminated through remediation. If you pay attention, the most risky vulnerability for the company has been resolved, rather than the one with the most vulnerabilities or the most critical vulnerability.
Then, the vulnerability management process is completed by eliminating the vulnerabilities that are the next priority for the company.
The risk-based approach is an essential method for vulnerability management today. There may be some uncertainty or inexperience regarding its implementation. The need for a solution to handle this as a framework can be met with ASM. Vulnerability management is just one of the most critical use cases that can be done with ASM. You have all your assets and their information at your fingertips. You can analyze and perform detection operations on your system from a single platform. Creating your own use cases is possible by querying this information with a search language. What can be done is open-ended. ASM will become a more hyped topic in the coming years and will continue appearing in different areas.
[1] “The Five Stages of Vulnerability Management.” Available: https://blog.teamascend.com/stages-of-vulnerability-management. [Accessed: Feb. 01, 2024]
[2] Johner Institut, “CVSS, Common Vulnerability Scoring System, IT-Security,” Johner Institut, Dec. 04, 2023. Available: https://www.johner-institute.com/articles/software-iec-62304/and-more/cvss-common-vulnerability-scoring-system/. [Accessed: Feb. 01, 2024]
[3] W. Haydock, “Exploit Prediction Scoring System (EPSS): a deep dive,” Deploy Securely, Feb. 28, 2022. Available: https://blog.stackaware.com/p/deep-dive-into-the-epss. [Accessed: Feb. 01, 2024]