The log-driven approach, which entails using hard data to find the breach’s root cause and identify the scope of the damages, is a common method for investigating data breaches. Sometimes, we don’t have all the logs we might need. In those cases, stepping back to think about the breach from our adversary’s perspective can provide imaginative ideas that can drive the investigation forward. In this analysis, I’ll describe how thinking like your adversary, in combination with other essential tactics, can enhance your data breach investigation.
Forming an Attacker Profile
To start the conversation, you need to identify potential adversaries, tactics, and motivation. A natural next step would be to browse the MITRE ATT&CK framework groups repository, which gathers together much of the work done across the cybersecurity industry to identify threat actor groups; break down their capabilities; and then map those capabilities to a typically used set of tactics, techniques, and procedures (TTPs); and, finally, tie it all together with threat intelligence. This work, while valuable, can get precise and, amid a fast-moving investigation, may be more of a distraction than a value add. But if you have a team who is well versed in using and navigating the ATT&CK framework, then lean into it.
However, I am personally a big advocate of a slightly more abstract grouping of attacker profiles. Sandia National Labs has used this tool over time (see table II in this paper) to map out several adversary groupings and their relative motivations and capabilities. One thing that I love about it is the incorporation of elements like intensity and stealth preferences as well as the range of capabilities (kinetic, physical, technical). You can also adapt it for your own purposes and environment. For example, expanding on technical capabilities to include on-prem networks, cloud, or software-as-a-service (SaaS).
Once you’ve identified some adversaries, tactics, or motivations, I’d recommend pulling a diverse group of people together for structured ideation. Ideally, participants shouldn’t all come from the security team: Pull in developers, product managers, or data stewards. The group size and process intensity should be tailored according to the situation’s immediacy. As you go through structured ideation, keep in mind that it is sometimes advantageous to move faster and perhaps repeat the process multiple times; learning and adaption speed is a key success metric for defenders as much as it is for the adversary.
Think of this step as brainstorming though your frame for ideation is set up in a very particular way.
- Describe the position. Set the stage for each participant by describing the position you’d like them to embody and think through. For example, you’d like them to think about an adversary targeting us to disrupt system operations and instigate downtime that impacts end users or our ability to deliver mission capability.
- Go through the attack process for ideas. Go through several stages of the attack process to gather ideas from the group. For example, if you know a breach started through stolen credentials that were accidentally checked into a git repository, cycling through the following sorts of questions can help:
- Where else might these credentials have gone or be used for?
- Would this team or similar users be doing something similar in other systems?
- Given the initial compromise, what would the adversary want to do next at different points in time: immediately, within a week, within a month, etc.?
This process can be very effective if you split into small breakout groups and divide your time into ideation and group presentations. Cycling through each of the question areas with ideation and presentation loops can also give each small team a chance to regroup and expand their ideas. It may also be useful to hold off on presentations until you reach the end of the question cycles to avoid creating a groupthink bias amongst your breakout teams.
Tying It Together
You’re now ready to pull the results of this ideation process, whether it’s done at a larger scale or a smaller one into security operations and incident management processes. You can take the ideas and turn them into threat hunt tasks, SIEM queries, or firewall rules that will help guide the search.
Even if security teams don’t have all the visibility they need, they can still see and explore their environment by looking through the adversary lens. This process of hunting and ideation can help identify blind spots that compliance frameworks cannot. Ultimately, thinking like an adversary helps ensure that security teams respond as effectively as they can to a breach.
Want more cybersecurity insights? Visit the Cybersecurity channel: