In section 55, we're going to continue the discussion with the responsibilities and roles, who does what? So when we construct our incident management organization one of the first things that we're going to do is meet with emergency management officials outside of our organization, because we want to get an understanding of what government capabilities exist nearby. Meaning primarily first responders, police, fire, EMS. And then we understand what local emergencies might occur either independent of ours or included in ours.

Now these emergency management activities would likely include recovery back to operational status, restoration of hardware, software, and data. Always to ensure the safety of personnel, possibly even to the point of evacuating endangered personnel.

Establishing a command center and one of the most critical functions managing communication to external parties. So we need to establish responsibilities for all parties concerned in our incident response plan. These need to cover what happens before, during and after incidents. For example, before, obviously the development of the response plans themselves.

As with everything else we've discussed, we're going to have to observe budget constraints. And we need to strike a balance between the response posture and operational processes. During, we will, of course have to handle and coordinate all the response activities. We will make every attempt reasonable to mitigate damage or losses, handle human safety and attempt to recover as quickly as we reasonably can.

Afterwards, we need to try all methods reasonable to decrease the likelihood of any recurrence, either immediate or later. There'll be no getting around the fact that we will have to deal with legal issues that may arise. The security manager needs to decide what qualifies as an incident. Some will be fairly obvious, like distributed denial of service and social engineering events. Some however are less obvious, like covered access or unauthorized changes. But in either case, incidents and disasters can result and we have to be prepared for both.

As before, we have to start out seeking and obtaining senior management commitment. Incident response can be more cost effective than trying to control all risks. The business may set a higher level of acceptable risk and this in its turn may lower mitigation costs.

Now the incident response team normally is comprised of the security manager, a steering committee, dedicated team members with specific skills and possibly virtual or ex-officio team members. The models typically follow one of these: Either a centralized, where there's only one team from a central location. Distributed, which are multiple teams. Coordinated, multiple distributed teams relying on a central emergency management team. Or outsourced altogether, meaning that would rely on an outsourced third party.

So let's take a look at some tables to show who is responsible for what. We begin with the security steering group. Now, this is typically the highest structure of an organization's functions related to information security. And here we have some examples of responsibilities that would typically fall to the security steering group, overall security management, the incident management team charter, approving exceptions or deviations and making final decisions.

The information security manager then becomes the on the ground leader. Responsibilities for the security manager would be, to maintain incident management capabilities, overall management of the risk and performing control measures to handle risk levels.

An incident response manager would typically be the leader of the actual team that responds to any security incident. Thus, they supervise the incident response activities coordinate resources, taking responsibility for IRP execution and delivering reports to the steering committee and executives. And incident handler is typically a member of the team and has their individually assigned duties.

Other members might include an investigator, finding root cause, writing reports of findings, trying to get to the bottom of things, but may not in fact be involved directly in the event itself. A security specialist may be a subject matter expert in IT security. And either consult with the team or may perform actions on the team directly.

Business managers are the kind of individuals that I mentioned as ex-officio, not directly involved in the plan or in the response, but they're in the information loop and need to be kept informed. These represent stakeholders who have an immediate interest in how the incident is being handled and its outcome.

We will have various IT specialists and representatives on the team and in support of the team, whether they're directly involved or not. Legal representatives and human resources are also ex-officio type members in the information loop, but not directly involved in the actual incident response itself. The same can be said for the public relations representative, a risk management specialist but the physical security and facilities folks may very well be directly involved in the incident response.

Certainly all three of these parties are going to be in the information loop, whether they are directly involved in the incident response or not. All of these persons, all of these roles will have specific skills that they contribute and actions that they will take in support of the incident response effort. These members need personal and tactical skills which will include hard ones and soft ones.

Everyone must be skilled and prepared to do active communication at all times. Leadership skills will also be essential. They have to be skilled in communication, presenting information and ensuring that they know who needs to know what so that the information can be presented in the proper form to the proper audience. There are required technical skills that are foundational and specific incident handling skills.

All of these parties on this team will need to know various things, who their various audiences are and their team members, or they could be it staff, applications owners, or a host of others that need certain messages and communications to be clear, precise, and accurate.

Once the incident itself has been handled and is no longer causing trouble actively, there are post-incident activities and investigation events that need to take place. This approach may seem obvious, but identifying the problem, creating a mitigation plan and implementing the solution may not be quite as obvious as the need for doing it.

Less obvious than this, will be the calculation of the total loss. The metrics for doing so should be justified in the regular program and then extended into the incident response planning. Part of this will be to justify IRT existence to senior management and continue the effort. It also may provide valuable information for court cases should one result.

At some point, following the actual event occurrence, we will need to conduct cause and corrective actions to get to the root of what was the causative factor. We need to examine the evidence that we've collected and find the root cause. This allows us to just dissect the event and prevent reoccurrence.

So the questions we need to examine would be, who was involved? What exactly happened? Where did the attack come from? When did it happen? Why did it happen? Which may be one of the more difficult questions to answer but how did it happen will be extremely important. And what was the reason for the attack? Similar to why did it happen. But there may be a reason that may give evidence as to why what happened happened the way that it did. And one or more people should be writing the documentation to preserve evidence. And it should be said that the chain of evidence and chain of custody need to be maintained.

In the planning effort we will need to establish the various procedures that will guide how those particular tasks are going to be performed. The incident handling process should adhere to strict rules for evidence preservation. To do so we should seek the advice of legal counsel, senior management, and or necessary law enforcement.

We have to be sure that the incident handlers know exactly what the rules are so that nothing is changed, modified or contaminated. And anything that happens along these lines, they need to understand the consequences when evidence becomes an admissible. We will first have to retrieve any information necessary to confirm that an incident has occurred. Then to the extent possible, we have to identify the scope of the effected environment and then ultimately determine the loss or damage and identify the means of attack.

Now, let us take a moment and examine the requirements for evidence. We know that contamination of evidence may be an obstacle to various types of forensic activities. If these become obstacles they can prevent us from identifying the perpetrator and identifying how the attack actually occurred. When we pull the plug on a compromised computer, this can preserve data on the drive but it can eliminate other kinds of actions and evidence of them.

Pulling the plug on a compromised computer is not always the best course of action to take, because it may eliminate a source of necessary evidence. But it can also cause a corruption of the data or loss of evidence in volatile memory. We have to carefully consider the consequences of such an action before we take it, because there will not be any undoing of this action once it's been taken. And what is lost will remain lost.

We have to ensure that our analysis is performed on copies and never on the original data. We have to take the original medium, create forensic copies, act on the copies and ensure that the evidence custodian takes the originals and puts them in secure storage where they will be left in pristine shape should they become necessary to be presented in court.

A copy of a drive must be a bid level, forensic quality rather than trying to make a copy. Hashing values placed on these copies and the original would be used as evidence of their guaranteed pristine shape. So legal aspects of forensic evidence means that we have to adhere to the rules of illegal admissibility. The federal rules of evidence and the federal rules of civil procedure are the authorities on this subject. And those rules are very stringent and need to be followed strictly.

The chain of custody needs to record who, what, when, where, and why of evidence access. And every single minute of its lifespan once it becomes part of our evidence chain of custody, needs to be accounted for. Technicians sign nondisclosure and confidentiality agreements before access to evidence articles can be granted. And technicians must follow specific checklists and make sure they maintain all activity logs and keep the chain of custody log fully up to date and totally accurate.

The case log itself should outline requests received, dates of investigative assignments and performance of tasks and all of the identifying information about the investigator. To guide this, we should use report templates to ensure that no item of evidence or chain of custody is left out. We also have to ensure that the investigations are fair and without bias.