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
