/security-risk-assessment

Prototypical implementation for an automated security risk assessment from the AutoS² research project.

Primary LanguagePythonGNU General Public License v3.0GPL-3.0

AutoS² Automated Risk Assessment

General Information and Status of Implementation

This repository is currently work in progress and used to display the results from the AutoS² research project and the associated dissertation. The following publications directly reference this repository:

  • INDIN 2023: Determining the Target Security Level for Automated Security Risk Assessments (published)
  • ETFA 2023: Evaluation Concept for Prototypical Implementation towards Automated Security Risk Assessments (published)
  • WFCS 2024: Requirements Analysis for the Evaluation of Automated Security Risk Assessments (accepted, but not yet published)
  • ETFA 2024: Evaluation of an Automated Security Risk Assessment based on a Manual Reference (in review)

Therefore, any feedback regarding the presented contents here in this repository are highly appreciated and can be submitted to us using the contact details from the bottom of this file.

Introduction

Manufacturing systems based on Industry 4.0 concepts provide a greater availability of data and have modular characteristics enabling frequent changes. This raises the need for new security engineering concepts that cover the increasing complexity and frequency of mandatory security risk assessments. In contrast, the current standardization landscape used for the assessment of these systems only offers abstract, static, manual, and resource-intensive procedures. Therefore, this repository proposes a method that further specifies the IEC 62443 aiming to automate the security risk assessments in such a way that manual efforts can be reduced and a consistent quality can be achieved.

A previous analysis already revealed the following hypothesis: If security risk assessment processes are automated for modular manufacturing systems, the required manual efforts are reduced by 20% in time and 50% in cost.

User Guide

This section describes how to use, test, and extend the prototypical implementation provided in this repository.

Repository Structure

The repository consists of the following folders:

  • aas_examples contains Asset Administration Shells (AASs) acting as the basis for three test cases as well as AASs with Submodel Templates relating to the implementation
  • doc contains additional documentation including figures of the used AASs, the overall process, and the provided test cases
  • knowledge contains files with the formalized expert knowledge for the automated risk assessment
  • src contains the program code of the prototypical implementation

Getting Started

The prototypical implementation is tested with Python 3.9.5 on a Windows and a Ubuntu Linux system. In order to execute the three example test cases, please follow the following steps:

  1. Clone the repository
  2. Install the required dependencies (see src/requirements.txt)
  3. Run the file src/main.py

An Internet connection is required to run the examples as the implementation requests information about exemplary vulnerabilities from the NIST NVD (National Vulnerability Database).

After starting the program, you can select one of the three examples (see Documentation) by entering the number 1, 2, or 3 when requested. After pressing Enter, information about the executed steps and intermediate results are printed to the terminal window. At the end, the final results of the risk assessment are shown in the terminal window. In addition, a PDF file Attestation.pdf is generated and stored in the main repository folder.

Custom Settings

  • We use the MITRE ICS ATT&CK framework from within the ics-attack-v13.1-mitigations.xlsx file which can be downloaded here.

  • The mapping of technical vulnerabilities to MITRE ICS ATT&CK techniques can be adapted based on the provided expert knowledge. The proposal is following this schema and can be changed within the knowledge/autos2-knowledge_2023_04_06.xlsx file.

  • The mapping of Intel TAL attacker characteristics to MITRE ICS ATT&CK techniques can be adapted based on the provided expert knowledge. The proposal is explained in detail within the INDIN 2023 publication and can be changed within the knowledge/autos2-knowledge_2023_04_06.xlsx file.

  • The mapping of IEC 62443 SRs and FRs to MITRE ICS ATT&CK mitigations can be adapted based on the provided expert knowledge. The proposal is explained in detail within the INDIN 2023 publication and can be changed within the knowledge/autos2-knowledge_2023_04_06.xlsx file.

  • All settings for the prototypical implementation, such as the paths to the files with the expert knowledge, can be changed in the src/setup.py file.

  • The number of requests per time for NIST NVD (National Vulnerability Database) is limited by the server. Therefore, some CVEs from the examples are stored and accessed locally in knowledge/example_cves.json.

Create your own Test Cases

In order to create a custom test case, the AASs have to follow a defined structure. All AASs of the machine, including the AASs of the modules and components, need to be stored in a single JSON file according to the three examples in the folder aas_examples. A machine consists of an arbitrary number of modules. The modules consist of an arbitrary number of components as shown in the following figure:

AAS Structure

The relationship between the machine and modules is defined in the Submodel HierarchicalStructures (see Additional Resources) in the AAS of the machine. Similarly, the relationship between the modules and components is defined in the Submodel HierarchicalStructures in the AASs of the modules.

The component AASs need to contain the Miscellaneous Submodel with the property SuitableForSafetyFunctions, the CVEs, and Physical Connections of the component. In addition, each component should contain a Submodel SecurityLevelIEC62443 with the SL-C and SL-A values. For each of those two Submodels, there is an AAS with a Submodel Template provided in the folder aas_examples of this repository.

