EN 
DE Effectively identify and assess attack risks during development.
Authors: Daniel Angermeier, Alexander Nieding, Jörn Eichler, Fraunhofer Institute for Applied and Integrated Security (AISEC)
Contribution – Embedded Software Engineering Congress 2017
The increasing interconnectedness of embedded systems, often entering this situation unhardened, is well-known as the "Internet of Shitty Things." It's equally clear that designing a solution requires a proper understanding of the problem. However, anyone attempting to gain this understanding through attack risk analysis during the development of embedded systems quickly finds themselves in a seemingly endless search for potential attack vectors, both in breadth and depth, and in fruitless discussions about attack probabilities and impacts. In the following, we discuss key challenges and provide guidance for the effective identification and assessment of relevant attack risks.
In the following, we will first briefly introduce the role of security risk analysis in the development process and describe the typical procedure of such an analysis. We will then describe typical problems and their causes during implementation and finally present possible solutions.
Risk analysis: briefly introduced & anchored in the development process
To address security risks during the development process, these risks must first be identified and assessed. A methodical and ideally tool-supported approach prevents easily avoidable errors that, if discovered later, are very difficult and costly to rectify. As always, however, practical experience is essential for successfully applying these methods. Below, we highlight some pitfalls and challenges that arise when applying risk analysis methods in practice. We do not present "the right approach" for analyzing attack risks, but rather provide an understanding of why many risk analyses are perceived or implemented as unproductive. We present potential solutions, along with their advantages and disadvantages, which can be incorporated into your own work.
Typical process of a risk analysis for embedded systems
The typical process of an analysis includes the following activities [1] [2], although the order and scope may vary depending on the chosen method:
- Standardize information about the subject of the investigation:
In this process, available information is gathered, simplified, and documented in a standardized format to prepare for the risk analysis. The subject of the investigation is clearly delineated from its surrounding context. Common techniques include interviews and document review. - Identifying threats:
The analyst identifies potential threats to the subject of investigation. This is based on both the architecture and technological aspects of the subject, as well as attacker models. - Assess damage and probability of occurrence:
The identified threats are assessed with regard to the damage they cause and their probability of occurrence. The damage assessment is often based on a definition of protection requirements, which directly follows the modeling of the object of investigation and is independent of the identified threats [3]. This defines protection goals based on the values of the object of investigation and the damages resulting from their violation. - Assess risks:
Based on the estimated threats and expected damages, potential risks to the subject of the investigation are identified and assessed.
Common problems and their causes
Below, we present some of the common problems encountered when conducting risk analyses and explore their causes.
System understanding:
Typically, a security analysis is an interdisciplinary activity, requiring both system understanding (application domain) and security expertise (security domain). Consequently, for a security expert unfamiliar with the application domain, simply familiarizing themselves with the system under investigation can be very time-consuming. Furthermore, there is a risk of losing track when reviewing extensive documentation and falling into "analysis paralysis" [4]. Conversely, developers without in-depth security expertise often find it difficult to identify the relevant aspects of the system within the context of the security analysis and to strike the right balance between precision and complexity management.
System modeling:
The notation used to model the object of study presents a further challenge. Free-form modeling allows for a quick and straightforward representation of the object. However, an unclear notation jeopardizes the consistent understanding of the system by third parties and the quality of the subsequent risk analysis. In contrast, notations with a formal foundation enable unambiguous interpretation and potentially also technical evaluation, but increase the time required for system modeling. Using the complete system model from the development process often fails due to the model's high level of detail and complexity, which, while necessary for system development, is frequently detrimental to risk analysis. Therefore, another challenge lies in choosing the appropriate level of granularity for the model, ensuring that no threats are overlooked while simultaneously keeping the complexity manageable.
Assessment of the damages:
Assessing damages is often difficult because damaging events have often not yet occurred within the organization, and therefore no empirical data exists. Sometimes, damages are identified that depend on the often difficult-to-predict behavior of third parties (reputational damage, loss of sales, etc.) and are more likely to be indirect, while the primary damage is not recorded. Frequently, damages are not specified in detail, but only their extent is estimated ("Firmware integrity: high"). This makes the analysis difficult to understand and leads to inconsistent assessments. Finally, it is often difficult to estimate how frequently damage occurs and how the corresponding scaling effect can be taken into account.
Threat identification:
To identify threats to the system, the analyst must adopt the perspective of potential attackers. This requires a deep understanding of possible attack techniques. Simultaneously, a sufficient understanding of the system is necessary for the applicability of these techniques. Neither creative attack vectors nor common and well-known threats should be overlooked. The challenge, therefore, lies in thinking unconventionally while also proceeding systematically to identify threats.
Threat assessment:
As a rule, there is hardly any systematic and relevant data available to estimate the probability of threats occurring. Determining a probability in the mathematical sense is generally not possible, as there is a lack of reliable foundations. Furthermore, frequent changes to these estimates are to be expected due to "discoveries" by security researchers who reveal new or simplified attack techniques.
Identification and assessment of the impact of measures against threats:
Similarly, measures must be modeled and their risk-reducing effects assessed. Comparing different groups of measures to select a suitable protection concept presents a recurring problem, as multiple analyses often need to be conducted and maintained consistently for a meaningful comparison.
Solutions for an effective analysis of attack risks
System understanding:
To support the interdisciplinary aspect between the application and security domains, an approach analogous to grey-box testing has proven effective. Here, the security expert engages in dialogue with the domain expert, conducts interviews, and selectively utilizes existing documentation to deepen their knowledge and model the system within the context of the security analysis. During the further course of the analysis, regular synchronization takes place between the domain experts to ensure consistent system modeling.
System modeling:
In our experience, a suitable, at least partially formalized, notation is required. For example, (possibly simplified) UML is a suitable notation, as it is sufficiently expressive and generally well understood. The modeling depth should not be too detailed initially, but rather refined as needed during the analysis. Indicators for this include, for example, technology transitions or confidence limits.
Assessment of the damages:
To support the standardized assessment of damage levels, an organization-wide, domain-specific catalog of the most concrete possible primary damages and their corresponding damage levels should be created. Assigning damages to violated security objectives, as opposed to directly assessing the impact of threats, offers two further advantages: Firstly, the damage becomes traceable from the system model; secondly, this also improves the consistency of different damage assessments.
Threat identification and assessment:
While creatively identifying potential attack vectors requires experience on the part of the analyst, the systematic detection of typical attacks can again be supported algorithmically and catalog-based. For this purpose, it is particularly useful if the system model, using a suitable notation, contains technological information that threats can reference. To support the estimation of threat probabilities or frequencies, a catalog should include preliminary assessments by security experts as a basis for the estimation in the concrete analysis.
Identification and assessment of the impact of measures against threats:
Measures should be cataloged and pre-assessed analogously to the threats. When selecting a risk analysis method, it is advisable to ensure that measures and their impact on the system can be flexibly considered.
Conclusion
A systematic and ideally tool-supported approach to risk analysis facilitates its execution and fulfills its purpose. It is important not to fall into "analysis paralysis," but rather to gain an overview of the relevant security risks. A level of detail appropriate to the needs of the modeling and the maintenance of catalogs for assessing damage, threats, and countermeasures make the complexity manageable. In system development, risk analysis can, above all, identify errors in system design early on. It does not replace activities such as testing, but rather complements them.
Bibliography and list of sources
| [1] | International Organization for Standardization (ISO), „ISO/IEC 27005:2008 Information technology – Security techniques – Information security risk management“, 2008. |
| [2] | J. Eichler and D. Angermeier, „Modular risk assessment for the development of secure automotive systems,“ in 31. VDI/VWG Joint Conference Automotive Security, 2015. |
| [3] | D. Angermeier, A. Nieding, and J. Eichler, „Supporting Risk Assessment with the Systematic Identification, Merging, and Validation of Security Goals,“ in International Workshop on Risk Assessment and Risk-driven Testing, 2016. |
| [4] | A. Langley, „Between “paralysis by analysis“ and „Extinction by instinct,“ in Sloan Management Review 36.3, 1995. |
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.
