Estimating Time-To-Compromise for Industrial Control System Attack Techniques Through Vulnerability Data

When protecting the Industrial Control Systems against cyber attacks, it is important to have as much information as possible to allocate defensive resources properly. In this paper we estimate the Time-To-Compromise of different Industrial Control Systems attack techniques by MITRE ATT&CK. The Time-To-Compromise is estimated using an equation that takes into consideration the vulnerability data that exists for a specific asset and category of vulnerability. The vulnerability data is derived from an Industrial Control Systems specific vulnerability dataset. As a result, we present the mapping of the attack techniques to assets and categories of vulnerability, which makes it possible to apply specific vulnerabilities to the technique. We also present the method of how to estimate the Time-To-Compromise of the techniques and finally the values of Time-To-Compromise. After mapping the attack techniques to assets and category of vulnerability we are able to estimate the Time-To-Compromise and discuss its trustworthiness.


Introduction
Industrial Control Systems (ICS) are the backbone of our society. They are the systems that control our electricity and many other critical infrastructures. We are reliant on these systems and this makes them a target for cyber attacks by potential malicious actors. One of the most well-known examples of a cyber attack specifically targeting ICS is Triton. In 2017 an attack with Triton was able to shutdown a petrochemical facility [1]. The number of reported vulnerabilities for ICS are increasing [2] and it is important to create a method for assessing them. By assessing the Time-To-Compromise (TTC) of a vulnerability, we can estimate the time that it would take for an attacker to compromise an asset. Knowing this information can help us prioritising resource allocation to protect the system.
In this paper we apply our method for estimating the TTC for ICS, previously reported in [3]. We specifically extend that paper by applying the method to the ICS attack techniques found in the MITRE ATT&CK knowledge base [4]. The main contribution of this article is that the techniques of MITRE ATT&CK ICS can be assigned an estimated TTC. For example, the estimated TTC for the Man in the Middle technique used on a Human-Machine Interface (HMI) is 2501 days for a novice and 6 days for an expert hacker. The problem of how to estimate TTC is difficult because of the many variables involved. For instance, the type of attacker and how vulnerable the asset is will affect the TTC of the asset. The method for estimating TTC was first created by McQueen et al. [5] and our method for estimating TTC for the ICS domain, labeled TTC ICS , is an adaption of that method. In our adaptation we, for example, use an ICS specific vulnerability dataset [6] to make the estimate ICS specific. In the next section we present the related work and then we give background to TTC, the ICS vulnerability dataset, as well as, the MITRE ATT&CK knowledge base. This article is part of the topical collection "Advances on Information Systems Security and Privacy" guest edited by Steven Furnell and Paolo Mori.
The continued sections includes the method, the results and finally the discussion.

Related Work
Several work exists that has developed the original TTC by McQueen et al. [5] further. In TTC ICS [3] we update several parameters based on new research and make the estimate specific for the ICS domain. Nzoukou et al. [7] estimates the Mean-Time-To-Compromise (MTTC) for a whole system using a Bayesian network. They assign the individual MTTC values based on exploits instead of giving a more general MTTC for the components. Zieger et al. [8] developed -TTC, which extends the original TTC and fixes some mathematical flaws. The mathematical flaw is for a variable that exists in the original TTC, but it does not exist in TTC ICS . They also divide the vulnerabilities into confidentiality, integrity, availability and execution.
Both Nzoukou et al. and Zieger et al add the metric Common Vulnerability Scoring System (CVSS) [9] to their estimate to add the exploit complexity into the equation. Leversage and Byres [10] developed a Mean Time-To-Compromise (MTTC) interval where they considered frequency of reviews of the access control list (ACL) rules as part of the estimate. They also replace McQueen et al.'s fraction of vulnerabilities that are exploitable based on skill level with the concept skill indicator.
In this paper we assign TTC values to ICS attack techniques defined by MITRE ATT&CK. A similar attempt to assign TTC probability distributions to the MITRE ATT&CK Enterprise domain was made by Xiong et al. [11]. They use a different method than the equation of estimating TTC as described in this paper and focus on the enterprise domain rather than the ICS domain. The method they use is to find resources, such as, academic papers and technical reports that contain information about the time taken for an attack or the probability that it succeeds. They do so with a systematic literature review and evaluate the credibility of the source since they acknowledge that the result is qualitative rather than quantitative. Considering that our method is quantitative, it makes it easier to update the TTC values and allows for more scalability.
The ICS asset that the techniques can be used on is specified in the MITRE ATT&CK framework. In the vulnerability dataset used when estimating the TTC ICS , the vulnerabilities are categorised according to product type. Since the ICS asset and product types do not directly translate, we must find a method of mapping the ICS assets to product type. Otherwise, we are unable to find the correct vulnerabilities in the dataset. A similar method of mapping the MITRE ATT&CK techniques to vulnerabilities is done by the Center for Threat Informed Defense [12].
They use the techniques for describing vulnerabilities in the Common Vulnerabilities and Exposures (CVE) list. Their intention is that this will make it easier for defenders to integrate vulnerabilities into their threat modeling considering that the vulnerabilities themselves are often detailed and technical rather than higher-level. When mapping, they ask the question "what steps are necessary to exploit this vulnerability?" and select a technique based on this.

