Another purpose why risk modeling is essential

0
909
Another purpose why risk modeling is essential


The content material of this put up is solely the duty of the writer.  AT&T doesn’t undertake or endorse any of the views, positions, or data offered by the writer on this article. 

Where do vulnerabilities match with respect to safety requirements and tips? Was it a protection situation or an interpretation and implementation situation? Where does a product, atmosphere, group, or enterprise vertical fail probably the most by way of requirements necessities? These questions are often left unanswered due to the hole between requirements or laws on the one hand, and necessities interpretation and implementation, on the opposite. Certified merchandise and environments typically undergo from safety points that had been presupposed to be lined by the necessities of the usual.

In [1], as an illustration, the authors give examples of susceptible merchandise that had been IEC 62443 licensed. In [2], SANS discusses the case of PCI-certified corporations and why they’re nonetheless being breached. This “interpretation gap,” whether or not it manifests within the implementation of necessities or within the evaluation course of, hinders safety and results in the truth that being compliant isn’t essentially the identical as being safe.

Admittedly, the interpretation of tips and necessities in requirements, which have a descriptive method generally, isn’t a straightforward job. Requirements will be relatively generic and large open to interpretation relying on the context, sources, the present risk panorama, the underlying applied sciences, and so forth. Specific necessities may also result in conflicting interpretations relying on the kind of stakeholder, which is able to inevitably have an effect on the implementation aspect.

Threat modeling is one technique to keep away from shortcomings (and even doable shortcuts) within the implementation of requirements, and the group’s personal safety insurance policies. Think of risk modeling as an enforcement mechanism for the right implementation of necessities. The purpose that is the case is easy; risk modeling thinks of the necessities by way of related threats to the system, and determines mitigations to scale back or utterly keep away from the related dangers. Consequently, every requirement is mapped to a set of threats and mitigations that covers related use instances underneath particular circumstances or context, e.g., what are the belief boundaries, protocols and applied sciences underneath use or consideration, third-party interactions, dataflows, information storage, and so forth.

This is turning into a must have these days since, in the case of technical necessities, the priority about their interpretation nonetheless persists even when corporations have been audited towards them. In the next, the offered information evaluation makes the hyperlink between disclosed vulnerabilities in Industrial Control Systems (ICS) and the technical necessities reported within the ‘gold standard’ of requirements on this space, particularly the IEC 62443. It reveals the problem of satisfying the necessities in broad phrases and the necessity for extra particular context and processes.

CISA ICS advisories’ mapping

The evaluation of CISA ICS advisories information, representing near 2,5K advisories launched between 2010 and mid-2023 [3], reveals the extent of the problem an implementer or an assessor is confronted with. Table 1 presents the highest weaknesses and the related depend of advisories in addition to IEC 62443 necessities’ mapping. Affected sectors, the CVSS severity distribution, and prime weaknesses per sector are additionally reported; in Figures 1 and a pair of, 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 inside the Bounds of a Memory Buffer

185

CWE-284

Improper Access Control

159

FR1 – Identification and authentication management (IAC)

 

FR2 – Use management (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 safety

 

SR/CR 7.2 – Resource administration

CWE-787

Out-of-bounds Write

139

SR/CR 3.5 – Input validation

CWE-287

Improper Authentication

137

SR/CR 1.1 – Human person identification and authentication

 

SR/CR 1.2 – Software course of and machine 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 dealing with

CWE-798

Use of Hard-coded Credentials

101

SR/CR 1.5 – Authenticator administration

CWE-306

Missing Authentication for Critical Function

98

SR/CR 1.1 – Human person identification and authentication

 

SR/CR 1.2 – Software course of and machine identification and authentication

 

SR/CR 2.1 – Authorization enforcement

CWE-352

Cross-Site Request Forgery (CSRF)

84

SR/CR 1.4 – Identifier administration

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 knowledge integrity

CWE-120

Buffer Copy with out 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 administration

 

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 fuel

CWE-119

Improper Restriction of Operations inside the Bounds of a Memory Buffer

18

Government Facilities

CWE-121

Stack-based Buffer Overflow

18

 

Guiding necessities’ interpretation

Table 1 reveals the numerous ranges of abstraction the vulnerabilities map to. This is likely one of the foremost points resulting in the elevated complexity related to the interpretation of necessities; for each the implementation and the evaluation. While a excessive stage of granularity permits for the definition of wanted safety mechanisms, a low stage of granularity in the course of the interpretation and implementation is important because it permits for a greater understanding of all of the kinds of threats or failures {that a} particular system could be topic to, e.g., given a deployment mannequin or an underlying expertise.

The case of the “Input validation” requirement is revealing, with eleven of the highest twenty weaknesses in Table 1 falling underneath it. On the floor, enter validation is relatively simple; analyze inputs and disallow something that may be thought-about unsuitable. In observe, nevertheless, the variety of properties of the information and enter use instances to probably validate will be daunting. It may also be laborious, and even unattainable, to flush out all doable nook instances. The IEC 62443 “input validation” requirement is kind of generic and encapsulates two CWE classes; “Validate Inputs” [4] and “Memory Buffer Errors” [5]. It is then important to have a transparent understanding of the goal utility or system to have the ability to determine related threats underneath every requirement and learn how to forestall them, i.e., obtain the stated requirement.

On the opposite hand, the “Improper access control” weak point [6] can be an fascinating use case. It is extraordinarily high-level and maps to 2 foundational necessities of the IEC 62443. This highlights a problem in vulnerability experiences, the place high-level abstraction weaknesses are being misused in disclosure experiences. More particular weaknesses associated to the sort of entry management concerned would have been extra applicable, e.g., lacking or weak authentication, lacking or incorrect authorization, and so forth. This isn’t helpful for development evaluation, particularly on how real-world vulnerabilities relate to technical necessities in requirements and laws.

Threat modeling is useful in each instances. Software builders, system architects, and safety professionals can perceive the necessities and handle the predictable safety points that fall underneath them, given particular assumptions in regards to the utility or the system setup. In addition, present risk modeling instruments can pace up the method by producing the related threats and their mitigations routinely, together with primarily based on risk intelligence information. The set of mitigations can be tailor-made to satisfy completely different wants; as an illustration, the energy of a possible adversary, as is the case within the IEC 62443 customary, the place 4 safety ranges are outlined. These safety ranges (1 to 4) outline technical necessities, together with requirement enhancements, with the intention to counter completely different ranges of danger.

I consider that by utilizing risk modeling as a framework, the interpretation and mapping of necessities into implementation and deployment measures develop into extra predictable. It will even give builders and system architects a greater probability of extra full protection and correct description of what the necessities must be, given the goal system context, its dependencies, and the present risk panorama.

The visitor writer of this weblog is a safety 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 

LEAVE A REPLY

Please enter your comment!
Please enter your name here