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