Background
In the following background sections, we describe the TTC by McQueen et al. [5], the ICS vulnerability dataset used to estimate the TTC [6] and finally the MITRE ATT &CK ICS technique knowledge base [4] on which we apply the TTC estimations.

Time-To-Compromise
In 2006, McQueen et al. published their first paper on the TTC and presented a method of how to estimate it [5]. The application of TTC estimations of ICS used in this paper is built on TTC ICS , which is an extension of the original TTC [3]. The TTC is estimated by combining the time to complete and probability for an attacker to exist in three different processes. In the first process, there is at least one available exploit and one known vulnerability for the component. In process two, there is no known exploit but at least one vulnerability is known. The third process is finding new vulnerabilities and creating new exploits. An attacker is either in process one or two since these are mutually exclusive, but will always continue to be in process three.
The TTC is estimated for four different skill levels of the attacker. These skill level are novice, beginner, intermediate and expert. McQueen et al. make the assumption that a more skilled attacker would have more exploits available to them and therefore the TTC would decrease. The differences between the TTC and TTC ICS are several. First, the dataset of vulnerabilities is different since we use a ICS specific dataset [6]. Next, the method of calculating the number and fraction of exploits available to the hacker based on skill level is updated. The estimated times to complete processes one and two are also updated based on new research. Instead of using a fixed value of Mean-Time-Between-Vulnerabilities (MTBV) in TTC ICS this value is estimated for every type of attack. We have also included the values of CVSS to take into consideration the severity or exploitability of the vulnerability.

Vulnerability Dataset
To make the TTC ICS ICS specific, we use a vulnerability dataset that only includes vulnerabilities for the ICS domain. 1 The dataset includes the product types as seen in Table 1 and the many different categories of vulnerabilities. The eight main categories are shown in Table 2 and these cover 95% of all vulnerabilities [6]. Compared to the more than 185 000 vulnerabilities in the National Vulnerability Database (NVD), 2 the ICS vulnerability dataset includes only 2740 vulnerabilities, after removing rejected ones.
Besides categorizing the vulnerabilities according to product type and category of vulnerability, the dataset also includes other important data for estimate the TTC, as seen in Table 3. Considering that CVSS version 2 type of vulnerabilities does not include a CVSS exploitability score, we also use the value of the CVSS base score when estimating the TTC. The ICS advisory creation date is used when estimating the Mean-Time-Between-Vulnerabilities (MTBV).

Techniques Knowledge Base
MITRE ATT&CK [4] is a knowledge base of tactics and techniques for attacking systems. One of the intentions of the knowledge base is to function as a framework when assessing the security of a system. When developing threat models it is useful to be able to refer to established tactics and techniques since it makes it easier to share information. With the work presented in this paper we aim to contribute to MITRE ATT&CK by adding the estimate of TTC ICS . MITRE ATT&CK includes tactics and techniques for the enterprise, mobile and ICS domains. In this paper we only focus on the tactics and techniques of the ICS domain. The MITRE ATT&CK ICS matrix shows the relation between the 78 different techniques categorized by 12 different tactics.
The tactics of MITRE ATT&CK answers the question why an attacker wants to perform an action. The techniques answers the question of how they perform the action. For example, an attacker may use the technique Exploit Public-Facing Application as a how to perform the tactics of Initial Access. The Initial Access is why they wanted to perform the technique. There are some techniques that can be used for several tactics. Besides the tactics and techniques, the knowledge base also includes which asset the technique applies to. MITRE recognizes seven assets in ICS networks: Control Server, Data Historian, Engineering Workstation, Field Controller/RTU/PLC/IED, Human-Machine Interface,

