In a world where virtually everything is connected to the internet, security is essential. This is especially crucial in complex systems: complexity is the enemy of security. Today’s cars are examples of such systems, they have lots of components that can be a security risk. Some exploits require physical access, some can be exploited remotely, via networks; some are due to problems in the software, others result from flaws in the hardware.
To uncover, and ultimately minimize, the security risks inherent in a system design, the engineering team performs a security analysis. While there are security specialists, developing secure systems is inherently an interdisciplinary activity, because it concerns hardware systems, software systems as well as users and other human actors.
The analysis should be sound, in the sense that it is internally consistent and complete and aligned with the (evolving) architecture of the system. It should be reproducible in the sense that other stakeholders should be able to retrace the reasoning. It should also be automated to the degree possible.
Currently, engineers primarily use Excel for such analyses. This is problematic because soundness is VERY hard to achieve with the means provided by Excel. Taken together, the interdisciplinary nature and the requirement for soundness make this a very attractive target domain for DSLs.
Together with Fraunhofer AISEC, we have been developing a DSL-based security risk analysis tool that is used in the automotive industry for analysing the security properties of E/E architectures. Fraunhofer AISEC has primarily contributed the methodology that supports systematic security analysis for automotive systems; and itemis has contributed their expertise in building DSL-based tools. The methodology is based on the steps described below.
Methodology and Tool
The process starts by capturing the system architecture at a suitable abstraction level. Usually this will be a hierarchical architecture including components, connections, data and functions (in the sense of functional architecture). The language used in this step supports textual and graphical syntax; the model might also be imported from other modeling tools.
Next is the definition of the security goals, i.e., a definition of which components and functions have to be protected. Examples include the confidentiality (data must not be leaked), integrity (data must not be tampered with) or availability (such as resilience against DoS attacks) of system elements. For each security goal the user can chose the damages associated with a breach of the goal from a predefined set of damage criteria. These can for example include damages concerning safety, financial losses or legal violations. The various levels of severity for each damage criterion are also predefined by the organization making each risk analysis more comparable and repeatable.
A goal can depend on other goals. The dependencies can be expressed using Boolean operators. This aspect of the methodology offers tabular notations, plus textual expressions for the various classifications and dependencies.
The definition of threats is next. Threats act on components or connections in the hierarchical architecture model. The tool can propose violations of the security goals based on the architecture. Users then estimate the effort that is expected for an attacker to perform this attack.
Like threats, the analyst estimates the effort to break a security control. In addition, dependencies to security goals can be modeled. For example, encryption always depends on the confidentiality of the cryptographic key. If a threat to the confidentiality of the key is modeled, then the tool can take this attack path into consideration when estimating the strength of the control.
Finally, the tool can calculate risk levels for security goals, threats and applied controls based on damage potential and required attack efforts propagated through the risk graph.
The tool also supports various reports and visualizations, in tabular and diagrammatic form, to provide an overview over the state of the analysis process as well as the risk reductions achieved by security controls.
Why a DSL
There are many good reasons for using language workbench technology to build a DSL for this domain.
One is the need for mixed notations. Diagrams, tables, unstructured text paragraphs and textual expressions must all be mixed and integrated to provide an appropriate user experience.
Another one is the need for checking the consistency of the models in terms of structure and relationships of security attributes: this is classic “type system stuff” and well supported by language engineering tools.
Finally, Jetbrains MPS, the language workbench we have used to build this language, also supports language modularity. This is important so we can replace parts of the overall language to adapt the tool to the slightly different methodologies used in our customers’ organizations. One variation point is the architecture model. Instead of the hierarchical component model, one could only use a (hierarchical) list of subsystems or import (proxies for) an architecture defined in another tool. Using language modularity, MPS allows us to customize Security Analyst easily.
Practical Use
YAKINDU Security Analyst (now itemis SECURE) was born out of concrete requirements in the automotive industry. Their increased awareness for security in their systems, plus the inadequacy of Excel for creating sound analyses for increasingly complex systems led to the need for a specialized tool. We are developing this tool together with a major German automotive OEM, who is actively supporting the development. At the same time there is significant interest from several other OEMs and tier one suppliers.
Information: YAKINDU Security Analyst Is Now itemis SECURE
Until now seriously complex Excel spreadsheet has been used. The tabular notation implied by Excel is suitable for some aspects of the analysis, for example, to get a quick overview of the security goals and to sort them based on criteria relevant for the current analysis. However, the tabular notation is really bad for others. For example, modeling the system itself with all relevant connections is painful. The same was true for the software architecture.
In our solution we carried over the good parts from Excel – we use tables where they make sense, but rely on e.g. a graphical representation to model the hardware and software architecture. Also, because the tool is aware the domain (security analysis) it can guide the analyst and propose potential security attacks and mitigations.
Comments