All the discussion so far in our CISO’s Guide to Advanced Attackers has been of preparation for the main event. The bell rings when an alert fires and it’s time for your incident response process to kick in. But as we have seen through our adversary analysis and intelligence gathering, “advanced attackers” present some unique challenges. In particular, they significant resources and time, which makes them difficult to deter – even if you successfully block one attack or stop a specific exfiltration, there will be more. A lot more. As usual we depend on process as the key to dealing with advanced attackers. But this class of adversaries requires you to put a premium on analyzing malware to isolate the root cause of the attack, looking for indicators to identify additional compromised devices, and then trying to piece together the bigger picture of the attack. React Faster and Better, CISO Style Let’s turn back the clock and review some of the Incident Response Fundamentals we introduced a few years ago. The process remains largely the same, but you are likely to need some of the data sources covered in React Faster and Better and some of the analysis techniques presented in the Malware Analysis Quant process maps to deal with advanced attackers’ tactics. If you weren’t worried enough about this, remember that your perceived success as CISO is directly correlated to your ability to respond effectively to incidents and keep your organization out of headlines. You don’t need a SIEM to do that correlation, by the way. During the Attack Once the alert sounds it is time to figure out whether the attack is legitimate, what it looks like, and the proper escalation path (if necessary). Here are the general steps in that effort: Gather information: For an investigator to make heads or tails of anything, your first tier needs to collect some information. Things like who triggered the alert and what systems and devices were involved. Were you notified by a third party (not a good sign)? Could you find an alert (perhaps one that was ignored) around the time period of the attack? You are trying to get a feel for whether this is an operational failure or something designed to evade your defenses. Escalate: Next you decide how far up the chain of command this needs to go. If there are critical systems involved (those on your list of things where compromise would be bad), then your spidey senses need to start tingling and you need the big guns involved. The escalation scenarios must be defined and agreed on ahead of time so your first tier responders know what to do and when. Size up: Once your second tier (or even third tier) responders are involved, the key is determining the scope of the situation. Was this a total compromise? Does extensive lateral movement indicate potential exfiltration? You need to know what you might be dealing with, and to assemble a list of the stuff you really need in order to investigate the incident. Initial Containment: Depending on your initial assessment of the situation you may need to quarantine devices, step up monitoring, or remove the device’s access to sensitive data. As with escalation, the initial set of containment actions should be documented in a playbook, with documented approval from all stakeholders, to ensure containment steps are not held up by bureaucracy. At this point you should have initial defenses in place and a feel for whether you are dealing with folks who know what they’re doing. If the attack doesn’t seem sophisticated or coordinated you can probably just wipe the machine and move on, hopefully using it as a teaching moment so the user doesn’t do something stupid again. Is it a risk to just wipe and move on? You bet! You lose any ability to seriously analyze the attack, but part of the CISO’s job is to allocate resources to the stuff that matters. Being able to tell the difference between an advanced attacker, an operational failure, and a stupid user error becomes a key determinant of success in the job, along with resource allocation. If there is a chance that you are dealing with an advanced attacker (or something else is pushing you to do a broader investigation), you will start working through a more detailed forensics process. That means quarantining the affected devices, taking forensic images, and working to determine the root cause of the attack. That requires you to dig into the malware and determine how the devices were compromised, then assess the extent of the damage. Digging for the Root (Cause) Malware analysis is a discipline all its own. We have documented the entire process in Malware Analysis Quant, but CISO types rarely fire up BackTrack or ship file up to malware sandboxes, so here is what you need to make sure the right stuff is happening to identify the root cause of a compromise. Build Testbed: It is rarely a good idea to analyze malware on production devices connected to production networks. So your first step is to build a testbed to analyze what you found. This is mostly a one-time effort but you will always be adding to the testbed, with the evolution of your attack surface. There are services that can do this as well, without the hardware investment. Static Analysis: The first actual analysis step is static analysis of the malware file to identify things like packers, compile dates, and functions used by the program. Dynamic Analysis: There are three aspects of what we call Dynamic Analysis: device analysis, network analysis, and proliferation analysis. To dig a layer deeper, first observe the impact of the malware on the specific device, dynamically analyzing the program to figure out what it actually does. Here you seek insight into memory usage, configuration, persistence, new executables, and anything else interesting associated with execution of the malware. This is managed by running the malware in a sandbox. Once you understand what the malware does to a device you can begin to figure out its communications paths. This includes command and control traffic, DNS tactics, exfiltration