Mapping of Techniques
The method of estimating TTC ICS for an attack requires that the product type and category of vulnerability are known. This is because we use a dataset of vulnerabilities for ICS that categories the vulnerabilities according to product type and category of vulnerability. When estimating the TTC ICS , we want to be able to find the specific vulnerabilities applicable for that product type and vulnerability. We assign the product type and vulnerability category for each technique as a way of mapping them. First we translate the ICS asset, which MITRE specifies for each technique, to product type and then we read the description of the technique to assign the most appropriate category of vulnerability that the technique is used for. The techniques in the MITRE ATT&CK knowledge base specify which ICS asset that the technique relates to. For 13 of the techniques, MITRE does not specify an ICS asset and then we do not map it or estimate the TTC ICS . Two of the seven ICS assets defined by MITRE ATT &CK are not present as a product type in the ICS vulnerability dataset. This is because the assets, Engineering workstation and Data historian, are not necessarily ICS specific. To still be able to align the two ICS assets to the ICS vulnerability dataset, we search through the description of the vulnerability for the keywords "workstation" and "historian". We only search the description of those vulnerabilities in the dataset that do not already have an assigned product type. The product type for these vulnerabilities are set to "NULL".
When mapping the techniques to vulnerability categories, we ask the questions "Which of the vulnerability categories present in the dataset is the most aligned to the described technique?" In addition we also look at the mitigations for the technique as suggested by MITRE to help us map correctly. For example, if the mitigation for the attack is "Access Management" the appropriate vulnerability category may be "Access Control". We first consider the main eight categories as seen in Table 2. If these categories are not valid vulnerabilities for the technique, we try to align it to any of the "Other" categories. The "Other" are 21 smaller categories that have been manually selected by the creators of the ICS vulnerability dataset.

Estimation of TTC ICS
When using the estimate for TTC ICS , some of the variables are fixed and some needs to be adjusted for the specific technique that we want to estimate the TTC ICS for.
In process 1, as seen in Eq. 1 below, the value of k is fixed to 2740 since that is the total number of entries in the ICS vulnerabilities dataset [6]. This value will change if the number of vulnerabilities of the dataset changes. The aim is to have the total number of vulnerabilities for all ICS assets.
The values of v, c2 and c3 depends on the number of vulnerabilities that exist for the specific technique. For m, the value is derived by searching for exploits in the Metasploit database. The Metasploit database ranks their exploits depending on how reliable they are, and we use this ranking to assume which exploit would be usable by an attacker with different skill levels. For example, if an exploit is of ranking "Excellent", we assume that all four skill levels of an attacker can use the exploit. However, if the exploit has a "Low" ranking, we assume that only expert attacker would be able to modify and use the exploit successfully. To find the number of exploits with access control as part of the description, at skill level excellent, the following search command is used: search description:"access control" type:exploit rank:excellent where v is the total number of vulnerabilities of that type component for that type attack [6], m is the number of exploits available to the hacker based on skill level, k is the total number of vulnerabilities [6], c2 is the average CVSS of version 2 vulnerabilities and c3 is the average CVSS of version 3 vulnerabilities.
The probability of an attacker to be in process 2 is the inverse of the probably of being in process 1, as seen in Eq. 2. The time taken to complete process 2 is estimated to be 37 days for a novice, 27 days for a beginner, 16 days for an intermediate and 6 days by an expert attacker. These values are found from a report which estimates that the time taken to develop an exploit for a known vulnerability is usually between 6 to 37 days with a median value of 22 days [13]. We derive our values by dividing the range of days between the four different skill levels of an attacker. Even though the report is not ICS specific, we assume that the time that it takes to develop an exploit is the same for the ICS domain as for any other domain.
Considering that process 3 is running in parallel to process 1 and 2, since an attacker could continuously try to find new vulnerabilities and build exploits, we do not estimate the probability of an attacker to be in process 3. For the time taken to complete process 3, we firstly consider the time that it would take an attacker to create an exploit for a known vulnerability and the time t 2 . Secondly we use the fraction of vulnerabilities that are exploitable (f), as seen in Table 4, and the Mean Time Between Vulnerabilities (b) to estimate the time it would take to find a new vulnerability and create an exploit for it.
The fraction of vulnerabilities that are exploitable (f) is estimated based on the CVSS exploitability score considering all the vulnerabilities in the vulnerability dataset. This gives us an estimate of which fraction of the vulnerabilities is exploitable for each skill level. 1916 of the records had the score assigned from values 0.3 to 3.9, but we consider the theoretical maximum range of 0.1 to 3.9 as seen in Table 4. Each of the vulnerabilities have a creation date of when the vulnerability became a CVE entry. We use the average time between each creation date to estimate the Mean Time Between Vulnerabilities (b). In reality the value shows how often a vulnerability is reported for a specific product type and category of vulnerability, but we use it as an indication of how often vulnerabilities are found.
where t 2 is the number of days taken to develop a new exploit, f' is the inverse of the fraction of vulnerabilities that are exploitable based on skill level and b is the Mean-Time-Between-Vulnerabilities (MTBV) in days as calculated from the ICS advisory creation day. (2) where T is the expected TTC, u = (1-f) v , which is the probability that Process 2 is unsuccessful where v is the number of vulnerabilities and f is fraction of vulnerabilities that are exploitable for a specific skill level. Also, u=1 if v=0.

