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

Wednesday, August 9, 2023

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

9:11 PM FireSaleHackBoy No comments

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	SR/CR 3.5 – Input validation
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

chart of vulnerabilities by sector

Figure 2. CVSS severity distribution.

pie chart of CVSS distrubution by severity

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.