you've made it to module for. This will be all about detecting the cyber incident,
so we'll walk through preparing and identifying, protecting. And now we're to detecting the cyber incident.
The first lesson is prevention is ideal, but detection is a must.
I'll say that again because this is a really important concept to get throughout this course. Prevention is ideal, but detection is a must.
The objectives for this lesson is one. Understand the importance of detecting anomalous and malicious behavior within the environment.
Two. Will discuss typical sources of data that can assist in detecting cyber events and incidents. And three. Understand how Certs can use a detect and analyze standard process and workflow to improve proficiency and effectiveness.
The objectives for this lesson is one. Understand the importance of detecting anomalous and malicious behavior within the environment
to discuss typical sources of data that can assist in detecting cyber incidents
and events, and in three understand how search can use a detect and analyze standard process and workflow. To improve proficiency and effectiveness,
we have to assume the adversary is already inside our network. That's why the statement of prevention is ideal. But detection is a must is so true if we already agree that they're inside our network, which is part of the concept behind zero trust networking. Architecture
is we can't prevent all attacks. We probably haven't prevented most of them. But once they are inside, that's where we really need to shine. We need to detect these adversaries quickly. The faster we can detect him, respond to it and re mediate, the less impact our organization will suffer.
So how do we get Detective are detecting activities and there's a few sources I'll walk through here that are commonly used first is if you're using the cloud. A Cloud access Security broker. We've already talked about Cosby's
maybe multi factor authentication logs. If you're using software as a service, you might get logs from your SAS applications,
usage data and transfer logs and AWS or azure. That could be very helpful, especially if you're normalising in overtime, where all of a sudden you see a spike in outbound data. That would be something to definitely investigate.
How about your users? While some activity there could be things like access attempts log in information. Multi factor authentication uses again within the user community. Also user and entity behavior in analytics or U E. B. A.
What is their normal behavior? Are they acting normal on the network?
How about any software or hardware installation? Those all could be important from insider threat or if their accounts been compromised and they're trying to install some malware on the system. You certainly want to be able to track that and get alerted to it.
Applications also have sources of information that can be helpful, like database access changes, tables being dropped, added data being removed, application privilege, escalations and moving and account within an application up to, say, an administrator
sensitive data access. So if you know all of your P, I I is located in a certain repository, and someone's trying to get access to that.
That's very helpful to know.
Modification of security controls, system notification messages and security events are all things within applications to be looking for us well
on your mobile devices, you might get alerts from your mobile device management or indium system, installation of applications, container ization logs, location information might be helpful, and any attempts to circumvent security controls.
It could also help you detect some sort of an incident.
How about user complaints? Maybe people complaining, Are you getting complaints from HR about users or their activity? You're getting reports from users about suspicious or anomalous behavior, where you getting complaints from management about users?
So, just like Homeland Security, if you see something, say something. I said the same thing in my user communities. If you see something weird on your computer, you get an error message you've never seen before. Something just isn't acting right. Your computer sluggish, and it never has been before.
Give us a call, let us know. Maybe it is something maybe it isn't. But I'd much rather have people letting us know about that kind of stuff.
And it's amazing how many incidents we did catch because of that.
Desktops and laptops, of course, could have in point detection and response tools that are sending US data host intrusion detection can be very powerful. Process execution. Of course, it's nice to know what processes air running and where the file path is of those processes. And if they're the expected ones,
how about changes done to the registry for persistence, perhaps on a Microsoft Windows system that could be very useful. And just any other evidence of persistence is something we always want to be on the lookout for
a few other sources that you should be looking toward for detection information, your servers and your virtual ization infrastructure. So do you have host detection on your servers? What about virtualization management CPU or memory spikes? All of a sudden that you're not used to seeing could be useful information.
What if you're using Microsoft s CCM or scum for patching asset management and log reviews and event management, and also in point detection and response on those systems to
you might have sensors deployed things like network taps that are giving you censor information or net flow data. You also might have sensors installed on the network. If your federal government your agency, you're probably familiar with Einstein State, local and tribal might get taps from DHS or sensors called Albert Sensors.
And these are all things that are looking for activity and matching them with signatures
could be DNs names that somebody is navigating to. It could be signatures through I. D s
logs or events that are being matched so anything like that could help in the network traffic. So network intrusion, detection and prevention, firewall devices, sandbox devices that air detonating both email attachments and files traversing your network proxies and D N S d HCP logs
TLS decryption. So maybe you're doing SSL or TLS inspection
router tables that are changing and packet capture. Some organizations do full packet capture. And also, if you are doing inspection of encrypted traffic, if you all of a sudden have traffic traversing your network that you cannot decrypt,
that could be an indication. Right there of encrypted traffic being
are encrypted traffic that's being encrypted by adversaries with Certs, of course that you don't have and that right there might be a red flag to go look at.
So the process. Once you detect an analyze something is typically what we see, you get an alert, you triage that alert.
Maybe you declare an incident. Remember, we've talked about type one type two little I bigeye, however you want to do it and then you investigate the incident that's been declared
All right, a quick question on this lesson, true or false, organizations should operate on the assumption that an adversary is already on the inside of the network.
And that answer, of course, is true. We should operate that way. We should just assume that our networks are compromised and really focus on detection. That's not to say we aren't still going toe invest in prevention because we just have to do that. But also, we need to really be looking at all right, they're already inside.
How do we catch him once they're here?
How do we make it really difficult for someone on the inside to get the information without us knowing about it?
Another question. What is not an example of user behavior Analytics. A access attempts be location information or C software installation.
The right answer here is location information. That's something a user doesn't actually do. It's something about the user that could be helpful. And it certainly could be helpful from a threat perspective on Loggins. But for the purpose of this question Behavior Analytics access attempts. You have a user trying to get access to. Maybe a file share a SharePoint site
that they're not supposed to get Teoh
or installing software is something that the user is responsible for.
So summary. In this lesson, we really talked about the importance of detecting anomalous and malicious behavior and what some of those sources are again. Typical sources of data that can assist in detecting cyber events and incidents, and how Certs can use a detect and analyze standard process of workflow
to improve their proficiency and effectiveness.