CompTIA CYSA+ CS0-002 – Eradication, Recovery, and Post-incident Actions Part 2

5. Recovery Actions (OBJ 4.2)

Recovery actions. In this lesson, we are going to talk about the four main types of recovery actions. These include things like patching, permissions, logging, and system hardening. When we talk about patching, this involves installing a set of changes to a computer program or it’s supporting data that’s designed to update it, fix it, and improve it. Now, when we deal with patching, this is something that is commonly done in our organizations. One of the most common mantras inside of it is scan, patch, scan. And what that means is we’re going to scan our network for vulnerabilities. We’re going to find all those things that are unpatched and patch them. That means getting all those security updates in place, and then we’re going to scan again to make sure that all those patches actually took place.

This is actually a big problem because when you push out a patch to thousands of computers across your network, there’s a chance that a couple of them may not have installed that patch correctly. And so if you don’t scan again afterwards to find out if that patch was actually successfully installed, this can be a big issue for you. Additionally, if you’re dealing with something that wasn’t a zero day attack, that means there was probably a patch available for it. And so if somebody got into your system, it’s most likely because you didn’t have a patch applied to that system. And so patching is the number one thing we have to think about inside of recovery after we patch that system. We also want to make sure we look at our different mitigating controls and our different processes to figure out why that patch wasn’t already installed.

The second thing we want to think about is permissions. There are all types of permissions that need to be reviewed and reinforced after an incident. For example, one of the most common things that people will do is have a mass password change. They’ll ask everybody to go forward and change their passwords. Now, this is a good security practice because those passwords may have been compromised as part of the breach. But it’s also something dangerous because every time you have people change their passwords, a lot of people will simply write down their passwords and that gives another intrusion vector that is possible for somebody to steal their password and be able to use it to log into the systems.

In addition to that, you also want to check your firewall ACLs and your different file systems and system privileges to make sure all of those permissions are set properly and make sure that people aren’t getting into your network by using incorrect permissions. The third area is logging. One of the things we want to do is verify the logging of our communication to our security monitoring hardware. This ensures that the scanning and monitoring and log retrieval systems are all functioning properly following the incident. A lot of times when a bad guy gets into your network, they will turn off the logging capabilities and you want to make sure all that stuff is back on because that’s important for you to be able to hunt down those attackers and detect future attacks as things move forward.

In addition to that, you want to make sure that your logs are all being audited and looked at to make sure they haven’t been modified by an attacker and that you’re ready to be able to analyze them again. The fourth recovery action we have is system hardening and this one is also very important. System hardening is the process of securing a systems configuration and settings to reduce it vulnerabilities and the possibility of being compromised. As we’re dealing with system hardening, we’re going to make sure that we are doing it because hardening is one of the most effective things we can do as a preventative measure when designing our system security. We want to make sure we’re doing all this before there’s an incident, but if we have an incident that means we must have missed something.

And so now it’s important to go back and harden again. Now, when you start dealing with all of these things, what are the kind of actions that you need to be performing when conducting system hardening? Well, there’s a lot of them. We can start out by deactivating unnecessary components. If there’s hardware or software or network ports or operating system processes and services or any applications that you’re not using, go ahead and turn them off and disable them. Something that is there and open or installed can be a vulnerability. So if you don’t need it, go ahead and remove it. The second thing, we want to disable any unused user accounts. Again, this is a vulnerable area for us. If we have default system accounts like Guest or Admin, those should be disabled if nobody’s using them.

Every account that’s there on your system is a potential intrusion vector. So we want to make sure we’re disabling anything that’s not being used. And this goes for your user accounts as well. If you have a user who’s been away for more than 30 days, go ahead and disable that account. When they come back, you can turn it back on. Our third thing we want to think about is how we’re going to implement patch management. Again, I mentioned this before, part of system hardening is patching bugs. And so if we have a good patching program in place, we want to make sure patch management is part of that throughout all of our systems as part of a good vulnerability mitigation program with our systems.

