We are now going to cover the fourth and final domain of the CISM exam preparation seminar, Domain Four, Information Security Incident Management. While security incident response, business continuity planning, and disaster recovery planning are often considered to be separate disciplines, they do share a common objective, the best possible continuity of business operations during and after a threat event.

There is a wide variety of threat events that, if realized, will call upon one or more of these three disciplines in response. Security incident response, business continuity, and disaster recovery all require advanced planning so that the organization will have discussed, documented, and outlined the responses required for the various types of incidents in advance of their occurrence.

Risk assessments are the foundation of this planning for all three disciplines as it is necessary to discover relevant risks and to establish priorities during response. One of the byproducts of planning security incident response, business continuity, and disaster recovery is the improvement of systems and processes.

Primarily, the planning efforts reveal improvement opportunities that, when implemented, will result in the information systems becoming more secure and resilient. These improvements generally mean that incidents are either less likely to occur or they will have less impact on the organization when they do.

A security incident can be caused by any one of several agents or actions. These can include computer account abuse, device or network trespass, information exposure or theft, malware, denial of service or distributed denial of service, loss of critical information, device theft, sabotage, or any other impact that disrupts the confidentiality, integrity, and availability of an enterprise system or data.

So when we look at the departments and other organizational entities that might be involved in an incident response plan, they can include any or all of these, IT obviously, internal audit, HR, legal, physical, and the rest. Some of these will be directly involved as contributors to the incident response plan or even participants in the recovery efforts. And some will be what you would call ex officio members, where they get information and are kept in the information loops but aren't directly involved in the incident response unless, of course, their department is directly concerned with the event itself.

So here we have some examples of typical types of events and the typical responses that we have. Natural disasters, we'll typically call upon the disaster continuity and disaster recovery efforts, man-made disasters, again, business continuity and likely the disaster recovery efforts. Theft of information, more probably we'll call upon the security incident response. And deliberate corruption of information or systems by an attacker, it may involve business continuity, but it will certainly involve security incident response teams.

So let's take a look at a graphical relationship between these two. We start with our normal operations there at the far left, and then we have an incident onset or a disaster onset, and there's nothing to say that the two couldn't be the same. Then we have the cross impact of incidents and disasters to the incident response plans, the business continuity plans, and the disaster recovery plans.

Once they have successfully accomplished their objectives, the systems and operations are recovered, and normal operations are resumed. So the incident management actions that take place during any of these will include things before, during, and after the incidents themselves. And they're designed with the following goals in mind, they need to provide a way to attempt for us to minimize the impact.

They should provide enough information to make right decisions at any point where a decision must be made as to the next step in the course. We want to try to maintain and restore continuity of services as best we can. This will be limited, of course, based on the circumstances. Ideally, these should provide for defense against future attacks or an extension or expansion of the current one, and there should be elements that provide for deterrence.

Now, any type of an event can disrupt business operations and become a more severe incident or even a disaster. Risk assessments and business impact analyses are used to prioritize response activities around the business priorities. And it's increasingly important to develop effective incident management plans so that we can conduct these things with great control and ensure that nothing is missed.

So let's cover some basic incident response concepts. These will involve a handling process that includes detection and reporting of incidents, triage of incidents, the analysis of them, and incident response actions. Now, the incident management process ensures impact of incidents is minimized, or at least it attempts to make sure that they are minimized.

The recording of the incident is useful for legal or disciplinary action as well as for lessons learned. Prioritization ensures that work is allocated properly. Incident response carries out various actions including mitigation, containment, and recovery.

So let's think back to the eight security principles we covered in section one. The incident response team must understand all of these. The team must also understand vulnerabilities, and that includes software issues like design flaws, man-in-the-middle attacks, malicious code, and all of the rest.

The team must also understand physical security issues and social engineering and the contributions they can make to causation of incidents and to exacerbation of incidents and how they can be counteracted. The team members should also have fundamental knowledge of how network protocols operate, such as the common TCP, IP, UDP, ICMP, and all the rest.

Team members need to be well-versed in operating system issues for Windows, Mac, Linux, or any other. Prior to provisioning, the system should have gone through a hardening process, configuration file reviews, privilege management processes, and so on. Team members must be familiar with common attack methods and how to counteract them. They should also know about malicious code, how it's propagated, and how it can be counteracted.

Members of the team should possess programming skills because it can help them detect vulnerabilities as well as running various scripts that can help them resolve the various issues they encounter. They will also need to be able to understand the coding and the practices of the developers in case the incident involves program modifications.