Quite a lot has been written about pen testing and hacker lifecycles. Over the past few months, for example, I've written a couple of articles for ADMIN about penetration testing: one about automated tools for pen testing [1] and the other about improving defense through pen testing [2]. However, comparatively little has been written about the knowledge, techniques, and tools necessary to analyze an attack or pen test as it occurs (i.e., the "other side," as it were, of an attack).

Indicators of Attack and Compromise

Before I stampede into the tools an analyst uses, it's important to identify an essential principle of the security analyst: As an attack occurs, certain things are left behind. This concept was first articulated by Edmond Locard [3] almost 100 years ago, well before the first modern computers were created. In fact, the concept that attackers leave behind signatures and traces is named "Locard's Exchange Principle."

The defender – in this case, the security analyst – needs to figure out what indicators of attack (IoAs) and indicators of compromise (IoCs) were left behind. An IoA is evidence left behind even if a particular attack doesn't lead to a break-in or data breach. An IoC is evidence left behind if an attack has successfully tricked or breached a security control. For example, an IoA could be a system scan or an unsuccessful attempt to create or exploit a buffer overflow condition. An IoC could be a case in which an attacker was able to exploit a buffer overflow successfully or otherwise gain unauthorized access to a system – same activity, two perspectives, and two sets of tools.

According to the Exchange Principle, Table 1 gives a quick overview of the tools that pen testers and security analysts use. This "quick and dirty" table is nowhere near perfect or thorough, but it's sometimes useful to think about the same activity – hacking – from two different perspectives. This model isn't perfect, because, after all, a pen tester can use Wireshark just as effectively as a security analyst. The pen tester, though, simply would use it in a different way.

Red Team/Blue Team Exercises

In my experience, pen testers are often called "red team" workers and security analysts "blue team" workers, often because pen testers and security analysts work together in teams during security exercises or war games.

Sometimes, these exercises are conducted to upskill a team of security workers. However, I've found that the most proactive, forward-thinking companies use these exercises to help preprogram and reprogram automated security tools, because the best reason to have pen testers isn't really to play "whack a mole" to try and find hackers or weak systems: The real reason to have pen testers is to improve the quality of the security analysts.

Several companies I know regularly conduct exercises that generate various IoAs and IoCs so that the security analysts can identify them in real time. In this way, security analysts can help fine tune their intrusion detection system (IDS) and security information event management (SIEM) tools.

Isn't There an App for That?

Over the last five years of traveling around the world talking with IT techs and cybersecurity workers, I've asked them about "killer cyber analytics tools." Invariably, they talk about monitoring logfiles and system processes and reviewing packet captures. At first, this kind of surprised me, because I thought that they would tell me about nifty, cool SIEM tools and host- and network-based IDS tools, such as Snort, Suricata, and Bro. Pretty consistently, the security pros I've talked to tell me that, although these tools are, of course, very useful and essential, you can't just "plug and pray" these systems into your network or network hosts. You have to pre-program them with information (i.e., customize them).

The best way to get this customization info is to break out the tried and true tools, so I'll take a quick look at these tools and then look through an applied example of what a security analyst does with them. (See also the "Steps in the Hacker Lifecycle" box.)