Incident Response Phases Part 1 of 3 - USALearning · Incident Response Phases Part 1 of 3. ... **015 In this case, we're talking about . incident response and how digital ... incident

Incident Response Phases Part 1 of 3

Table of Contents

Incident Response Phases ............................................................................................................... 2

IR Preparation -1 ............................................................................................................................. 3

IR Preparation - 2 ............................................................................................................................ 7

Identification/Detection -1 ........................................................................................................... 10

Identification/Detection -2 ........................................................................................................... 13

Notices .......................................................................................................................................... 18

Page 1 of 18

Incident Response Phases

1515

Incident Response Phases

**015 In this case, we're talking about incident response and how digital forensics gets integrated within it. So, we'll go through the phases of incident response.

Page 2 of 18

IR Preparation -1

16

Incident Response (IR) Plan is a living document that prescribes how the incident response will take place.

• Processes and Procedures• Communication Plan• Measurement metrics

Having a risk assessment and identification of assets in advance of an incident.

Tools and collection media should be prepared in advance.

IR Preparation -1

**016 Okay. So, this preparation, IR preparation, is when you already have a team. having a plan, a solid, well thought out plan, is critical. It's a living document, meaning it should be updated regularly. It should be looked at. Certain things become obsolete. Certain things become more important. You want to be looking for these things. And this is slightly different, but it actually does affect the digital forensics capability or digital forensics team as well, how they will interact

Page 3 of 18

with the incident response. They may actually be a part of the native team. Or they may join up with an incident response team. So, it kind of depends. And sometimes there could be a mish-mash, if you will, if for whatever reason, one incident remote incident response team needs a local digital forensics team. So, that sort of stuff should be decided and documented well within the incident response plan. These processes, the procedures, the communication plans, very, very important. Who gets told about what when things are happening? This should go all the way up to the C suite. We're talking CEO, CIO type folks. When are they notified? Who else do you bring in, legal counsel? Do you bring in HR? Are you talking to those folks as things happen? Sometimes, the communications team-- and I'm talking about the folks who actually interact with-- if you have a company, the people who interact with the mass media. Sometimes, you have to get ahead of this and talk about it if you have a corporation that's big enough and they're publicly traded so this could affect their stock. So, all of that should be part of the incidence response plan. People who are doing this should know where to go and who to speak to. And a measurement of metrics, part of the metrics that we're talking about, how much time, man hours are you spending on doing this cost-

Page 4 of 18

wise. The time can obviously, depending on the average hourly wage, if you will, can be figured that way too. But you're talking about cost for purchasing more things, new equipment, new software, travel. So, all that measurement metrics should be put into the plan so people know going in. When the bell rings, if you will, they know immediately to start keeping track of these specific metrics so they can quantify what it is that's happened and how much it's actually cost the company. And then having a risk assessment ahead of time and identification of assets in advance, this is very important. and I've found, and maybe if you all have dealt with other customers as well, maybe Ty has, a lot of times the people that we deal with do not necessarily know what is the most important within their company. Now, they know their business. But I'm talking about do you know if that server or that server has the most important data on it. If that one gets compromised, and this one doesn't, do you care? And do you know the difference? Would you know? A lot of times they do not know the difference on this. So, doing this risk assessment, it's like what is the most important. What happens when this box gets popped and this one doesn't? Or what if this entire subnet gets hit? Is this the most important? Well, no that's archive of really old historical things. Then you know. And that will

Page 5 of 18

help an incident response team react as well. So, identifying the important assets in advance of any incident, so you know exactly which IPs. When you hear these IP addresses, should you be concerned? You should know that. And this is assuming this is a local team that knows its actual area. If you're a remote team, sometimes that's harder. That's the kind of information gathering that you do when you show up. It's like okay, you've talked about these IPs. What does that mean? Are these important boxes? What are they? Oh, they're infrastructure pieces. They're your routers and your switches. Now, it could be much more important. It might not be as important, depending on how you find out or what you find out. And then of course the tools and collection media should be prepared in advance. This seems again relatively obvious. Ostensibly, it is. But there are many times where somebody borrowed this tool, somebody borrowed this hard drive, and they did not return it. So, staying on top of that on a regular basis should be a part of the incident response plan as well.

