Welcome back. We're going to be continuing with investigations here and we're going to be looking at digging a little bit deeper into data sources to show you where you might be looking for data and give you an idea of some places to go look. Some common data sources, would obviously be logs as we said in the previous section of host network infrastructure. We talked about people, collected drive images and then Cloud service provider. Let's talk just a little bit more specifically about each one of those. For one, when we say logs, it's not just a matter of just saying okay, we're going to need to get information from logs. Let's go grab logs. You have to understand that in most organizations getting access to some logs like traffic logs, packet logs, even host logs and things like that on really sensitive systems, that access may take some time. It may require special permissions, special sign-up and it just may be a time factor involved in getting you access to logs. A lot of times we're going to need to ask for logs are types of logs that just the very nature of the council logs they are, would take time to get to the logs. It may be the best sources that it may not be. You have to make that decision, when you know case it is. Some would be very sensitive, so you have to be understand that you may have to go through the process of being read in to be able to view or have access to certain types of logs.You might not have that access by default and consider privacy. Some of the data that we may be collecting could impose on people's privacy depending on the type of environment you work in and whether or not they're doing, it's during lunch when they're looking at their personal emails and stuff like that. Maybe the public Wi-Fi was involved. All of these are things that you have to consider when you're requesting these log sources. It may not be something that you can just go out and grab. When it comes to people, as we said, interviewing is becoming more common because if you leave it to an end-user a lot of times to try to email your description, a lot of times you just need to actually let them walk you through what happened because have you ever heard an end-user trying to describe to you what a click button is. They might say things like the little clicky thing, but for you to have a visual reference of what it is they're talking about, will definitely make a huge difference. Most end-users, if you ask them what a systray is, they don't know what that is. You will need to have some type of interview logs times to get a real idea of what happened. Did they actually click on something to launch the phishing attack? Or was it just a matter of them visiting a specific site, because that can be come to completely different compromises. You also want to make sure you're conscious of employee time and commitments. Consider the fidelity of information gathered during interviews. Also, you want to make sure that, when we do these types of interviews in real incidence, it requires us to go through a process of scheduling meetings just like you would schedule any other type of meeting. So don't expect that just because you're working on an incident, you just going to be able to go in, like some sharpshooter and just start pulling people out of their day-to-day jobs to sit down and help you respond to this incident. If does not work like that in real life. If it's a really critical incident, you're going to get some acceleration and you probably going to get more quick cooperation when people than if it weren't, but just be prepared for the fact that you might have to go through the process of scheduled these meetings as if it were just any other type of meeting, but you want to make sure that it's, the most important thing is that you get the right people and you get those data sources from the right people, then that's more important than how fast you get them usually. Now you also want to understand that, you can't retrieve same as raw data when you're talking people because of the fact raw data is something that does not have the influence of human opinion and human emotion and all these different things. You can't treat data sources from people like interviews. You can't treat that as raw data. This is what we mean too, by associating the fidelity there. So you want to make sure that you take it with a grain of salt as my father used to say. The data source, if it's drive images or memory drives. A lot of times when we're talking about lab breaches, if it's a lab hacker, if it's a hacker data breach, it's ongoing right now, often times you're going to find that your best data source or your best source of data for that breach would be in memory. For that reason, we always encourage you to follow the order of volatility, which usually means memory first. Don't forget sensitivity of memory and drive images because in memory, there could be very sensitive things that you quite frankly may not even have the need to know to see. You might be if you want to make it into a classification, then you might be have a classification at one level, but you go in and do an investigation on machine and you find out that maybe that machine has a reference to something in memory that's classified as a different level because maybe, someone that's high-ranking made a mistake and typed something in there, do they weren't supposed to type something like that. These are all things we consider. You also want to maintain access logs and chain of custody. Even though we said earlier in this skills path and we're talking about background, that generally speaking, when incident response. Something being admissible in court or trying someone in court is usually not the primary consideration. You still want to consider the fact that it could end up in court. In secondly and more importantly actually, you want to understand and remember that as you're collecting this data, you definitely want to maintain a record of who has access to it, even if it's not original evidence, just copies of it. Because as things start to get a handle or as things start to leak or as information starts to leak to the press and all that type of stuff, you're going to want a good chain of custody or good field on who had access to this information if you're trying to trace down leaks and that type of thing. Remember, always don't interfere. Would the overall incident response process as you collected this data. More frequently in an investigation, we're seeing that we're going to go to Cloud service providers and you really want to treat them like a valued partner because look at, let me just explain something. You got to think that these Cloud service providers, they have incidents, they have situations or where they have this would incidents, they get called on all the time. They develop most of them, at least the ones that I work with and I work with 300 bigger ones on a regular basis. They have developed quite a tool chest of things that they can use on the back in to assist you when you're trying to close out an incident or something like that. Treat them as value part and partner, make them feel that way. Make sure you reach out often, even if you can schedule meetings would have representative from your Cloud service provider, pre-incident before there's an incident or in between the incidents to can establish these communications and establish what it may be able to help you may not be. Often, it will help in establishing root-causes I alluded to earlier. Sometimes the incidence will actually show surface first in your Cloud environment, especially as you start to move more and more of your stuff there. In some cases, Cloud service providers actually office incident response services, depending on what type of incident it is. For this one, we did do a summary basically standard where the incident response team, asked many questions, parts lots of data and you want to make sure you treat everything is sensitive, even if you don't know it is. That's because you don't want the fact the point is you don't know. If you treat everything as it's sensitive, if something turns out to be sensitive, you're covered. If you treat everything as if it's not sensitive and you just start doing your incident response heroics here. You find out later something is sensitive and you treated that way. That could be a big problem. You might be the cause of a new incident. None of us want that to happen as incident remponders. Also, you want to document any locations of any findings and how you access the data. A lot of times investigative really end up helping to uncover on new indicators of compromise. Keep that in mind and hopefully you enjoyed this session and feel free to reach out and go back and review the others as it ties into this