Our fourth thing we want to consider is how we’re going to restrict host access to different peripherals. How are we going to make sure that people aren’t using USB or Bluetooth as an attack vector. This again is something we need to think about and if we don’t need those things for a business case, we can go ahead and disable them. Going back to our first step, right? Deactivating unnecessary components. Our fifth and final thing we want to consider is how we’re going to restrict shell commands. Now, shell commands are issued through the command shell, and these should be disabled for most users on your system, except your administrators.

If nobody has a valid business case of why they need command line access, go ahead and shut that down. That’s just one more attack vector that we can harden and shut down and keep away from the attackers. Now, to summarize all of this, I really have three simple mottos for system hardening. And if you keep these in mind during your exam, you’re going to do well, because you can always think, should I get rid of this? Should I block this? Should I use this mitigation? And if it’s one of these three mottos, you probably should. The first one is uninstall anything you aren’t using that includes hardware, software, programs, anything like that. If you don’t need it, uninstall it, because it’s just an intrusion vector.

Second, if you need it, make sure you patch it frequently. Again, scan, patch, scan. You’re going to scan your network, find the vulnerabilities, patch those vulnerabilities, and then scan again to see what vulnerabilities remain. And finally, my third motto always restrict users to the least privilege. Again, if you can’t turn it off and you can’t patch it, you want to make sure you restrict it and you mitigate that risk. And one of those things is your users. Users do a lot of stupid things in our network works, but if we restrict them to the least privilege, we can limit the damage they can do. So keep those three mottos in mind, and you’ll do well on the exam.

6. Post-Incident Activities (OBJ 4.2)

Post incident activities. Our final phase of an incident response is to conduct our post incident activities. This is going to occur once the attack or immediate threat has been neutralized and the system has been restored to secure operation. So once we’ve done all that, we’re back in business. Everything is hunky dory and we’re back to normal. But there’s still some things we need to do. And this is where post incident activity comes into play. We’re going to analyze the incident and responses to identify whether the procedures or systems could have been improved. Now, as part of our post incident activities, we have three main areas that we’re going to consider in this lesson. We have report writing, incident summary reports, and evidence retention.

First, let’s talk about report writing. Report writing is an essential analyst skill and it’s used to communicate information about the incident to a wide variety of stakeholders. Now, when you’re making these reports, you want to make sure you’re clearly marking them for the intended audience because depending on who you’re writing it for, that is either going to have different classification levels or different audiences who have different needs. For example, if I work for the government and I’m talking about something that happened on a top secret system, that report needs to be marked top secret to make sure only cleared people can read that report.

Additionally, if I’m in a business organization, I might write a report for the technical audience and one for leadership. And those are going to be very different reports. When I write one for my senior leadership, I’m going to create an executive summary. This is a shorter report that has different sections on it for things like our problem statement, our observations, our conclusions, and our recommendations. Inside this executive summary, it uses, usually it’s just going to be a handful of pages. These are going to have a lot of charts and graphs in there. They’re going to have a lot of bullets that bring out the key information because they don’t need all the technical details of the incident.

They need to know what was the business impact and how can we prevent this from happening again. Generally, if you have an incident, you have some kind of a deficiency, right? Somebody was able to break into your systems. So in your executive summary you should tell them how they broke in and what you need to stop that from happening again. That may be a higher budget, more people, or some other type of resource that you just don’t have. And so asking for those things as part of your executive summary is an important thing to do. Next, we have an Incident summary Report, and this is a report written for a specific audience with key information about the incident for their use.

Now, these incident summary reports are going to contain information about how the incident occurred, how it could have been prevented in the future. The impact and damage on the systems and any lessons learned. Now, I know this sounds a lot like the executive summary I just mentioned, so what’s the difference? Well, the executive summary is one type of incident summary report, but there’s many others. For instance, if you’re working with public relations, you’re going to have to write a report for them with the key details they need to be able to really set to the media and the public at large. That would be one incident summary report.

