Security Operations Event Monitoring

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

14 hours 39 minutes
Video Transcription
All right, let's go ahead and look at security program operations. So when we're talking about operations, we're talking about those day to day things that our security program has to account for. We've gotta monitor the network and ensure that
there's nothing malicious going on or and even not malicious. There's nothing that violates a security policy.
One. Scan the network for malicious codes. We want to choreograph the network in such a way that we have availability as appropriate. But we also don't compromise security for that purpose. So we segment
the network into trusted versus untrusted. We use firewalls. In order to do that,
we have to have a means of responding to incidents as they happen. Another part of operations is planning for business continuity, right? Making sure that as we make changes on the network many times, people think of BCP is kind of a long term, not day to day
business continuity. Planning is always going on, just like risk planning
is always going on in your network. Always
in the back of our mind, we think, How's the business going? Keep going
all right. Service providers will talk a little bit about Cloud management service level agreements. So security, proper program operations again, the day to day stuff that we do as security professionals. All right, so the first piece event monitoring so
events, you know, if we want to call an event, an event can simply be defined as a change in ST.
Not good, not bad. It just is. Deanna service started
this file was accessed that to a right that doesn't necessarily mean anything. Usually
there were more concerned with these events once they elevate to an incident. And an incident is events that have a negative impact on the system.
But wouldn't we rather catch them before they become incidents? Right. So if I'm aware of the events that are going on in my network, I can have a better chance at mitigating or preventing ideally the incidents. So the tools that we have, we review logs. Honey pots are great, um,
sources of information because
they're vulnerable, or at least a peer vulnerable to an attacker. And when the attacker tries to compromise the system
that honey pot records all his actions. So I get a little bit of knowledge about what that Attackers doing
intrusion, detection and prevention systems are going to mitigate the threats of malicious activity on my network detection systems. Detect they don't stop. Prevention systems do actually stopped by sending a TCP reset or some means,
uh, to the source of the activity.
Now, usually systems today
they're not one or the other. They're a combination of the two, their ideas and I p s all world up into one.
All right. Sim systems thes air about, um,
gathering information about threats pulling information from log files, whether their firewalls or honey pots or whatever providing a central location with which I confuse those.
And that stands for security event, an incident monitoring systems. This idea of orchestration, automation that's all they're getting at. That is Let's have an automated means toe pull log information event information from all my devices in the network. And that's tremendously helpful
in a medium
toe Lord Chuy's company,
Vulnerability Management.
And that comes from event management, right? Let's keep our eyes on the events before we start to have compromises. But vulnerabilities are the weakness. Right? When we're talking about an event
we're looking at, the possibility of vulnerabilities been compromised. But when we're looking just a vulnerabilities like you don't have risk
if you don't have a weakness, right? So when we look at the weaknesses, we call those vulnerabilities. We're looking at ways that we remain vulnerable
and their security scans that test the system. You know, looking for open ports. And that falls into vulnerability assessments there. Just scanning tools that might help you map out the network, for instance,
so that once at the network mapped out, then I can run in the Vulnerability Assessment Owner particular system.
And then I can try penetration tests to try to exploit. So usually these three go together, scan the network, find your target test for open ports or assess vulnerabilities, then try to exploit with a pen test.
You don't know if your system is configured in such a way that it can withstand an attack until you test it
right. You can audit all day long, and audit will tell you if you're following policy. But only a test will show you
the rial, the real success or give you a better indication the real success of configuration
and like I mentioned auditing, are we in compliance? And that's the question we want to answer with auditing A. Are we in compliance? Then the next question. Will it work? That's got to come from a pen test. But when we're looking at auditing an audit has to be objective.
You can get objective it. Ian House. I'm not saying you have to outsource,
but it has to be objective. So what that means is, if your auditors are reporting to a supervisor of the team you're auditing, that's not a very clear path, right? There's a little conflict of interest there.
Um, if you're auditing yourself, usually not so objective, Man, I did a lousy job on this date night. That's never been put in a report. I've written not ones.
So we need objectivity.
We have to scope the off it that has to be detailed and specified. Is it this particular system? Is that this particular network or sub net?
Is it
specifically an application or an individual? What is the audit?
Okay, we will also have to document our approach. How are we going to approach the audit? What's our methodology? And then, of course, any constraints that air in place, we may only be able to conduct an audit between certain hours using certain tools. And then, of course, we document our reports. So
those are the five components
of of the report. And let me tell you, up with the coppers has five components and I said objective. Certainly. An audit needs to be objective. Absolutely. But in this context, I miss Red. In this context, I would look at it as part of your report should address. What's the objective of the office?
Why couldn't we just have different words in the English language for different things? So I just miss read that. But certainly an audit has to be objective. But these five components are the five components of a report. So what's the objective of the audit? How big is the audit? What's its scope? What's our methodology? Are there constraints?
And then, ultimately the report rule
include what was right. The result is
Up Next