Let's go ahead and dive into the identification phase of incident response. This is definitely wanted a more critical areas of this and a response because first of all, if you think about it, if you never identify an incident, then you won't know there's an incident and something that might not even get responded to. But at the same time, if you're too verbose or you're paying too much attention to too much verbose information, you may find yourself in a situation toward your simply responding to too much. In other words, every little thing happens, you responding to it with a full incident response process and you inundate your resources toward you're really not effective in your incident response practice. Let's talk about a couple of things here what defines an incident. This is really important to make sure you define what an incident is. Now, we have clearly some generic examples or some generic definitions that we can give you. For example, an event that requires a response should already be defined in a policy. In other words, what it boils down to is what we consider to be an incident could vary greatly from organization to organization. For example, something that may be considered an incident for DOD, may not even be on the radar for let's say a newspaper organization. If you look at those two extreme differences where they have focuses on two different things, whereas if you'd think about a newspaper organization, a lot of focus would be on integrity, whereas if you look at DOD of most of the focus is on confidentiality. An incident in one scenario in one environment may not even be a trickle on the radar in another. One lesson there is what defines an incident should be very specific to an organization on some levels, and it should definitely be something that's tied to your policies and procedures and things like that even if it's not an IR policy. Because technically your incident response policies should have the red tie-ins to your overall corporate security policy and overall corporate security strategy. Then usually what is incident? It's something that has an adverse or negative impact. The real question is, how do we identify when they happen? A lot of organizations that I've seen in my consulting have really good policies, they have really good descriptions, and really good definitions of what an incident is, but when it comes down to the action of actually identifying when that incidents happen, when an incidence lied? A lot of them fall short in that area. Looking at the ability to identify. Some sources of an incident notification, this includes end-user's. This is one of the most common sources. Now they might not always be reliable because a lot of times in users will freak out over things that aren't necessarily an incident and report those things, but keep in mind, we also have the opposite problem. Where there are absolutely things that your end user should be reporting that they just don't report. You can have a really reflection of what we see in the rest of the world, some of your end-users are extremely paranoid, extremely sensitive to every little thing. If something acts differently on that system for just a second, even if the browser takes longer to load and usual, they're going to automatically report that and tell you that something's going on, someone's hacked the Machine, whatever. Whereas you have other users literally could have the cursor moving and opening documents and doing everything by itself, and they might not report it. You have to be aware of the fact that end-users are still really one of your first sources of instant notification, because they still are wanted leaders and how we get notified of incidence. Now, once we define this and we'll talk about this in a little more depth in a couple of pages over here, but once you know that, it gives you the foresight to now tap into that and bridal data where you can make it useful. There's also log sources like SIM solutions, IDS solutions, firewalls, host-based intrusion prevention systems. These can all be sources of event notification. Part of the problem is when you look at an enterprise environments, there so much of this data in so many logs, it could just be overwhelming to the point that it's not useful. You get blinded or paralyzed by just the sheer volume of logs and data, and this is one area that we really see machine learning, deep learning, and AI helping out tremendously. Taken that massive amount of data carbon through it really quickly and telling us what it means. Then there's also notification from outside entities like law enforcement, and we'll talk about that a little more here in just a second. Some caveats and things that happen makes sure the incident identification process is sufficient. If you have your definitions to loose, then literally every single thing will turn into an incident and then your paralyze yourself that way. If you have your process too tight and your criteria too tight, then you obviously miss critical events and you will lose the opportunity to learn from incidents that you are not considering when maybe you should have considered somewhere else. Keep in mind, these are definitely either A, decisions that should be made at a higher level than just the security team, and at the very least, there should be some influence and visibility from departments other than just a security team. One of the biggest flaws I see in incident response is incident response and security in general has just traditionally been something that's owned by IT or owned by security, and you can see the lack of input from other parts of the organizations in a lot of these procedures and processes. We'd like to see it more balanced, also where the input is coming from more than just IT or more than security. That's where you get really the right balance between these two, is if you look at it from that perspective. You also want to make sure that you allow room for identifying new incidence. Just because it's not defined does not mean it's not an incident. You can have things that happen daily that aren't necessarily defined incidents, but they might become one after that day. Organizations change, we're changing rapidly, we're rapidly migrating the cloud services and things like that. The landscape for what defines an incident is changing as well. Also the environment that we're working in, we're working with a different level of control than we've had before. Some areas we have more control when you consider cloud migration, but there's definitely some few areas where we have less control, such as layer 2 monitoring and stuff like that, or physical layer monitoring. You just don't have the visibility that we had before. The landscape is definitely changing and we're definitely seeing new things happen with these new environments, like cloud-based environments that we haven't seen before. You want to make sure you leave room for that in your criteria to where you can grow and basically expand, shrink, do whatever you need to do, or pretty much just adapt to what your environment is becoming. Now to maintain scope and focus, you want to identify the incident and move on to classification. After you've done that, don't try to do containment at this stage, this is a big mistake that a lot of junior incident response teams will make. They will jump in, they will go ahead and get the defecation part done, and then now they'll start trying to do containment because they're freaking out, they're worried about how upper management is going to look at it. We've got a bad threat actor in the environment, we want to get this contained as soon as possible. You do want to get it contained as soon as possible, but what's more important is working your process properly so that whatever happens at the end, you clearly and concisely followed your own organizationally approved incident response policies and procedures. You want to at least make sure you meet that criteria, because if something goes off the rails, at least you follow proper policy and procedure, and it's something that you can usually recover from. But if you don't even follow your own policies and procedures and you jump the gun and jump to contain it before, you've done the right classification, you've done the right criteria rating and all that, you could be guilty of putting more resources into containment, or putting resources into containment that may not even be relevant to that threat because you didn't do proper classification in the beginning. Don't be so anxious to jump right to containment. Work the process. How are these incidents detected? It happens a lot of different ways and I remember reading one of the Verizon data breach reports. It wasn't the one from this year, but I think it was one for maybe two or three years ago. In there they looked at law enforcement as being one of the primary notifiers, or one of the number one detectors of corporations being compromised. Now, we're not even talking about adding into that equation, government organizations. Even with non-government organizations, a lot of times law enforcement is the first entity to identify or detect that there's an incident there. They detect it, they notify you in and you decide if it's an incident inside your organization or not. There's also internal detection like your data loss prevention, your IPS, your exfiltration protection and stuff like that, also third-party consultants and vendors. You want to think here like your MSSPs, the people that you have looking at your data, looking at your traffic in real time, that may not be part of your internal actual team. Then of course, the worst-case potential scenario here is where your exfiltrated data ends up on the internet or on the Dark Web and you find out that way. Obviously, we don't want that to be how you find out. We want to make sure that this is like the worst-case scenario truly, we don't want you to end up in that situation. That's pretty much it. Hope you enjoyed it. Come back and see us in the next.
