An attack simulation tests your defences against a scenario or objective defined in advance. Depending on the question you need answered, it can take the form of technical adversary emulation, a broader red team engagement or a tabletop exercise for incident management. The formats differ in method and risk, but they share one principle. Before work starts, we define what is to be tested and the criteria for assessing the result.
Attack simulation is not a single standardised test. Before we begin, we establish what needs to be assessed, be it your technical detections, your ability to stop particular adversary behaviour, your incident management, or a broader attack objective that matters to the business. That determines the scenario, the teams involved and the testing method.
A technical simulation can use the tactics and techniques that fit a given threat or objective, and these can be mapped to MITRE ATT&CK. In adversary emulation, the focus is on particular attacker behaviour and on whether your defences can detect or contain it. In a broader red team engagement, the main aim may be to reach a defined objective while testing your defences across people, processes and technology. The rules of engagement define the exact format and the permitted methods.
A tabletop exercise is not a technical attack on systems. It is a facilitated incident scenario in which the people in each role are told how the situation is developing and make decisions as they would in a real incident. It can test escalation, accountability, internal and external communication, incident management, business continuity, recovery and anything else the scenario is designed to cover. We then document not only the discussion but also the processes and responsibilities that need improving.
The choice does not come down to one format being simpler and another more advanced. If you need to find out whether people know their roles in an incident, a tabletop exercise may be appropriate. If you need to validate specific detections and technical controls, that calls for a technical simulation. If you need to assess your defences against a broader, objective-driven operation, a red team engagement may be justified. Formats can be combined, as long as each has a clear objective.
We define what the simulation will test, what the criteria are for success and for assessing your defences, and what information is needed to design the scenario. For a technical simulation, we also agree the objectives, the systems, the permitted methods, the sensitive assets, escalation and the stop conditions.
We run the agreed technical scenario or facilitate the tabletop session, and document the key events. In a technical simulation, we keep the evidence and a timeline of operator actions. In a tabletop exercise, we record decisions, the flow of information, unclear responsibilities and any other observations relevant to the exercise's objectives.
We compare the results with the objectives set at the start. In a technical simulation, we analyse what the defences prevented, detected, investigated or missed. In a tabletop exercise, we assess decision-making, escalation, communication, the usability of your plans and the other capabilities tested in the scenario.
We document specific technical and organisational improvements, responsibilities and priorities. Once the changes have been made, we can design a comparable retest scenario to check progress in specific capabilities, rather than simply repeating the previous exercise.
Test your defences against a specific scenario
Describe the systems, risk or incident scenario you want to test. We will reply within one working day and work out which simulation format fits best.
“Test our security” is too broad a task. A useful simulation starts with a specific question. Does a particular attacker behaviour trigger a detection? Can your SOC investigate and escalate the event? Can management make decisions in a ransomware scenario? Do your fallback communication channels work during an incident? Once the objective is clear, we can choose the scenario, the participants, the evidence to collect and the criteria for assessing the result.
A technical simulation is active testing and carries some risk. That is why written authorisation and rules of engagement are required before it starts. A tabletop exercise involves no attack on your systems, but it too has to be defined in advance, including who takes part, in which roles, where the boundaries of the scenario lie and what information will be documented afterwards.