SAVTA: A Hybrid Vehicular Threat Model: Overview and Case Study
2.2. Threat Modeling Approaches
2.2.3. Vulnerability and Threat-Centric
2.2.5. Attack Trees
- We start the process by looking at what are we facing? We can address this question by defining the Attacker Profile which includes information about all possible attackers who may target the vehicular system. We classify these attackers based on their motivation and the other resources that they have or use to reach their goal.
- In addition, we have to answer the next main question what do we have? The answer to this question should cover all the possible weak points that we have in our system. We achieve that by identifying all the vehicle’s attackable assets; and for each of them, we have to identify all the vulnerabilities and threats which affect it. We also need to define the relations which interconnect the different assets. These relations are a reflection of the functional requirements that the system needs to work. By defining the relations between the different assets, we can point out the assets on which all others depend for accomplishing the objective (i.e., the centre of gravity [47,48]) as well as the possible attack chain which leads to defining all attack surfaces.
- The last question we need to answer is what do we need to secure these assets? Security requirements need to be determined for each asset as well as the relationship between them. Determining these requirements involves defining the references for the security mitigation implementation against attacks that may threaten the assets, for example, the integrity requirement of the communication link which could be threatened by a replay attack.
- After obtaining the previous information, we start linking them together to create an abstract model which can be used to create attack trees which will be adopted to classify and identify all the vulnerabilities, threats, and attacks. It is important to note that the three previous steps can be achieved in parallel and carried out by different security teams.
3.1. Attacker Profile
- Falsification: An attacker (who could be the owner or the driver) may wish to misrepresent actual vehicle information such as changing the achograph or odograph measurements to sell the car with a false mileage reading or to defraud the operator and safety regulations .
- Illegal profit: An attacker could make a profit by stealing the vehicle or by selling the attack capability to a different organization. Some attacks could be driven by a commercial competitor of the target vehicle’s vendor to sabotage their product and gain market share. Although there is no published case which states that a particular attack has been carried out based on industrial espionage, such motivation remains valid since there is a history of industrial espionage between vehicle manufacturers . Such an attack requires the collusion of one or more insiders in the targeted organization.
- Fun and vandalism: Revenge and vandalism could motivate some attacks, as in the case of a dismissed employee who sought to punish his ex-company by bricking cars sold by this company .
- Research and test purposes: Attacks and penetration tests could be performed by security experts or test teams. The attackers, in this case, have benign motivations. They seek to discover security flaws in different components of the vehicle systems before they can be exploited by third parties.
- Terrorist: There are still no real incidents in which such motivation has been proven to be behind the vehicle cyberattack; Richard Clarke, a former U.S. National Coordinator for Security Infrastructure Protection and Counterterrorism, hinted that the fatal crash of journalist Michael Hastings’ Mercedes C250 coupé is consistent with a car cyberattack .
- Overlap: Sometimes, multiple motives could lie behind a single attack.
- Limited: Attackers in this group have limited financial resources and insignificant knowledge about the vehicle architecture. Such attackers lack the ability to use complicated tools. Regular car thieves, owners who would like to install or replace a component within their cars, an attacker who tampers with highway signals to gain a reputation in their community, unsophisticated attackers (script kiddie) and others are good examples of members of this group.
- Adequate: This group includes highly skilled experts who have adequate tools and equipment to perform the attack. However, they may not have sufficient financial resources to support them or to build bigger teams and cause huge damage. However, the members of this group could use their experience to obtain profit, such as by operating as black-hat hackers. Mechanics, owners with good knowledge and security researchers belong to this group.
- Sophisticated: This group contains expert hackers with sophisticated tools and huge financial support. Good examples of this group are the cybersecurity organizations (governmental and nongovernmental) who have multiple members of the above group who work together. Typically, massive financial support enables them to obtain sophisticated tools and attract experts. Some security research groups with similar resources could be another example of this class.
3.2. Attackable Assets
- In-Vehicle Hardware: ECUs represent the main hardware target within the modern vehicle. One primary attack against the ECU is a side channel attack. By carrying out such attacks, the attacker can gather information during the execution of the crypto-system and use of the information gathered to extract secure critical information such as crypto keys [53,54,55]. In addition, reaching the in-vehicle hardware gives the attacker the opportunity to replace any legitimate device with a malicious one, or even to install new hardware which could cause havoc.ECUs are not the only hardware components that could be targeted by attackers. Other devices that are connected to the vehicle, such as phones, tablets, diagnostic devices connected via ODB-II, etc., can be used as a gateway to attack a vehicle if it contains a security vulnerability . Woo et al.  demonstrated the possibility of attacking a vehicle remotely by using a malicious application installed on a smartphone connected to the victim’s vehicle.The smart sensors (e.g., camera, LiDAR, radar, etc.) within the vehicle can be other hardware targets for various attacks such as camera sensor blinding attacks , LiDAR blinding attacks , and others. These attacks aim to prevent these sensors from working properly, which has a serious safety impact on both autonomous and normal vehicles.
- Software and Firmware: The massive amount of integrated software in each vehicle and the different levels of security auditing between the different vendors make the software more susceptible to attacks. Attackers can benefit from software vulnerabilities to inject malicious code, causing software components to behave maliciously or to stop the application and prevent the vehicle from achieving certain functionalities. The firmware which controls the ECU could be a target for various attacks; some attackers could tamper with the ECU firmware to achieve superior performance .Not only automotive applications but firmware itself can contain many vulnerabilities or unnecessary embodied services which could be exploited by an attacker [60,61]. Manipulating the firmware of ECU usually requires a direct access to the target ECU. ECUs are programmable devices that include some ports and serial consoles to help the developer access and maintain the firmware and software mapped to each ECU. The same ports and consoles can give attackers the ability to reflash the ECU with malicious custom firmware . In 2015, Charlie Miller and Chris Valasek  were able to flash one of Cherokee Jeep’s head unit chips with modified firmware (Chip tuning attack ). Later, they used the malicious firmware to send commands through the in-vehicle network to perform malicious actions such as disabling brakes, taking control of the steering wheel, and even stopping the engine.Over the Air (OTA) firmware and software updates represent a new challenge as well as a predictable resource for introducing new vulnerabilities to the automotive system if not handled correctly. One malicious or wrong update can end up as a huge issue, as in the case of the 2016 Toyota Land Cruiser Enform system, which was continuously rebooting itself because of a new update containing errant data .
- Data: The huge amount of data exchanged, the architecture of the in-vehicle network used to transfer this data, and the unsophisticated hardware (i.e., ECU) used to store it make data a very attractive asset for security attacks. Attackers can target data stored in some ECUs; this data could be the execution code of the applications, the firmware drivers, crypto-private keys, digital certificates, or private vehicle and driver activities (e.g., vehicle location, navigation destination, etc.). Extracting such data may occur by targeting the hardware through side-channel attacks, or by targeting one malicious software component or the Operating System (OS) itself, especially if that OS does not store the data properly with strict access restrictions. Alternatively, attackers could threaten transmitted wired/wireless data within the vehicle.
- In-vehicle data exchanged between different components or between one component and its sensors or actuators. Attacking this data depends on the existence of vulnerabilities in the internal network protocols. Spoofing, altering, or drooping the transferred data between the on-board system and different sensors or actuators are examples of attacks against such data .
- Data transferred between the vehicle and the external world using Vehicle-to-everything (V2X) communication technologies. This includes exchanged data between vehicles using Vehicle-to-Vehicle (V2V) communication or data transferred between the vehicle and surrounding infrastructure using Vehicle-to-Infrastructure (V2I) communication. This data could be targeted after it is received by the sensors; in this case, it is treated as in-vehicle exchanged data. In other cases, the data can be infected by different attacks (such as spoofing and emitting false data) before it has been revived by sensors . Finally, the data could be targeted before it leaves its source.
- Surrounding infrastructure: Another critical asset that could be targeted by attacks is the surrounding environment of the vehicle. Although the surrounding environment, such as other vehicles, roadside units (RSUs), etc., is considered external to the in-vehicle system, it has a direct impact on the security of the in-vehicle system since it is the data source for sensors and V2X. Note that the under-study in-vehicle systems (or the vehicle as a unit) are considered external for other vehicles moving on the same road or for road infrastructure. Thus, the surrounding environment can be studied similarly to in-vehicle systems by looking at its threat agents as well as its assets (i.e., hardware, software and framework, data). Many security attacks can be launched against the surrounding infrastructure. A typical example of such an attack is adding stickers to traffic signs . Another example is modifications to electronic road signs, such as “Zombies Ahead”, where an attacker figured out how to alter the text on electronic road signs to create warnings of a zombie attack. Even such a ridiculous attack could create public safety issues for drivers on the roadway .
3.3. Attack Effects
- Limited attack: The ultimate target of some attacks could be a single part of the vehicle. The effect of such attacks will remain limited to the attacked ECU(s) and not propagate any further. The targeted system will define the jeopardy level of the attack.
- Stepping stone attack: The attack can start by compromising one component or subsystem. Later, the attacker uses this subsystem as an attack surface to plague all related subsystems. The same process can be repeated for the newly infected components. Koscher et al.  showed that an attacker who can control one ECU is able to attack other connected ECUs.
3.4. Security Requirements
- Integrity: providing integrity within vehicular systems is composed of:
- Providing hardware integrity to prevent and detect any hardware component fraud.
- Providing framework and software integrity to ensure that only trusted code can be run and to prevent infected code and malware from running.
- Providing data integrity to safeguard against any modifications to data during a transaction.
- Authentication: is used to ensure and verify the authenticity of an entity. This includes the identity of that entity as well as other properties such as its location. Another important property that needs to be authenticated is the freshness of the information. The receiver needs to be able to verify that the data has been created/sent by the sender at a claimed time.
- Authorization: determines whether a certain component is allowed to access or communicate a certain resource (i.e., who should talk to whom). Approving the request of that component depends on the authentication of the requester as well as the access control rules for the requested resource.
- Confidentiality and Privacy: while providing authentication for the exchanged messages in the vehicular domain is vital, providing confidentiality is often less important. For example, there is no critical reason to encrypt all the messages exchanged between the different ECUs inside the vehicle. Enforcing confidentiality for the exchanged data should not be mainly to prevent vehicle identification detection. The ability to identify the vehicle is feasible already by different mechanisms without the need to snoop on exchanged messages (such as identifying the vehicle by color, number plate, etc.) The primary goals should be preventing a leak of the driver’s critical data (such as driver behavior, previous location) as well as guaranteeing that any observer is unable to efficiently link different messages coming from the same source. In addition, it is critical to ensure the privacy of the data collected by the different sensors (e.g, images captured by the camera). In some scenarios, confidentiality is required; for example, leaving valuable stored information (e.g., private keys) without any confidentiality protection may leave the entire vehicle security at stake if an attacker is able to extract this data.
- Availability: refers to the fact that the assets must be available even if the system is under attack. Availability is required particularly for safety-related applications which are integrated into the vehicle. Losing the availability of such applications may have serious consequences, and even threaten the lives of passengers. This property is a common concern of both safety and security, but they address it differently. While safety handles unintentional events which may lead to loss of availability, security focuses on intentional attacks.
3.5. Attack Accessibility
- Direct access: Some attacks require direct (physical) access by the threat agent to the target vehicle. Replacing the hardware component or connecting a malicious third party to the in-vehicle network is an example of such attacks. Such direct access could be achieved while a vehicle is parked. In such circumstances, the attackers cannot access the in-vehicle system, but may still be able, for example, to attach an external device to the vehicle such as a GPS device to track the vehicle later, or to target the vehicle’s immobilizer and electronic locks . In some cases, taking the car to the service station for a regular check could become an avenue for direct access by attackers. In such cases, an attacker has full access to the in-vehicle system and could take advantage of existing physical interfaces (e.g., OBD-II port, USB port, and others) to gain direct access to the internal network. The owner or the driver has the advantage of log inside the vehicle for an unlimited time.
- Remote access: Other attacks do not require any direct access to the target vehicle. Attackers could target the vehicle remotely. Such attacks take advantage of the integrated wireless features of modern cars. These features include Bluetooth, a cellular connection, wireless tire pressure monitoring, etc. Attackers need to be within a particular distance of the targeted vehicle; this distance is based on the technology used to attack the vehicle, e.g., 40 meters for wireless communication. Long-range wireless technologies give the attacker the ability to target the system from very far away, as in the case of using the entertainment system to play a song laced with malware which is able to emit malicious messages to the CAN bus .
- Mixed access: Direct access to the vehicle could be a means to introduce remote attacks. Indeed, some attackers with rapid direct access to the vehicle may install devices inside the vehicle (such as a USB cover, malicious DVD, malicious component connected via OBDII port, etc.) or outside it (communication sniffing devices). Later, they can employ those parasitic devices to target the vehicle remotely. Attackers may use other people to install these devices, such as a valet who parks the victim’s car, a mechanic at a service station , and so on.
3.6. Abstract Model and General Attack Trees
- Targeted assets: the first layer of the model contains all the (sub)system assets (e.g., hardware, software and firmware, data, or surrounding infrastructure). Within each of these assets, there are different vulnerabilities which could be targeted by motivated attackers.
- Requirements violation: the exploitation of an existing vulnerability in any asset will lead to a violation of one or more of the security requirements (i.e., confidentiality, integrity, availability, authorization, and authentication). We can further identify and classify potential threats based on the violated requirement(s).
- Accessibility: eventually, the way of accessing the assets (i.e., remote, direct, or mixed access) in order to exploit a specific vulnerability is used as the last level for compartmentalization.
4. Attack Tree and Risk Analysis
5. Use Case: Autonomous Vehicle Driving
Conflicts of Interest
- Broy, M.; Kruger, I.H.; Pretschner, A.; Salzmann, C. Engineering automotive software. Proc. IEEE 2007, 95, 356–373. [Google Scholar] [CrossRef]
- Charette, R.N. This car runs on code. IEEE Spectr. 2009, 46, 3. [Google Scholar]
- Wolf, M.; Weimerskirch, A.; Paar, C. Secure in-vehicle communication. In Embedded Security in Cars; Springer: Berlin/Heidelberg, Germany, 2006; pp. 95–109. [Google Scholar]
- Tuohy, S.; Glavin, M.; Hughes, C.; Jones, E.; Trivedi, M.; Kilmartin, L. Intra-vehicle networks: A review. IEEE Trans. Intell. Transp. Syst. 2014, 16, 534–545. [Google Scholar] [CrossRef]
- Miller, C.; Valasek, C. Remote exploitation of an unaltered passenger vehicle. Black Hat USA 2015, 2015, 91. [Google Scholar]
- Link, R. Is Your Car Broadcasting Too Much Information? 2015. Available online: https://blog.trendmicro.com/trendlabs-security-intelligence/is-your-car-broadcasting-too-much-information/ (accessed on 18 May 2020).
- Fabian, A.; Scherschel, D.S. Beemer, Open Thyself!—Security vulnerabilities in BMW’s ConnectedDrive. 2015. Available online: https://www.heise.de/ct/artikel/Beemer-Open-Thyself-Security-vulnerabilities-in-BMW-s-ConnectedDrive-2540957.html (accessed on 18 May 2020).
- Lodge, D. Hacking the Mitsubishi Outlander PHEV Hybrid. 2016. Available online: https://www.pentestpartners.com/security-blog/hacking-the-mitsubishi-outlander-phev-hybrid-suv/ (accessed on 18 May 2020).
- Thompson, C. A Hacker Figured Out a Way to Almost Completely Control GM Cars with OnStar. 2015. Available online: https://www.businessinsider.com/hackers-device-can-take-over-gm-cars-with-onstar-system-2015-7?IR=T (accessed on 18 May 2020).
- SAE Vehicle Electrical System Security Committee. Sae j3061-Cybersecurity Guidebook for Cyber-Physical Automotive Systems; SAE—Society of Automotive Engineers: Warrendale, PA, USA, 2016. [Google Scholar]
- Schneier, B. Attack Trees - Modeling security threats. Dr. Dobb’s J. 1999, 24, 21–29. [Google Scholar]
- Shirey, R.W. Internet Security Glossary, version 2; RFC 4949; 2007; Available online: https://www.rfc-editor.org/info/rfc4949 (accessed on 18 May 2020).
- International Organization for Standardization. Information Technology—Security Techniques—Information Security Management Systems—Overview and Vocabulary; Standard, International Standard ISO 27000; International Organization for Standardization: Geneva, Switzerland, 2016. [Google Scholar]
- Shostack, A. Experiences Threat Modeling at Microsoft; MODSEC@MoDELS; 2008; Available online: https://adam.shostack.org/modsec08/Shostack-ModSec08-Experiences-Threat-Modeling-At-Microsoft.pdf (accessed on 18 May 2020).
- Shostack, A. Threat Modeling: Designing for Security; John Wiley & Sons, Inc.: Indianapolis, IN, USA, 2014. [Google Scholar]
- Casey, T. Threat Agent Library Helps Identify Information Security Risks; Intel Corporation White Paper; Intel Corporation: Santa Clara, CA, USA, 2007; Volume 2, Available online: https://www.sbs.ox.ac.uk/cybersecurity-capacity/system/files/Intel%20-%20Threat%20Agent%20Library%20Helps%20Identify%20Information%20Security%20Risks.pdf (accessed on 18 May 2020).
- Rosenquist, M. Prioritizing Information Security Risks with Threat Agent Risk Assessment; Intel Corporation White Paper; 2009; Available online: https://media10.connectedsocialmedia.com/intel/10/5725/Intel_IT_Business_Value_Prioritizing_Info_Security_Risks_with_TARA.pdf (accessed on 18 May 2020).
- Hamad, M.; Nolte, M.; Prevelakis, V. Towards Comprehensive Threat Modeling for Vehicles. In Proceedings of the 1st Workshop on Security and Dependability of Critical Embedded Real-Time Systems, Porto, Portugal, 28 November 2016; p. 31. [Google Scholar]
- Camek, A.G.; Buckl, C.; Knoll, A. Future Cars: Necessity for an Adaptive and Distributed Multiple Independent Levels of Security Architecture. In Proceedings of the 2nd ACM International Conference on High Confidence Networked Systems, HiCoNS ’13, Philadelphia, PA, USA, 8–13 April 2013; ACM: New York, NY, USA, 2013; pp. 17–24. [Google Scholar] [CrossRef][Green Version]
- Bezemskij, A. Detecting Cyber-Physical Threats Against Autonomous Robotic Systems in Routine Missions. Ph.D. Thesis, University of Greenwich, London, UK, 2017. [Google Scholar]
- Karahasanovic, A.; Kleberger, P.; Almgren, M. Adapting Threat Modeling Methods for the Automotive Industry. In Proceedings of the 15th ESCAR Conference, Berlin, Germany, 7–8 November 2017; pp. 1–10. [Google Scholar]
- Caralli, R.A.; Stevens, J.F.; Young, L.R.; Wilson, W.R. Introducing Octave Allegro: Improving the Information Security Risk Assessment Process; Technical Report; Software Engineering Inst., Carnegie-Mellon Univ.: Pittsburgh, PA, USA, 2007. [Google Scholar]
- ERSI. Intelligent Transport Systems (ITS); Security; Threat, Vulnerability and Risk Analysis (TVRA); Technical Report; ETSI: Sophia Antipolis, France, 2010. [Google Scholar]
- Skybox™ Security. Threat-Centric Vulnerability Management (TCVM). 2019. Available online: https://www.infosecurityeurope.com/__novadocuments/480016?v=636628566546630000 (accessed on 18 May 2020).
- Checkoway, S.; McCoy, D.; Kantor, B.; Anderson, D.; Shacham, H.; Savage, S.; Koscher, K.; Czeskis, A.; Roesner, F.; Kohno, T.; et al. Comprehensive Experimental Analyses of Automotive Attack Surfaces. In Proceedings of the USENIX Security Symposium, San Francisco, CA, USA, 8–12 August 2011. [Google Scholar]
- Koscher, K.; Czeskis, A.; Roesner, F.; Patel, S.; Kohno, T.; Checkoway, S.; Mccoy, D.; Kantor, B.; Anderson, D.; Shacham, H.; et al. Experimental security analysis of a modern automobile. In Proceedings of the 2010 IEEE Symposium on Security and Privacy, Berkeley/Oakland, CA, USA, 16–19 May 2010. [Google Scholar]
- Kohnfelder, L.; Garg, P. The Threat to our Products. 1999. Available online: https://adam.shostack.org/microsoft/The-Threats-To-Our-Products.docx (accessed on 18 May 2020).
- Winsen, S. Threat Modelling for Future Vehicles: On Identifying and Analysing Threats for Future Autonomous and Connected Vehicles. Master’s Thesis, University of Twente, Enschede, The Netherlands, 2017. [Google Scholar]
- Macher, G.; Sporer, H.; Berlach, R.; Armengaud, E.; Kreiner, C. SAHARA: A security-aware hazard and risk analysis method. In Proceedings of the 2015 Design, Automation & Test in Europe Conference & Exhibition (DATE), Grenoble, France, 9–13 March 2015; pp. 621–624. [Google Scholar]
- Monteuuis, J.P.; Boudguiga, A.; Zhang, J.; Labiod, H.; Servel, A.; Urien, P. Sara: Security automotive risk analysis method. In Proceedings of the 4th ACM Workshop on Cyber-Physical System Security, Incheon, Korea, 4–8 June 2018; pp. 3–14. [Google Scholar]
- NCC Group. The Automotive Threat Modeling Template. 2016. Available online: https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2016/july/the-automotive-threat-modeling-template/ (accessed on 18 May 2020).
- Microsoft. Microsoft Threat Modeling Tool. Available online:https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling (accessed on 18 May 2020).
- Ma, Z.; Schmittner, C. Threat modeling for automotive security analysis. Adv. Sci. Technol. Lett. 2016, 139, 333–339. [Google Scholar]
- Lautenbachl, A.; Islam, M. Security models. Deliverable D2: HEAVENS. HEAling Vulnerabilities to ENhance Software Security and Safety. 2016. Available online: https://autosec.se/wp-content/uploads/2018/03/HEAVENS_D2_v2.0.pdf (accessed on 18 May 2020).
- Moore, A.; Ellison, R.; Linger, R. Attack Modeling for Information Security and Survivability; Technical Report CMU/SEI-2001-TN-001; Software Engineering Institute, Carnegie Mellon University: Pittsburgh, PA, USA, 2001. [Google Scholar]
- Arnold, F.; Guck, D.; Kumar, R.; Stoelinga, M. Sequential and parallel attack tree modelling. In International Conference on Computer Safety, Reliability, and Security; Springer: Cham, Switzerland, 2015; pp. 291–299. [Google Scholar]
- Vesely, W.E.; Goldberg, F.F.; Roberts, N.H.; Haasl, D.F. Fault Tree Handbook; Technical Report; Nuclear Regulatory Commission: Washington, DC, USA, 1981.
- Izosimov, V.; Asvestopoulos, A.; Blomkvist, O.; Törngren, M. Security-aware development of cyber-physical systems illustrated with automotive case study. In Proceedings of the 2016 Design, Automation & Test in Europe Conference & Exhibition, DATE 2016, Dresden, Germany, 14–18 March 2016. [Google Scholar]
- Nigam, V.; Pretschner, A.; Ruess, H. Model-Based Safety and Security Engineering. arXiv 2018, arXiv:1810.04866. [Google Scholar]
- Kong, H.K.; Hong, M.K.; Kim, T.S. Security risk assessment framework for smart car using the attack tree analysis. J. Ambient Intell. Humaniz. Comput. 2018, 9, 531–551. [Google Scholar] [CrossRef]
- Hamad, M.; Tsantekidis, M.; Prevelakis, V. Red-Zone: Towards an Intrusion Response Framework for Intra-Vehicle System. In Proceedings of the 5th International Conference on Vehicle Technology and Intelligent Transport Systems (VEHITS), Crete, Greece, 3–5 May 2019. [Google Scholar]
- Henniger, O.; Apvrille, L.; Fuchs, A.; Roudier, Y.; Ruddle, A.; Weyl, B. Security requirements for automotive on-board networks. In Proceedings of the 2009 9th International Conference on Intelligent Transport Systems Telecommunications (ITST), Lille, France, 20–22 October 2009. [Google Scholar]
- Ruddle, A.; Weyl, B.; Idrees, S.; Roudier, Y.; Friedewald, M.; Leimbach, T.; Fuchs, A.; Gürgens, S.; Henninger, O.; Rieke, R.; et al. Security Requirements for Automotive On-Board Networks Based on Dark-Side Scenarios Deliverable D2.3: EVITA. E-Safety Vehicle Intrusion Protected Applications. 2009. Available online: https://www.researchgate.net/publication/46307752_Security_requirements_for_automotive_on-board_networks_based_on_dark-side_scenarios_Deliverable_D23_EVITA_E-safety_vehicle_intrusion_protected_applications (accessed on 18 May 2020).
- Aijaz, A.; Bochow, B.; Dötzer, F.; Festag, A.; Gerlach, M.; Kroh, R.; Leinmüller, T. Attacks on inter vehicle communication systems-an analysis. In Proceedings of the 3rd International Workshop on Intelligent Transportation (WIT 2006), Hamburg, Germany, 14–15 March 2006. [Google Scholar]
- McCarthy, C.; Harnett, K.; Carter, A. Characterization of Potential Security Threats in Modern Automobiles: A Composite Modeling Approach; Technical Report; National Highway Traffic Safety Administration: Washington, DC, USA, 2014.
- Mead, N.R.; Shull, F.; Vemuru, K.; Villadsen, O. A Hybrid Threat Modeling Method; Technical Report-CMU/ SEI-2018-TN-002; Carnegie Mellon University—Software Engineering Institute: Pittsburgh, PA, USA, 2018. [Google Scholar]
- Von Clausewitz, C.; Howard, M.E.; Paret, P. On War; Princeton University Press: Princeton, NJ, USA, 1984. [Google Scholar]
- Stevens, R.; Votipka, D.; Redmiles, E.M.; Ahern, C.; Sweeney, P.; Mazurek, M.L. The Battle for New York: A Case Study of Applied Digital Threat Modeling at the Enterprise Level. In Proceedings of the 27th USENIX Security Symposium (USENIX Security 18), Baltimore, MD, USA, 15–17 August 2018; USENIX Association: Baltimore, MD, USA, 2018; pp. 621–637. [Google Scholar]
- Anderson, R. On the security of digital tachographs. In European Symposium on Research in Computer Security; Springer: Berlin/ Heidelberg, Germany, 1998; pp. 111–125. [Google Scholar]
- Meredith, R. VW agrees to pay G.M. $100 million in Espionage Suit. 1997. Available online: https://www.nytimes.com/1997/01/10/business/vw-agrees-to-pay-gm-100-million-in-espionage-suit.html (accessed on 18 May 2020).
- Poulsen, K. Hacker Disables More Than 100 Cars Remotely. 2010. Available online: https://www.wired.com/2010/03/hacker-bricks-cars/ (accessed on 18 May 2020).
- Nimmo, K. Richard Clarke: Hastings Accident “Consistent with a Car Cyber Attack”. 2013. Available online: http://www.informationliberation.com/?id=44269 (accessed on 18 May 2020).
- Kocher, P.C. Timing attacks on implementations of Diffie-Hellman, RSA, DSS, and other systems. In Annual International Cryptology Conference; Springer: Berlin/Heidelberg, Germany, 1996; pp. 104–113. [Google Scholar]
- Saeedi, E.; Kong, Y. Side-channel vulnerabilities of automobiles. Trans. IoT Cloud Comput. 2014, 2, 1–8. [Google Scholar]
- Eisenbarth, T.; Kasper, T.; Moradi, A.; Paar, C.; Salmasizadeh, M.; Shalmani, M.T.M. On the power of power analysis in the real world: A complete break of the KeeLoq code hopping scheme. In Annual International Cryptology Conference; Springer: Berlin/Heidelberg, Germany, 2008; pp. 203–220. [Google Scholar]
- Woo, S.; Jo, H.J.; Lee, D.H. A practical wireless attack on the connected car and security protocol for in-vehicle CAN. IEEE Trans. Intell. Transp. Syst. 2014, 16, 993–1006. [Google Scholar] [CrossRef]
- Petit, J.; Stottelaar, B.; Feiri, M.; Kargl, F. Remote Attacks on Automated Vehicles Sensors: Experiments on Camera and LiDAR. Black Hat Europe 2015, 11, 2015. [Google Scholar]
- Shin, H.; Kim, D.; Kwon, Y.; Kim, Y. Illusion and dazzle: Adversarial optical channel exploits against lidars for automotive applications. In International Conference on Cryptographic Hardware and Embedded Systems; Springer: Cham, Switzerland, 2017; pp. 445–467. [Google Scholar]
- Wasicek, A.; Andre, W. Recognizing Manipulated Electronic Control Units. In Proceedings of the SAE 2015 World Congress & Exhibition, Detroit, MI, USA, 21–23 April 2015. [Google Scholar]
- Yoney, D. Tesla Model S Owners Hack Their Cars, Find Ubuntu. 2014. Available online: https://www.autoblog.com/2014/04/12/tesla-model-s-owners-hack-their-cars-find-ubuntu/ (accessed on 18 May 2020).
- Dunn, M. Toyota’s killer firmware: Bad design and its consequences. EDN Network 2013. Available online: http://faculty.cs.tamu.edu/ioerger/ethics/Toyota-s-killer-firmware–Bad-design-and-its-consequences-1.pdf (accessed on 18 May 2020).
- Bécsi, T.; Aradi, S.; Gáspár, P. Security issues and vulnerabilities in connected car systems. In Proceedings of the 2015 International Conference on Models and Technologies for Intelligent Transportation Systems (MT-ITS), Budapest, Hungary, 3–5 June 2015; pp. 477–482. [Google Scholar]
- Wasicek, A.; Weimerskirch, A. Recognizing Manipulated Electronic Control Units; SAE Technical Report; SAE: Warrendale, PA, USA, 2015. [Google Scholar]
- Bogage, J. Scary Glitch Affects Luxury Cars. 2016. Available online: https://www.bostonglobe.com/lifestyle/2016/06/09/scary-glitch-affects-luxury-cars/kj4wg2lhphlJDC3gATGuPM/story.html (accessed on 18 May 2020).
- Rouf, I.; Miller, R.; Mustafa, H.; Taylor, T.; Oh, S.; Xu, W.; Gruteser, M.; Trappe, W.; Seskar, I. Security and Privacy Vulnerabilities of In-car Wireless Networks: A Tire Pressure Monitoring System Case Study. In Proceedings of the 19th USENIX Conference on Security (USENIX Security’10), Washington, DC, USA, 11–13 August 2010; USENIX Association: Berkeley, CA, USA, 2010. [Google Scholar]
- Eykholt, K.; Evtimov, I.; Fernandes, E.; Li, B.; Rahmati, A.; Xiao, C.; Prakash, A.; Kohno, T.; Song, D. Robust physical-world attacks on deep learning visual classification. In Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition, Salt Lake City, UT, USA, 18–23 June 2018; pp. 1625–1634. [Google Scholar]
- Olofsson, J. ‘Zombies ahead!’A study of how hacked digital road signs destabilize the physical space of roadways. Vis. Commun. 2014, 13, 75–93. [Google Scholar] [CrossRef]
- Verdult, R.; Garcia, F.D.; Ege, B. Dismantling megamos crypto: Wirelessly lockpicking a vehicle Immobilizer. In Proceedings of the Supplement to the 22nd USENIX Security Symposium (USENIX Security 15), Washington, DC, USA, 12–14 August 2015. [Google Scholar]
- International Organization of Standardization. Information Technology–Security Techniques–Methodology for IT Security Evaluation; Standard, International Standard ISO/IEC 18045; ISO: Geneva, Switzerland, 2008. [Google Scholar]
- International Organization for Standardization. Information Technology – Security Techniques–Evaluation Criteria for IT Security; Technical Report; International Organization for Standardization: Geneva, Switzerland, 2009. [Google Scholar]
- Guilbert, G.; Jack, E.; Karl, R.; Deerek, W. Explaining Volkswagen’s Emissions Scandal. New York Times, 2016. Available online: https://sit.instructure.com/courses/17250/files/2569242/download?download_frd=1(accessed on 18 May 2020).
- Pendleton, S.; Andersen, H.; Du, X.; Shen, X.; Meghjani, M.; Eng, Y.; Rus, D.; Ang, M. Perception, planning, control, and coordination for autonomous vehicles. Machines 2017, 5, 6. [Google Scholar] [CrossRef]
- Nassi, D.; Ben-Netanel, R.; Elovici, Y.; Nassi, B. MobilBye: Attacking ADAS with Camera Spoofing. arXiv 2019, arXiv:1906.09765. [Google Scholar]
- Strachan, L.A. Re-mapping privacy law: How the google maps scandal requires tort law reform. Rich. JL Tech. 2010, 17, 1. [Google Scholar]
- Shafiee, M.; Enjema, E.; Kolios, A. An integrated FTA-FMEA model for risk analysis of engineering systems: A case study of subsea blowout preventers. Appl. Sci. 2019, 9, 1192. [Google Scholar] [CrossRef][Green Version]
- Chybowski, L. Importance Analysis of Components of a Multi-Operational-State Power System Using Fault Tree Models. Information 2020, 11, 29. [Google Scholar] [CrossRef][Green Version]
- Kordy, B.; Mauw, S.; Radomirović, S.; Schweitzer, P. Foundations of attack–defense trees. In International Workshop on Formal Aspects in Security and Trust; Springer: Berlin/Heidelberg, Germany, 2010; pp. 80–95. [Google Scholar]
- Roy, A.; Kim, D.S.; Trivedi, K.S. Attack countermeasure trees (ACT): Towards unifying the constructs of attack and defense trees. Secur. Commun. Netw. 2012, 5, 929–943. [Google Scholar] [CrossRef]
|STRIDE||Security Attribute (CIA)||Explanation|
|Spoofing Identity||Authenticity||pretend to be someone else|
|Tampering with Data||Integrity||improper assets alterations|
|Information Disclosure||Confidentiality||to access to confidential data|
|Denial of Service||Availability||disable or delay accessing an asset|
|Elevation of Privilege||Authorization||perform unauthorized actions|
|Elapsed Time||The required time to identify a vulnerability in one asset and exploit it|
|Expertise||The level of attacker expertise (i.e., layman, proficient, expert, or collaboration of many experts)|
|Opportunity||the window of opportunity to perform the attack|
|Equipment and tools||The type of equipment and tools which is required to identify and exploit a vulnerability|
|Disabling the camera||Distorting the road sign |
|Blinding the camera ||Manipulating the road signs|
|Placing a LED device||Changing the data on the road sign|
|Emitting a strong light to the camera||Installing a fake sign|
|Jamming Attack ||Projecting images of fake road signs |
|Covering the camera with tape||Manipulating the stored images|
|Breaking the camera||Manipulating the|
|Confusing proper function of the camera||Changing the stored image or writing fake bits|
|Confusing the auto controls of the camera||Disclosing the captured images|
|Disabling road signs||Extracting the images and transmitting them to remote location|
|Removing the road sign totally|
© 2020 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).
Hamad, M.; Prevelakis, V. SAVTA: A Hybrid Vehicular Threat Model: Overview and Case Study. Information 2020, 11, 273. https://doi.org/10.3390/info11050273
Hamad M, Prevelakis V. SAVTA: A Hybrid Vehicular Threat Model: Overview and Case Study. Information. 2020; 11(5):273. https://doi.org/10.3390/info11050273Chicago/Turabian Style
Hamad, Mohammad, and Vassilis Prevelakis. 2020. "SAVTA: A Hybrid Vehicular Threat Model: Overview and Case Study" Information 11, no. 5: 273. https://doi.org/10.3390/info11050273