As a follow-up to our recently held State of the Hack: Back to the Remediation webinar, questions answered by presenter Jim Aldridge are listed below. 

1. How do you develop a business case for resources for security incident management, remediation, and log analysis?
   This is an area with which many organizations that have not experienced an incident struggle with. I would recommend conducting a realistic incident simulation to exercise the organization's incident response plan. This should go beyond a table-top exercise and actually test responders' capabilities to use logs to identify and track attacker activity. This approach should provide the organization a good understanding of weaknesses in these areas. For example, I assisted a bank with planning and executing this type of exercise. They were concerned about targeted threats and had never experienced a security breach. After a series of meetings to better understand their environment, we designed a scenario based on an incident we had worked on in the past. In their scenario, picture a blank screen with a SQL Server and a question mark on it. We would give them a clue, and then we would on and say, "Okay, so what would you do if you got this information?" And then we provided a little bit more of the diagram. It was in the style of a choose your own adventure.
2. During incident response what tools do you use for networking indicators; are any of them open source?
   Typically, we like to deploy our network sensors, which we don't offer as a standalone product at this time. That intelligence is only available as part of our Managed Defense™ service, in large part due to the back end processing that's involved. I would categorize those as proprietary. They do a lot for us, but we also leverage whatever the client has in place.
   t
   Sources of helpful information include:
   • Firewall logs (established connection information)
   • DNS logs (which host resolved a given domain name at a given time)
   • NetFlow (connection information)

   One of the more mature security organizations that I've worked an incident with has a particularly effective network monitoring set up. They collect NetFlow information from across the environment. This enables them to rapidly identify lateral movement.

 

3. Is the Mandiant incident response tool available to the public?
   Mandiant for Intelligent Response® is a commercial product. As I mentioned, Redline™ is a free tool that I encourage you to take a look at. It is very similar to MIR in terms of the capabilities on individual hosts, but it's designed to be executed against one host versus an enterprise.
4. What are your thoughts on best countermeasures against pass the hash tactics?
   It is most important to prevent the attacker from getting access to that hash in the first place. That's one reason why I like application whitelisting so much, particularly on domain controllers, because this can prevent even a domain admin from running the hash dumper. Unfortunately, once the attacker has that hash, it's not good. Another strategy is to reduce the number of places where an attacker could readily obtain privileged users' hashes. First, privileged users should operate with non-privileged accounts for their day-to-day activities. This helps reduce the impact of a spear phishing email or strategic web compromise that impacts that user. To conduct administration activities, connect to a jump server using two-factor authentication. Maybe incorporate a password vault so that the vault connects the user to the jump server, after a two-factor authentication process, and the password is never divulged to the user (or present on the admin's PC). Then lock down the jump server with application whitelisting, implement enhanced logging and monitoring. Configure firewalls and systems to only accept inbound connections on administrative services from the jump servers and not from the network at large. Each of these countermeasures helps to mitigate a part of the attack lifecycle; implementing them together can help greatly strengthen the security posture.
5. What kind of back door were the attackers using on the first infected systems?
   That varies widely. On some cases I worked recently we've seen Gh0st RAT, we've seen Poison Ivy, we've seen a custom back door that doesn't really have a name because it's something that this one particular group uses. The particular tool there wasn't the point, just more the fact that they were infected. We're seeing a lot more use of publicly available back doors. They can be pretty effective, and can also be hard to detect.
6. How would one ever determine the true scope of a foothold in a global environment if it's using multiple command and control points?
   To answer that question, you have to start by comprehensively surveying the environment for indicators of compromise (IOC). You start by taking the pieces of information you know, e.g. the backdoors the attacker is known to use, known compromised accounts, and command-and-control IP addresses. Perhaps this yields you two systems that are initially suspected of being compromised. You then you ask the question, "Well, where did they go from those two systems? How did they get on those two systems?" You conduct forensic analysis to understand all the facts related to those systems: how did they gain access, what did they do, where did they go, and what tools did they use. Then you follow those threads, identifying more systems. This can be challenging in a large environment, which is one of the really helpful use cases for Mandiant for Intelligent Response. The largest organization where I have conducted this type of incident response had around 135,000 hosts. With a team of five or six people and about eight weeks, we could get a handle on that environment.
7. How do we balance the need to contain and respond and the need to preserve forensic evidence?
   It depends on whether you think that it's likely to go to court or in litigation. You want to make sure that your procedures are as least intrusive as possible, but typically in most APT-type cases, we don't really worry as much about formal chain of custody for systems or preserving every system in its original state. The way I would look at it is, I would develop a set of procedures for your organization to talk about how you determine when you need to preserve and what that means and what your standard operating procedures are, so that you can explain and minimize - both explain what you're doing as well as minimize - the impact on systems.