Understanding Security Logging and Monitoring Failures
Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Time
2 hours 3 minutes
Difficulty
Intermediate
CEU/CPE
2
Video Transcription
00:00
>> Understanding security logging and monitoring failures or
00:00
learning objectives here are to describe
00:00
security logging and monitoring failures.
00:00
Demonstrate how to test for various types
00:00
of security logging monitoring failures.
00:00
The next point, how to remediate
00:00
security logging and monitoring failures.
00:00
Now let's take a step back.
00:00
Why do we have logs in the first place?
00:00
Why do we have security monitoring tools?
00:00
Anyway, it's both a proactive control
00:00
as well as a reactive control.
00:00
One hand, we're trying to detect
00:00
if someone's attacking our web server,
00:00
and the other thing is,
00:00
unfortunately, if someone is breached.
00:00
If they have the logs there to try to determine
00:00
who is responsible and how to fix their system.
00:00
How to block whatever malicious traffic attack
00:00
them in the first place,
00:00
and look for things like attribution
00:00
or indicators of compromise IOCs.
00:00
There's a couple of aspects as far as
00:00
why things are logged and monitored.
00:00
For example, let's pretend we have a WordPress site,
00:00
and the WordPress site has no logging and it has
00:00
no monitoring or any extra logging or monitoring tools.
00:00
If an attacker does a brute force attack,
00:00
maybe they use something like WP scan or
00:00
they think they found a SQL injection
00:00
run something like SQL map.
00:00
Whoever owns that server,
00:00
in this case, we're pretending we do.
00:00
We're not going to see any of that traffic.
00:00
We're not going to be able to
00:00
detect SQL injection attack.
00:00
We're not going to be able to see the WP scan
00:00
being passed in the user agent string,
00:00
and the attacker is going to
00:00
attack our server without any proactive controls.
00:00
No one's going to block them.
00:00
Nothing bad is going to happen to them as far
00:00
as their inability to attack our server,
00:00
because we don't have any logging
00:00
or monitoring tools setup.
00:00
Let's say that we do now
00:00
have security logging and monitoring tools.
00:00
Unfortunately, people do this
00:00
usually after an attack or after
00:00
a breach because they realized the importance of it.
00:00
But what happens in this case is
00:00
we do see that someone's trying to brute
00:00
force logins and they are locked out after
00:00
three unsuccessful attempts and
00:00
their IP address is blocked.
00:00
We see them try to brute force directories
00:00
and in which case we get an alert.
00:00
We're able to block them in that case.
00:00
That's the benefit of having these tools.
00:00
Heaven forbid someone actually
00:00
gets on your server and they
00:00
delete your logs locally on the server.
00:00
Hopefully you're pushing logs somewhere else.
00:00
Those logs are being ingested somewhere else,
00:00
and despite the fact that they're deleted locally,
00:00
that we still have a copy of that somewhere.
00:00
Maybe we have
00:00
some managed detection and response capability
00:00
that that information is pushed somewhere else offsite,
00:00
and defenders are monitoring that information,
00:00
and they see that someone was able to get on the system,
00:00
and they're able to determine who that is,
00:00
and then able to
00:00
launch remediation actions from there incident
00:00
responders leap in to
00:00
protect our server and are successful in doing so.
00:00
But only because we have
00:00
a good logging and monitoring capabilities setup.
00:00
I think that touches on
00:00
each of these four aspects that we have here.
00:00
How do we test for this?
00:00
It's going to be a little bit of
00:00
white-box testing, gray box testing.
00:00
It is hard to do this with black-box testing because
00:00
how are you going to legitimately get
00:00
access to someone's logs?
00:00
If we're going from the black box perspective,
00:00
if you hack and gain access to
00:00
somebody's account and then can view logs from there.
00:00
You can say, you're not properly encoding
00:00
[LAUGHTER] the output from the log,
00:00
but that's only because you were able to
00:00
exploit it from another angle.
00:00
The white-box testing is you legitimately,
00:00
maybe you get credentials provisioned for you.
00:00
You're able to audit the logs.
00:00
What are you looking for in this case?
00:00
You're looking for logs containing sensitive information.
00:00
Maybe username and passwords are
00:00
being passed into the logs where if
00:00
someone does gain proper access to that,
00:00
they can log into someone like the admin.
00:00
We saw that example in the first lesson.
00:00
Also have to ask how often our logs
00:00
rotated are written example our article
00:00
is about the OPM breach that occurred over a year.
00:00
If logs are rotated in a very short period of time,
00:00
then defenders really don't
00:00
have that type of visibility,
00:00
because logs are rotated in a very short period of time,
00:00
so the longer you can keep logs, the better.
00:00
You also have to figure who can review logs.
00:00
We just don't want any user having the ability to review
00:00
logs or any one unauthenticated review logs.
00:00
We want to make sure only those who
00:00
have a need to know are able to review logs.
00:00
Again, we want our lives to be backed up,
00:00
not on the server itself,
00:00
but somewhere else off premises.
00:00
We also want, is data and
00:00
logs being properly validated encoded,
00:00
so that something like a cross-site scripting attack,
00:00
which you'll see next, is not successful.
00:00
AWS Guard Duty.
00:00
There are some things in place,
00:00
especially in the Cloud and AWS Cloud.
00:00
Things like Guard Duty and Cloud Trail that
00:00
are monitoring for you all the
00:00
different traffic that's occurring in your account.
00:00
That's more of an account control.
00:00
This is how you mitigate it.
00:00
You have controls like this in place,
00:00
you ensure all login access control,
00:00
service side input validation failures are logged.
00:00
You're ensuring that logs are
00:00
generated in a format that log management
00:00
solutions that our blue team can
00:00
ingest and that's taking the logs from that server,
00:00
ingesting them into the sim or sim can
00:00
be easily consumed for the defenders to
00:00
determine whether an attacker is successful.
00:00
If you've ever looked at logs,
00:00
it's a very daunting thing.
00:00
There can be terabytes
00:00
of data that someone has to come through,
00:00
and that's why we have these
00:00
security solutions that do it for us.
00:00
It makes life a whole lot easier.
00:00
We're ensuring that log data is correctly encoded,
00:00
again, to prevent injection attacks.
00:00
It's not properly encoded
00:00
and an attacker can launch something like
00:00
an out-of-band cross-site scripting attack
00:00
because it's not properly encoded,
00:00
and lastly establish or adopt
00:00
an incident response and recovery plan.
00:00
Again, we're doing all this so that
00:00
in the worst-case if we are breached,
00:00
the incident response team can review
00:00
the logs and try to determine what occurred,
00:00
so that we can properly remediate
00:00
everything and recover things back to
00:00
a state where the attacker
00:00
can't get back on our system where we can
00:00
patch things and make sure that we're not attacked again.
00:00
In summary, we've described
00:00
security login monitoring failures, what they are,
00:00
how to test for these things,
00:00
and also ways to remediate or prevent
00:00
security logging and monitoring failures.
Up Next
Scenario: The OPM Hack
15m
Lab: OWASP Mutillidae Practice
30m
Instructed By
