In this lesson we're going to talk
about automated reports.
Now, an automated report is a report
that's going to be generated by your computer system
automatically on your behalf.
For example, you might have an antivirus software
that is going to be run once an hour.
And every hour it's going to scan your system
and if it finds anything
it's going to send that as a report
back to your security operation center.
Or you may have some sort
of an endpoint detection response capability on your system
and it will go out and continually be sending out a report
once a day back to your security operation center
so they can know what the status is of that machine
and anything that was suspicious during that day.
Here's an example of an automated security incident report
that was generated by an endpoint
in detection response capability
that I've used in one of my previous networks.
Now here you're going to see some basic fields
such as the report ID, the generation date,
the report period, and the prepared by.
In this case, the report ID was 54738.
The generation date was November 12th, 2023,
and the report period was the entire 24 hour period
of November 12th, starting at 0:00:00
going to 23:59:59 seconds,
which would be 11:59 p.m.
for those of us who work in America.
Now, when we look at the prepared by
this would normally have an analyst name
or if it was shared by the system automatically
just like this one was
you would see something like automated report
or automated reporting system.
Next, there'll be some sort of an executive summary
that will tell you a little bit about the report.
In this case, it says that this automated report
identifies a critical security incident
indicative of a potential network breach.
The report highlights suspicious file access patterns
and multiple network requests
to known malicious external IP addresses.
Now, the great thing about this executive summary
is you can read that and then determine
is this worth more of your time
to go further down and read more about it?
For example, if you're not the network analysis person,
this may not be the report for you to look at.
You may want to send this over to that person
while you work on something else like a malware analysis
if that's what your position is.
So the executive summary is very helpful
summarize what is in this report
because these reports could be one page long,
two pages long, five pages long, 10 pages long,
or even 100 pages long depending on the amount of activity
in your network.
In this case, the sample report I have
is only two pages long
so the executive summary is very short
and we're only going to look at about four different incidents
that were logged inside of this report.
Now, the first one we have was labeled as a critical alert
because it was a suspicious file
access pattern was detected.
You could see the timestamp.
This happened on November 12th, 2023 at 4:53 a.m.
Right there that's already something that's suspicious to me
because 4:53 a.m. is outside of the normal working hours
for this organization.
This organization keeps normal banking hours
between nine and five and so anything outside of that
would look a little suspicious to us.
Then we can see what user was involved, in this case jdoe,
and we see the system file server three.
We can then see the details about it,
which was multiple rapid file access attempts were detected
and the behavior matches known ransomware footprints.
The action taken,
the user account was suspended automatically by our system,
the affected system was kicked off the network and isolated
and the initiated data backup procedures
as part of our incident response playbook actions.
Next, we had a high alert,
which was an excessive admin login failures,
and again, this happened on the 12th of November,
and this time at 9:34 a.m.
This happened on our main controller
and this happened from the admin user
because it was an admin attempt to log in.
And this was on the main controller,
which is our domain controller for this network.
We see that there was over 20 failed login attempts
in just under five minutes
from the IP address of 192.168.1.105.
That IP address is an internal IP
so that tells me we may have an insider threat
or we have somebody who's already exploited our network
on one of our machines through something
like a social engineering or phishing attempt
and now they're trying to break into our domain controller.
The action taken was that IP address was blocked
so that communication can no longer happen
and the admin account password was automatically reset
by our system because again,
we're using automated and orchestrated ways
to respond to some of these minor security incidents.
The third one we have is a moderate alert.
This was unusual outbound traffic,
and it occurred at 1:45 in the afternoon
and the system was database server zero two.
We saw a large amount of data transfer
going to IP address 172.217.1.14
and this was flagged in our threat intelligence feeds.
The action taken, the network connection was terminated,
and traffic contents were placed under review.
At that point,
this would notify our security operation center
and they'll be able to go in
and do the additional cybersecurity analysis
on this incident to see was it malicious,
suspicious, or was it benign?
And it may have just been
that we are backing up our database server,
in which case it would've been benign
if we were backing it up to an offsite cloud backup.
But as we analyze this we can then determine
was this really something that was a problem
or is it something that was allowed
because it was part of our backup strategy?
The next thing we're going to look at is on page two,
which is our fourth alert
and this is an informational alert,
which just says software was installed.
Now in general, software being installed is not a big deal,
but we do want to at least log it so we know what happened.
Now as we look at this,
this happened at 6:53 in the evening.
The user was msmith and it happened on Workstation 22.
The software that was installed is called FileZilla FTP
and the file hash was not matching a known safe version.
Now, this doesn't mean that this was bad.
It may have been that this user msmith
went to the internet and downloaded FileZilla
and installed it themself,
which may have been against our acceptable use policy,
but doesn't necessarily mean it was an attacker hacking us.
So we'd want to investigate it and figure it out.
In this case, we could see the action taken.
The software execution was blocked
because we're using application whitelisting
and the user was contacted to verify
that they tried to do it.
And if we called up msmith and they said,
"Oh yes, I just tried to install it,"
we'd say, "Oh, bad, don't do that again.
Next time, call the service desk
and we'll install the software for you,"
and we can just file this away as a non-issue.
But if he said, "I didn't do that,"
and we start looking into it
and he wasn't even at work that time,
this means that his account may have been compromised
and we'd have to look into that further.
So these are the kind of things you can find
inside of your automated reports.
After that, you'll have the incident analysis.
And you can see here we have threat trends,
user behavior and data flow anomalies.
We then have some security recommendations of what we can do
based on the reports that we saw in this daily report,
And then our conclusion where we basically summarize
what we did, what we saw,
and what things need to be further looked at
over the next couple of work days.
And then if we have any kind of appendix to this,
it may include things like snippets of the logs
to show us what was installed and what happened.
We could see a list of the IPs and domains involved
and other things like that.
All of this is data that can be put into the security report
and using automation and orchestration,
we can not only look for these things and get reports on it,
but we can actually act on them in real time
and this way we can mitigate some of these incidents
before they become a bigger issue for us
and cause a wide scale data breach or network outage.