Attack trees aren’t one-size-fits-all: designing adaptable attack tree models for reuse
Driving toward Compliance: Auto Industry Scaling up to Meet New Regulations for In-Vehicle Cybersecurity
November 24, 2021
The Ultimate Guide: Automotive Cybersecurity Standards & Regulations
April 25, 2022
Attack trees aren’t one-size-fits-all: designing adaptable attack tree models for reuse
by David Mor-Ofek
Category: Risk Assesment
February 24, 2022
Building attack trees for scale is a difficult task – C2A Security Director of Product, David Mor Ofek provides a blueprint for security assessors that allow attack trees to grow with your model, saving time and resources.
Today’s connected automated vehicle (CAV) architecture is considerably more complex than ever before. As CAVs scale to match the demands of the consumer; so does the requirement for strong, resilient security posture that can readily identify and mitigate potential threats.These concerns are largely addressed during the threat and risk assessment (TARA) process, a critical part of the vulnerability management process. When a new vehicle is designed, the TARA process identifies potential threat vectors and informs countermeasures to address those vulnerabilities. This process is best done as quickly and efficiently as possible so that necessary improvements can be put into place. Building and designing attack trees are an important aspect of the TARA process, but there’s one problem: attack tree creation is a complicated and time consuming process, typically involving intensive, expert-driven construction of a vehicle’s vulnerabilities. A security assessor may build hundreds of attack trees throughout the entire product lifecycle – it’s repetitive, it’s arduous, it’s inefficient, and many want it automated.
Fortunately, attack trees can be designed to grow in tandem with models. In this blog post, C2A will explain the problem with current approaches to attack trees, suggest design principles that can be applied for a scalable approach that meets the needs of connected vehicles, and explain this approach with an example for context.
The typical approach to building attack trees
Today, preparation of attack trees is mainly dealt with by two alternative strategies: attack tree catalogs and automatic tree-building.In the catalog approach, a security assessor will use ready-made trees for the mainstream attack path, covering as much of the attack path domain as possible. Conversely, the automatic approach follows a consistent method of building trees from a design. Remember: building attack trees requires the highest level of expertise. Though automated and template-based approaches can help alleviate some of the heavy lifting, both strategies ultimately only give partial solutions. To add real security value, it's important to consider a fundamental security principle: designed attack trees.
Like any software design, attack trees involve a high level of planning. There is an expectation that security needs will grow alongside the development of a vehicle system. To be more efficient and prevent the duplication of work, it's critical that a security assessor prepare an infrastructure that will scale with the project, recycling work as the system evolves, as opposed to initiating a complete redesign in each phase.
Attack Trees Design Principles
There’s no incorrect way to build an attack tree; different approaches have different benefits and can even be applied to the same system. That said, these fundamental principals can help in building a scalable attack tree that will grow with any system.- Design Principle 1: Pull elements only from the design phase under analysis to streamline building
The design phase includes connections, assets, and attributes, and will comprise the building blocks of attack trees. For attack paths with an element that does not exist, security assessors should either add it to the design, or wait for a more advanced design phase for this particular attack path. - Design Principle 2: Put scalability first to build attack trees for expansion
Each phase should be an expansion of the previous design, with the leaves of the current phase acting as the root of subtrees in the next phase. - Design Principle 3: Leverage micro subtrees as building blocks
By using micro subtrees as building blocks for later iterations of attack trees, security assessors can seamlessly replace or add according to the design. Each subtree represents a specific section of the attack path – be it communication entry points, operating systems, or kernel attacks – and are designed for reusable, agile threat management. - Design Principle 4: Take a vehicle’s evolving design into account with a layered tree approach The layered tree approach will allow assessors to account for the different abstraction levels in a vehicle’s evolving design from pure concept layer to technical and implementation layers.
In context: applying design principles to your approach
Now, these design principles will be applied to a sample ADAS system built with C2A’s AutoSec ANALYSIS.
At the highest abstraction phase, the ADAS system itself is only a decision element, with one functional asset for performing the decisions. The connectivity element provides navigation and v-data, while sensor perception messages are sent from the sensor element, actuation messages from the actuation element, and the connectivity element contains an updater application and a routing table.
This example will take one severe safety Damage Scenario: collision with nearby vehicle, and one Threat: tampering with the decision software model code.
Applying design principle 1 — using only elements from the model — the following tree emerges.
Note that there are 2 nodes Exploit Code Vulnerability and Connect to External Interface; both used as methods instead of steps. These are placeholders for later development in which the security assessor will need to change the underlying steps according to the design.
In a later design, details have emerged about the systems and subsystems needed, as well as the specific technology to be used:
The Elements in the previous design are now complete systems with ECU and internal properties, such as rich OS, and the general connections between the Elements have become Ethernet, CAN, C-VTX, and LTE networks.
When building attack trees for this design, the following steps should be taken:
- Build sub-trees to represent technology-specific attacks
- Reuse previous trees structure to represent the new design
Using a sub-tree for the TCU external connection:
Integrating with a sub-tree for exploiting code in a rich OS environment:
Now, the attack tree represents a new design while keeping to the original structure of the tree and integrating with sub-trees that represent the new design.
As connected vehicles evolve, so must our approach to attack tree design
Designing for reuse and scale is a part of software developments day-to-day, attack tree models should be no different. Unlike catalogs and automatic tree-building, designed trees are considerate of future iterations of vehicle design — minimizing time investment with maximum reward. Preparing the right infrastructure will allow attack trees to evolve and expand with the design of the model, and is key to scaling security work. By focusing on only one design phase at a time, prioritizing attack tree expansion, leveraging micro subtrees and adopting a layered tree approach, security assessors will design agile, forward-thinking attack trees that can scale to match the TARA needs of the entire security lifecycle.Curious to learn more about AutoSec ANALYSIS and how AutoSec platform empowers OEMs and suppliers with full-spectrum visibility, control and protection of cybersecurity status for all vehicle programs, read more here or join our Newsletter through this link
