Hello and welcome to the instant response and recovery discussion. In this domain, we're going to be covering the following objectives here on the screen in front of you. Describing the incident handling process. Take a look at what instance handling is, why it's important, why do we have to identify an incident, how do we identify it, what do we do once we have one. All of those things will be subject to the conversation. Contribute to the incident handling process based upon the roles that we have within the organization. Are we a user? Are we an administrator? Are we a stakeholder? Are we a contributor in terms of creating data? Are we somebody who maybe understanding and monitoring and manipulating data by looking at logs? Different roles we have and based on that we may do different things in the incident handling process. Describe the supporting role, the roles we play in the forensics investigation process. We as an actor turn to somebody who will go and investigate and find information maybe as a first responder, maybe able to do and support certain activities and we'll have to take a look at those. Describe the supporting role or roles in business continuity planning process we may play. Same thought process there. Same thought process there for business continuity planning. want to make sure we're aware of that. And describe the supporting role in the disaster recovery planning process. So, walking through forensic examination, BCP, business continuity, and DRP, disaster recovery planning. We'll take a look at the roles we play and the responsibilities we have across all of those areas within this discussion. Let's jump right in with participating in incident handling, let's take a look at what we do there. Module topics will be preparation, detection and analysis, containment, eradication and recovery, post-incident activity and implementation of countermeasures. We'll begin by talking about what incidence response is and defining it. You'll see in front of you incidence response is the process of going ahead and responding. So we respond to some sort of stimulus in the organization, in an organized and thoughtful way that's going to allow us to understand what's happened, contain the incident if containment is part of the process, identify all the issues and concerns we have. And ultimately, as a result of that, examine and then figure out what the next steps are by evaluating, analyzing, reporting and taking whatever mediative and/or containment-based actions we may need to take to ensure that the incident does not become any worse than it may already be. And that we can then understand and identify the concerns that the incident may have caused. The risks, the threats, the vulnerabilities that may be involved. So, incident response is that process of responding in an organized manner to some sort of compromise, some sort of bad activity or issue or concern that's become apparent to us. Or attempt to compromise of organizational information and the technology assets of the organization. Once we think about incident response, we have to define some key terms. The idea of an event, an adverse event, and computer security incident all become important. An event is something that has happened that's recorded inside of our systems. Not all events are bad, not all events are good, they are just events. And so, we classify them. So, an event is simply something that occurs that we take note of. An adverse event is something that occurs that we take note of that is bad, as opposed to simply being something that may or may not be a problem for us. And then, computer security incidents are adverse events that directly impact the computer security or the capabilities around the computer security that we are trying to create or manage in a specific system or within a group, a host of systems, or rather a group or a collection of hosts that we may be thinking of. An incident, in other words, is going to be something that we classify that is specific to a certain system, or specific to a certain category, a service, a user, whatever it may be. And it has adverse impact, adverse effects on the organization. So when it focuses specifically on computer security, we classify it differently than we would simply an adverse event that may or may not impact computer security, but does certainly have a negative connotation. Remember, the computer security framework that we think about, we monitor against, we manage around, it's going to be made up of three distinct components, we've talked about them before. Confidentiality, integrity, and of course availability. Computer security incident would affect one or all three of those in a negative way. When we think about preparation, we have to think about planning to be successful as I often speak about, planning to be successful is going to involve three distinct things. You could see them on the screen in front of you. We have to plan for, and ultimately create incident response policies in this area, incident response plans, and then related incident response procedures that will be driven from. And implement the things that we are discussing. Incident response policies are seen as being high level and strategic. We should have a policy that stipulates and directs how activity should be undertaken in a broad framework within the organization with regards to incident response, that will drive the overall approach. But again very high level, very strategic. What we then distill that down into that becomes operationalized is an incident response plan. Little more focus, little more detail narrowly defined, really focused on going out and getting the job done. In terms of framing the conversation, providing the resources, and ensuring that we have direction. That will be the incident response plan. The tactical specific elements that we use to accomplish individual aspects of incident response are going to come from the various procedures that we create that the plan will help implement, drive, and manage. And so all three of these levels are all focuses at different levels for different reasons and different ways for the preparation activity. When we are planning to create a policy, we have to work with strategic stakeholders in the business, customers at a high level that will help us to understand what it is we're looking to accomplish. And what the business requirements are we have to support and align with, in order to make incident response something that will make sense. And also be valuable to the business. What we should not do is go out and write our policy, in other words, in a vacuum, and allow the stakeholders to have no input at all. And then show them the policy and say, look, we're going to respond to these incidents. Yay, right? Well that may or may not work. What about all the remote activity that you haven't accounted for? What about mobile device activity that you haven't accounted for? What about cloud based services that you haven't accounted for, may be the conversation that will come out of that because the stakeholders will look at the policy and say, well this is nice. This really only deals with local traffic or local focus for incident response within the LAN isolated from the outside world. And while we need that, that's good to start with, we need separate policies for wireless based access. We need a separate policy for mobile based devices. We need a separate policy for cloud services. Or we need to combine them all together into one and deal generically with the idea of incident response. So you would need that insight, that guidance, that focus. And that would happen by, you share it the thought process and inviting the stakeholders to come in and give you some input before you actually go ahead and draft.