Open and edit AAS Examples

The used AASs are created with the AASX Package Explorer Release 2023-03-02. In order to open and edit the AASs provided as JSON files, follow these steps:

  1. Open the AASX Package Explorer
  2. Click File, then Open ..
  3. Select AAS JSON file (*.json) on the bottom right
  4. Select one of the provided examples and click Open
  5. Click Workspace, then Edit

After editing the files, you can save these as JSON files:

  1. Click File, then Save as ..
  2. Select AAS JSON file (*.json) to save your AAS as a JSON file
  3. Run the implementation and enter the number 0 when requested
  4. Insert the whole path including the complete file name of your AAS and press the Return Key on your keyboard

Random SL-C and SL-A Generator

As many component manufacturers do not provide the SL-C and and SL-A values for each component yet, you can use the Random_SL_Generator.py located in the aas_examples folder. Therefore, execute the Random_SL_Generator.py script and follow the instructions in the command window. The script will fill all CR values inside the SecurityLevelIEC62443 with random numbers between 0 and 3. The SL-A value for each CR is always smaller or equal to the corresponding SL-C value. SL-4 values are excluded here.

AAS and Submodel Status

  • The current versions uses AAS generated with the AASX Package Explorer Release 2023-03-02. A compability to future AASs of version 3 is planned and part of the future work.

  • After running the implementation, the security risk assessment results should be written to the SecurityRiskAssessment- and SecurityLevelIEC62443-Submodels of the AASs. Those two Submodels are a result of the AutoS² research project and not standardized yet. The functionality to write the results is currently not implemented and part of the future work. However, the Submodel Templates containing the structure of those two Submodels are provided in the folder aas_examples of this repository.

  • In future, the CVEs (currently stored in the Miscellaneous Submodel) will be provided in a VulnerabilityManagement submodel that is currently in a standardization process of the IDTA.

Documentation

Swimlanes

To develop the abstract concepts from the IEC 62443-3-2 standard up to the degree necessarily required for automation, an analysis followed by a specification needs to be performed. This work uses a lightweight and adapted version of the Business Process Model Notation (BPMN) to collect and visualize all information mandatory for a security risk assessment within swimlanes. The result is an overview of the stakeholders, inputs, decisions, outputs, information model elements, and environmental influences in a graphical way. The main structure is represented by a pool containing the different process participants. In this case, there are six swimlanes inside the pool. Each swimlane includes one of the three process participants i.e., (1) component manufacturer, (2) system integrator, and (3) asset owner as typical industrial stakeholders, as well as (4) the information model representing the internal data for processing, (5) the security risk assessment process as the basis for the decision logic, and (6) the environment containing external data, e.g. public databases or already formalized security expert knowledge. All details can be found within the associated figure in doc/Process_Swimlanes.png.

High-Level-Process

Based on the detailed process described in the swimlanes, a higher level process is created. This is the basis for the structure of the prototypical implementation:

CPS Architecture

Network Architecture of the provided Example "CPS"

The general network architecture of the examples is shown here:

CPS Architecture

The Customizable Production System (CPS) from the SmartFactoryOWL consists of three modules (Laser, Conveyor, Cabinet). The modules consist of components that are safety-relevant (yellow boxes) and components that are not safety-relevant (green boxes). Based on the component characteristics, the components are grouped into Zones (grey boxes). The black lines represent the network connections.

Example Test Cases

This repository contains three examples with different resulting risks for the assets of the module Cabinet.

  • In Example 1, all four Safety PLCs have vulnerabilities leading to resulting risks
  • In Example 2, the Safety PLC 3 has no vulnerabilities. As a result, the Safety PLC 3 is protected by the path and there is no risk. The same counts for Safety PLC 4, as it is protected by Safety PLC 3 as well
  • In Example 3, none of the four Safety PLCs have vulnerabilities. As a result, there are no resulting risks

CPS Examples Test Cases

Additional Resources

Here are some additional resources with further information for related contents:

Related Publications for this Project

Information about the AAS

Contact Information

For contributions, maintenance, and feedback, please contact us:

Marco Ehrlich (Concept and Process Description)
inIT - Institute Industrial IT
Technische Hochschule Ostwestfalen-Lippe
32657 Lemgo, Germany
marco.ehrlich@th-owl.de

Andre Bröring (Implementation)
inIT - Institute Industrial IT
Technische Hochschule Ostwestfalen-Lippe
32657 Lemgo, Germany
andre.broering@th-owl.de

Any additional or supporting information is available upon request.

Funding

This work was funded by the Ministry of Economic Affairs, Industry, Climate Action and Energy of the State of North Rhine-Westphalia within the research project "Automatic Evaluation and Monitoring of Safety & Security Properties for Intelligent Technical Systems" (AutoS²).

Project Page Institute Industrial IT | Project Page it's OWL

License

GNU General Public License v3.0

Any further information can be found within the LICENSE file.

ProjectLogo