Mind the (Interpretation) gap: Another reason why threat modeling is important

Read Time:7 Minute, 55 Second

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

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)

SR/CR 1.4 – Identifier management

CWE-89

Improper Neutralization of Special Elements Used in an SQL Command (‘SQL Injection’)

SR/CR 3.5 – Input validation

CWE-319

Cleartext Transmission of Sensitive Information

SR/CR 4.1 – Information confidentiality

CWE-427

Uncontrolled Search Path Element

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’)

SR/CR 3.5 – Input validation

CWE-522

Insufficiently Protected Credentials

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

Commercial Facilities

CWE-79

Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’)

Food and Agriculture

CWE-20

Improper Input Validation

Chemical

CWE-20

Improper Input Validation

Healthcare and Public Health

CWE-284

Improper Access Control

Transportation

CWE-121

Stack-based Buffer Overflow

Oil and gas

CWE-119

Improper Restriction of Operations within the Bounds of a Memory Buffer

Government Facilities

CWE-121

Stack-based Buffer Overflow

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.