The content of this post is solely the responsibility of the author. AT&T does not adopt or endorse any of the views, positions, or information provided by the author in this article.
Where do vulnerabilities fit with respect to security standards and guidelines? Was it a coverage issue or an interpretation and implementation issue? Where does a product, environment, organization, or business vertical fail the most in terms of standards requirements? These questions are usually left unanswered because of the gap between standards or regulations on the one hand, and requirements interpretation and implementation, on the other. Certified products and environments often suffer from security issues that were supposed to be covered by the requirements of the standard.
In [1], for instance, the authors give examples of vulnerable products that were IEC 62443 certified. In [2], SANS discusses the case of PCI-certified companies and why they are still being breached. This “interpretation gap,” whether it manifests in the implementation of requirements or in the assessment process, hinders security and leads to the fact that being compliant is not necessarily the same as being secure.
Admittedly, the interpretation of guidelines and requirements in standards, which have a descriptive approach in general, is not an easy task. Requirements can be rather generic and wide open to interpretation depending on the context, resources, the current threat landscape, the underlying technologies, etc. Specific requirements might also lead to conflicting interpretations depending on the type of stakeholder, which will inevitably affect the implementation side.
Threat modeling is one way to avoid shortcomings (or even possible shortcuts) in the implementation of standards, and the organization’s own security policies. Think of threat modeling as an enforcement mechanism for the proper implementation of requirements. The reason this is the case is simple; threat modeling thinks of the requirements in terms of relevant threats to the system, and determines mitigations to reduce or completely avoid the associated risks. Consequently, each requirement is mapped to a set of threats and mitigations that covers relevant use cases under specific conditions or context, e.g., what are the trust boundaries, protocols and technologies under use or consideration, third-party interactions, dataflows, data storage, etc.
This is becoming a must-have nowadays since, when it comes to technical requirements, the concern about their interpretation still persists even when companies have been audited against them. In the following, the presented data analysis makes the link between disclosed vulnerabilities in Industrial Control Systems (ICS) and the technical requirements reported in the ‘gold standard’ of standards in this area, namely the IEC 62443. It shows the difficulty of satisfying the requirements in broad terms and the need for more specific context and processes.
CISA ICS advisories’ mapping
The analysis of CISA ICS advisories data, representing close to 2,5K advisories released between 2010 and mid-2023 [3], reveals the extent of the challenge an implementer or an assessor is faced with. Table 1 presents the top weaknesses and the associated count of advisories as well as IEC 62443 requirements’ mapping. Affected sectors, the CVSS severity distribution, and top weaknesses per sector are also reported; in Figures 1 and 2, and Table 2.
Table 1. Top weaknesses in CISA’s ICS advisories and their IEC 62443 mapping.
|
Weakness |
Name |
Number of advisories |
IEC 62443 technical requirement |
|
CWE-20 |
Improper Input Validation |
266 |
SR/CR 3.5 – Input validation |
|
CWE-121 |
Stack-based Buffer Overflow |
257 |
|
|
CWE-79 |
Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’) |
205 |
|
|
CWE-119 |
Improper Restriction of Operations within the Bounds of a Memory Buffer |
185 |
|
|
CWE-284 |
Improper Access Control |
159 |
FR1 – Identification and authentication control (IAC)
FR2 – Use control (UC) |
|
CWE-125 |
Out-of-bounds Read |
158 |
SR/CR 3.5 – Input validation |
|
CWE-22 |
Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’) |
149 |
|
|
CWE-400 |
Uncontrolled Resource Consumption |
145 |
SR/CR 7.1 – Denial of service protection
SR/CR 7.2 – Resource management |
|
CWE-787 |
Out-of-bounds Write |
139 |
SR/CR 3.5 – Input validation |
|
CWE-287 |
Improper Authentication |
137 |
SR/CR 1.1 – Human user identification and authentication
SR/CR 1.2 – Software process and device identification and authentication |
|
CWE-122 |
Heap-based Buffer Overflow |
128 |
SR/CR 3.5 – Input validation |
|
CWE-200 |
Exposure of Sensitive Information to an Unauthorized Actor |
115 |
FR4 – Data confidentiality (DC)
SR/CR 3.7 – Error handling |
|
CWE-798 |
Use of Hard-coded Credentials |
101 |
SR/CR 1.5 – Authenticator management |
|
CWE-306 |
Missing Authentication for Critical Function |
98 |
SR/CR 1.1 – Human user identification and authentication
SR/CR 1.2 – Software process and device identification and authentication
SR/CR 2.1 – Authorization enforcement |
|
CWE-352 |
Cross-Site Request Forgery (CSRF) |
84 |
SR/CR 1.4 – Identifier management |
|
CWE-89 |
Improper Neutralization of Special Elements Used in an SQL Command (‘SQL Injection’) |
81 |
SR/CR 3.5 – Input validation |
|
CWE-319 |
Cleartext Transmission of Sensitive Information |
75 |
SR/CR 4.1 – Information confidentiality |
|
CWE-427 |
Uncontrolled Search Path Element |
64 |
SR/CR 3.5 – Input validation
CR 3.4 – Software and information integrity |
|
CWE-120 |
Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’) |
62 |
SR/CR 3.5 – Input validation |
|
CWE-522 |
Insufficiently Protected Credentials |
62 |
SR/CR 1.5 – Authenticator management |
|
Figure 1. Number of vulnerabilities per sector
|
|
Figure 2. CVSS severity distribution.
|
Table 2. Top weaknesses per sector.
|
Sector |
Top Weakness |
Name |
Number of advisories |
|
Critical Manufacturing |
CWE-121 |
Stack-based Buffer Overflow |
175 |
|
Energy
|
CWE-20 |
Improper Input Validation |
147 |
|
Water and Wastewater |
CWE-20 |
Improper Input Validation |
87 |
|
Commercial Facilities |
CWE-79 |
Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’) |
42 |
|
Food and Agriculture |
CWE-20 |
Improper Input Validation |
55 |
|
Chemical |
CWE-20 |
Improper Input Validation |
54 |
|
Healthcare and Public Health |
CWE-284 |
Improper Access Control |
32 |
|
Transportation |
CWE-121 |
Stack-based Buffer Overflow |
31 |
|
Oil and gas |
CWE-119 |
Improper Restriction of Operations within the Bounds of a Memory Buffer |
18 |
|
Government Facilities |
CWE-121 |
Stack-based Buffer Overflow |
18 |
Guiding requirements’ interpretation
Table 1 shows the varied levels of abstraction the vulnerabilities map to. This is one of the main issues leading to the increased complexity associated with the interpretation of requirements; for both the implementation and the assessment. While a high level of granularity allows for the definition of needed security mechanisms, a low level of granularity during the interpretation and implementation is necessary as it allows for a better understanding of all the types of threats or failures that a specific system might be subject to, e.g., given a deployment model or an underlying technology.
The case of the “Input validation” requirement is revealing, with eleven of the top twenty weaknesses in Table 1 falling under it. On the surface, input validation is rather straightforward; analyze inputs and disallow anything that can be considered unsuitable. In practice, however, the number of properties of the data and input use cases to potentially validate can be daunting. It might also be hard, or even impossible, to flush out all possible corner cases. The IEC 62443 “input validation” requirement is quite generic and encapsulates two CWE categories; “Validate Inputs” [4] and “Memory Buffer Errors” [5]. It is then essential to have a clear understanding of the target application or system to be able to identify relevant threats under each requirement and how to prevent them, i.e., achieve the said requirement.
On the other hand, the “Improper access control” weakness [6] is also an interesting use case. It is extremely high-level and maps to two foundational requirements of the IEC 62443. This highlights an issue in vulnerability reports, where high-level abstraction weaknesses are being misused in disclosure reports. More specific weaknesses related to the kind of access control involved would have been more appropriate, e.g., missing or weak authentication, missing or incorrect authorization, etc. This is not useful for trend analysis, especially on how real-world vulnerabilities relate to technical requirements in standards and regulations.
Threat modeling is helpful in both cases. Software developers, system architects, and security professionals can understand the requirements and address the predictable security issues that fall under them, given specific assumptions about the application or the system setup. In addition, current threat modeling tools can speed up the process by generating the relevant threats and their mitigations automatically, including based on threat intelligence data. The set of mitigations can also be tailored to meet different needs; for instance, the strength of a potential adversary, as is the case in the IEC 62443 standard, where four security levels are defined. These security levels (1 to 4) define technical requirements, along with requirement enhancements, in order to counter different levels of risk.
I believe that by using threat modeling as a framework, the interpretation and mapping of requirements into implementation and deployment measures become more predictable. It will also give developers and system architects a better chance of more complete coverage and accurate description of what the requirements ought to be, given the target system context, its dependencies, and the current threat landscape.
The guest author of this blog is a security researcher at iriusrisk.com.
References
[1] https://arxiv.org/pdf/2303.12340.pdf
[2] https://www.sans.org/white-papers/36497/
[3] https://www.cisa.gov/news-events/cybersecurity-advisories
[4] https://cwe.mitre.org/data/definitions/1019.html
[5] https://cwe.mitre.org/data/definitions/1218.html
[6] https://cwe.mitre.org/data/definitions/284.html