MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is a knowledge base that models adversaries in the wild. It’s been widely adopted by the community and has become, in a short span of time, one of the key resources for security teams, both offensive and defensive.
What I believe is central to ATT&CK, and has contributed to its wide success, is the idea of gap assessment based on the real world. You know what you’re doing has a good chance of being relevant when you’re evaluating your security risks and defenses against actual threats and adversaries’ behaviors as seen in the wild. And what’s happening in the community, via ATT&CK, is better leverage of things like threat intelligence and threat hunting in order to effectively assess risk and exposure, and also test security controls and the technologies implementing them.
For those who have never seen it, tactics and techniques are structured as a matrix (see image below). Each column represents a tactic, which would be a stage in the kill chain, and it has multiple techniques (and possibly sub-techniques – introduced in v7.0). Because the threat landscape, as well as our understanding of it, are in constant evolution, ATT&CK is a WIP; a living project, constantly evolving, changing, reorganized, etc. There are currently matrices for Enterprise environments (also covering the clouds and containers), Mobile (covering iOS and Android), and ICS (Industrial Control Systems). The same goal applies to all – showing the actions an adversary may take along the kill chain.
Why a new one?
There is already a matrix for ICT systems, which actually include a range of embedded technologies. So why a new one? Before I answer that, let me quickly introduce the ICT domain and matrix. These are the environments (both hardware and software) that manage industrial operations, such as the electric grids, water treatment plants, manufacturing operations, etc. For ICT environments, the kill chain is essentially the same as the enterprise one, in the actual attack phase. The only change is at the post-breach level and end goals. So instead of exfiltration, you’ve got two stages called ‘Inhibit Response Function’ and ‘Impair Process Control’, which would represent interfering with safeguards or disrupting control operations, which could have huge safety implications. So the focus (in terms of impact) is naturally on operations, as opposed to data integrity in IT systems for instance. Also, techniques are different and less numerous than on the enterprise side, although a lot in the enterprise matrix is still relevant given that the boundaries are blurred, and most entry points to ICT systems are still actually part of an IT environment.
Now back to the question above. When I started working on automotive security, coming from the IT security world, I realized that many of the techniques that are used against these environments, also referred to as E/E architectures, were not part of existing matrices. Another basic observation here is that a vehicle is not an ICT nor an IT environment. The ‘classical’ kill chain does make sense to a certain extent, but it doesn’t necessarily reflect things like the physical proximity and access, which would be way more prevalent here than with existing matrices. Also, E/E architectures are still a green field and different vendors have their own view of it. Here is how Bosch sees it for instance. There might be many changes in the topology of these systems in the future, as well as their hardware and software, which in fact is another good reason why these environments need their own ATT&CK matrix.
A sample kill chain & Matrix
As an initial effort, I wanted to generate a sample kill chain and matrix just to show a concrete example of what this would look like. The focus would be two-fold here:
• The functionality of relevant non-IT-based components, e.g., ECUs, and
• What adversary behavior is associated with components and environments they make up.
To fill up the sample matrix below, the following type of attacks can be taken into account:
• Attacks on interfaces (CAN/LIN, Diagnostics, Ethernet, USB, RF, Wi-Fi,…), along with applications using them (e.g., IT backends or Mobile infrastructure),
• Attacks on dedicated OSes (e.g., real-time operating systems) or other dedicated protocols (SecOC, SOME/IP, DoIP,…),
• Hardware attacks (side-channel, firmware extraction,…),
• Software attacks (malicious updates, vulnerabilities in existing binaries,…).
Note that more commonly seen technologies and protocols (from the IT world) will probably become more and more relevant with newer environments, which would increase the overlap with other matrices, but will also bring in more specific access and data handling functionalities that would be more relevant here.
So this is a draft ATT&CK matrix for an embedded-based environment, taking as a use case the automotive domain. I have explicitly added the physical medium, for initial access and execution, which can be dropped later on in the attack chain. In fact, an attacker can always remotely relay an attack via a physical device that would be attached to the target once it’s initially compromised, if no other built-in means is available or can be made available. Also, note that reconnaissance and setting up the infrastructure and resource development (which do not appear in the matrix above) can be quite specific in this case. For instance, it might involve dismantling the control panel to tear down ECUs, but existing techniques can also be relevant, including passive reconnaissance or scanning and so on.
Those familiar with the automotive domain can recognize some of the techniques mentioned above. For initial access, for instance, there are a few techniques that involve diagnostics, head or telematics units, telematics servers, connected services or apps, etc. For execution, you could have a diagnostic session, or a remote command-line shell (which would be similar to other matrices), but it would involve other techniques for circumventing specific controls to execute code. Moving on along the chain there are many things that are quite similar to the IT or ICT matrices.
This was a fun exercise, but I truly believe that we need ATT&CK-like modeling for all existing environments. All weaknesses, vulnerabilities, and threats are certainly not created equal, and a focus on what attackers can actually do will drive better prioritization, and together with the context of the environment at hand, it will allow for better risk assessment and threat modeling with effective reduction of the risk and the attack surface. It will also allow for better community work, which is really needed in security, regardless of the target domain or environment.
