Now we're going to jump right into investigations. Pretty much answered the questions of who, when, what and where. One of the things that we want to establish right off the bat here is you really don't want to try to isolate investigation to any one phase or even in between any two phases. You want to make sure that you understand that when we talk about investigation incident response, investigation is really a process or something that's going on possibly throughout the entire response effort. It could extend beyond different phases like containment and eradication and it's usually done to answer questions from the business. This may be questions that are on the fly generated by the business, or it may be questions that are just answered as part of your normal IR response effort. You know, you have your questions in your IR response that may be just being part of our being answered here. One of the common questions that you're going to see is what was accessed. It's very common. It's usually one of the first questions that upper management wants to know, because in the back of their minds they are thinking about what were the bad people in here looking for? What did they take and that is all precluded by what they accessed. This can also be helpful in eradication. As you start to look at how are you going to eradicate, what things are going to be when you get to that point, and how you're going to do your checks to make sure that you did. For example, if you think about the fact that if you know that you're compromised by an APT group that specializes in accessing financial data, then, you're pretty safe to at least start off with the hypotheses that most of the access attempts are going to be places where you might have financial data because they would have been looking for that. Now, that's not the same Schegloff and assume that that's all they went after but if you know that that's an APT and you know that that's what they're MO is, then you're pretty safe, at least forming a few hypotheses based on that theory and that will help you to figure out a lot of what was accessed. What is the root cause? This question may not be answered right away. Understand this is one of the biggest misconceptions I see what people new to answer response is understand that even though we say that we want you to try to establish root cause in the containment and eradication phases, somewhere in there is usually a good place to establish what root-causes is. But just understand that it's not guaranteed that that's going to necessarily happen. Or at least root cause to the quantitative level. We might say all well it looks like it was definitely a phishing attack from someone in engineering versus it was exactly this machine that someone clicked on a link. You may not get that granular of an answer right away. Understand that and know that you can't really hold up the progress of moving through your response phases, being hung up on detailed root cause analysis. Some organizations have went through entire data breaches completely, contain the incident and close it out and they didn't establish root cause until well after the incident was long over because that is the way to data film. Don't be afraid of that. Of course, you want to establish root cause as soon as you possibly can in the incident, but just understand that that's not always going to happen right away. You also want to know what devices and resources are involved in the Data Breach. This has going to have a lot to do with who you end up having to brief. It's also going to have a lot to where you might have to get cooperation as far as handling the incident. Another important part is the investigation data sources. Like if you think about it, host logs, network logs, infrastructure logs, Cloud service provider logs, these are all going to be valuable data sources. One that's often overlooked is just the ones that you get from interviewing people. If you know, for example, that a data breach happened because of a phishing attack in the administrative department where an admin worker clicked on a link or something like that, then talking to those people in that department or that person could be very valuable in helping you to structure and not just root cause, but other things like how long the compromise has been about, because maybe that person clicked on that link months ago and they just didn't notice it until an incident got kicked off. Collect the drive images, memory damps, packet captures. These are all going to be valuable data sources that you would have to pull data from in your investigation. Now, one thing you want to be careful with here is, and we'll talk about this again. Is you want to make sure that in your investigative process, you're not stepping on the toes and impeding progress from the other parts of the phases that may be going forward like you don't want to in the effort of investigation stop the entire response process. You have to be conscious of the fact that you probably going to be working in parallel with others who may be working on trying to close out that sentiment. Also don't leave out the Cloud service providers as a possible place for getting data sources. For some of you, most of your data sources are going to come from the Cloud service provider or the Cloud Service Provider environment because some of you are migrated almost a 100 percent or some of even a 100 percent to Cloud service providers or to being a Cloud enabled organization. With that being said, you should be conscious of the fact that a lot of your investigative data is going to come from there. You're not going to be able to go necessarily to an admin and have them physically let you plug into a server or something like that. The last thing I want to talk about is actually sharing your findings or knowing where and how to share your findings. Keep in mind that you're dealing with highly confidential or in some cases, classified information here if you're in that type of environment. You want to be really careful in how you go about sharing this information. You want to have a pre-established communication path for how you get the information from your data collection to who you're trying to share it with. You also want to make sure that you don't let this interfere or stop other incident response processes or procedures and one of the most important things is you need to make sure that as you share these findings, when you're writing that investigative report, that your tone and the way that you position and present the findings is appropriate to whoever the audiences are that you're getting ready to present this to. If you remember those things that will definitely help you button up some of the loose ends that you have in your already establishments in response procedures specifically towards investigations. Thank you for listening to this specific skills path on investigations. Hope to see you again and another one.