Results
The mapping between the MITRE ATT &CK ICS assets and the product types of the ICS dataset are shown in Table 5.
The reasoning when mapping the techniques to vulnerability categories is presented in Appendix 7. There are 78 techniques defined by MITRE ATT&CK, but as described in Sect. "Mapping of Techniques", 13 have been removed since they did not define an ICS asset affected by the technique. We are thus left with 65 techniques. We can see some patterns, such as that Initial Access techniques mostly relate to access control vulnerabilities and execution and persistence mostly relate to command or code injections. We also see how most Collection techniques relate to information leakage vulnerabilities and Lateral Movement is caused by access control issues. In Table 6 we show an overview of the different vulnerability categories with ICS assets that were found when mapping the MITRE ATT&CK techniques.
Considering that the calculation of TTC ICS follows the same method, we do not show the result of all estimated values. Instead we focus on the most common vulnerability categories that we found when mapping the techniques. These are Access Control, Information Leakage and Denial of Service.
We also estimate the TTC ICS specifically for the ICS assets HMI and protection system. This is because the HMI is most commonly place on the edge of the network and sometimes accessible remotely whereas the protection system is often placed further within the network. By looking at two different types of assets while considering three different vulnerability categories we will be able to showcase the estimation of TTC ICS . The results on the estimated TTC ICS values are found in Table 7, rounded to the nearest day.  We can see from Table 7 that generally the techniques with Access Control for HMI have a higher TTC ICS compared to Information Leakage and Denial of Service. It is expected that it would take more time to gain access on an HMI compared to cause an DoS or even gain information from, for example, sniffing. The type of vulnerability with lower TTC ICS is Denial of Service, which is one of the common types of attacks against ICS [14]. The data also suggest that the TTC ICS is higher for protection systems. This supports the idea that protection systems and other OT-systems, as compared to more standard IT-systems, are more difficult to access and understand for attackers than the contradicting hypothesis that OT systems are generally built with poorer security. We must however also acknowledge the data set that we have with 148 vulnerabilities for HMI as compared to 32 for protection systems.
It appears that for the protection system, the TTC ICS is similar for Access Control and Denial of Service. A possible explanation to this could be that protection systems are sometimes completely lacking access control. Poor access control was found to be a common weakness in new ICS software in 2009-2010 [15].

