EN 
DE Efficient evaluation through component-based software design
Author: Sergey Tverdyshev, SYSGO AG
Contribution – Embedded Software Engineering Congress 2017
In the Internet of Things (IoT), traditional IT security is increasingly being extended to embedded components. A characteristic feature of the security requirements of many IoT systems is the increased focus on integrity and availability. This is also reflected in certification standards: The classic Common Criteria for Information Technology Security (ISO 14508) are being supplemented by domain-specific security standards, such as IEC 62443 for Industrial Control Systems, EDSA (Embedded Device Security Analysis), or J3061 in the automotive sector, which are characterized by a strong focus on "security for safety.".
The success of IoT approaches lies in the fact that embedded COTS components are relatively loosely linked using open standards and open protocols. This modularity is also reflected in the certification standards. We demonstrate where and how a component-based software design significantly simplifies meeting certification requirements.
Inherent modularity of IoT
The Internet of Things (IoT, [1]) is extremely heterogeneous, highly dynamic, always available, and therefore vulnerable to attack at any time. The IoT consists of IoT components as modular building blocks.
Security is usually modular.
Figure 1 (see PDF) shows the safety model according to Part 1 of the CC (Section 7.1), which is also explicitly addressed by IEC 62443-1-1 (Section 5.1).
Figure 1 shows all Assets, threats, and countermeasures are each represented as a box. more precisely In our experience, however, the image often looks more like Figure 2 (see PDF).
Table 1 gives an example of a possible allocation:
| Number/Color | Asset | threat | Countermeasure |
| 1/red | Engine control | Delay in obstacle detection → personal injury | Real-time guarantees, separation |
| 2/green | Performance logger | Loss of Operational History | Password in the web interface |
Table 1: Assignment of Figure 2 (see PDF) with two specific assets
In the example in Table 1, the assets and their threats vary considerably in criticality. This is illustrated by the specific figures in Figure 2 (see...). PDFIt also becomes clear that a more The threat lies in the attacker's attempt to bypass countermeasures; for example, Ethernet access to the performance logger could be misused to also attack the engine control unit. One way to manage complex IT systems, and especially IoT components of varying criticality, at an appropriate level of abstraction is to divide them into security domains ("divide and conquer"). A security domain is a zone in which all objects are subject to the same security policy [8]. The boundaries of security domains are also called "trust boundaries.".
„"Divide and conquer" (D&C) in Common Criteria certification (e.g., security domains, domain separation)
In the Common Criteria for Information Technology Security Evaluation (CC), a manufacturer collaborates with a testing body to evaluate an IT product proposed by the manufacturer. The product can consist of software or software and hardware; IoT components are therefore explicitly included. If the evaluation is successful, the certification body, in Germany the BSI (Federal Office for Information Security), issues a certificate.
The Common Criteria require developers to submit design documentation as a central component of the documentation to the review body. Depending on the desired evaluation level, this documentation must include a one- or two-level subdivision into subsystems (single-level) or subsystems and modules (two-level). The properties of subsystems and modules and their interactions must be described. The design documentation also describes the extent to which the interfaces of subsystems and modules are directly or indirectly accessible to an attacker.
A security architecture is a means of analyzing and documenting the security properties of a system with regard to its security domains.
A security architecture (ADV_ARC) according to Common Criteria must explain the following points:
- What security domains does the system have? To what extent are these security domains completely separated, or are they allowed to communicate with each other (in a controlled manner)? In our example, the performance logger and the engine control unit would be different domains.
- How is the system initialized?
- How does the system protect itself against an attacker attempting to attack it?
- How does the system protect against being circumvented?
(In our example: Web access to the performance logger cannot bypass the engine control unit)?
TuH in IEC 62443
IEC 62443 is a standard for the security of industrial control systems as a whole (especially parts 3-1 to 3-3) and their components (especially parts 4-1 and 4-2). IEC 62443 is referenced by the safety standard IEC 61508 for security (IEC 61508 Part 1-1 Section 7.5.2.2: "If security threats have been identified, then a vulnerability analysis shall be undertaken in order to identify security requirements. Note: Guidance is given in the 62443 series"). IEC 62443 is still largely under (advanced) development under the umbrella of IsaSecure.
In IEC 62443, the security domains are called "zones", and the system should support partitioning into zones (IEC 62443 Part 3-3 Section SR 5.4) as well as operate resource management that is robust against attackers (IEC 62443 Part 3-3 Sections SR 7.1 and SR 7.2 and IEC Part 4-2 Sections CR 7.1 and CR 7.2), e.g. against Denial-of-Service.
Regarding development processes, IEC 62443 Part 4-1 SR-2 requires the creation of a threat model with trust boundaries, which also addresses how information flows across these trust boundaries. A defense-in-depth design is recommended (IEC 62443 Part 4-2 SD-2). IEC 62443 Part 4-1 SD-6 further requires that minimizing the attack surface must be a design goal.
TuH in IsaSecure EDS / SDLA / SSA
In the standards SDLA (processes), EDSA (functional systems for components), and SSA (functional requirements for entire systems), IsaSecure has developed a concrete certification scheme for the IEC 62443 series, which also incorporates suggestions from NIST 800-53. For example, EDSA-311 (Table 2) requires the following at the functional level:
| FSA-RDF-1 | The IACS embedded device shall provide means to enforce assigned authorizations for controlling the flow of information outside the embedded controller zone and between interconnected systems in accordance with user specific policy |
| FSA-RDF-2 | The IACS embedded device shall separate data acquisition services, from management functionality |
| FSA-RDF-3 | The IACS embedded device shall isolate security functions from non-security functions by means of partitions, domains, etc., including control of access to and integrity of, the hardware, software, and firmware that perform those security functions |
| FSA-RDF-4 | The IACS embedded device shall prevent unauthorized and unintended information transfer via shared system resources where it supports connection sessions from users with different levels of access |
Table 2: FSA-RDS requirements of EDSA-311.
As in IEC 62443 Part 4-1, SDLA-312 requires a modular design (SDLA-DSD-1.*) and the clear identification of trust boundaries and attack surfaces (SDLA-SAD-*) at the process level.
TuH in J3061
SAE's J3061 is the most recent of the standards we are considering, and we are referring to the published draft from 2016. Creating a software architecture here begins with "Refine Functional Cybersecurity Concept into Technical Cybersecurity Concept" (Section 8.4.3), and again, the isolation of specific functions is important. An example given is: "Isolation/partitioning of systems that have external access (e.g., Wi-Fi, Bluetooth, OBD) from safety-critical systems and systems that can have important impacts on the operation of the vehicle." The software architecture is then subjected to a threat analysis with regard to confidentiality, integrity, and availability (Section 8.6.3) and examined for vulnerabilities and threats. Section 8.6.4 mentions STRIDE, ASF, and DREAD as possible tools for threat categorization.
Commonalities and outlook
In considering software architecture requirements, we have primarily focused on the TuH (Technology, Technology, and Health) in the left branch of the V-model. It is clear that fulfilling these requirements simplifies not only the design but also the testing and vulnerability analysis.
From the perspective of material consumption (e.g., one control unit per security domain), an architecture with a clear and, above all, unavoidable separation of tasks appears more complex at first glance. However, material consumption can be controlled through virtualization as follows:
- With regard to network virtualization, newer developments in load-balancing real-time network standards are particularly interesting (e.g., TSN, IEEE 802.1 Qbu/Qbv), which allow cabling to be shared securely.
- With regard to CPU virtualization, the MILS concept, which originally comes from safety- and material-sensitive avionics, has been gaining increasing popularity for several years [9] [10].
On a MILS system, the example from Section 2 would look like this (see Figure 3, PDF).
When implemented using a MILS system as shown in Figure 3 (see PDFThe isolation, resource management, and information flow control required by Common Criteria, IEC 62443, EDSA, and J3061 are provided by a separation kernel. The partitions of a separation kernel serve as templates for security domains in systems using a MILS architecture.
8 Literatur
| [1] | I. Yaqoob, E. Ahmed, I. Hashem, A. Ahmed, A. Gani, M. Imran and M. Guizani, "„Internet of Things Architecture: Recent Advances, Taxonomy, Requirements, and Open Challenges“ [Online] |
| [2] | R. Davidson, Keeping hackers at bay [On-line] |
| [3] | R. Ernst, „Automotive Ethernet – Opportunities and Pitfalls“ [Online] |
| [4] | Silicon Labs, „Silicon Labs Advances Bluetooth Smart Connectivity with Energy-Friendly SoC and Software Solution (NASDAQ:SLAB)“ [Online] |
| [5] | A. Greenberg, „’'Crash Override': The Malware That Took Down a Power Grid“ [Online] |
| [6] | Miller, Remote Exploitation of an Unaltered Passenger Vehicle, 2015 |
| [7] | Forbes, Internet of Things (IoT) Predictions From Forrester, Machina Reserach, WEF, Garntner, IDC, 2016 |
| [8] | BW Lampson, „Protection,“ 1971. [Online] |
| [9] | S. Tverdyshev, H. Blasum, B. Langenstein, J. Maebe, B. De Sutter, B. Leconte, B. Triquet, K. Müller, M. Paulitsch, A. Söding-Freiherr von Blomberg and A. Tillequin, MILS Architecture, EURO-MILS, 2013 |
| [10] | S. Tverdyshev and 3rd International Workshop on MILS, Security by Design: Introduction to MILS, 3rd International Workshop on MILS, 2017 |
Our training courses & coaching sessions
Do you want to bring yourself up to date with the latest technology?
Then find out more here Regarding training courses/seminars/workshops and individual coaching sessions offered by MircoConsult on the topic Quality, Safety & Security.
Training & coaching on the other topics in our portfolio can be found here. here.
Quality, Safety & Security – Expertise
Valuable expertise on the topics of quality, safety & security is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