Now, if I’m working with the system administrators on how they can prevent this from happening in the future, I might have a different incident summary report written in a very high tech language so they know all the different configurations that were wrong and what they can do to prevent this in the future. So again, it goes back to knowing who your audience is and getting the right report for the right people. The third thing we need to talk about here is evidence retention. Now, evidence retention is the preservation of evidence based upon the required time period defined by regulations. If there’s a legal or regulatory impact that’s caused by the incident.

For example, if you want to be able to go after the attacker who got into your network and you want to prosecute that person, you’re going to need to retain the evidence. This is important because all of that evidence is going to have to be retained until all the legal actions, including any appeals, have been completed. When you’re dealing with cases where prosecution is desired, you can expect that you’re going to have to retain that evidence for several years. This is a big deal. Now, why is it a big deal? Well, because that retention is going to cost you money, it’s going to cost you resources. And so you have to be able to weigh that as part of your evidence retention.

Now, every organization has the ability to set its own period in their data retention policy. And as you think about your data retention, you are free to set it any way you want. But in some cases, your organization will have additional requirements that are set forth by law. For example, if you’re a publicly traded company, you might fall into the requirements of Sarbanes Oxley here in the United States. Now, in general, most organizations will set a minimum retention period of at least six months. But some of these other laws and regulations may require you to hold that data for several years as part of that law and regulation. So make sure you’re dealing with your legal team as well when you’re developing your data retention policies.

Now, another factor you have to consider is cost. I said it costs a lot of money to retain this evidence. Now, it would be great for us to be able to retain all the data and evidence for an unlimited duration of time, but that is simply not practical. The more stuff you retain, the more hard drive space or server space or cloud storage space you’re going to need. And all of that represents additional cost to your organization. Thankfully, the price of storage continues to decrease exponentially over time. For example, my company uses an online backup solution that provides us with unlimited storage for a fixed annual fee.

Using an offsite storage solution like this can be a great option for you to consider. The other concern with cost occurs when some of your hardware has to be collected as evidence during a response. For example, if one of your servers is collected as evidence for a case headed to prosecution, you may not get it back for two or three years. In this case, you’re going to have to replace that server in order to fully recover your operations. And this could cost you tens of thousands of dollars depending on the scale of your incident. And therefore, it’s important for you to consider that your organization has to address this in their budgeting for a potential incident response in the future.

7. Lessons Learned (OBJ 4.2)

Lessons learned. In this lesson, we are going to talk about lessons learned, which is a key part of your post incident activities. Now, lessons learned are an analysis of the events that can provide us insight into how to improve response processes in the future. The lessons learned process is a formalized method for us to document the things we experienced during the incident. What went right, what went wrong? What could we do better next time? All of these things are things that should be recorded and our internal organizational processes should be improved so that the same issues don’t occur again during the next incident.

For example, maybe the change management board was too slow to approve the security fix that we needed to implement during the incident response as we tried to secure the network. One lesson learned here might be captured as the need for us to decrease the approval times for emergent change requests during an incident. Now, we don’t have to redevelop the change process during the lessons learned session though. We just need to identify what could have been improved. To capture the lessons learned. I recommend you conduct a meeting with the people directly involved with the incident response at various levels of the organization. This will allow you to determine exactly what happened and at what times during that specific incident.

You’ll also want to focus on the relationships within the organization during that response. Was communication up and down the organization effective? How about the documented notification procedures? Were those followed correctly? And if so, did they work? All of these are things you want to capture during your lessons learned. Now, lessons learned meetings can be structured using what we call the six questions. And these are the things you really want to base your meeting around to be able to capture the most data from your teams. First, who is the adversary? Essentially? Was this an insider threat, an external threat, or both? Second, why was the incident conducted? Exactly? What were the motives of the adversary? And what type of assets were they trying to go after? All of this goes to the why, the motive behind it.

