Security Criticality Analysis
The Security Criticality Analysis is performed to identify which of the components in a product are important to pay extra attention to when trying to minimize the risk of vulnerabilities.
Security Critical Components
A security critical component is any element within a system whose compromise could significantly impact the system's security posture, leading to potential breaches, data loss, or operational disruption. Identifying and protecting these components is essential for maintaining the overall security of a system or network.
Some examples of what is often considered critical components:
- components used to communicate and exchange data with external systems and/or users (e.g. communication stacks, file processing)
- components accepting and processing user inputs (e.g. HMI components)
- components processing user provided data (e.g. configuration files)
- components providing security related functionality, such as user authentication and authorization, cryptographic functionality, security logging
- components in which vulnerabilities have previously been identified
- components executing with higher privilege than other code (for example SYSTEM, administrator, root)
- Typically any component which is part of the attack surface and/or the threat model is a security critical component
Criticality Analysis
-
Why
For Security Critical Components it may be relevant to plan for additional regression testing.
After a minor code change, having a good Criticality Analysis will help when analyzing the potential security impact of the change; if code is changed in a module/component which has been classified as security critical additional analysis should be made to determine if the change affects the actually critical code. See example below. -
When
For new development; the Criticality Analysis is worked on between G2 and G3 and the approved analysis should be available at G4. The criticality analysis is initially done during the design phase, but it is recommended to update the criticality during the implementation phase based on actual implementation.
For a Roll-Up, TC, CC, or Service Pack the existing Criticality Analysis should be updated, if needed. -
Who
The Architect is the responsible role. -
Where
The analysis is performed on component level but could in some cases be done on product level. -
What
The analysis should list the criticality of the component with a motivation. Some components that at first glance look like they may be critical could, after taking the security context into consideration, be considered non critical.
It should also describe the essential functions of the product and refer to the architecture and design of the security controls that describe how these are designed not to prevent any essential function from operating. -
How
The result of the analysis could be documented as a table with the criticality information, see the examples below.
It could also contain diagrams to give a better overview of components, subcomponents and relations between them.
Normally a critical component is related to at least one requirement in under the Foundational Requirements in the Product Security Standard/IEC 62443-3-3/4-2. Describe which of the Foundational Requirements the critical component is related to. -
Inputs to the analysis
- Security Architecture Description and design documents
- Security Criticality Analysis from the previous release can be updated to a new version
- Security context
Examples of Criticality Table
| Component | Criticality | Motivation |
|---|---|---|
| A | Non critical | No communication across trust boundaries |
| B | Critical | Receives data via the network |
| C | Critical | Implements encryption or message data |
| D | Critical | Implements User Authentication and user access control |
| Software Component | Internal Component | Criticality | Motivation |
|---|---|---|---|
| A | A1 | Non critical | No communication across trust boundaries |
| A | A2 | Critical | Receives data via the network |
| B | - | Critical | Implements encryption or message data |
| C | - | Critical | Implements User Authentication and user access control |
| Software Component | Internal Component | Method | Criticality | Motivation |
|---|---|---|---|---|
| A | A1 | - | Critical | Receives data via the network |
| A | A2 | - | Critical | Receives user input |
| A | All other | - | Non critical | No communication across trust boundaries |
| B | - | Encrypt | Critical | Implements encryption or message data |
| B | - | All other | Non critical | No security functionality |
| C | - | - | Critical | Implements User Authentication and user access control |
| D | - | - | Non critical | No security functionality, No communication across trust boundaries |
Example of Essential Functions
The essential functions of a system are the functions needed for the system to perform its main tasks.
The security criticality analysis should describe the essential functions and refer to the architecture and design of the security controls that describe how these are designed.
This is to prevent any essential function from not operating. The essential functions may be inside the product, but they may also be in a system that the product is a part of.
Common essential functions for a DCS are:
- Control: That the controller can control its output IO
- Command: That an operator can issue commands to the physical system
- View: That an operator can see the correct status of the physical system
- Alarms: That alarms are not lost
- History: That historic data is not lost
Safety Instrumented Functions are always considered essential and are normally covered by the list below
How to analyze the potential security impact of a change in a Security Critical Component
If, for example, code is changed in a module which is considered security critical because it contains functions that perform user authentication, a deeper analysis should be made to determine if the code change affects the authentication functions.
If this is the case the security assessment questions related to user authentication should be revisited and the answers should be changed if necessary. If the changes do not affect the authentication functions the impact analysis does not need to be as thorough.
This means that the impact analysis for a small code change is most likely easier for a component/product with a fine grained security criticality analysis, than for one where only a few big components are analyzed, because in the fine grained case probably a bigger amount of the code will be classified as non-critical. A product which is treated as a monolith is most likely classified as critical because some part of the product has critical functions, even though most of the functions are not critical.