Home > CWE List > VIEW SLICE: CWE-1358: Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS (4.16) |
|
CWE VIEW: Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS
CWE entries in this view (graph) are associated with the Categories of Security Vulnerabilities in ICS, as published by the Securing Energy Infrastructure Executive Task Force (SEI ETF) in March 2022. Weaknesses and categories in this view are focused on issues that affect ICS (Industrial Control Systems) but have not been traditionally covered by CWE in the past due to its earlier emphasis on enterprise IT software. Note: weaknesses in this view are based on "Nearest IT Neighbor" recommendations and other suggestions by the CWE team. These relationships are likely to change in future CWE versions.
The following graph shows the tree-like relationships between
weaknesses that exist at different levels of abstraction. At the highest level, categories
and pillars exist to group weaknesses. Categories (which are not technically weaknesses) are
special CWE entries used to group weaknesses that share a common characteristic. Pillars are
weaknesses that are described in the most abstract fashion. Below these top-level entries
are weaknesses are varying levels of abstraction. Classes are still very abstract, typically
independent of any specific language or technology. Base level weaknesses are used to
present a more specific type of weakness. A variant is a weakness that is described at a
very low level of detail, typically limited to a specific language or technology. A chain is
a set of weaknesses that must be reachable consecutively in order to produce an exploitable
vulnerability. While a composite is a set of weaknesses that must all be present
simultaneously in order to produce an exploitable vulnerability.
Show Details:
1358 - Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS
Category - a CWE entry that contains a set of other entries that share a common characteristic.
ICS Communications
- (1359)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications)
Weaknesses in this category are related to the "ICS Communications" super category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
ICS Communications: Zone Boundary Failures
- (1364)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1364
(ICS Communications: Zone Boundary Failures)
Weaknesses in this category are related to the "Zone Boundary Failures" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Within an ICS system, for traffic that crosses through network zone boundaries, vulnerabilities arise when those boundaries were designed for safety or other purposes but are being repurposed for security." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Improper Removal of Sensitive Information Before Storage or Transfer
- (212)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1364
(ICS Communications: Zone Boundary Failures) >
212
(Improper Removal of Sensitive Information Before Storage or Transfer)
The product stores, transfers, or shares a resource that contains sensitive information, but it does not properly remove that information before the product makes the resource available to unauthorized actors.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Privilege Chaining
- (268)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1364
(ICS Communications: Zone Boundary Failures) >
268
(Privilege Chaining)
Two distinct privileges, roles, capabilities, or rights can be combined in a way that allows an entity to perform unsafe actions that would not be allowed without that combination.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Privilege Management
- (269)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1364
(ICS Communications: Zone Boundary Failures) >
269
(Improper Privilege Management)
The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Authentication
- (287)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1364
(ICS Communications: Zone Boundary Failures) >
287
(Improper Authentication)
When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.
authentification
AuthN
AuthC
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Authentication Bypass Using an Alternate Path or Channel
- (288)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1364
(ICS Communications: Zone Boundary Failures) >
288
(Authentication Bypass Using an Alternate Path or Channel)
The product requires authentication, but the product has an alternate path or channel that does not require authentication.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Missing Authentication for Critical Function
- (306)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1364
(ICS Communications: Zone Boundary Failures) >
306
(Missing Authentication for Critical Function)
The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
- (362)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1364
(ICS Communications: Zone Boundary Failures) >
362
(Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
Race Condition
Composite - a Compound Element that consists of two or more distinct weaknesses, in which all weaknesses must be present at the same time in order for a potential vulnerability to arise. Removing any of the weaknesses eliminates or sharply reduces the risk. One weakness, X, can be "broken down" into component weaknesses Y and Z. There can be cases in which one weakness might not be essential to a composite, but changes the nature of the composite when it becomes a vulnerability.
Session Fixation
- (384)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1364
(ICS Communications: Zone Boundary Failures) >
384
(Session Fixation)
Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Unrestricted Upload of File with Dangerous Type
- (434)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1364
(ICS Communications: Zone Boundary Failures) >
434
(Unrestricted Upload of File with Dangerous Type)
The product allows the upload or transfer of dangerous file types that are automatically processed within its environment.
Unrestricted File Upload
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Download of Code Without Integrity Check
- (494)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1364
(ICS Communications: Zone Boundary Failures) >
494
(Download of Code Without Integrity Check)
The product downloads source code or an executable from a remote location and executes the code without sufficiently verifying the origin and integrity of the code.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Trust Boundary Violation
- (501)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1364
(ICS Communications: Zone Boundary Failures) >
501
(Trust Boundary Violation)
The product mixes trusted and untrusted data in the same data structure or structured message.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Exposure of Resource to Wrong Sphere
- (668)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1364
(ICS Communications: Zone Boundary Failures) >
668
(Exposure of Resource to Wrong Sphere)
The product exposes a resource to the wrong control sphere, providing unintended actors with inappropriate access to the resource.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Incorrect Resource Transfer Between Spheres
- (669)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1364
(ICS Communications: Zone Boundary Failures) >
669
(Incorrect Resource Transfer Between Spheres)
The product does not properly transfer a resource/behavior to another sphere, or improperly imports a resource/behavior from another sphere, in a manner that provides unintended control over that resource.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Check for Unusual or Exceptional Conditions
- (754)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1364
(ICS Communications: Zone Boundary Failures) >
754
(Improper Check for Unusual or Exceptional Conditions)
The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Inclusion of Functionality from Untrusted Control Sphere
- (829)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1364
(ICS Communications: Zone Boundary Failures) >
829
(Inclusion of Functionality from Untrusted Control Sphere)
The product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Improper Isolation of Shared Resources on System-on-a-Chip (SoC)
- (1189)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1364
(ICS Communications: Zone Boundary Failures) >
1189
(Improper Isolation of Shared Resources on System-on-a-Chip (SoC))
The System-On-a-Chip (SoC) does not properly isolate shared resources between trusted and untrusted agents.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Physical Access Control
- (1263)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1364
(ICS Communications: Zone Boundary Failures) >
1263
(Improper Physical Access Control)
The product is designed with access restricted to certain information, but it does not sufficiently protect against an unauthorized actor with physical access to these areas.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Non-Transparent Sharing of Microarchitectural Resources
- (1303)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1364
(ICS Communications: Zone Boundary Failures) >
1303
(Non-Transparent Sharing of Microarchitectural Resources)
Hardware structures shared across execution contexts (e.g., caches and branch predictors) can violate the expected architecture isolation between contexts.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Use of Default Password
- (1393)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1364
(ICS Communications: Zone Boundary Failures) >
1393
(Use of Default Password)
The product uses default passwords for potentially critical functionality.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
ICS Communications: Unreliability
- (1365)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1365
(ICS Communications: Unreliability)
Weaknesses in this category are related to the "Unreliability" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Vulnerabilities arise in reaction to disruptions in the physical layer (e.g. creating electrical noise) used to carry the traffic." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Stack-based Buffer Overflow
- (121)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1365
(ICS Communications: Unreliability) >
121
(Stack-based Buffer Overflow)
A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).
Stack Overflow
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Privilege Management
- (269)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1365
(ICS Communications: Unreliability) >
269
(Improper Privilege Management)
The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Missing Authentication for Critical Function
- (306)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1365
(ICS Communications: Unreliability) >
306
(Missing Authentication for Critical Function)
The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Acceptance of Extraneous Untrusted Data With Trusted Data
- (349)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1365
(ICS Communications: Unreliability) >
349
(Acceptance of Extraneous Untrusted Data With Trusted Data)
The product, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
- (362)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1365
(ICS Communications: Unreliability) >
362
(Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
Race Condition
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Reliance on Untrusted Inputs in a Security Decision
- (807)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1365
(ICS Communications: Unreliability) >
807
(Reliance on Untrusted Inputs in a Security Decision)
The product uses a protection mechanism that relies on the existence or values of an input, but the input can be modified by an untrusted actor in a way that bypasses the protection mechanism.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Improper Protection Against Voltage and Clock Glitches
- (1247)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1365
(ICS Communications: Unreliability) >
1247
(Improper Protection Against Voltage and Clock Glitches)
The device does not contain or contains incorrectly implemented circuitry or sensors to detect and mitigate voltage and clock glitches and protect sensitive information or software contained on the device.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Improper Handling of Single Event Upsets
- (1261)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1365
(ICS Communications: Unreliability) >
1261
(Improper Handling of Single Event Upsets)
The hardware logic does not effectively handle when single-event upsets (SEUs) occur.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Improper Handling of Faults that Lead to Instruction Skips
- (1332)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1365
(ICS Communications: Unreliability) >
1332
(Improper Handling of Faults that Lead to Instruction Skips)
The device is missing or incorrectly implements circuitry or sensors that detect and mitigate the skipping of security-critical CPU instructions when they occur.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Improper Handling of Hardware Behavior in Exceptionally Cold Environments
- (1351)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1365
(ICS Communications: Unreliability) >
1351
(Improper Handling of Hardware Behavior in Exceptionally Cold Environments)
A hardware device, or the firmware running on it, is
missing or has incorrect protection features to maintain
goals of security primitives when the device is cooled below
standard operating temperatures.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Handling of Physical or Environmental Conditions
- (1384)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1365
(ICS Communications: Unreliability) >
1384
(Improper Handling of Physical or Environmental Conditions)
The product does not properly handle unexpected physical or environmental conditions that occur naturally or are artificially induced.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
ICS Communications: Frail Security in Protocols
- (1366)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols)
Weaknesses in this category are related to the "Frail Security in Protocols" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Vulnerabilities arise as a result of mis-implementation or incomplete implementation of security in ICS implementations of communication protocols." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Stack-based Buffer Overflow
- (121)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols) >
121
(Stack-based Buffer Overflow)
A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).
Stack Overflow
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Out-of-bounds Read
- (125)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols) >
125
(Out-of-bounds Read)
The product reads data past the end, or before the beginning, of the intended buffer.
OOB read
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Privilege Chaining
- (268)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols) >
268
(Privilege Chaining)
Two distinct privileges, roles, capabilities, or rights can be combined in a way that allows an entity to perform unsafe actions that would not be allowed without that combination.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Privilege Management
- (269)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols) >
269
(Improper Privilege Management)
The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Incorrect Default Permissions
- (276)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols) >
276
(Incorrect Default Permissions)
During installation, installed file permissions are set to allow anyone to modify those files.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Authentication Bypass by Spoofing
- (290)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols) >
290
(Authentication Bypass by Spoofing)
This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Missing Authentication for Critical Function
- (306)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols) >
306
(Missing Authentication for Critical Function)
The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Missing Encryption of Sensitive Data
- (311)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols) >
311
(Missing Encryption of Sensitive Data)
The product does not encrypt sensitive or critical information before storage or transmission.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Cleartext Storage of Sensitive Information
- (312)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols) >
312
(Cleartext Storage of Sensitive Information)
The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Cleartext Transmission of Sensitive Information
- (319)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols) >
319
(Cleartext Transmission of Sensitive Information)
The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Missing Cryptographic Step
- (325)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols) >
325
(Missing Cryptographic Step)
The product does not implement a required step in a cryptographic algorithm, resulting in weaker encryption than advertised by the algorithm.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Use of a Broken or Risky Cryptographic Algorithm
- (327)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols) >
327
(Use of a Broken or Risky Cryptographic Algorithm)
The product uses a broken or risky cryptographic algorithm or protocol.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Use of Insufficiently Random Values
- (330)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols) >
330
(Use of Insufficiently Random Values)
The product uses insufficiently random numbers or values in a security context that depends on unpredictable numbers.
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Same Seed in Pseudo-Random Number Generator (PRNG)
- (336)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols) >
336
(Same Seed in Pseudo-Random Number Generator (PRNG))
A Pseudo-Random Number Generator (PRNG) uses the same seed each time the product is initialized.
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Predictable Seed in Pseudo-Random Number Generator (PRNG)
- (337)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols) >
337
(Predictable Seed in Pseudo-Random Number Generator (PRNG))
A Pseudo-Random Number Generator (PRNG) is initialized from a predictable seed, such as the process ID or system time.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Predictable from Observable State
- (341)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols) >
341
(Predictable from Observable State)
A number or object is predictable based on observations that the attacker can make about the state of the system or network, such as time, process ID, etc.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Acceptance of Extraneous Untrusted Data With Trusted Data
- (349)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols) >
349
(Acceptance of Extraneous Untrusted Data With Trusted Data)
The product, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Improperly Implemented Security Check for Standard
- (358)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols) >
358
(Improperly Implemented Security Check for Standard)
The product does not implement or incorrectly implements one or more security-relevant checks as specified by the design of a standardized algorithm, protocol, or technique.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
- (362)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols) >
362
(Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
Race Condition
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Insecure Temporary File
- (377)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols) >
377
(Insecure Temporary File)
Creating and using insecure temporary files can leave application and system data vulnerable to attack.
Composite - a Compound Element that consists of two or more distinct weaknesses, in which all weaknesses must be present at the same time in order for a potential vulnerability to arise. Removing any of the weaknesses eliminates or sharply reduces the risk. One weakness, X, can be "broken down" into component weaknesses Y and Z. There can be cases in which one weakness might not be essential to a composite, but changes the nature of the composite when it becomes a vulnerability.
Session Fixation
- (384)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols) >
384
(Session Fixation)
Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Incorrect Use of Privileged APIs
- (648)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols) >
648
(Incorrect Use of Privileged APIs)
The product does not conform to the API requirements for a function call that requires extra privileges. This could allow attackers to gain privileges by causing the function to be called incorrectly.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Out-of-bounds Write
- (787)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols) >
787
(Out-of-bounds Write)
The product writes data past the end, or before the beginning, of the intended buffer.
Memory Corruption
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Improper Isolation of Shared Resources on System-on-a-Chip (SoC)
- (1189)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols) >
1189
(Improper Isolation of Shared Resources on System-on-a-Chip (SoC))
The System-On-a-Chip (SoC) does not properly isolate shared resources between trusted and untrusted agents.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Non-Transparent Sharing of Microarchitectural Resources
- (1303)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols) >
1303
(Non-Transparent Sharing of Microarchitectural Resources)
Hardware structures shared across execution contexts (e.g., caches and branch predictors) can violate the expected architecture isolation between contexts.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Use of Default Password
- (1393)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1359
(ICS Communications) >
1366
(ICS Communications: Frail Security in Protocols) >
1393
(Use of Default Password)
The product uses default passwords for potentially critical functionality.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
ICS Dependencies (& Architecture)
- (1360)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1360
(ICS Dependencies (& Architecture))
Weaknesses in this category are related to the "ICS Dependencies (& Architecture)" super category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
ICS Dependencies (& Architecture): External Physical Systems
- (1367)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1360
(ICS Dependencies (& Architecture)) >
1367
(ICS Dependencies (& Architecture): External Physical Systems)
Weaknesses in this category are related to the "External Physical Systems" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Due to the highly interconnected technologies in use, an external dependency on another physical system could cause an availability interruption for the protected system." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Improper Protection Against Voltage and Clock Glitches
- (1247)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1360
(ICS Dependencies (& Architecture)) >
1367
(ICS Dependencies (& Architecture): External Physical Systems) >
1247
(Improper Protection Against Voltage and Clock Glitches)
The device does not contain or contains incorrectly implemented circuitry or sensors to detect and mitigate voltage and clock glitches and protect sensitive information or software contained on the device.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Improper Protections Against Hardware Overheating
- (1338)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1360
(ICS Dependencies (& Architecture)) >
1367
(ICS Dependencies (& Architecture): External Physical Systems) >
1338
(Improper Protections Against Hardware Overheating)
A hardware device is missing or has inadequate protection features to prevent overheating.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Reliance on Insufficiently Trustworthy Component
- (1357)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1360
(ICS Dependencies (& Architecture)) >
1367
(ICS Dependencies (& Architecture): External Physical Systems) >
1357
(Reliance on Insufficiently Trustworthy Component)
The product is built from multiple separate components, but it uses a component that is not sufficiently trusted to meet expectations for security, reliability, updateability, and maintainability.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Handling of Physical or Environmental Conditions
- (1384)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1360
(ICS Dependencies (& Architecture)) >
1367
(ICS Dependencies (& Architecture): External Physical Systems) >
1384
(Improper Handling of Physical or Environmental Conditions)
The product does not properly handle unexpected physical or environmental conditions that occur naturally or are artificially induced.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
ICS Dependencies (& Architecture): External Digital Systems
- (1368)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1360
(ICS Dependencies (& Architecture)) >
1368
(ICS Dependencies (& Architecture): External Digital Systems)
Weaknesses in this category are related to the "External Digital Systems" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Due to the highly interconnected technologies in use, an external dependency on another digital system could cause a confidentiality, integrity, or availability incident for the protected system." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
External Control of System or Configuration Setting
- (15)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1360
(ICS Dependencies (& Architecture)) >
1368
(ICS Dependencies (& Architecture): External Digital Systems) >
15
(External Control of System or Configuration Setting)
One or more system settings or configuration elements can be externally controlled by a user.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Authentication
- (287)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1360
(ICS Dependencies (& Architecture)) >
1368
(ICS Dependencies (& Architecture): External Digital Systems) >
287
(Improper Authentication)
When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.
authentification
AuthN
AuthC
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Missing Authentication for Critical Function
- (306)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1360
(ICS Dependencies (& Architecture)) >
1368
(ICS Dependencies (& Architecture): External Digital Systems) >
306
(Missing Authentication for Critical Function)
The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Use of Single-factor Authentication
- (308)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1360
(ICS Dependencies (& Architecture)) >
1368
(ICS Dependencies (& Architecture): External Digital Systems) >
308
(Use of Single-factor Authentication)
The use of single-factor authentication can lead to unnecessary risk of compromise when compared with the benefits of a dual-factor authentication scheme.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Cleartext Storage of Sensitive Information
- (312)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1360
(ICS Dependencies (& Architecture)) >
1368
(ICS Dependencies (& Architecture): External Digital Systems) >
312
(Cleartext Storage of Sensitive Information)
The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Expected Behavior Violation
- (440)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1360
(ICS Dependencies (& Architecture)) >
1368
(ICS Dependencies (& Architecture): External Digital Systems) >
440
(Expected Behavior Violation)
A feature, API, or function does not perform according to its specification.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
- (470)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1360
(ICS Dependencies (& Architecture)) >
1368
(ICS Dependencies (& Architecture): External Digital Systems) >
470
(Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection'))
The product uses external input with reflection to select which classes or code to use, but it does not sufficiently prevent the input from selecting improper classes or code.
Reflection Injection
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Use of Client-Side Authentication
- (603)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1360
(ICS Dependencies (& Architecture)) >
1368
(ICS Dependencies (& Architecture): External Digital Systems) >
603
(Use of Client-Side Authentication)
A client/server product performs authentication within client code but not in server code, allowing server-side authentication to be bypassed via a modified client that omits the authentication check.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Externally Controlled Reference to a Resource in Another Sphere
- (610)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1360
(ICS Dependencies (& Architecture)) >
1368
(ICS Dependencies (& Architecture): External Digital Systems) >
610
(Externally Controlled Reference to a Resource in Another Sphere)
The product uses an externally controlled name or reference that resolves to a resource that is outside of the intended control sphere.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Not Using Complete Mediation
- (638)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1360
(ICS Dependencies (& Architecture)) >
1368
(ICS Dependencies (& Architecture): External Digital Systems) >
638
(Not Using Complete Mediation)
The product does not perform access checks on a resource every time the resource is accessed by an entity, which can create resultant weaknesses if that entity's rights or privileges change over time.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Insufficient Technical Documentation
- (1059)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1360
(ICS Dependencies (& Architecture)) >
1368
(ICS Dependencies (& Architecture): External Digital Systems) >
1059
(Insufficient Technical Documentation)
The product does not contain sufficient
technical or engineering documentation (whether on paper or
in electronic form) that contains descriptions of all the
relevant software/hardware elements of the product, such as
its usage, structure, architectural components, interfaces, design, implementation,
configuration, operation, etc.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Inconsistency Between Implementation and Documented Design
- (1068)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1360
(ICS Dependencies (& Architecture)) >
1368
(ICS Dependencies (& Architecture): External Digital Systems) >
1068
(Inconsistency Between Implementation and Documented Design)
The implementation of the product is not consistent with the
design as described within the relevant documentation.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Use of Unmaintained Third Party Components
- (1104)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1360
(ICS Dependencies (& Architecture)) >
1368
(ICS Dependencies (& Architecture): External Digital Systems) >
1104
(Use of Unmaintained Third Party Components)
The product relies on third-party components that are not
actively supported or maintained by the original developer or a trusted proxy
for the original developer.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Reliance on Component That is Not Updateable
- (1329)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1360
(ICS Dependencies (& Architecture)) >
1368
(ICS Dependencies (& Architecture): External Digital Systems) >
1329
(Reliance on Component That is Not Updateable)
The product contains a component that cannot be updated or patched in order to remove vulnerabilities or significant bugs.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Reliance on Insufficiently Trustworthy Component
- (1357)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1360
(ICS Dependencies (& Architecture)) >
1368
(ICS Dependencies (& Architecture): External Digital Systems) >
1357
(Reliance on Insufficiently Trustworthy Component)
The product is built from multiple separate components, but it uses a component that is not sufficiently trusted to meet expectations for security, reliability, updateability, and maintainability.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Use of Default Password
- (1393)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1360
(ICS Dependencies (& Architecture)) >
1368
(ICS Dependencies (& Architecture): External Digital Systems) >
1393
(Use of Default Password)
The product uses default passwords for potentially critical functionality.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
ICS Supply Chain
- (1361)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1361
(ICS Supply Chain)
Weaknesses in this category are related to the "ICS Supply Chain" super category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
ICS Supply Chain: IT/OT Convergence/Expansion
- (1369)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1361
(ICS Supply Chain) >
1369
(ICS Supply Chain: IT/OT Convergence/Expansion)
Weaknesses in this category are related to the "IT/OT Convergence/Expansion" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "The increased penetration of DER devices and smart loads make emerging ICS networks more like IT networks and thus susceptible to vulnerabilities similar to those of IT networks." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Not Failing Securely ('Failing Open')
- (636)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1361
(ICS Supply Chain) >
1369
(ICS Supply Chain: IT/OT Convergence/Expansion) >
636
(Not Failing Securely ('Failing Open'))
When the product encounters an error condition or failure, its design requires it to fall back to a state that is less secure than other options that are available, such as selecting the weakest encryption algorithm or using the most permissive access control restrictions.
Failing Open
Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.
Improper Access Control
- (284)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1361
(ICS Supply Chain) >
1369
(ICS Supply Chain: IT/OT Convergence/Expansion) >
284
(Improper Access Control)
The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.
Authorization
Category - a CWE entry that contains a set of other entries that share a common characteristic.
ICS Supply Chain: Common Mode Frailties
- (1370)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1361
(ICS Supply Chain) >
1370
(ICS Supply Chain: Common Mode Frailties)
Weaknesses in this category are related to the "Common Mode Frailties" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "At the component level, most ICS systems are assembled from common parts made by other companies. One or more of these common parts might contain a vulnerability that could result in a wide-spread incident." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.
Improper Control of a Resource Through its Lifetime
- (664)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1361
(ICS Supply Chain) >
1370
(ICS Supply Chain: Common Mode Frailties) >
664
(Improper Control of a Resource Through its Lifetime)
The product does not maintain or incorrectly maintains control over a resource throughout its lifetime of creation, use, and release.
Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.
Improper Neutralization
- (707)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1361
(ICS Supply Chain) >
1370
(ICS Supply Chain: Common Mode Frailties) >
707
(Improper Neutralization)
The product does not ensure or incorrectly ensures that structured messages or data are well-formed and that certain security properties are met before being read from an upstream component or sent to a downstream component.
Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.
Improper Adherence to Coding Standards
- (710)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1361
(ICS Supply Chain) >
1370
(ICS Supply Chain: Common Mode Frailties) >
710
(Improper Adherence to Coding Standards)
The product does not follow certain coding rules for development, which can lead to resultant weaknesses or increase the severity of the associated vulnerabilities.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Reliance on Insufficiently Trustworthy Component
- (1357)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1361
(ICS Supply Chain) >
1370
(ICS Supply Chain: Common Mode Frailties) >
1357
(Reliance on Insufficiently Trustworthy Component)
The product is built from multiple separate components, but it uses a component that is not sufficiently trusted to meet expectations for security, reliability, updateability, and maintainability.
Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
Generation of Predictable IV with CBC Mode
- (329)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1361
(ICS Supply Chain) >
1370
(ICS Supply Chain: Common Mode Frailties) >
329
(Generation of Predictable IV with CBC Mode)
The product generates and uses a predictable initialization Vector (IV) with Cipher Block Chaining (CBC) Mode, which causes algorithms to be susceptible to dictionary attacks when they are encrypted under the same key.
Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.
Protection Mechanism Failure
- (693)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1361
(ICS Supply Chain) >
1370
(ICS Supply Chain: Common Mode Frailties) >
693
(Protection Mechanism Failure)
The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
ICS Supply Chain: Poorly Documented or Undocumented Features
- (1371)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1361
(ICS Supply Chain) >
1371
(ICS Supply Chain: Poorly Documented or Undocumented Features)
Weaknesses in this category are related to the "Poorly Documented or Undocumented Features" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Undocumented capabilities and configurations pose a risk by not having a clear understanding of what the device is specifically supposed to do and only do. Therefore possibly opening up the attack surface and vulnerabilities." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Active Debug Code
- (489)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1361
(ICS Supply Chain) >
1371
(ICS Supply Chain: Poorly Documented or Undocumented Features) >
489
(Active Debug Code)
The product is deployed to unauthorized actors with debugging code still enabled or active, which can create unintended entry points or expose sensitive information.
Leftover debug code
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Hidden Functionality
- (912)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1361
(ICS Supply Chain) >
1371
(ICS Supply Chain: Poorly Documented or Undocumented Features) >
912
(Hidden Functionality)
The product contains functionality that is not documented, not part of the specification, and not accessible through an interface or command sequence that is obvious to the product's users or administrators.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Insufficient Technical Documentation
- (1059)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1361
(ICS Supply Chain) >
1371
(ICS Supply Chain: Poorly Documented or Undocumented Features) >
1059
(Insufficient Technical Documentation)
The product does not contain sufficient
technical or engineering documentation (whether on paper or
in electronic form) that contains descriptions of all the
relevant software/hardware elements of the product, such as
its usage, structure, architectural components, interfaces, design, implementation,
configuration, operation, etc.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Inclusion of Undocumented Features or Chicken Bits
- (1242)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1361
(ICS Supply Chain) >
1371
(ICS Supply Chain: Poorly Documented or Undocumented Features) >
1242
(Inclusion of Undocumented Features or Chicken Bits)
The device includes chicken bits or undocumented features that can create entry points for unauthorized actors.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
ICS Supply Chain: OT Counterfeit and Malicious Corruption
- (1372)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1361
(ICS Supply Chain) >
1372
(ICS Supply Chain: OT Counterfeit and Malicious Corruption)
Weaknesses in this category are related to the "OT Counterfeit and Malicious Corruption" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "In ICS, when this procurement process results in a vulnerability or component damage, it can have grid impacts or cause physical harm." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques
- (1278)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1361
(ICS Supply Chain) >
1372
(ICS Supply Chain: OT Counterfeit and Malicious Corruption) >
1278
(Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques)
Information stored in hardware may be recovered by an attacker with the capability to capture and analyze images of the integrated circuit using techniques such as scanning electron microscopy.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
Privilege Separation and Access Control Issues
- (1198)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1361
(ICS Supply Chain) >
1372
(ICS Supply Chain: OT Counterfeit and Malicious Corruption) >
1198
(Privilege Separation and Access Control Issues)
Weaknesses in this category are related to features and mechanisms providing hardware-based isolation and access control (e.g., identity, policy, locking control) of sensitive shared hardware resources such as registers and fuses.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Improper Prevention of Lock Bit Modification
- (1231)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1361
(ICS Supply Chain) >
1372
(ICS Supply Chain: OT Counterfeit and Malicious Corruption) >
1231
(Improper Prevention of Lock Bit Modification)
The product uses a trusted lock bit for restricting access to registers, address regions, or other resources, but the product does not prevent the value of the lock bit from being modified after it has been set.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Security-Sensitive Hardware Controls with Missing Lock Bit Protection
- (1233)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1361
(ICS Supply Chain) >
1372
(ICS Supply Chain: OT Counterfeit and Malicious Corruption) >
1233
(Security-Sensitive Hardware Controls with Missing Lock Bit Protection)
The product uses a register lock bit protection mechanism, but it does not ensure that the lock bit prevents modification of system registers or controls that perform changes to important hardware system configuration.
Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.
Improper Access Control
- (284)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1361
(ICS Supply Chain) >
1372
(ICS Supply Chain: OT Counterfeit and Malicious Corruption) >
284
(Improper Access Control)
The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.
Authorization
Category - a CWE entry that contains a set of other entries that share a common characteristic.
ICS Engineering (Constructions/Deployment)
- (1362)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1362
(ICS Engineering (Constructions/Deployment))
Weaknesses in this category are related to the "ICS Engineering (Constructions/Deployment)" super category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
ICS Engineering (Construction/Deployment): Trust Model Problems
- (1373)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1362
(ICS Engineering (Constructions/Deployment)) >
1373
(ICS Engineering (Construction/Deployment): Trust Model Problems)
Weaknesses in this category are related to the "Trust Model Problems" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Assumptions made about the user during the design or construction phase may result in vulnerabilities after the system is installed if the user operates it using a different security approach or process than what was designed or built." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Privilege Management
- (269)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1362
(ICS Engineering (Constructions/Deployment)) >
1373
(ICS Engineering (Construction/Deployment): Trust Model Problems) >
269
(Improper Privilege Management)
The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Reliance on Untrusted Inputs in a Security Decision
- (807)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1362
(ICS Engineering (Constructions/Deployment)) >
1373
(ICS Engineering (Construction/Deployment): Trust Model Problems) >
807
(Reliance on Untrusted Inputs in a Security Decision)
The product uses a protection mechanism that relies on the existence or values of an input, but the input can be modified by an untrusted actor in a way that bypasses the protection mechanism.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Acceptance of Extraneous Untrusted Data With Trusted Data
- (349)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1362
(ICS Engineering (Constructions/Deployment)) >
1373
(ICS Engineering (Construction/Deployment): Trust Model Problems) >
349
(Acceptance of Extraneous Untrusted Data With Trusted Data)
The product, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
ICS Engineering (Construction/Deployment): Maker Breaker Blindness
- (1374)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1362
(ICS Engineering (Constructions/Deployment)) >
1374
(ICS Engineering (Construction/Deployment): Maker Breaker Blindness)
Weaknesses in this category are related to the "Maker Breaker Blindness" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Lack of awareness of deliberate attack techniques by people (vs failure modes from natural causes like weather or metal fatigue) may lead to insufficient security controls being built into ICS systems." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
ICS Engineering (Construction/Deployment): Gaps in Details/Data
- (1375)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1362
(ICS Engineering (Constructions/Deployment)) >
1375
(ICS Engineering (Construction/Deployment): Gaps in Details/Data)
Weaknesses in this category are related to the "Gaps in Details/Data" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Highly complex systems are often operated by personnel who have years of experience in managing that particular facility or plant. Much of their knowledge is passed along through verbal or hands-on training but may not be fully documented in written practices and procedures." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Insufficient Technical Documentation
- (1059)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1362
(ICS Engineering (Constructions/Deployment)) >
1375
(ICS Engineering (Construction/Deployment): Gaps in Details/Data) >
1059
(Insufficient Technical Documentation)
The product does not contain sufficient
technical or engineering documentation (whether on paper or
in electronic form) that contains descriptions of all the
relevant software/hardware elements of the product, such as
its usage, structure, architectural components, interfaces, design, implementation,
configuration, operation, etc.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Incomplete Design Documentation
- (1110)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1362
(ICS Engineering (Constructions/Deployment)) >
1375
(ICS Engineering (Construction/Deployment): Gaps in Details/Data) >
1110
(Incomplete Design Documentation)
The product's design documentation does not adequately describe
control flow, data flow, system initialization, relationships between tasks,
components, rationales, or other important aspects of the
design.
Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.
Improper Adherence to Coding Standards
- (710)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1362
(ICS Engineering (Constructions/Deployment)) >
1375
(ICS Engineering (Construction/Deployment): Gaps in Details/Data) >
710
(Improper Adherence to Coding Standards)
The product does not follow certain coding rules for development, which can lead to resultant weaknesses or increase the severity of the associated vulnerabilities.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Missing Documentation for Design
- (1053)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1362
(ICS Engineering (Constructions/Deployment)) >
1375
(ICS Engineering (Construction/Deployment): Gaps in Details/Data) >
1053
(Missing Documentation for Design)
The product does not have documentation that represents how it is designed.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Incomplete I/O Documentation
- (1111)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1362
(ICS Engineering (Constructions/Deployment)) >
1375
(ICS Engineering (Construction/Deployment): Gaps in Details/Data) >
1111
(Incomplete I/O Documentation)
The product's documentation does not adequately define inputs,
outputs, or system/software interfaces.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
ICS Engineering (Construction/Deployment): Security Gaps in Commissioning
- (1376)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1362
(ICS Engineering (Constructions/Deployment)) >
1376
(ICS Engineering (Construction/Deployment): Security Gaps in Commissioning)
Weaknesses in this category are related to the "Security Gaps in Commissioning" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "As a large system is brought online components of the system may remain vulnerable until the entire system is operating and functional and security controls are put in place. This creates a window of opportunity for an adversary during the commissioning process." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Incorrect Default Permissions
- (276)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1362
(ICS Engineering (Constructions/Deployment)) >
1376
(ICS Engineering (Construction/Deployment): Security Gaps in Commissioning) >
276
(Incorrect Default Permissions)
During installation, installed file permissions are set to allow anyone to modify those files.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
- (362)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1362
(ICS Engineering (Constructions/Deployment)) >
1376
(ICS Engineering (Construction/Deployment): Security Gaps in Commissioning) >
362
(Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
Race Condition
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Use of Default Password
- (1393)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1362
(ICS Engineering (Constructions/Deployment)) >
1376
(ICS Engineering (Construction/Deployment): Security Gaps in Commissioning) >
1393
(Use of Default Password)
The product uses default passwords for potentially critical functionality.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
ICS Engineering (Construction/Deployment): Inherent Predictability in Design
- (1377)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1362
(ICS Engineering (Constructions/Deployment)) >
1377
(ICS Engineering (Construction/Deployment): Inherent Predictability in Design)
Weaknesses in this category are related to the "Inherent Predictability in Design" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "The commonality of design (in ICS/SCADA architectures) for energy systems and environments opens up the possibility of scaled compromise by leveraging the inherent predictability in the design." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques
- (1278)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1362
(ICS Engineering (Constructions/Deployment)) >
1377
(ICS Engineering (Construction/Deployment): Inherent Predictability in Design) >
1278
(Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques)
Information stored in hardware may be recovered by an attacker with the capability to capture and analyze images of the integrated circuit using techniques such as scanning electron microscopy.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
ICS Operations (& Maintenance)
- (1363)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1363
(ICS Operations (& Maintenance))
Weaknesses in this category are related to the "ICS Operations (& Maintenance)" super category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
ICS Operations (& Maintenance): Gaps in obligations and training
- (1378)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1363
(ICS Operations (& Maintenance)) >
1378
(ICS Operations (& Maintenance): Gaps in obligations and training)
Weaknesses in this category are related to the "Gaps in obligations and training" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "OT ownership and responsibility for identifying and mitigating vulnerabilities are not clearly defined or communicated within an organization, leaving environments unpatched, exploitable, and with a broader attack surface." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
ICS Operations (& Maintenance): Human factors in ICS environments
- (1379)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1363
(ICS Operations (& Maintenance)) >
1379
(ICS Operations (& Maintenance): Human factors in ICS environments)
Weaknesses in this category are related to the "Human factors in ICS environments" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Environmental factors in ICS including physical duress, system complexities, and isolation may result in security gaps or inadequacies in the performance of individual duties and responsibilities." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Insufficient Psychological Acceptability
- (655)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1363
(ICS Operations (& Maintenance)) >
1379
(ICS Operations (& Maintenance): Human factors in ICS environments) >
655
(Insufficient Psychological Acceptability)
The product has a protection mechanism that is too difficult or inconvenient to use, encouraging non-malicious users to disable or bypass the mechanism, whether by accident or on purpose.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
User Interface (UI) Misrepresentation of Critical Information
- (451)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1363
(ICS Operations (& Maintenance)) >
1379
(ICS Operations (& Maintenance): Human factors in ICS environments) >
451
(User Interface (UI) Misrepresentation of Critical Information)
The user interface (UI) does not properly represent critical information to the user, allowing the information - or its source - to be obscured or spoofed. This is often a component in phishing attacks.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
ICS Operations (& Maintenance): Post-analysis changes
- (1380)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1363
(ICS Operations (& Maintenance)) >
1380
(ICS Operations (& Maintenance): Post-analysis changes)
Weaknesses in this category are related to the "Post-analysis changes" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Changes made to a previously analyzed and approved ICS environment can introduce new security vulnerabilities (as opposed to safety)." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
ICS Operations (& Maintenance): Exploitable Standard Operational Procedures
- (1381)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1363
(ICS Operations (& Maintenance)) >
1381
(ICS Operations (& Maintenance): Exploitable Standard Operational Procedures)
Weaknesses in this category are related to the "Exploitable Standard Operational Procedures" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Standard ICS Operational Procedures developed for safety and operational functionality in a closed, controlled communications environment can introduce vulnerabilities in a more connected environment." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
ICS Operations (& Maintenance): Emerging Energy Technologies
- (1382)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1363
(ICS Operations (& Maintenance)) >
1382
(ICS Operations (& Maintenance): Emerging Energy Technologies)
Weaknesses in this category are related to the "Emerging Energy Technologies" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "With the rapid evolution of the energy system accelerated by the emergence of new technologies such as DERs, electric vehicles, advanced communications (5G+), novel and diverse challenges arise for secure and resilient operation of the system." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Input Validation
- (20)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1363
(ICS Operations (& Maintenance)) >
1382
(ICS Operations (& Maintenance): Emerging Energy Technologies) >
20
(Improper Input Validation)
The product receives input or data, but it does
not validate or incorrectly validates that the input has the
properties that are required to process the data safely and
correctly.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Improper Authorization
- (285)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1363
(ICS Operations (& Maintenance)) >
1382
(ICS Operations (& Maintenance): Emerging Energy Technologies) >
285
(Improper Authorization)
The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.
AuthZ
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Improper Certificate Validation
- (295)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1363
(ICS Operations (& Maintenance)) >
1382
(ICS Operations (& Maintenance): Emerging Energy Technologies) >
295
(Improper Certificate Validation)
The product does not validate, or incorrectly validates, a certificate.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Improper Following of a Certificate's Chain of Trust
- (296)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1363
(ICS Operations (& Maintenance)) >
1382
(ICS Operations (& Maintenance): Emerging Energy Technologies) >
296
(Improper Following of a Certificate's Chain of Trust)
The product does not follow, or incorrectly follows, the chain of trust for a certificate back to a trusted root certificate, resulting in incorrect trust of any resource that is associated with that certificate.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Origin Validation Error
- (346)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1363
(ICS Operations (& Maintenance)) >
1382
(ICS Operations (& Maintenance): Emerging Energy Technologies) >
346
(Origin Validation Error)
The product does not properly verify that the source of data or communication is valid.
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Insufficient Control of Network Message Volume (Network Amplification)
- (406)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1363
(ICS Operations (& Maintenance)) >
1382
(ICS Operations (& Maintenance): Emerging Energy Technologies) >
406
(Insufficient Control of Network Message Volume (Network Amplification))
The product does not sufficiently monitor or control transmitted network traffic volume, so that an actor can cause the product to transmit more traffic than should be allowed for that actor.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
URL Redirection to Untrusted Site ('Open Redirect')
- (601)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1363
(ICS Operations (& Maintenance)) >
1382
(ICS Operations (& Maintenance): Emerging Energy Technologies) >
601
(URL Redirection to Untrusted Site ('Open Redirect'))
The web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect.
Open Redirect
Cross-site Redirect
Cross-domain Redirect
Unvalidated Redirect
Category - a CWE entry that contains a set of other entries that share a common characteristic.
ICS Operations (& Maintenance): Compliance/Conformance with Regulatory Requirements
- (1383)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1363
(ICS Operations (& Maintenance)) >
1383
(ICS Operations (& Maintenance): Compliance/Conformance with Regulatory Requirements)
Weaknesses in this category are related to the "Compliance/Conformance with Regulatory Requirements" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "The ICS environment faces overlapping regulatory regimes and authorities with multiple focus areas (e.g., operational resiliency, physical safety, interoperability, and security) which can result in cyber security vulnerabilities when implemented as written due to gaps in considerations, outdatedness, or conflicting requirements." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.
Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.
Improper Adherence to Coding Standards
- (710)
1358
(Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) >
1363
(ICS Operations (& Maintenance)) >
1383
(ICS Operations (& Maintenance): Compliance/Conformance with Regulatory Requirements) >
710
(Improper Adherence to Coding Standards)
The product does not follow certain coding rules for development, which can lead to resultant weaknesses or increase the severity of the associated vulnerabilities.
Relationship
Relationships in this view are not authoritative and subject to change. See Maintenance notes.
Maintenance
This view was created in CWE 4.7 to facilitate and illuminate discussion about weaknesses in ICS with [REF-1248] as a starting point. After the release of CWE 4.9 in October 2022, this has been under active review by members of the "Boosting CWE" subgroup of the CWE-CAPEC ICS/OT Special Interest Group (SIG). Relationships are still subject to change. In addition, there may be some issues in [REF-1248] that are outside of the current scope of CWE, which will require consultation with many CWE stakeholders to resolve.
View ComponentsA | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z
CWE-349: Acceptance of Extraneous Untrusted Data With Trusted Data
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
Relevant to the view "Architectural Concepts" (CWE-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Languages Class: Not Language-Specific (Undetermined Prevalence)
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-489: Active Debug Code
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product is deployed to unauthorized actors with debugging code still enabled or active, which can create unintended entry points or expose sensitive information.
A common development practice is to add "back door" code specifically designed for debugging or testing purposes that is not intended to be shipped or deployed with the product. These back door entry points create security risks because they are not considered during design or testing and fall outside of the expected operating conditions of the product.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Languages Class: Not Language-Specific (Undetermined Prevalence) Technologies Class: Not Technology-Specific (Undetermined Prevalence) Class: ICS/OT (Undetermined Prevalence) Example 1 Debug code can be used to bypass authentication. For example, suppose an application has a login script that receives a username and a password. Assume also that a third, optional, parameter, called "debug", is interpreted by the script as requesting a switch to debug mode, and that when this parameter is given the username and password are not checked. In such a case, it is very simple to bypass the authentication process if the special behavior of the application regarding the debug parameter is known. In a case where the form is: (bad code)
Example Language: HTML
<FORM ACTION="/authenticate_login.cgi">
<INPUT TYPE=TEXT name=username> </FORM><INPUT TYPE=PASSWORD name=password> <INPUT TYPE=SUBMIT> Then a conforming link will look like: (informative)
http://TARGET/authenticate_login.cgi?username=...&password=...
An attacker can change this to: (attack code)
http://TARGET/authenticate_login.cgi?username=&password=&debug=1
Which will grant the attacker access to the site, bypassing the authentication process.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
Other
In J2EE a main method may be a good indicator that debug code has been left in the application, although there may not be any direct security impact.
CWE-290: Authentication Bypass by Spoofing
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThis attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.
This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Relevant to the view "Architectural Concepts" (CWE-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
Example 1 The following code authenticates users. (bad code)
Example Language: Java
String sourceIP = request.getRemoteAddr();
if (sourceIP != null && sourceIP.equals(APPROVED_IP)) { authenticated = true; }The authentication mechanism implemented relies on an IP address for source validation. If an attacker is able to spoof the IP, they may be able to bypass the authentication mechanism. Example 2 Both of these examples check if a request is from a trusted address before responding to the request. (bad code)
Example Language: C
sd = socket(AF_INET, SOCK_DGRAM, 0);
serv.sin_family = AF_INET; serv.sin_addr.s_addr = htonl(INADDR_ANY); servr.sin_port = htons(1008); bind(sd, (struct sockaddr *) & serv, sizeof(serv)); while (1) { memset(msg, 0x0, MAX_MSG); }clilen = sizeof(cli); if (inet_ntoa(cli.sin_addr)==getTrustedAddress()) { n = recvfrom(sd, msg, MAX_MSG, 0, (struct sockaddr *) & cli, &clilen); }(bad code)
Example Language: Java
while(true) {
DatagramPacket rp=new DatagramPacket(rData,rData.length);
outSock.receive(rp); String in = new String(p.getData(),0, rp.getLength()); InetAddress clientIPAddress = rp.getAddress(); int port = rp.getPort(); if (isTrustedAddress(clientIPAddress) & secretKey.equals(in)) { out = secret.getBytes(); }DatagramPacket sp =new DatagramPacket(out,out.length, IPAddress, port); outSock.send(sp); The code only verifies the address as stored in the request packet. An attacker can spoof this address, thus impersonating a trusted client. Example 3 The following code samples use a DNS lookup in order to decide whether or not an inbound request is from a trusted host. If an attacker can poison the DNS cache, they can gain trusted status. (bad code)
Example Language: C
struct hostent *hp;struct in_addr myaddr;
char* tHost = "trustme.example.com"; myaddr.s_addr=inet_addr(ip_addr_string); hp = gethostbyaddr((char *) &myaddr, sizeof(struct in_addr), AF_INET); if (hp && !strncmp(hp->h_name, tHost, sizeof(tHost))) { trusted = true; } else {trusted = false; }(bad code)
Example Language: Java
String ip = request.getRemoteAddr();
InetAddress addr = InetAddress.getByName(ip); if (addr.getCanonicalHostName().endsWith("trustme.com")) { trusted = true; }(bad code)
Example Language: C#
IPAddress hostIPAddress = IPAddress.Parse(RemoteIpAddress);
IPHostEntry hostInfo = Dns.GetHostByAddress(hostIPAddress); if (hostInfo.HostName.EndsWith("trustme.com")) { trusted = true; }IP addresses are more reliable than DNS names, but they can also be spoofed. Attackers can easily forge the source IP address of the packets they send, but response packets will return to the forged IP address. To see the response packets, the attacker has to sniff the traffic between the victim machine and the forged IP address. In order to accomplish the required sniffing, attackers typically attempt to locate themselves on the same subnet as the victim machine. Attackers may be able to circumvent this requirement by using source routing, but source routing is disabled across much of the Internet today. In summary, IP address verification can be a useful part of an authentication scheme, but it should not be the single factor required for authentication.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-288: Authentication Bypass Using an Alternate Path or Channel
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThis table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Architectural Concepts" (CWE-1008)
Relevant to the view "CISQ Data Protection Measures" (CWE-1340)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Languages Class: Not Language-Specific (Undetermined Prevalence) Example 1
Register SECURE_ME is located at address 0xF00. A mirror of this register called COPY_OF_SECURE_ME is at location 0x800F00. The register SECURE_ME is protected from malicious agents and only allows access to select, while COPY_OF_SECURE_ME is not. Access control is implemented using an allowlist (as indicated by acl_oh_allowlist). The identity of the initiator of the transaction is indicated by the one hot input, incoming_id. This is checked against the acl_oh_allowlist (which contains a list of initiators that are allowed to access the asset). Though this example is shown in Verilog, it will apply to VHDL as well. (informative)
Example Language: Verilog
module foo_bar(data_out, data_in, incoming_id, address, clk, rst_n);
output [31:0] data_out; input [31:0] data_in, incoming_id, address; input clk, rst_n; wire write_auth, addr_auth; reg [31:0] data_out, acl_oh_allowlist, q; assign write_auth = | (incoming_id & acl_oh_allowlist) ? 1 : 0; always @*
acl_oh_allowlist <= 32'h8312;
assign addr_auth = (address == 32'hF00) ? 1: 0;always @ (posedge clk or negedge rst_n)
if (!rst_n)
endmodule
begin
else
q <= 32'h0;
enddata_out <= 32'h0;
begin
end
q <= (addr_auth & write_auth) ? data_in: q;
enddata_out <= q; (bad code)
Example Language: Verilog
assign addr_auth = (address == 32'hF00) ? 1: 0;
The bugged line of code is repeated in the Bad example above. Weakness arises from the fact that the SECURE_ME register can be modified by writing to the shadow register COPY_OF_SECURE_ME, the address of COPY_OF_SECURE_ME should also be included in the check. That buggy line of code should instead be replaced as shown in the Good Code Snippet below. (good code)
Example Language: Verilog
assign addr_auth = (address == 32'hF00 || address == 32'h800F00) ? 1: 0;
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
CWE-312: Cleartext Storage of Sensitive Information
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.
Because the information is stored in cleartext (i.e., unencrypted), attackers could potentially read it. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information. When organizations adopt cloud services, it can be easier for attackers to access the data from anywhere on the Internet. In some systems/environments such as cloud, the use of "double encryption" (at both the software and hardware layer) might be required, and the developer might be solely responsible for both layers, instead of shared responsibility with the administrator of the broader system/environment. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Relevant to the view "Architectural Concepts" (CWE-1008)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Languages Class: Not Language-Specific (Undetermined Prevalence) Technologies Class: Cloud Computing (Undetermined Prevalence) Class: ICS/OT (Undetermined Prevalence) Class: Mobile (Undetermined Prevalence) Example 1 The following code excerpt stores a plaintext user account ID in a browser cookie. (bad code)
Example Language: Java
response.addCookie( new Cookie("userAccountID", acctID);
Because the account ID is in plaintext, the user's account information is exposed if their computer is compromised by an attacker. Example 2 This code writes a user's login information to a cookie so the user does not have to login again later. (bad code)
Example Language: PHP
function persistLogin($username, $password){
$data = array("username" => $username, "password"=> $password); }setcookie ("userdata", $data); The code stores the user's username and password in plaintext in a cookie on the user's machine. This exposes the user's login information if their computer is compromised by an attacker. Even if the user's machine is not compromised, this weakness combined with cross-site scripting (CWE-79) could allow an attacker to remotely copy the cookie. Also note this example code also exhibits Plaintext Storage in a Cookie (CWE-315). Example 3 The following code attempts to establish a connection, read in a password, then store it to a buffer. (bad code)
Example Language: C
server.sin_family = AF_INET; hp = gethostbyname(argv[1]);
if (hp==NULL) error("Unknown host"); memcpy( (char *)&server.sin_addr,(char *)hp->h_addr,hp->h_length); if (argc < 3) port = 80; else port = (unsigned short)atoi(argv[3]); server.sin_port = htons(port); if (connect(sock, (struct sockaddr *)&server, sizeof server) < 0) error("Connecting"); ... while ((n=read(sock,buffer,BUFSIZE-1))!=-1) { write(dfd,password_buffer,n); ... While successful, the program does not encrypt the data before writing it to a buffer, possibly exposing it to unauthorized actors. Example 4 The following examples show a portion of properties and configuration files for Java and ASP.NET applications. The files include username and password information but they are stored in cleartext. This Java example shows a properties file with a cleartext username / password pair. (bad code)
Example Language: Java
# Java Web App ResourceBundle properties file ... webapp.ldap.username=secretUsername webapp.ldap.password=secretPassword ... The following example shows a portion of a configuration file for an ASP.Net application. This configuration file includes username and password information for a connection to a database but the pair is stored in cleartext. (bad code)
Example Language: ASP.NET
...
<connectionStrings> <add name="ud_DEV" connectionString="connectDB=uDB; uid=db2admin; pwd=password; dbalias=uDB;" providerName="System.Data.Odbc" /> </connectionStrings>... Username and password information should not be included in a configuration file or a properties file in cleartext as this will allow anyone who can read the file access to the resource. If possible, encrypt this information. Example 5 In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications. At least one OT product stored a password in plaintext. Example 6 In 2021, a web site operated by PeopleGIS stored data of US municipalities in Amazon Web Service (AWS) Simple Storage Service (S3) buckets. (bad code)
Example Language: Other
A security researcher found 86 S3 buckets that could be accessed without authentication (CWE-306) and stored data unencrypted (CWE-312). These buckets exposed over 1000 GB of data and 1.6 million files including physical addresses, phone numbers, tax documents, pictures of driver's license IDs, etc. [REF-1296] [REF-1295]
While it was not publicly disclosed how the data was protected after discovery, multiple options could have been considered. (good code)
Example Language: Other
The sensitive information could have been protected by ensuring that the buckets did not have public read access, e.g., by enabling the s3-account-level-public-access-blocks-periodic rule to Block Public Access. In addition, the data could have been encrypted at rest using the appropriate S3 settings, e.g., by enabling server-side encryption using the s3-bucket-server-side-encryption-enabled setting. Other settings are available to further prevent bucket data from being leaked. [REF-1297]
Example 7 Consider the following PowerShell command examples for encryption scopes of Azure storage objects. In the first example, an encryption scope is set for the storage account. (bad code)
Example Language: Shell
New-AzStorageEncryptionScope -ResourceGroupName "MyResourceGroup" -AccountName "MyStorageAccount" -EncryptionScopeName testscope -StorageEncryption
The result (edited and formatted for readability) might be: (bad code)
Example Language: Other
ResourceGroupName: MyResourceGroup, StorageAccountName: MyStorageAccount
However, the empty string under RequireInfrastructureEncryption indicates this service was not enabled at the time of creation, because the -RequireInfrastructureEncryption argument was not specified in the command. Including the -RequireInfrastructureEncryption argument addresses the issue: (good code)
Example Language: Shell
New-AzStorageEncryptionScope -ResourceGroupName "MyResourceGroup" -AccountName "MyStorageAccount" -EncryptionScopeName testscope -StorageEncryption -RequireInfrastructureEncryption
This produces the report: (result)
Example Language: Other
ResourceGroupName: MyResourceGroup, StorageAccountName: MyStorageAccount
In a scenario where both software and hardware layer encryption is required ("double encryption"), Azure's infrastructure encryption setting can be enabled via the CLI or Portal. An important note is that infrastructure hardware encryption cannot be enabled or disabled after a blob is created. Furthermore, the default value for infrastructure encryption is disabled in blob creations.
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
Terminology
Different people use "cleartext" and "plaintext" to mean the same thing: the lack of encryption. However, within cryptography, these have more precise meanings. Plaintext is the information just before it is fed into a cryptographic algorithm, including already-encrypted text. Cleartext is any information that is unencrypted, although it might be in an encoded form that is not easily human-readable (such as base64 encoding).
CWE-319: Cleartext Transmission of Sensitive Information
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
Many communication channels can be "sniffed" (monitored) by adversaries during data transmission. For example, in networking, packets can traverse many intermediary nodes from the source to the destination, whether across the internet, an internal network, the cloud, etc. Some actors might have privileged access to a network interface or any link along the channel, such as a router, but they might not be authorized to collect the underlying data. As a result, network traffic could be sniffed by adversaries, spilling security-critical data. Applicable communication channels are not limited to software products. Applicable channels include hardware-specific technologies such as internal hardware networks and external debug channels, supporting remote JTAG debugging. When mitigations are not applied to combat adversaries within the product's threat model, this weakness significantly lowers the difficulty of exploitation by such adversaries. When full communications are recorded or logged, such as with a packet dump, an adversary could attempt to obtain the dump long after the transmission has occurred and try to "sniff" the cleartext from the recorded communications in the dump itself. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information. This table specifies different individual consequences
associated with the weakness. The Scope identifies the application security area that is
violated, while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides information about
how likely the specific consequence is expected to be seen relative to the other
consequences in the list. For example, there may be high likelihood that a weakness will be
exploited to achieve a certain impact, but a low likelihood that it will be exploited to
achieve a different impact.
This table shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition,
relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user
may want to explore.
Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Relevant to the view "Architectural Concepts" (CWE-1008)
Relevant to the view "Hardware Design" (CWE-1194)
The different Modes of Introduction provide information
about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at which
introduction
may occur, while the Note provides a typical scenario related to introduction during the
given
phase.
This listing shows possible areas for which the given
weakness could appear. These
may be for specific named Languages, Operating Systems, Architectures, Paradigms,
Technologies,
or a class of such platforms. The platform is listed along with how frequently the given
weakness appears for that instance.
Languages Class: Not Language-Specific (Undetermined Prevalence) Technologies Class: Cloud Computing (Undetermined Prevalence) Class: Mobile (Undetermined Prevalence) Class: ICS/OT (Often Prevalent) Class: System on Chip (Undetermined Prevalence) Test/Debug Hardware (Often Prevalent) Example 1 The following code attempts to establish a connection to a site to communicate sensitive information. (bad code)
Example Language: Java
try {
URL u = new URL("http://www.secret.example.org/"); }HttpURLConnection hu = (HttpURLConnection) u.openConnection(); hu.setRequestMethod("PUT"); hu.connect(); OutputStream os = hu.getOutputStream(); hu.disconnect(); catch (IOException e) {
//...
}Though a connection is successfully made, the connection is unencrypted and it is possible that all sensitive data sent to or received from the server will be read by unintended actors. Example 2 In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications. Multiple vendors used cleartext transmission of sensitive information in their OT products. Example 3 A TAP accessible register is read/written by a JTAG based tool, for internal use by authorized users. However, an adversary can connect a probing device and collect the values from the unencrypted channel connecting the JTAG interface to the authorized user, if no additional protections are employed. Example 4 The following Azure CLI command lists the properties of a particular storage account: (informative)
Example Language: Shell
az storage account show -g {ResourceGroupName} -n {StorageAccountName}
The JSON result might be: (bad code)
Example Language: JSON
{
"name": "{StorageAccountName}",
}
"enableHttpsTrafficOnly": false, "type": "Microsoft.Storage/storageAccounts" The enableHttpsTrafficOnly value is set to false, because the default setting for Secure transfer is set to Disabled. This allows cloud storage resources to successfully connect and transfer data without the use of encryption (e.g., HTTP, SMB 2.1, SMB 3.0, etc.). Azure's storage accounts can be configured to only accept requests from secure connections made over HTTPS. The secure transfer setting can be enabled using Azure's Portal (GUI) or programmatically by setting the enableHttpsTrafficOnly property to True on the storage account, such as: (good code)
Example Language: Shell
az storage account update -g {ResourceGroupName} -n {StorageAccountName} --https-only true
The change can be confirmed from the result by verifying that the enableHttpsTrafficOnly value is true: (good code)
Example Language: JSON
{
"name": "{StorageAccountName}",
}
"enableHttpsTrafficOnly": true, "type": "Microsoft.Storage/storageAccounts"
Note: to enable secure transfer using Azure's Portal instead of the command line:
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
Maintenance
The Taxonomy_Mappings to ISA/IEC 62443 were added in CWE 4.10, but they are still under review and might change in future CWE versions. These draft mappings were performed by members of the "Mapping CWE to 62443" subgroup of the CWE-CAPEC ICS/OT Special Interest Group (SIG), and their work is incomplete as of CWE 4.10. The mappings are included to facilitate discussion and review by the broader ICS/OT community, and they are likely to change in future CWE versions.
|