We're going to move into section seven now and talk about the conduct of incident response. So here we're going to talk about the basic techniques that have to be employed for doing incident response, beginning with detection, followed by response, reporting, recovery, and then the subject of capturing our lessons learned.

Now when it comes to incident response, security professionals manage the day-to-day operations of key security services, as well as participating in cross-enterprise processes. The security professional must understand the many types of security technologies that are deployed in his enterprise. Thus, the professional should also understand the role that security plays in operational processes such as change, configuration, incident, and problem management. Now incident response, looked at as a simple form to begin with, is detecting a problem, determining its cause, minimizing the potential for damage caused by this, resolving the problem, and then documenting each step for the purposes of lessons learned and process improvement.

Now, we have a common framework to these models and it includes the creation of a response capability, the actual process of incident handling and the responses that we're going to make to it, and then the recovery and ultimately the feedback.

So next let's take a look at how an incident might transpire. So here you have a diagram that shows how we progress from normal state through an incident and back to normal state. As you see in this diagram, we start out with strategic planning, and this is where we're going to put together all of our policies and procedures, etc. so that we will know how to deal with an incident when it comes up. And it really is more a case of when than if.

We have to have a portion of our program dedicated to proactive defense to try to stop these things from happening in the first place. But inevitably, there will be something that comes along that is able to overpower or in some way circumvent the proactive defenses we put up. Thus, the incident occurs. From there we immediately launch into the triage process, discovery, and response, followed by adjustments, recovery and then restoration of operations. And below the colored arrows, you see what takes place and about when in the timeline.

Detective controls work all the way from normal to the start of the triage and discovery response phase because we have to have that to tell us that something is wrong and to give us an understanding of what may be going on, followed by the activation of recovery. We have our preventive and corrective controls, which will run probably through most of the spectrum of event activities that are going on, and then compensating and countermeasures.

Compensations are simply controls we put in place when direct solutions may be unattractive for some reason. And then as the incident begins to take shape, just prior to its occurring, countermeasures begin to be progressively activated to try to keep the event from either happening or from getting as bad as it possibly can. So through this cycle, our policies and procedures will be active through all phases, even if we're not using every one of them at each and every phase.

So let's begin with the actual actions we're going to take through those phases. Once we have an incident identified, we're going to have to undertake to do triage, that is the detection, identification, and notification phases. In our triage, we will have to decide what exactly are we faced with. What kind of an incident is this? How serious might it be? Is it a legal thing, or is it an operational thing? Those are the decisions that we typically have to address during triage because those decisions will drive a lot of what we're going to do following.

Once we've settled triage we move into investigation. Here we're going to do analysis, interpretation, the reaction, and the recovery. We're going to try to do containment of whatever the offending agent is to keep it from spreading. And we're going to have to do various forms of analysis to make sure that we're keeping track of all the different places that it could go, trying to sort out the symptoms to clarify what it is we're actually faced with down at the causative agent. And then we're going to have to track each and every process that we begin so that we can make sure that they are making progress, that they are either ineffective and need to be replaced or that they're actually doing the job. And we're tracking to make sure we have an eye on the possible spread.

Following investigation and using the information we've put together in that phase, we move into recovery. Here we're going to try to get the business back up and running, even if only at a minimalist level to begin with. And we're going to look at best case affected systems and get them back into production as quickly as we can, but not too quickly because we don't want to put them back into play before we really have a sense of whether or not they're going to go down again right in front of us for having jumped the gun, so to speak.

Now our attack detection techniques are going to include various things, such as signature or pattern-matching detection methods. If it's a signature, let's take a virus, for example, the antivirus software might take care of it, or it may be something that an intrusion detection can pick up. By doing this and other forms of pattern-matching, we may be able to prevent the attack from progressing and escalating, stop it altogether, or we may have to pick up the signature, or the pattern, as we progress through the early stages.

We also have the possibility of analyzing protocol behavior. Anything that's anomalous may signify that it could be an incident, it could be an attack, or it could simply be a component that is not recognizing something or is in the process of failing. We have a statistical, or time-based, type of action, anomaly, and we're going to detect this based on a pattern of things that seems to develop over time. One of our defenses and countermeasures will be an anti-malware system of some description. These, of course, to be effective as a proactive defense require continual updates and monitoring. We also have to be certain that no one but authorized administrative technicians are able to shut it off down to the work station level, and that updating is regularly performed. And each implementation has to be monitored to ensure that we have records, that these activities are in fact being taken.

We have our SIEMs, our security information and event management systems, a fairly recent addition to our toolkit. These provide support to audit, as well as incident response, and they're able to track successful and failed access attempts, privilege usage, service failures, and help us correlate events that take place at various connected platforms that the SIEM is able to correlate one event with another to give us a track through which the attack might have processed.