Discussion
From the results we can see that the TTC ICS for protection systems information leakage stands out as low. The reason for this is that the vulnerabilities in the dataset were reported on the same day and therefore the MTBV is 0. For the estimation, this indicates that new vulnerabilities are very quickly being discovered, even though that is not the case since the vulnerabilities were only 4. Improvements on the tool would be to in these cases use another MTBV, such as the average MTBV for those types of vulnerabilities for any given asset. In this case the average MTBV for all vulnerabilities of type Information Leakage is 14, rounded to the closest day. This is still a lot lower MTBV compared to the other estimated TTCs, but using the MTBV of 14 changes the TTC ICS from 37, 27, 16 and 6 days to 258, 44, 17 and 6 days. It is also noticeable from the results that regardless of the type of asset or category of vulnerability, an expert is able to compromise it in 6 days. The result of the final TTC estimate is greatly dependent on how we map the techniques of attack to vulnerability category type. It is also dependent on how we map the ICS assets to the assets present in the ICS vulnerability dataset. Many of the techniques maps to the same vulnerability category and product type. This means that we will see the same TTC ICS for many different techniques. This is due to the lack of granularity and we could achieve a more specific value of TTC ICS per technique if the techniques were more specific. We believe, however, that it is a good start to get a TTC ICS value per technique even though many of them will be the same. Two of the ICS assets from MITRE ATT&CK were not present in the vulnerability dataset and in this case we instead searched the description of the vulnerability. An improvement would be to continue the categorisation work of the dataset and assign asset to each vulnerability. Many of the assets in the vulnerability dataset did not have an asset defined.
We acknowledge that the ICS vulnerability dataset must be accurate to result in a correctly estimated TTC value, which places the trust in already conducted research. We also trust that the method of estimating the TTC ICS is accurate. Considering that TTC ICS combines data and frameworks in a novel way, we are unable to compare it directly to other existing TTC approaches. For example, the TTC by McQueen etl. al. [5] does not look at specific attacks, but estimates the overall TTC for components. Instead, the results of the estimate has been evaluated by comparing it to other research results. However, future work includes further validation by interviewing experts in the ICS domain. The experts would be able to compare their assessment of the TTC with the results in this article. Other future work is to create an automated tool to estimate the TTC instead of using an Excel sheet to do the calculations. The tool could automatically be updated if the MITRE ATT&CK techniques or the vulnerability dataset would change to stay up-to-date.
In a survey where ethical hackers were asked about how long it takes for them to perform certain tasks, it was found that it takes the majority are able to collect data after gaining access to a system in between 1 and 5 h [16]. The same survey shows that it takes the majority 1-5 h to break into an environment after finding an exposure. For the estimated TTC ICS , we found that it would take an expert 6 days to compromise the asset. The discrepancy in TTC could be because the survey of ethical hackers were not ICS specific and this could indicate that typical IT systems are faster to compromise. The reason could also be related to that the time scale is not calibrated between the two data sets.

Initial Access
• Exploit Public-Facing Application The public-facing application can be accessible remotely via the Internet when using a web browser and therefore we consider the category of vulnerability as Web. • Exploitation of Remote Services This vulnerability does not have to be external facing, the attacker can, for example, move laterally from the IT network. The technique gives both initial access to the ICS environment and lateral movement within so we consider the category as Access Control. • External Remote Services This technique exploits remote services that run externally. Considering that the external remote services means an initial access to a service that is should not be accessible by an attacker, we consider this to be an Access Control vulnerability. • Internet Accessible Device Even though the main weakness is that the device is accessible via the Internet, the vulnerability itself is that the access control is not implemented correctly in case of an attach. Therefore we consider it to be a Access Control category. • Remote Services By exploiting remote services, the attacker is typically using vulnerabilities of the type Access Control, since they have been able to bypass this. • Replication Through Removable Media For this technique, the attacker would place malware on removable media, for example a USB, and physically connect it to the system. Since this technique could place any number of different types of vulnerabilities on the removable media, we are unable to categorize it.

Command and Control
• Commonly Used Port Using common ports for communication to hide the traffic flow is not exploiting a vulnerability therefore we cannot categorize it. • Standard Application Layer Protocol Using application layer protocols for malicious communication is not caused by exploiting a vulnerability and therefore we cannot categorize it.

Impact
• Loss of View Causing a loss of view of ICS equipment we consider to be of a Denial of Service type of vulnerability. • Manipulation of View If an attacker can manipulate the view we assume that they have access and therefore we consider it to be a Access Control type of vulnerability.