Detection and validation of network security incidents

- Do you know how to detect and validate a network security incident? If not, well, stick around. - [Announcer] You're watching IT Pro TV. (gentle music) - Welcome back to the ECIH series here at IT pro TV. And today we are talking more about network incidents, that's right. We need to be able to detect and validate that a network incident is actually occurring. Of course, helping us out today is going to be Adam. Adam we're so glad you're with us because it does seem like it would be important for us to be able not only to detect, but to validate that an actual network incident is occurring seems a skillset that might be important for somebody that's wanting to become an incident handler. So let's start there if we could, with how do we actually do that, if you could. - Absolutely. So, you know, when we think about how we can detect and ultimately understand, as Daniel is suggesting it's very important for us, that there is something happening, in other words, detect and validate, right, that there is a network security incident. By the way, may have already happened, maybe happening, maybe about to happen, we could see early warning signs, right, lead versus lag indicators. We want to think about those but ultimately, whether it is currently going on, about to become an issue for us, or it's already happened and we're seeing evidence of it after the fact, how do we do that and what are really the things that we have to understand and know about? It's a very important question. Join me here let's talk about a couple of things that are going to be helpful to frame this conversation as we think about answering Daniel's question. Incident responders, members of our IH&R teams need to be able to understand suspicious... (Daniel laughing) suspicious events when they see them or when they're made aware of them. Now, not every suspicious event represents an attack. We do want to be clear about this. But it's more likely that it is something that is going to present a problem so we want to make sure we pay attention. But for every suspicious event, there has to be a story that definitively tells us what is behind that event or it has to remain a point of contention for us in a point of focus until we can tell that story. How do we tell that story? We root cause analyze ultimately, continuously asking questions, examining, right, discovering, containing, ultimately eradicating, all things we've talked about time and again throughout our course across multiple topic areas become important but we have to make sure that we are asking the right questions, we are analyzing, we're reading the tea leaves, looking at that evidence, talking to various people, right? Victims, users, employees, et cetera getting a complete picture, and then deciding hopefully with enough evidence to make a valid from our perspective assessment we want to then decide whether this is worth pursuing. We should also include and look at monitoring across various systems, logs become very important here. I've talked time and again with you about the value of logging, not just on systems we think are most likely going to be attacked but across the entire operational landscape because the reality is if I'm attacking a system, you better believe I'm going to create diversions in other areas and maybe even launch that attack from a different system so I cover my tracks and don't make it obvious that I really wanted the file server. I may touch 10 or 12 boxes using automated scripts and a variety of techniques so that you have to figure out which of those 12 was really my target. If I damage all of them, but really only want to get one it's going to be a lot more difficult for the IH&R team to tell that story definitively and unravel that mystery. And as a result, I may have time to get away, right, as a result of hiding and obfuscating my true intentions. So when we think about validating, detecting and validating network security incidents, we really have to think about being able to separate out the false positives. You've probably used this term before, and focus on the warning signs that are valid that really help us to understand the true intent in nature, the direction, the focus, the ultimate goal of what that root cause is that's at the heart of that attack. That's our job, that's what we need to do. - Adam, this seems like it's going to be one of the the bigger lifts when it comes to incident handling, incident response, because there's a lot of moving parts when it comes to networks, right? Nuts and bolts all over the place. So I feel like this is probably going to be a large swath of tools and tactics, techniques that we are going to use to try to get into doing this. Could you give us at least, start to give us a list of things that would walk us down some of those tactics or tools. - Absolutely. And Daniel's right. There's going to be a very large number of them more so by the way, as he already told us but let's be clear, then we can cover in a single episode. That's why we have detailed episode or show notes for everyone of our discussions. Remind you from time to time to go take a look at those, a lot more depth there. In this case, there's going to be command line, switches and details that you're going to want to know for the exam that I can't necessarily cover on one or more area of our discussion, but we're also going to remind you as we do in some other areas. So we have some hands on episodes towards the end of the course to drill down on some of the tools, the techniques, things that are going to be important for the exam, you want to check those out as well. Those are going to be beneficial. Let's begin answering Daniel's question by talking about how we monitor network traffic. What are some of the things we want to do there? We want to focus on both incoming and outgoing traffic that by directional flow, you often hear me referring to when I can say it correctly, ingress and egress traffic because stories are not told from one direction or one perspective only, we need both perspectives, both directions to completely understand root cause. Tools can record IP/Mac addresses, time and date of access, protocols used, ports, types of connections, the list goes on depending on the tools we choose and there are many standard tools, many specific specialized tools, right? But whatever tools we use and there's a sampling of some of them specifically because Daniel said, "Hey, there's a lot of tools, what would be some," I've included some in a few of our discussion areas so you can see or begin to see what they may look like, you may even recognize some of these tools. Wireshark for instance, pretty popular tool. By the way, a hint and a half for you, probably one you want to be familiar with for the exam. But whatever tools we use, these are pretty standard information items that any and all of these tools will help us to capture whether it's a network analyzer like wireshark, whether it is a wireless or wired network analyzer, we'll talk about some of those cool tools like Cain & Abel for instance, and many others that exist. Whatever it is, we want a tool that is going to vacuum up information and then allow us to delve into it at whatever appropriate depth we figure is going to be appropriate for us based on the kind of information we want to find. But if we don't capture that traffic, we don't have a record of it, there's nothing for us to examine. So the most important thing we can do is make sure we're capturing any and all traffic coming and going at key choke points, right, ingress and egress gateways are typically where we do our monitoring. And then within the organization, if we have certain subnets or VLANs that are highly specific, need to be protected and are isolated for those reasons probably want to throw a monitor there as well because that's likely where the attacker is heading. And we want to find an evidentiary trace of their path and figure out where they came from and where they're going to coz maybe we can find them and stop them before they do harm. Pick up on the tools that we specify as we go through these discussions these are likely going to be tools that are asked about on the exam. You want to group them with the appropriate kind of activity so you understand what they're used for. It's going to be very important. So this is one, right? - Yes. - One set of tools, one activity monitoring network traffic but we've got lots of them, right? It's not just monitoring network traffic, it's a lot of other stuff as well. So can I throw another one up? - Hit me with it. I can't wait actually, I love this. - Let's put another one. Continue to tell me that story for Daniel. Let's give him some more information, give you some more information. What about sniffing network traffic? I just talked about monitoring it. A lot of people say, well, monitoring, sniffing, isn't that really the same thing? I mean they sound very similar, right? Monitoring is about paying attention to what's going on, looking at that traffic flow, maybe having certain filters or alert thresholds that we set, right? Sniffing, it's a little bit different, right? We're recording that traffic. Some people call sniffing eaves dropping, it really depends on your perspective, I suppose, right? But a lot of times bad actors are not going to be monitoring out in the open, they're going to be trying to hide their activity while they're recording what's going on so they can understand the impact they're having and also maybe uncover opportunistic targets that they may not be aware of that they want to go after. So sniffing is really the idea of capturing traffic but doing so in a stealthy way. Why would the IH&R team, why would the incident handlers, people that are the good people, right, that are out, they're fighting the good fight, why would they want to be scocking around and hiding in dark areas and sniffing? Well, because this is what bad actors do. Who better to learn, how to live off the land and find the bad actors than the people that understand their mindset. This is why we need to train, this is why we need to understand how our adversaries are going to act and why we need to pay attention to those systems and tools and techniques, extracting complete data packets and storing them on a system for analysis. By doing this, you kind of it surreptitiously, right, by doing it without making a lot of noise about it but gathering as much data as possible. So thereafter they can tell a much more complete story about our network and IH&R team member we could see the whole operational landscape, and probably pick out those unusual traffic flows that those bad actors may be engaging in, again, capturing all, and I capitalize the word, ALL, all the data that passes through the networks, again, reminding you this should include wireless connections. Overlook wireless at your peril, both in the real world and on the exam in particular. Wireshark, by the way is a constant theme through many of these discussions, that's why I said, it's a tool you want to be a aware of but there's some other really good ones in here. They're all good by the way but some ones you hear a lot about, Tcpdump, Cain &Abel, you heard me mention that one, it's been around forever, Kismet a Linux based tool, that's very popular to do a lot of this kind of stuff. And I'm sure if we ask Daniel he's probably used one or more of these. We all have our favorites and we all use different. I happen to love wireshark, I go back with it before it was wireshark back when it was ethereal before it got bought, commercialized and relabeled. But I use another tool called network chemistry. Packertyzer from Network Chemistry. Network Chemistry's the name of the company behind its basically wire shark and it works essentially the same way for the interface. So it's another one surround, it's free as is wire shark, right, you don't have to pay for it but you can't spend money to get additional support and things like that, build your own filters and rule sets. It's very complex and very capable tool. So again, beyond the lookout for tools associated with this but sniffing that network traffic, having that complete picture, archiving and then being able to analyze it in real time or near real time, or historically covers us for things that have not happened yet but may, things that are happening in real time and things that have already happened. We can see evidence of any and all of that as we go back and look. So these are all going to be important. - Yeah. Now another term that's very tightly related to what we've been talking about monitoring and sniffing is packet analysis. Even maybe even use synonymously in certain groups how would we differentiate packet analysis from what we've seen over? - So let's put up performing packet analysis. Let's talk a bit about that. It's a great question. What is the similarity, perhaps similarities, what are the differences or difference. Packet analysis is what we do after we have established our monitoring footholds so we're recording and looking at information in real time, sniffing to capture that data, archive it and potentially go back to it. What do we do then? We actually go in and analyze it, pack it by packet, if necessary, perhaps over a session looking at an entire translated exchange of information over several minutes or who knows how long that particular exchange may take place. It may be several packets, could be hundreds or thousands but we want to delve into each packet, break it open, look at the header, the information about where it's been, where it's going to, what kind of languages and connections we're used to communicate protocols and ports in other words, and we want to look in the middle of that data packet. What's the actual payload, the bits right of the data, as well as at the far end of that packet, which is the trailer. What kind of integrity, CRC, cyclic redundancy checks, check sums, information about whether that data is trustworthy coz it has not been modified or it appears to be trustworthy. But the integrity, the check for whether it's been messed with or not does not come back positive, we know there's something wrong because the data is not the way it should be. So we can glean a tremendous amount of information by looking at individual packets. Now, you may not be familiar with a data packet the way I just described it, broken into three specific parts, the header, the data packet or the frame or the payload it's referred to differently depending on where we're analyzing the data, at what level of dare I say it, the OSI model, Daniel always shutters when I a OSI model, "Oh the cold chill." (both laughing) You don't have to worry about the OSI model for this exam but you should have passing familiarity coz with what it rep exactly. What it represents because it is a multilayer model that helps us to understand functionality of how we process information within a computer we're sending or receiving really should be something that every incident handler has a working familiarity with. But when we break down data into this three compartmentalized thought process or model we put the trailer on the end, we're talking about how we build the data packet that is sent and received through the OSI model. I just want to make sure you understand the logic of that. We use is a term called data encapsulation to understand how we build that structure from the top of the OSI model down right from the uppermost application layer, layer seven all the way down to layer one, the physical layer, we're encapsulating data and we're building out that structure as we go and we de encapsulate as we move data up the model from the physical to the application layer translating it from machine friendly data binary bits of zeros and ones, just, you know, digital data which is what machines speak back to human friendly data. What you see on the screen is human friendly data, right? And data can exist in multiple forms. We want to understand that as an incident handlers as well coz we have to understand the different forms to truly understand the story the data is telling us in any particular moment in time. We search for particular strings, binary structures I just mentioned. The whole logic of this as we encapsulate and de encapsulate packets across the story of the capture packet matrix, we may use hex editors to view the actual raw bits of the packet, things like metadata that may be associated with a file or a specific area of the data but we may not understand because it may not be in a form we can see. Hex editors can translate that and show us that data with a little bit of a work, but they can certainly do that. Cain & Abel, dsniff, ettercap, Network Grep or nGrep as it's usually referred to, OmniPeek, Snoop, TCPdump, again, these are all tools that can do packet analysis in the case of TCPdump it can do sniffing as well as pack analysis. So it does double duty as can Cain & Abel for instance in many of these other tools as well. So when we're thinking about packet analysis, we really thinking about looking at the data to understand the story that's buried, right, kind of contained in those hidden areas of the data. - I would think that going hand in hand with this might also be a log analysis because there's a lot of network traffic that is actually being logged, maybe a network service is letting someone know whether it was sock connection was connected effectively or not, or whether or not someone was able to log in, the different types of services that we have. Is that something we would need to look out for as well? - Why not? Of course, we could always fit another one in and I happen to have it ready. So, so much the better. So let's talk about log now. It's actually a really good way to bring a lot of this to together because you know we've captured the traffic, we've talked about analyzing and breaking down into its individual components, the header, the data packet itself, the payload as we call it, the trailer but as Daniel rightly points out, that's good, Adam, right? That's good stuff but what if that data that we want is on another system somewhere else and we have to look elsewhere to find it. Well logs as you keep hearing us say, is that perfect place, right? So we want to log or have logs, we want to be logging, we want to analyze those logs either manually or with the help of a variety of log analysis tools. We've talked about CIS logging, kind of the newer, modern, sexier cooler version of that, SIM and SIM solutions, many of them cloud based today using artificial intelligence machine learning, data visualization business intelligence capabilities to tell stories that are not human recognizable, meaning we look at data we don't see the pattern, but the system looks at it using all these capabilities and says, "Oh, this is actually related, "and let's put this up so you can see this" understanding and explaining that and applying filters this is important to avoid unnecessary data, right? We don't want to be drowning, right? You've called it analysis paralysis, if I remember correctly. We don't want to drown in a sea of data that is not necessary. We want to swim in a confined small space with data that tells highly compelling and relevant stories and be able to totally understand that story and exclude the stuff that for now, given the context of what we're doing, it's just not relevant. It's going to be very important. - Now, what about the host itself? Is there anything that we need to be analyzing when it comes to that? - I can think of... - One or two things maybe. - Couple of things. I can put something together quickly if you're going to force me to whip something on. (Daniel laughs) Let's talk about host analysis. - You're a wizard, Adam. - I can just make things appear out of nowhere but don't ask any more questions coz this is the last thing I can make appear out of nowhere. - Okay. - So performing a host analysis, really bringing this together, right? Really adding in the final level and layer of detail. This is a great way to end our thought process around all the different places we look things we analyze because this is where it all comes together, right? The host, the endpoint, the thing that we are most likely protecting or responding to coz somebody who is violated and the thing that a bad actor is looking to take away from us is one or more hosts, one or more endpoints, right? Whether it's a mobile device like your phone, it's a fixed asset like a laptop, it's racked and stacked infrastructure that's sitting somewhere in a data center, the end of the day, all of them are hosts. We can do one of two things. Daniel and I have talked about of these approaches in other areas of the course. Static analysis, right? I say, look but do not execute. This is where we examine the code of the malware by de compiling it. We break it open, right? We'll probably use some sort of tool that can open up the actual packaging encapsulation that is surrounding the malware to understand the line by line code, but we're not going to execute this thing coz if we do, we're not quite sure what's going to happen but pretty confident something bad will occur. We look for the PE information, right, the executable information, all that kind of stuff that we talked about. We also talked about dynamic analysis, monitor and execute is what I say here. We want to run this thing, right, we want to be able to see what it does but we want to take safety steps. We want to sandbox and isolate ourselves, ensuring that if we do infect the system, which is a very likely outcome we're not going to infect everything around us. Let's physically cut off the machine, let's contain that safe environment and let's run it there but then let's make sure that we don't allow it to escape. So we want to make sure we understand the difference here between both static and dynamic analysis. - Great stuff, Adam, thanks so much. We are out of time for this episode, but remember we went over how we actually do network analysis and verify that we have a network incident occurring, detect those things and some tools and techniques that will allow us to perform those functions. So very good stuff. Probably need to go over this once or twice just to make sure you got all those in the old noodle but if you're ready to go, then we'll see you in the next episode. That being said, we are out of time. We got more to come in this series and hopefully we'll see you then. Until then have a great day. - Take care, buddy. - [Announcer] Thank you for watching IT Pro TV.