In this lesson, I'll discuss what happens before an attack actually happens, and what should be done before an attack actually happens. We're going to explore the incident response plan, understand how organizations rely on other people to support them during or before an attack, and discuss what to do during an incident. So let's talk about an incident, and we can also, because of the course that you're in, we can call the incident an attack. So an attack is whenever a user is not receiving an expected level of service from an IT service. Expected levels of service are based on service level agreements, or SLAs. Now, an incident could be generally something like, something's not working properly. Now, you don't see incidents being used synonymous with attacks, but what you will see is the major incidents or outages caused by an attack. So an outage or major incident is defined as a significant event which demands a response beyond the routine. Resulting from uncontrolled developments in the course of the operation of any establishment or transient work activity. So, meaning that somebody, let's just preface what we're going to talk about for the next three lessons, which is a denial of service attack. A denial of service attack is really an outage, it's a major incident which you have to go above and beyond the call of normal duty, in order to address that situation. Incident response plans are designed to help organizations be guided through an incident. Incident response plans are not for your normal, I can't access this hard drive, or this resource isn't available, these are major issues, major incidents or outages. Now, you may have an incident response plan that is separate from your major incident response plan, or even a security response plan. But we're going to talk about what we need to have inside the incident response plan. According to SANS, incident response plans should include preparation, identification, containment, eradication, recovery, and lessons learned. Any time that we have an incident, we want to minimize the damage that is caused by the incident. So a denial of service attack, for example, or a ransomware attack, the goal is to minimize damage. So in each of the phases of the incident response plan, like preparation, what do we need to know, what systems are critically identified? Identification, what is going on with the systems, what is impacted? Containment is diving into, well, let's make sure this thing is controlled. If it's ransomware, how do we contain the ransomware so it doesn't spread? Eradication, removing the actual virus, or the thing that's causing the service to go down. Recovery is going to be putting all files back into place, or putting service back in place. And then finally, you want to make sure that you have lessons learned as a report after the incident has taken place. This is due to the fact that we want to learn from our mistakes, and maybe there's security policies that we could implement, to make sure that the incident doesn't happen again, or the attack is mitigated next time. Whenever you are developing an incident response plan or you're looking at what happens before an attack, you really have to understand your critical systems. If there is ever an attack, you need to do this before, which is hard, because you never know when an attack starts. So that's why it is important to always make sure you have identified your critical services or critical systems. So that you know what to do in case of the attack, or in case of a major outage, so identify your mission critical systems. The next is to identify support services for those systems, so at the university, we have both an incident response plan, and we also have a major incident response plan, now, the two could be different. Our incident response plan is really under security, and our major incident response plan is for any outages that occur during the normal course of business. Let's say one of our data centers goes down, and it's an outage for some part of the campus. So network, for example, your network includes firewall, switches, routing. Connection to data centers, or connections to mission critical buildings. Those are all examples of where we need to make sure that we identify what is critical to keep the business up and running. Power disruptions are another critical system, data center outages, that If a data center goes down, we could have a major incident. Defining the roles and who does what is another major portion of the incident response plan. Outlining who's going to do what, identifying a mission commander, an incident commander, to guide you through the entire process, should be set up ahead of time and outlined in your incident response plan. Now, I'm not going to go into detail about incident response plans right now. Because there are so many things that you need to consider in an incident response plan, that's not the point of this module. But I will put resources out there for you, so you can look at some incident response plans and see what to do. But defining your roles, for example, and who does what is a major portion of that incident response plan. So not everybody's doing the same thing, if we all get in a room and we don't know what to do, we are wasting time, so it's important to have roles defined for everyone. Understand your systems and procedures, understand how your systems are configured, or where's the information documented at? What if you lose your network connection, or Internet connection? Where do you have your incident response plan that is not on your primary network? Maybe you have another third party service, like Amazon Web Services or Azure, for example. Or even another organization, we do this a lot in higher education. We share information and share servers between campuses, so that we make sure that the core data is not in one location. Where do you go for help as well, make sure that's identified, and what is the plan? The entire incident response plan should outline what to do in case of an attack, and what to do in case of a major outage or emergency. By far, we need to communicate, this is the most critical, in my opinion. Communication is very tough, especially in an emergency. Sometimes people will just want to jump in, and they need to look at the documentation and communicate what they're doing, share what they're doing. Define who should have the communication role, and who should send the notifications to other parts of the organization, or other parts of your constituents, really. Identifying logistics in a major outage is also important. What happens if it's a long term outage, like a denial of service attack that lasts days, we've had this happen at the university years ago. You need to define who's getting sleep, you can't work for 24 hours straight, your brain doesn't function. And who gets to sleep when, who runs and gets food, who has a company credit card on them at all times? And what about after the incident, what do you do to clean things up? One thing that we've identified, exercising this over and over and over again at the university, is that I rarely use my company credit card, my university credit card. But what if something happens and I'm not at the university, or what happens if something happens to the building, and I can't go back in and grab my credit card? You need to have the resources available to you at any time to recover. So in the next few videos, I'm going to discuss an attack that we had, which is a good representation of what we actually need to be looking for during an incident. So, it was Monday morning, everybody was in the office, luckily. It was in the middle of the semester, so there were students around, university's generally very busy during the semester. Everyone is reading their email from the weekend, this is about 9 o'clock in the morning on a Monday. It took just one person with permissions to take down a major part of one of our servers. And we'll explain a little bit more about that in the subsequent videos. But what I want you to understand is, this could happen at any time. We were extremely lucky that everybody was there on a Monday morning. But think about your security and what people have access to, be thinking about where your plans are. If this happens to you, this exact situation, what are you going to do? Companies get destroyed, and this is a ransomware attack, companies get destroyed because of ransomware. There's been numerous hospitals, there's been organizations that pay a lot of money to restore files because of a ransomware attack. But I'll talk more about that in subsequent videos.