Then comes our response. The containment strategy here is going to be driven by several criteria. One thing that we have to consider as early as possible is whether or not we're going to have to preserve forensic evidence for possible legal action. This represents one of the very first forks in the road, so to speak, that we're going to face in the process of incident response. If it isn't a legal type of an event then we're looking at something operational, and this is somewhat less rigorous than one that will have a legal implication. But we have to make this determination because if we start with operational it's very difficult to back up and go through it from the legal perspective, given that it's much greater in its rigor. If it is legal we can start that way, and if it turns out to be operational we're able to ease off ever so slightly, but we can't go the other way. So this again needs to be a decision made as early in the process of response as we can make it.

We have to examine the availability of services provided by the affected component so that we can assess what the business impact will be and that will give us some insight as to the true urgency and importance of our response. At all stages, we have to look at the potential damage that can be caused. As early as we can, we need to look at the damage of potentially leaving the component in place. And like so many other things that we're going to examine in this process, we must look at the consequences of doing or not doing. If we leave it in place there will be a consequence. Could that be worse than if we take it out, or replace it with something else? So those decisions must be weighed before they're executed.

We always have to consider the amount of time required for containment strategy to become effective. Things will not happen instantly in many cases, and those things that do happen instantly, if we've taken the wrong decision, they may happen in a way that we hadn't foreseen or didn't want. So again, we have to be very careful about the decisions we made, despite our need to be hasty. And we always need to look at the resources required to contain the affected component. All of this needs to be considered as carefully, but as swiftly, as possible.

Some incidents spread very, very rapidly and give us very little time to make these decisions. But we're going to have to do that and we have to do it with that sense of urgency, but with caution, because one of the things we learn in incident response is once you've done something it is exceedingly difficult, if not outright impossible, to undo what you've done. Thus the need for continued caution.

At several different points, we have to consider the question of reporting. We also have to consider the question of what our information is, who it's provided to, and whether or not that's going to make it only through internal channels, or whether there's a chance it may make it through external channels and end up in the media. In some cases we won't have a choice about that, it will end up in the media, but that will be a choice for someone who is running the company, between them, the management, and the legal office.

What we need to do is make sure that the information that we provide as we pass these reports up is as clear and as accurate and as authentic as we can make it. But we must ask, does the media or an organization's external affairs group need to be in the loop? If they do, the management of the incident response capability will be the ones to make that decision. Does the organization's legal team need to be involved in the review? Again, the same answer to the same question. At what point does notification rise to line management, middle management, senior management, the board, or stakeholders? This again will be a management decision, but when we go through the exercises and preparation and training, these are questions that must be addressed so that we have the answers rather than having to think about it when we're on the spot.

What confidentiality requirements are necessary to protect the incident? We have to protect two different kinds of information here: the incident information itself, and any information that is the corporate resource that is being compromised, potentially, by the event. What are the methods used for reporting? If email is attacked, how does that impact the reporting and notification process? This highlights the need to have alternate ways of doing many of the things that we will do during incident reporting.

As we move later and later into the process, we come to recovery, and that means eradicating of the corrupting agent and restoration of the affected systems. Now, this is eliminating the offending agent, of course, but it's also bringing the systems that have been impacted by it into a state whereby we can reactivate them and put the organization back on its feet. It's very difficult to think about what is happening and how we need to learn from it while the incident is going on. Those actions are mutually exclusive. But we need to be sure that we are making a transcript of everything that's going on, who's doing what, and all persons involved in the response need to be making a record of everything that they're doing, why, and what the consequence of their action was.

We want to try to get to the question of root cause. We're going to ask this question in the form of why until there is only one answer, or perhaps not one absolute or clear answer but a very limited set of possibilities. This is an intensive process involving numerous individuals from across the disciplines to determine why something happened and how to prevent it in the future, starting with what happened and what was the offending agent.

You work with reasonably knowable information to analyze symptoms and evidence, and formulate and validate assumptions. And questions that we're going to ask will reflect what is possible and what is probable. A lot of things are possible, but we have to work on what is probable based on the symptoms, the reactions, the consequences of actions. And here on the right side of our slide, there are a number of methods that can be employed. The five whys, failure mode and effects analysis, Pareto analysis, and so forth. These are all suitable methods for determining the root cause. Taking your selection from among them, as long as it works for you and gives you the answers to these questions and many others, it's probably going to be a very effective method.

Now let's draw a distinction between problem management and incident management. Problem management is concerned with tracking an event back to its root cause. Well, we do that with incidents as well. But what we're trying to do is separate problem from incident, because a problem may incur incidents but a problem typically is a recurring event that works over a period of time requiring a more strategic approach and a longer-term view of how to solve the problem. This is typically involved with defects that may exist in the organization, in the system. Incidents, on the other hand, have one thing in common with projects, they typically have a definite start and, we always hope, a definite end. And we need to manage everything that happens within those two points in time. So it is more limited in its scope than a problem. But depending upon what the problem or the incident might be will have a lot to say about the urgency and the potential damage that either one can cause, and so we need to address each with the urgency the given situation demands.