Page 6 of 18

IR Preparation - 2

17

Define structure of the IR Team.• Centralized – one team for the organization• Distributed – multiple teams, determined by location or

function

Train members of the IR team for their tasks as well as cross-train in different roles.

Conduct practice events and exercises regularly to prepare and hone skills.

IR Preparation -2

**017 Okay. So, preparation two here is part of the policy and the plan. The structure of the teams should be defined. You could have a centralized team that does everything for the entire organization. Or you could have either mini teams or multiple teams depending on the size of the organization. And depending on their function, or their location, set them up in such a way that it helps the response time and the efficiency of your response team be the best that it can possibly be. We talked about this before, training members on the incident response team for the tasks that they'll be

Page 7 of 18

responsible for and talking about cross training the members so they can do multiple roles if need be because, again, people take leave. People leave. People take jobs, different jobs. So, it's not always the same people that will be doing your incident response. And this is pretty key. Conduct practice events and exercises. You can train and train and train, but having something to validate your training is so, so important. It can show you exactly where there are gaps in your training and what you've thought. Exercising can be simple drills that you throw at particular people. Or it could be a full-fledged exercise, an operational exercise that starts with a compromise or something. And you tabletop it with even people as high as the C suite. And you work your communications channels up and down to see if hey, I assume that Jeffrey was going to do this for me. And then he goes, "No, I assumed I was not." So, you find out all these things when you actually conduct your exercises and you practice. And you practice together as a group. So, I'd like to really emphasize that exercising and practicing. It's a difficult thing to sell, in general, because many of us that are security professionals already know that IT security doesn't make any money. We're the fires extinguishers of the world. They need to have us because we need to be there. But we actually don't make any money for the

Page 8 of 18

operations, unless you are doing managed security type of thing. Okay, yes you're a part of the operations that actually makes the money. But doing it on your own networks and that is different. So, selling, having everybody from your team sit down for half a day or a day, they are losing productivity from you. But that will come back, I think, two times, three times of the time that you're taking time to actually train these folks and put them together as a team. You will get returns on that two and three times over because they know what they're doing when it happens. When the bell rings, it wasn't just me sitting on a machine doing my training. I sat with the people I'm going to work with. And we talked through, we worked through the issues that we needed to. So, I think that's really, really important if you can, for your team, should you set up an incident response capability.

Page 9 of 18

Identification/Detection -1

18

Methods to detect incidents• IDS alarm• Log analysis• Public disclosure or attacker announcement• 3rd party information

Identify and classify incidents completely before invoking IR response

• What type of incident?– PII compromise, DDoS, Insider Threat. . .

Follow the IR plan.

Identification/Detection -1

**018 So-- oh, I'm sorry. Go ahead. Student: I know like our company, they go through disaster recovery tests. Spend lots of money to go through these tests two, three times a year. Instructor: Sure. Student: I can't see-- this is more likely to happen than a DR, like a disaster, I would think. Instructor: Right. That does seem to be the case. But I think the fear of losing everything and-- so it's kind of operations based, if you will. Does

Page 10 of 18

that make sense? I might lose the ability to make money, or I'm going to lose part of my business, even though, like you said, an incident like that is probably more likely to happen. So, in that case, if it's possible, maybe you can inject into that disaster recovery, in addition to that, we found out that this insider threat did these things. And that's kind of the worst of all possible scenarios. You'd rather have it normal ops for everything else. No, the volcano next door did not blow up while our insider stole all our goods also. But if there only doing one exercise a year or two exercises a year, and they're not going to slap a second or third one on there for you just for your, in this case, like an IT incident type of thing, perhaps-- and it doesn't have to be the full-- the most horrible thing in the world. But perhaps in the middle of that chaos might be a decent time to throw a little something like, "Hey, we're having a spear phishing campaign. Could that be the reason that certain things are happening?" It will add to the chaos a little bit, obviously. But certainly if it happens, you've talked about it, you've walked through some of it. So, it may not be a bad time if it's possible to inject a little bit of IT incident response or forensics type of things to happen. Maybe even simulating oh, we lost those two servers, and we've got to pull that data back. Have your data team try to go grab those servers and those hard drives and see how much of the data they can pull back.

