I’ve been involved in the world of offensive security for quite a while now, and there are some topics of discussion that are recurring that I think tend to generate a lot of conversation while achieving very little. One such discussion is on the difference between simulation and emulation, which I saw crop up again recently on LinkedIn (but unfortunately do not have a link for).
We could make arguments that they are distinct things with distinct different meanings, but the whole reason the argument is needed is because they are not sufficiently distinct words. They are so similar in meaning that it’s impractical to make a distinction, but nevertheless we try.
Now, I’m no etymologist, so I will probably oversimplify things here. But let’s take a look at their etymology, from Merriam Webster.
Simulation
Latin simulātiōn-, simulātiō “act of copying, putting on an appearance, pretense,” from simulāre, similāre “to pretend, assume the appearance of by one’s conduct, produce a fraudulent imitation of, imitate”
Okay so simulation means we copy something, or we imitate it. We could probably read into this origin a few different ways, but I feel like they all come back to one thing: imitation.
Emulation
Latin aemulātiōn-, aemulātiō, from aemulārī “to vie with, rival, imitate”
And emulation means we… imitate something. Well, this is awkward.
One theory of difference
To better understand The irony of this is that I guarantee some people have the exact opposite idea for the difference between these two, further reinforcing my point , it can help to explore some different red team operations and what their objectives may look like.
Example 1: “We want to understand what kind of damage could be done if an unauthorized actor gained access to our internal knowledge management systems.”
In this example, we are engaged in a simulated attack with a particular objective in mind. It does not necessarily detail the tools to use, the timeline to follow, or even a motivation – the objective is to perform exploratory work to understand the implications of a compromise of a particular system. The ultimate simplification of this type of engagement is “What if…?”
Example 2: “Other organizations in our industry are being targeted by the Lazarus Group and we would like to understand how our organization would fare if we were targeted.”
In this example, we are engaged in an emulated attack. We have a specific threat actor we are replicating in order to help our organization practice their response and make sure their controls are solid. That threat actor has specific tactics, techniques, and procedures that they have been observed using, and they have specific motivations and desired outcomes. If we were to perform the same level of extreme simplification to this type of engagement, it would boil down to “What if X did Y?”
Does it matter?
No, not really.
Red team engagements can be fluid and hard to define. One engagement may purely be to exercise existing security controls, another may be to spend 9 months infiltrating the organization to steal sensitive information, another yet may be a table top exercise with stakeholders in order to help identify weaknesses in processes and systems. While there are clear delineations between these three types of exercises used as examples, I don’t think there’s significant value in trying to split the middle example into two different types.
Arguing the distinction between simulation and emulation is a form of bike-shedding. At no point does the organization get value from time spent determining whether to call something a simulation or an emulation. In fact, some value may be lost while trying to explain to everyone else your nuanced view of the differences between your “Attack Simulation” offering and your “Adversary Emulation” offering.
Rather than focusing on what to call it, focus on clarifying the question that the organization is seeking to answer. Whether you are simulating or emulating is irrelevant, and what actually matters will be uncovered during the discovery phase of engagement planning.
If you absolutely need to give it a name, consider a more generic option such as “Attack Hilariously, Merriam-Webster also includes "imitation" in one of the definitions for model. We'll never escape imitation. ” - which makes it clear that it is a model of an attack, and models can inherently have varying levels of detail. You can have a super generic model of an attack, and you can have a super detailed model of an attack. Either way, you’re still modeling the attack.