February 20, 2019
Threat Modeling with TMTe4PT
Combining Safety and Security Threat Modeling to Improve Automotive Penetration Testing
From a traditional point of view, vehicles used to be closed systems in which components communicated between each other over a central vehicle bus and no connection to remote systems was possible. However, this has drastically changed during the last years with increasing connectivity and autonomy of today’s vehicles. While car manufacturers have a long experience in dealing with safety problems, dealing with security risks raised by this development is a relatively new domain for them.
This has also implications on the process of identifying potential safety and security risks. On the one side, there is a well established process measuring safety risks. For example, if one million devices are inspected and ten will fail, the probability of one device failing can be calculated quite accurately. On the other side, security risks in the automotive domain can hardly be measured and testing processes are not standardized yet. For instance, it is not possible to prove the absence of vulnerabilities, only that none are found with a certain amount of effort.
Furthermore, safety and security analysis are mostly conducted separately. This is especially a problem for security risks which might have implications on the safety side. Therefore, a holistic threat analysis approach for vehicles should include both the analysis of safety and security risks with their mutual influences and dependencies.
Due to the fairly new field of merging safety and security, not many threat models exist in research. Up to our knowledge, non of the existing models support penetration testing of vehicles by providing a ranking system and tool support. Since we regularly perform threat modelling in this domain as part of our Embedded Systems Assessments , filling this gap was the main goal of this thesis.
Existing Threat Models
The following existing threat models combining safety and security were analyzed with respect to our criteria for automotive penetration testing: Standard based, Not Attacker based, Rating provided, Automation possible, Tool available, Low complexity.
Threat Model | S | At | R | Au | T | L |
---|---|---|---|---|---|---|
Composite Threat Model1 | X | X | X | X | ||
SGM2 | X | X | X | X | ||
STRIDE3 | X | X | X | X | ||
SAHARA4 | X | X | X | |||
CHASSIS5 | X | X | ||||
FMVEA6 | X | X | X | |||
HEAVENS7 | X | X | X | X | X | |
EVITA8 | X | |||||
SINA9 | X | Y | X | X | X | |
OCTAVE10 | X | |||||
PASTA11 | X | |||||
Trike12 | X | X | X | X | ||
VAST13 | X | X | X | X | ||
… | … | … | … | … | … | … |
None of the evaluated threat models shown in the table above fit our criteria perfectly. So we have decided to build our own model based on the three existing models STRIDE, Composite Threat Model, and SGM.
The most important factor for us was an existing tool support. Therefore, we have chosen STRIDE as our threat classification and generation model. The other models, like SAHARA or FMVEA which use the STRIDE threat modeling approach have added unwanted functionality, but they inspired us to do the same. The VAST model fulfilled the same criteria as STRIDE. However, their ThreatModeler tool is not free and we haven’t found any scientific analysis of this method.
The reason for choosing the Composite Threat Model over the other models, which combined safety and security, was it’s simplicity in the calculation of the threat level and the use of the metrics we have selected for our own methodology.
The SGM was perfect suited for our cause in fulfilling the role of providing a simple and structured safety method which can be utilized to generate security threats.
Existing Tools
In the table below all tools are listed and evaluated based on the following criteria: For a better visualization of the system, the possibility to draw a Data Flow Diagram (DFD) is required. Because no tool has features specifically for the automotive domain, it has to be expandable to an extend that the user can implement the missing components. In order to reduce the workload for the security expert, it has to generate the threats automatically based on the diagram drawn and pre-defined rules.
Application | DFD | Expandable | Threat Generation |
---|---|---|---|
IriusRisk | X | X | |
securiCAD | X | X | |
ThreatModeler | X | X | X |
Threat Dragon | X | X | |
Sea Sponge | X | X | |
Threat Modeling Tool | X | X | X |
Two programs, the ThreatModeler and Microsofts' Threat Modeling Tool (TMT) fulfill all of our requirements. We have chosen the TMT, because it is free and it is based on STRIDE.
The CVSIL Threat Modeling Methodology
As noted above, we have created our own novel threat methodology called CVSIL combining Common Vulnerability Scoring System (CVSS) and Automotive Safety Integrity Level (ASIL) which should support prioritizing threats based on their damage potential. It combines the outcome of a Hazard Analysis and Risk Assessment (HARA) with the results from using Microsofts’ Threat Modeling Tool (TMT) 2016. In short, with our solution, the faults from the HARA have to be mapped to fitting threats from the TMT. Then, the Collateral Damage Potential (CDP) metric can be derived from ASIL calculation for each fault, and so the CVSS overall score can be calculated and used as risk level.
The figure above is showing a small part of the whole threat model, the Setting CDP phase of the CVSIL methodology with Input (blue), Output (green) and Examples (cyan). The example illustrates how the Severity (S) and Controllability (C) from the ASIL analysis at the end of the HARA can be mapped to a CDP value and than used in determining the CVSS score. For the complete model and explanation we refer to our master thesis.
Threat Modeling Tool Extension for Penetration Tester
We developed the Threat Modeling Tool Extension for Penetration Tester (TMTe4PT) 14 as an open source tool in form of an extension for the Microsoft Threat Modeling Tool 2016 with an adapted version of the automotive threat modeling template from the NCC Group . The app was written in JavaScript using the Vue.js (v2.5.2) framework and can be bundled in a single static HTML file and therefore used in any modern browser.
Our tool adds the calculation of the Common Vulnerability Scoring System v2 for each threat generated by the TMT, as well as the option of bulk modifications. With the filtering and sorting of the tabular data, it is possible for a penetration tester to find the threats which match his/her criteria and therefore supports in prioritizing test activities (e.g., a tester wants to find the threats with the highest CVSS Score with Ethernet as Interaction and a Local (L) Access Vector).
Summarized Features
- Adding CVSS calculation to threats generated by the Microsoft TMT 2016
- Import of the save (.tm7) and report (.htm) file of the TMT
- Filtering the threats with a simple query logic
- Bulk modification of threats
- Export of the data and/or query in json format
For a detailed explanation of each feature and how they are used, we refer to the documentation of our tool on GitHub .
A ready-to-use version is provided on GitHub in the testFiles
folder with some sample data. The file TMTe4PT.html
has to be opened in a web browser and the report and save file from MS TMT 2016 need to be loaded. After that, the CVSS score can be set for each of the generated threats.
For more information about our embedded services see SCHUTZWERK Embedded Systems Assessments or contact us.
Credits
Disclaimer: This tool and methodology was developed by Michael Wolf as part of the Master Thesis “Combining Safety and Security Threat Modeling to Improve Automotive Penetration Testing”. The work was sponsored by the BMBF project SecForCARs and created at SCHUTZWERK GmbH (supervisor Dr. Bastian Könings) in cooperation with the Institute of Distributed Systems at Ulm University (referee: Prof. Dr. Frank Kargl, supervisor Dr. Rens van der Heijden), and the Institute of Energy Efficient Mobility at University of Applied Sciences Karlsruhe (co-referee: Prof. Dr. Reiner Kriesten, supervisor Jürgen Dürrwang and Florian Sommer).
References
[Composite] Stijn van Winsen. Threat Modelling for Future Vehicles, On Identifying and Analysing Threats for Future Autonomous and Connected Vehicles. Master Thesis. Kerckhoffs Institute Faculty of Electrical Engineering, Mathematics and Computer Science University of Twente: University of Twente, Jan. 2017, https://essay.utwente.nl/71792/1/Master_Thesis20170214-FINAL%20PUBLIC.pdf ↩︎
[SGM] J. Dürrwang, K. Beckers, and R. Kriesten. “A Lightweight Threat Analysis Approach Intertwining Safety and Security for the Automotive Domain”. In: Computer Safety, Reliability, and Security. International Conference on Computer Safety, Reliability, and Security. Lecture Notes in Computer Science. Springer, Cham, Sept. 12, 2017, pp. 305–319. D I: https://doi.org/10.1007/978-3-319-66266-4_20. ↩︎
[STRIDE] S. Hernan, S. Lambert, T. Ostwald, and A. Shostack. “Threat Modeling-Uncover Security Design Flaws Using the STRIDE Approach”. In: MSDN Magazine (Jan. 1, 2006), pp. 68–75. L: http://download.microsoft.com/download/3/a/7/3a7fa450-1f33-41f7-9e6d-3aa95b5a6aea/MSDNMagazineNovember2006en-us.chm. ↩︎
[SAHARA] G. Macher, H. Sporer, R. Berlach, E. Armengaud, and C. Kreiner. “SAHARA: A Security-Aware Hazard and Risk Analysis Method”. In: 2015 Design, Automation Test in Europe Conference Exhibition (DATE). 2015 Design, Automation Test in Europe Conference Exhibition (DATE). Mar. 2015, pp. 621–624. D I: https://doi.org/10.7873/DATE.2015.0622. ↩︎
[CHASSIS] C. Raspotnig, P. Karpati, and V. Katta. “A Combined Process for Elicitation and Analysis of Safety and Security Requirements”. In: Enterprise, Business-Process and Information Systems Modeling. Lecture Notes in Business Information Processing. Springer Berlin Heidelberg, 2012, pp. 347–361. D I: https://doi.org/10.1007/978-3-642-31072-0_24 ↩︎
[FMVEA] C. Schmittner, T. Gruber, P. Puschner, and E. Schoitsch. “Security Application of Failure Mode and Effect Analysis (FMEA)”. In: Computer Safety, Reliability, and Security. Ed. by A. Bondavalli and F. Di Giandomenico. Lecture Notes in Computer Science. Cham: Springer International Publishing, 2014, pp. 310–325. D I: https://doi.org/10.1007/978-3-319-10506-2_21. ↩︎
[HEAVENS] M. M. Islam, A. Lautenbach, C. Sandberg, and T. Olovsson. “A Risk Assessment Framework for Automotive Embedded Systems”. In: Proceedings of the 2Nd ACM International Workshop on Cyber-Physical System Security. CPSS ’16. New York, NY, USA: ACM, 2016, pp. 3–14. D I: https://doi.org/10.1145/2899015.2899018. ↩︎
[EVITA] O. Henniger, A. Ruddle, H. Seudié, B. Weyl, M. Wolf, and T. Wollinger. “Securing Vehicular On-Board IT Systems: The EVITA Project”. In: VDI/VW Automotive Security Conference. Ingolstadt, Germany, Oct. 2009. ↩︎
[SINA] K. Schmidt, P. Tröger, H.-M. Kroll, T. Bünger, F. Krueger, and C. Neuhaus. “Adapted Development Process for Security in Networked Automotive Systems”. In: SAE International Journal of Passenger Cars - Electronic and Electrical Systems 7.2 (Apr. 1, 2014), pp. 516–526. D I: https://doi.org/10.4271/2014-01-0334. ↩︎
[OCTAVE] C. J. Alberts, S. G. Behrens, R. D. Pethia, and W. R. Wilson. “Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) Framework, Version 1.0”. Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania, Technical Report CMU/SEI-99-TR-017, 1999. http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=13473. ↩︎
[PASTA] T. Ucedavélez and M. Morana. Risk Centric Threat Modeling: Process for Attack Simulation and Threat Analysis. John Wiley & Sons, May 2015. 1-664. L: http://dx.doi.org/10.1002/9781118988374 ↩︎
[Trike] Saitta, Paul, Larcom, Brenda, and Eddington, Michael. Trike v. 1 Methodology Document [Draft]. July 13, 2005. L: http://www.octotrike.org/papers/Trike_v1_Methodology_Document-draft.pdf ↩︎
[VAST] ThreatModeler Software, Inc. Threat Modeling Methodology | OCTAVE, STRIDE, PASTA,Trike, VAST. Sept. 15, 2018. L: https://go.threatmodeler.com/process-flow-diagrams-vs-data-flow-diagrams-in-threat-modeling ↩︎
[TMTe4PT] TMTe4PT on GitHub: https://www.github.com/schutzwerk/tmte4pt ↩︎