Page 11 of 18

And that can be an exercise for them during that time. So, that's a thought. Okay. Identification and detection, this is like the second part. You do the preparation. And you actually go out and you figure out what's going on by doing identifying and detecting. So, you look. Where did this incident-- where was it actually caught? Are we talking about an intrusion detection system or intrusion prevention system, IDS/IPS alarm coming? We're talking about a log. Somebody that was reviewing some logs discovered some stuff that may have happened a little while back. Or, is it public disclosure? This could be a hacktivist group that's sending nasty emails at you. How did you discover things are happening? Or they're bragging. The attacker makes an announcement on the web that we stole all your goods. And they're going to be on Pastebin in twenty-four hours unless you do this thing. So, where did that come from? Third party information, this is generally speaking like if the FBI knocks on your door and says, "Yeah, there's something going on and your information is part of it or it has been compromised already." Obviously, very bad news. So, you want to set levels of response that are commensurate to what's happening. That seems really obvious. But setting it up ahead of time will go a long way so people don't run around like chickens with their head cut off.

Page 12 of 18

For the incidents, what type of incident are we talking about? Are we talking about personally identifiable compromise? Are we talking about a distributed denial of service? Is it an insider threat? So, working to identify, and you classify these incidents, whether you use a level system of say level one, two, or three, your incidence response plan should have that set up in such a way that your team knows exactly what to do for the particular type of incident that happens to come along.

Identification/Detection -2

19

Make an initial determination of what devices or systems are or may be compromised.

• Do we have a hostname or IP address?• What path did traffic likely take to get to the victim?

Detection and identification of the incident is not a single event; as information is learned there may be other systems which are also affected.

Quality documentation in this phase allows correlation of information and further incident analysis.

Identification/Detection -2

**019 Oh, I'm sorry. Go ahead.

Page 13 of 18

Student: Today, are attacks multi- faceted, or increasingly-- do you see multiple incidents, multiple symptoms occurring, but you don't know what the ultimate goal of the attack is? Do we have an idea of what the approach is of attackers? Instructor: Okay so, there's kind of multiple questions in there. So, it takes a good bit of investigating to see if the seven indicators that you get are actually associated because if you're a big enough organization, you may be and probably are targeted by multiple other malicious actors. So, it's kind of difficult to say for sure. And here's something, too. The people I've worked with before and dealt with threat intelligence, and here's what they found. They found that there's malware or exploit reuse amongst the hackers. Meaning, I get on a box. And I look around and go, "Wow, here's a tool I can use. It's already on the box." I don't have to ingress and push something onto the box. I don't' have to leave anything. Somebody else-- or it's already a piece of code that I can adjust for my needs. Point the IP address back to my servers that I want it to do something with. So, there's a lot of low-hanging fruit out there. They're finding that many of the-- so, you would think that in sophistication, everything would just continue to climb. And I'm trying to remember the study on this, but what they were finding was because there was so much low-hanging fruit, people were still using Windows XP,

Page 14 of 18

they're still using IE 8, Internet Explorer 8, or whatever it is, why do I need my zero day super-duper thing, when all I have to do is use Metasploit or some other-- well, maybe not Metasploit directly, but something a little easier? So, all that to say that it kind of just depends. I think the better malicious actors are just extremely hard to find because they just know what they're doing. And they're very careful. They're very meticulous. And my understanding of how they work is that they use time. They're an advanced persistent threat. The persistence is that they can stay there for a week, a month, a year. So, they don't have to do everything at once. They make ingress. They set up a foothold so they can maintain that presence, and then they go away, no log data, no nothing for a while. They come back, they look around a little bit, and they move. They move once. They move twice, whatever their plan is. So, unfortunately, if you have two or three actors like that in your network, and you find evidence from all three of them, it is difficult. Timelines may mishmash. So, that's going to make it difficult as well. I think it would take a very hard and very rigorous forensic look at things and do timestamp correlations. And it would take a lot to actually figure out what it is they're doing I think. It's-- for the folks who don't want to be seen, I think it's very hard to see them.