Our third thing we’ll look at when did the incident occur? Now this is important because we need to know when did this thing happen? Did it happen during a busy shopping period to happen during the middle of summer? Did it happen overnight? We have to figure that out because that can tell us when we’re being targeted. In addition to that, we might want to figure out when did we detect it? Because if it happened at three in the morning and our people didn’t come to work till eight in the morning and it took them three more hours to figure it out, that was a long time that we didn’t detect this incident. And so these are things you want to think about.

Also, we want to think about where, where did this incident occur? Did it occur inside of a host system or a server or a network segment? What was being affected as part of this? Our fifth thing we want to consider is how, how did the incident occur? What tactics and techniques and procedures did the adversary use? How did they break into the system? Did they have a good knowledge base of their adversary kill chain and know all about your systems and what all your weaknesses were? All of that goes back to how, how did this happen? Which then can tell us how we could stop in the future, right? And then six, what controls could have mitigated it. Now this is important because now that we’ve captured all this information about who and why and when and where and how, we need to think about what, what can we do about it? And that’s a big part of lessons learned.

We identify all these problems and we want to learn the lessons and incorporate those into our future network design. Now another thing I want to point out is that when we are dealing with a lessons learned meaning it is important that we are focused on what we can do better, not who do we blame for this issue. In a lessons learned workshop we are never trying to find blame, only improvements. So I like to pull out my can of blame, remover and remove all blame from the situation. We want to figure out what worked and do more of that. We want to figure out what didn’t work and do less of that. This is what’s important when dealing with a lessons learned meaning we want to provide a culture of safety where your employees feel safe to tell what they think went wrong without being blamed.

They don’t want to be fearful of losing their job here. They want to make sure we all are okay with the fact that something bad happened and now we’re trying to work together to prevent something bad happening again in the future. Now another part of this is we’re going to conduct a report and this is often called an after action report or an AAR or a lessons learned report an LLR. Now this report is going to provide insight into the specific incident and how to improve response processes in the future. You might see here that we actually write a lot of reports as cybersecurity analysts. We talked in the last lesson about our incident summary reports and our executive summaries. Now we’re talking about after action reports and lessons learned reports.

These reports are going to allow us to bring up to light all of those issues that we found inside that working group after the incident so we can solve these things for the long term. Now there are a lot of benefits of using lessons learned and after action reports. These include instant response plan updates, IOC generation and monitoring and change control processes. Now when we talk about instant response plan updates. This is going to be updated based on the lessons learned that we had from the real world. Oftentimes we write up all these plans in theory what we think is going to happen and how we think we will best handle the situation. But then when the rubber meets the road and we actually have an incident and we execute those plans, things go wrong.

So we have those scars and we want to take those scars as lessons learned and incorporate them and modify those plans. I always tell my team I don’t care if we make mistakes, but we just shouldn’t make the same mistakes over and over again. We need to learn from those mistakes, update our plans and processes, and then incorporate those changes into the way we work. Our second thing we want to talk about here is indicators of compromise. One of the things you can generate from your lessons learned is indicators of compromise. If the response team feels that it didn’t receive enough actionable information during an incident, they can also verify that the security monitoring and logging services are up to par.

During the incident, analysts may have developed new filters and query statements, and they have different scripts they’ve created to discover and correlate these different indicators of compromise. The incident response team may be able to detect new or variant Malware code based on that, and they create signatures specifically to identify it. These new detection rules and binary signatures can be added back into your security systems to provide ongoing monitoring as a way to identify these new IOCs you’ve developed based on these lessons learned. And finally, the change control or change management process. We want to use our lessons learned to improve the change control process in our organization.

For example, a lot of organizations are very tightheld in their change management process and this can slow things down well in the middle of an instant response. That can be a really bad thing because if it takes you three weeks to get approval to put a new router or switch on the network, that is going to be way too much time and you’re going to be way too slow to get the aversary out of your network. Instead, you need to have a change management and change control process that can work very fluidly and very rapidly in an agile manner to help you get the changes you need through the system. And lessons learned is a great way to point out issues with your change management process and get those changes back into the process for future iterations. Bye.

• Category: Uncategorized