Section 53, we're going to discuss Information Security Incident Management and the Goal. Like any emergency, the best time to plan for security incident response is prior to the start of any actual incident. During an incident where there is little or no advanced planning, emotions may run high, and there may be a heightened sense of urgency. This is truly a poor time to thoughtfully analyze the situation, conduct research and work out the sequence of events that should next take place.

Effective incident response plans take time to develop. And a security manager who is developing an incident response plan must first thoroughly understand business processes and underlying information systems in order to then discover the resource requirements, dependencies and failure points.

A security manager must first develop a high-level incident response plan, which is then usually followed with the development of several incident response playbooks, which are step-by-step instructions to follow when specific types of incidents security events occur.

Now we look at normal operations and how controls are activated throughout all phases of an incident. There may be governing regulations that require sensitive information be appropriately protected through all operational phases, including periods of disruption and system compromise. And here in our graphic, we see how these play together.

We begin at the left with strategic planning. Here we have policy guides, controls implementations and actions during all the phases. This is where the planning essentially takes place and then is implemented in the enterprise. As you can see across the top, the directives cover the entire spectrum of activities.

Moving one step, we go to proactive defense. These are the proactive controls that we put in place to try to keep events from turning into security incidents. When an incident seems to be in the building stage, proactive defenses may go active, where what they're doing before is monitoring the situation. In such a state, their detective aspects kick off and begin alerting.

Preventive controls take on different states and start different actions, trying to keep the event from occurring. Compensating controls can also come into play. And then when the event actually occurs, the detective controls continue, the preventive controls shift to corrective, and then we have compensating and countermeasures also to reinforce the response.

Now that the incident has finally transpired and is now active, we then begin our process of triage, discovery and response. Here the detective controls shift to recovery. Corrective controls are still active and still attempting to correct and minimize the damage. And the countermeasures that we actively pursue are doing the same thing.

Once we have performed our triage, discovery and response activities, we can move into the next phase where we can adjust, recover and restore. Here, too, we're going to capture the lessons learned, and those are going to be incorporated back into the strategic planning process, first to examine how we did during this event, and second, how we can do better with the next one.

As with every other process we've discussed during this CISM review seminar, we want to ensure that the incident response process is in strategic alignment with the overall business of the enterprise and its priorities.

So in the formation of the plan, we need to look at the following components. Who are the stakeholders? What is our constituency, and what are their expectations? What is the mission? We always need to identify what the mission goals are so that everyone will understand the purpose and where we want to go with this particular process.

We want to identify services that should be clearly defined for stakeholders and for us, those that are critical, those that are important and those that might be able to wait until we recover the more critical or important ones. The organizational structure will figure prominently in how this process will be put together.

Obviously, we need to account for all the resources, the resources that we will require for doing the response and the resources that we need to protect during the response. Funding, of course, will be required. And we may need to exercise and acquisition to get specialized equipment or training or software.

Ultimately, of course, we need management buy-in to ensure full support for this process through all of its phases. The incident management will, of course, be part of our entire process of risk management. In this particular case, incident management is the last line of defense for a cost-effective risk management program. It must integrate with business processes and with business continuity planning. It must enable us under these adverse conditions to be able to manage risk and assure stakeholders that operations can be protected and resumed. And it has to be part of an organization's overall self-protection strategy.

So like all the processes we've discussed, we need to define what the goal of incident management is going to be. In the first place, we want to try to prevent incidents from becoming problems. And then we want to try to prevent the problems from becoming disasters. And in the course of handling any incident, we're going to go through these basic categories of activities in an effort to try to keep an incident from becoming a problem or exacerbating into a disaster.

In the phase of triage, we need to detect, identify and perform preliminary notification. Following this, we'll need to do the deeper dive of investigation, in which we're going to do incident analysis, interpretation of our findings, formulate and activate a reaction and then begin recovery.

During this time, we also have to perform containment to ensure that there is no spread or worsening of the conditions. And in keeping with that, we will have to analyze and continue to track to make sure that should any of those things occur, we're on top of it.

Once the dust has settled, so to speak, we want to move into our recovery phase. Our goal here is to get the business back up and running as best we can. And in best case, we can bring the affected systems back into production at a fairly early point. But we must take care to make sure we don't rush that because bringing the systems back into production before we are certain might simply re-introduce and reactivate the incident again.

So in Section 54, we're going to further investigate Information Security Incident Management and discuss the Strategy. Now, when we're constructing a strategy, we have to give consideration to several points. We have to create well-documented procedures or gather them, and then plan using them before incidents occur. And this could require significant resources and consensus from stakeholders.

We have a number of choices. We can wait for the unacceptable consequences to start, or we can use persuasive business cases of how unacceptable consequences affect other business efforts. The severity criteria of the incident should be consistently applied, and they should be clear to all parties involved. It should also be equally clear who has the authority to determine the response activities, such as who can declare that we have a disaster happening.