Page 15 of 18

The folks like hacktivists that want you to know they did something, I think it's more obvious. They're like, "We're hacking your web server. And this is what we're doing," type thing. They don't necessarily talk about their exploits. But you can kind of look where you need to look. So, I'm sorry I said a lot about that. But that's the challenge of all of this, incidence response in general and certainly in digital forensics is that you're finding pieces. And you're trying to put together the story. And then if somebody did something-- another actor did something really close to that same thing, how do you differentiate? You can't exactly call them and ask them, "Were you the one that did this here?" So, it is a very difficult challenge. Initial determination of what devices or systems are, or may be, compromised, what do we have when we talk about this? And this is the team again. We've already established the team. And the team is getting ready to go and do its thing. How much information does it have, does the team have? Are we talking about host name, IP address, a domain? It could be very spotty information and indicator since sometimes you'll get a pretty decent chain of events that has happened. What path did the traffic likely take to get to the victim? And that's where sometimes the email that we just talked about-- sometimes, that's the case. It's relatively obvious. Other times they have what they call

Page 16 of 18

watering hole attacks, which are essentially you have a server that has files that everybody uses. And what you do is you go take one of their forms out of there. And it happens to be a PDF. And there are PDF attacks. Most of them are patched now. But it used to be you could put your piece of malware on that PDF. Now, everybody thinks it's the regular company PDF that they were supposed pull when they were doing this particular thing or this form. And so, you may have a watering hole attack. So, that's a little bit more difficult to figure out how that's getting to you. Detection and identification of incident is not a single event. We just talked about that. We were talking about small slivers of information that you have to piece together with your team. And you learn there may be other systems which are also affected. It's a cycle where you do your initial look at the information, and you slowly work your way out, if you will. You get your initial information. You find out what else has been affected. And you move to those pieces. And then you keep moving out until you find what you're looking for. And hopefully, you can find the ending of this. And then quality documentation in this phase allows correlation of information. That is so true. Being organized a the very beginning of an incident, taking that information, whatever you have, the hosting, the IP address, the domain, etc., and

Page 17 of 18

documenting it in such a way that you can use it, and your team can use it effectively, very important.

Notices

Notices

© 2016 Carnegie Mellon University

This material is distributed by the Software Engineering Institute (SEI) only to course attendees for their own individual study.

Except for the U.S. government purposes described below, this material SHALL NOT be reproduced or used in any other manner without requesting formal permission from the Software Engineering Institute at [email protected].

This material was created in the performance of Federal Government Contract Number FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The U.S. government's rights to use, modify, reproduce, release, perform, display, or disclose this material are restricted by the Rights in Technical Data-Noncommercial Items clauses (DFAR 252-227.7013 and DFAR 252-227.7013 Alternate I) contained in the above identified contract. Any reproduction of this material or portions thereof marked with this legend must also reproduce the disclaimers contained on this slide.

Although the rights granted by contract do not require course attendance to use this material for U.S. government purposes, the SEI recommends attendance to ensure proper understanding.

THE MATERIAL IS PROVIDED ON AN “AS IS” BASIS, AND CARNEGIE MELLON DISCLAIMS ANY AND ALL WARRANTIES, IMPLIED OR OTHERWISE (INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE, RESULTS OBTAINED FROM USE OF THE MATERIAL, MERCHANTABILITY, AND/OR NON-INFRINGEMENT).

CERT ® is a registered mark owned by Carnegie Mellon University.

Page 18 of 18