In this video, we're going to talk about incident response. What is the incident response? Incidence response or IR, as it's more commonly known, is a structured methodology for handling security incidents breaches, and cyber threats. A well-defined incident response plan, IRP. allows you to effectively identify, minimize the damage, and reduce the cost of cyber attack while finding and fixing the cause to prevent future attacks. Then incident response is typically broken down into six phases; preparation, identification, containment, eradication, recovery, and lessons learned. Basically, we talked about alerts, with that you would get through your SIM or you're inner SIM devices or perhaps a security incident is reported directly to the SOC and the SOC would then have to take that alert and analyze it. We talked about that a little bit earlier. If that analysis results in the fact that it is possibly a real incident, an attacker has breached your organization or there's malware that's been discovered or something along those lines, then you would activate your IR plan. Incidence response preparation is the first phase of a good incident response plan. Everything that you do within preparation should be done before an actual incident occurs. These are things that happen at a management level or in a training level. This is going to deal with building your team and making sure all your people on your incident response team are in your side of your SOC in general, have the proper training and guidance they need. If you don't have a large enough organization to have a dedicated incident response team, you then need to make sure you have what they call a fireman team or basically an external consultant that's ready to respond to you specifically. This way, in the case of an incident, if you don't have a dedicated incident response team, instead of them shopping around, trying to make those initial calls, that organization already knows you, your organization, they will need to respond with how many people, the severity of issues that they would need to respond to, things of that nature. It's good to have that already in place. You can also knock out some illegal issues if there's non-disclosure agreements or something that need to be signed and all those signs beforehand and ready to go. A lot of organizations, especially if they're large enough, will use both the user internal IR team and the user external consultancy team. In addition to team prep, you want to make sure that you have in your incident policies and playbooks already built. You want to make sure you understand what your business continuity plans are, your escalation policies in terms of when do you escalate from just a SOC analyst to SOC management to your security management to your board of executives, things like that. If it's a small issue you've made, you keep it within your security departments but if it gets to business disrupting activities, you should probably notify your board of directors and things of that nature. That'll be defined in your escalation policies. Long through recovery procedures, in addition to having these plans and policies in place, you need to practice them. A lot of times, what will happen here is you'll write up, say, we talked about playbooks earlier with security and you remember that playbook, you'll have your playbook written up for a specific type of attack and then you can practice this by saying, okay, we've detected malware that's beaconing to an external C2 host, what do we do? Then we follow playbook and we identify during this practice if a plan works and if it doesn't work we know, where can we fix it. This is how you would blow up these playbooks. Generally speaking. You're going to have a lot of playbooks by the time you're going to build without. It's very important, just like when we talked about identifying the assistant network and knowing what normal looks like. It's very important to have a solid preparation for incident response. You want to have a good basis of what to do in case something happens. Because when something does happen, and it will happen especially if you're in a larger organization, larger organizations do have security incidents guaranteed. The severity of the security instance is what's in question. It's important to have a good plan because when the security incidence do happen, things are going to be stressful, you're going to have to move quickly and you don't have time, you don't want to waste time trying to build these processes in. You'll want to figure out who it is that you need to call during an incident, you want to already have that plan result. The first real phase of an incident after we've already in our progress done, long freeness may happen hopefully. Here's our identification phase. During this phase, the SOC is notified of suspicious activity via security ticket or an alert from NSM tool or some IDS or IPS, some tools SOC utilizes. It is not always clear at first whether a breach or other security incident has occurred. When determining whether a security incident has occurred, organizations should look at when the event happened, how it was discovered, and who discovered the breach. Organizations should also consider how the incident will impact operations, if other areas have been impacted, and the scope of the compromise. Then once the incident has been verified a handler should be assigned and a log of all actions should be started. If you remember back to our SIM, the SIM we get a lot of alerts for someone attempting to use a local admin account on the system. The alerts pop up, a SOC analyst goes to analyze the alerts to verify if it's an issue or not. Also verification they go, oh, there is no user on that machine, we think this is an actual attack. Then one would look and say, well , how do we discover this? Well, our IDS saw it, it was reported to us on SIM, it's happening as we're in a situation. We believe that it only affects this local host. Then they're going to start trying to work out at this point also maybe how it happened. Sometimes, that prints its processing power gap, they will happen later but for now, they're going to want to try and identify what is happening. If it's a piece of malware, for instance, they're going to want to maybe get a signature for it. If they can't, it will stay as it is. That way they can identify the scope. If they can get a malware signature, then they can run that signature across all of their host with their IDS and say, does any other file on any other hosts have a file signature that matches this one? If the answer is yes, we can see what the scope is, we can see what other areas may have been compromised by the type of asset. If it's a mail server or something along those lines that's talking to all the hosts on your network, then the scope of the compromise might be quite large because it may have spread to other hosts on the network already. Once you've verified that it's an incident, is an actual incident that needs to be escalated into an incident response scenario, a formal incident handler should be assigned. Instead of just SOC analysts handling alerts as they come into their queue, a formal person should be identified and handle and resolve this incident less than it's escalated and things of that nature. Once they've signed, they should also initiate a log. The log is going to have all the details. When did the first alerts come in? What are the actions that the incident responders are taking? Who was involved? They should be as detailed as possible. The third phase is incident response containment. Once a threat has been identified, the incident response team, the IR team, should work to contain the threat to prevent further damage to other systems and organizations at large. It's during this phase that the responder quickly isolates any infected machine and works on backing up any critical data on an infected system, if possible. Next, a temporary fix should be implemented on an infected machine to prevent the threat from escalating. The goal is to limit the number of systems compromised during this phase. This is what we were talking about previously with identifying the signature and then beginning to scan across your network frame where also that signature may appear. There are other techniques that you could use during this phase. What we're talking about here though when we isolated is if we can isolate this network communication with other host, then we're going to try and limit its capability to spread to other systems. Now the trick here though is we have the isolated from the host but we still need to be able to connect to it as incident responders to fix the issue. There's a lot of tricks you can do there, generally speaking, though the incident responders will serve network routing procedures that only allow them to talk to it or they'll sandbox the environment and something along those lines. What you don't want to do is turn the machine off. If you turn the machine off you're in a high risk of losing any forensics evidence that you have of the incident because you may lose memory and if malware, for instance, is running in memory, that would be lost. You don't want to turn your machine off. The real specifics on how you want to cut it off are going to depend on your organization and the assets available. Sometimes people will want to keep network communications open to the Internet, for instance, that way, if it's a piece of malware that is beaconing externally, they can then monitor where it's attempting to beacon to, whereas if they cut it off, maybe the malware has kill switch or something like that and once it detects it's not connected to the Internet, it begins to change itself. You want to try and back up critical data if you can. You have to be careful during this phase in order not to back up the malware itself. You'll need to identify what it is first and where it's at and how it operates if we start backing it up. Hopefully, you already have critical data backed up higher to an inset. The reason being for that is you want to be able to do clean re-install and re-emerges if you can if it's something that you'll need to do after you investigate the system. Then two, nowadays the number one security incident that has happened in to organizations is ransomware attacks. Ransomware attacks, once they get onto a system, they encrypt all the data on the system making it unrecoverable to the system owners or the organization and the organization either pays a fee or sometimes it's just destructive and there is no unlock mechanism. Ransomware is not a big deal if you have good backups. However, if you do not have good backups, it is completely devastating to an organization. The goal during the contaminant phase is to reduce the scope and the impact of that incident. Something else to keep in mind here is an organization is on the clock up until this containment phase. As quickly as possible, they need to be able to up into the recovery phase depending on the scenario but as quickly as possible, they need to identify and contain the attack, the incident as they can. Ideally, 10 minutes it would be top speed if you can do that but within an hour or a couple hours depending on the scenario. If this is taking you days and weeks to do, then there's a lot of room for improvement most likely within your organization. The problem with this timeline is that it's going to be in direct competition depending on your setup. If your only response team is external consultants and the external consultants have to travel to your location to do incident response, that immediately is going to widen the amount of time that you need to contain the issue. It's all stuff to consider when you develop your IRP is your incident response plans. Our fourth base, eradication. Once the threat has been sufficiently contained, the IR team should work to implement a more permanent fix. This might include patching hardware, reconfiguring systems and application architecture, or rebuilding systems for production. The goal is to eliminate the entry points that the threat actor used to obtain access to the network. During the eradication phase, the IR team should also be documenting all actions required to eradicate the threat. In addition, any defenses in the network should be improved so that the same incident doesn't occur again. If we think back to our, probably management aspect, if the incident was the results of a vulnerability or missing patch on our system, we would patch it at this point. If it was the result of bad firewall rules, we would appeal those firewall rules. We would do everything that we can to remove from the system if it's just deleting the application, if we need to completely re-image the system, we can have those go back, so we've gotten a place to re-image a system and once we've identified it, contained it, got all the information about it we need to get, we want to make sure that it's not our system anymore. This can be hard to do and so a lot of places will just re-image their systems because it's the most guaranteed way to try to ensure that you've got it out of your machines in whatever the incident it is with malware or something. Phase recovery. At the recovery stage, any production systems affected by a threat will be brought back online. This includes any data recovery or restoration efforts that need to take place as well. The IR team will need to decide when operations will be restored, test and verify that infected systems are fully restored and continue to monitor for malicious activity and validate recovery. Vulnerabilities are remediated, compromised accounts have passwords changed or are removed altogether and replaced with other more secure methods of access. Functionality is tested in day-to-day business resumes. We talked about taking these good backups. Maybe you would have your backups then you would wipe the system, that'd be the eradication part and then in the recovery phase, this is where we're actually going to re-image the system from our good backups. We would write IoCs or whatever the incident was, we would push those apps all over our NSM products to make sure the IoCs are detected everywhere on the network that they can be. Once our images are restored to our systems, we verified that our systems are up and running and are doing what their business needs are. If there's any passwords that were compromised, if someone's user account was compromised, you have interfered the count, if there was something like a web login that was compromised, maybe you look at rolling out two-factor authentication, some way to harden these areas that are compromised. But the idea here is to get back to business as quick as possible. It's two timelines. We talked about that first-timeline which was time to containment and then our second time here is time to recover. Our TTR. TTR is a big goal for businesses depend on the situation. This from a business level is what we would usually monitor. Timely containment is important for security in terms of spread, we want to reduce the impact as much as possible but business timeline recovery is a metric feel a lot of businesses use to measure things like downtime. You want to be able to recover as quick as possible. The skill that you need to recovery is obviously going to depend on the scope or the impact of the incident itself. In the case of an incident, these middle four phases, identification containment, eradication, recovery, these are all in a race, you want to move as fast so you can move, while still doing everything that you need to do and in the correct way to do it. You don't want to make any mistakes. You don't want to miss anything, you don't want to mess up your log streaming like that, we need to move quickly and smoothly. In order to do that, you need to have solid preparation. Then the sixth phase here is lessons learned. In this sixth phase, we're going to take all documents that are logs and all of the processes that we use during the incident response process from last five phases. We're going to finalize those documents, we'll put a report together, we'll submit those reports, we'll debrief various teams and business management on what the incident was if it's necessary. Then we're going to look for places within that process that we just went through that we can improve. Here, we're not attempting to improve the specific protections around what the vulnerability was, we're looking to improve our incident response procedure. Maybe we found that our escalation policies weren't thorough enough to move rapidly enough to give us a clearance that we needed to continue on to the next phase. Maybe we want to adjust our escalation policies or maybe we found that our SIM wasn't reporting fast enough or our IDS coverage wasn't enough. These are the things that we would as SOC look to improve. It's during the eradication recovery phase that we look to fix the issues that were with the incident itself, vulnerabilities, and what have you and inserting the lessons learned that we look to improve our SOC capabilities. Then we'll meet and conduct a debrief on that report with business stakeholders. We'll recommend any improvements in the IR process and how the threat can be contained and eradicated in the future. Now that's a lightning-fast talk about incident response. Obviously, each one of these phases has a huge amount of tools that you can use and a lot of skills and techniques There's forensics and analysts involved, there's a lot of very deep technical things learned here, you can spend a lot of time learning it. It's the bread and butter of the SOC. The SOC area has two major functions that they can do. They're going to monitor for suspicious activity and then they're going to respond to suspicious activity or incidents. Those are committed to big thing. This instance response section will be a huge amount of your day-to-day task as a SOC analyst. Our next section we're going to talk about course conclusions and final comments.
