To be able to manage the massive amount of information you
receive from log files and event notifications,
you'll want to use a Security Information and Event
Management Device or SIEM.
A SIEM is designed to collect information from anything
on the network that can create log files, security
alerts, or any type of real time information
that can tell us about what's happening on the network
right now.
The SIEM is commonly used as a central repository.
So everything will be logged and aggregated
into the central database of the SIEM.
From there, you can create reports
and historical perspectives of what's
been happening on the network over time.
You might also be able to correlate data
from different devices to see if you can start
to see events occurring even though the data
sources that you're receiving are
very different between these different devices.
And, of course, since you're collecting
all of this information into a central database,
it's a perfect place to go to be able to perform forensics
after a security event has occurred.
The data that's being fed into the SIEM
is coming from very different devices.
A Windows server works very differently
than a Linux workstation, which works very differently
than a router or a switch.
So there needs to be a standard way
to be able to send log files from other devices
into this central repository.
And the name of that standard is called syslog.
There is usually a syslog compatible collector
that is part of the SIEM itself.
This collector is waiting for messages
to be sent from all of those different diverse devices
on the network.
And the format of those messages coming
in to the syslog collector are in this standard syslog format.
As you could have probably already guessed,
being able to store all of this data from all of these devices
over a long period of time is going
to require a lot of storage space.
So it's very common on a SIEM to allocate
terabytes and terabytes of storage
so that you can collect a lot of this information
and store it for a long period of time.
So what types of information would
be valuable to store in a SIEM?
Well, from a security perspective
you'd love to be able to see who may be attempting
to authenticate into a server.
Maybe you'd like some record, a VPN connectivity or firewall
session logs.
Or perhaps you want to see people
that are trying to communicate outbound from your network
to a location that you would not like to allow--
those would be the denied outbound traffic flows--
or maybe just a generic overview of network utilization
and something that you can track and trend over time.
It's also common to grab raw packet captures as well.
Especially if an event occurs, and you can add the packet
captures into the event to add more information about what
may have happened during that time frame.
It's common in larger organizations
to have a Security Operations Center, or a SOC.
Someone in the SOC is able to monitor all of these SIEMs,
evaluate the type of data that may be coming in,
and be able to react to some of the information that's provided
from the dashboard of the SIEM.
As you can imagine, there is a constant flow
of traffic and information being put into the SIEM.
So it's very important that you're
able to react to the data that you're receiving.
The logs that are being added to the SIEM are able to be parsed
and then the Sim can identify if a security exception might
exist within those log files.
From there, notifications can be sent over email or text message
to inform people of the exceptions that
have been found.
And this could even be automated through a ticketing system,
so that as soon as a problem is identified,
it can be assigned to a technician who can then
evaluate what the next steps might be.
At the core of the SIEM is the log information.
This is a screenshot from a SIEM that
shows an example of the logs you would
get from a Windows system.
For example, here is a log entry that shows
a user account was enabled.
It shows a security ID, an account name
of "Administrator"-- and here's the domain
name associated with that--
and then some additional account information
from that computer as well.
Obviously, there is a large amount of log information
that is stored on the system with an extensive amount
of data.
That's why most SIEMs are going to have a dashboard that
rolls up that information into a mode that
can be easily identified and easy to understand what's
happening.
So you can see trending of logs, how many types of security
events have been received, the top devices that
are reporting in, and even the severity of those Windows
events.
We can see that we've had successes,
a large number of failures, and some informational severities
as well.
Most Sims also include report writers.
So you'll be able to gather information into the logs
and then create a more readable view of that data,
especially over a long period of time.
Being able to pull important information
from this very large amount of data
relies on different techniques and analytics.
One of these would be big data analytics
which is the ability to look through large amounts of very
diverse data to be able to identify patterns that normally
would be invisible to a human being.
Another type of analytics looks at how people are acting.
So you would have user and entity behavior
analytics which examine how people are using the network.
Even if they're not directly attacking a device,
there may be a way to tell if that particular type of pattern
could cause potential problems in the future.
And another type of analytics is a sentiment analytics.
This examines how the public views
a particular organization.
For example, if a public opinion of an organization
happens to be very bad, it tends to attract
hackers who can then create problems on that network.
So being able to measure how your organization is viewed
on social media may have a direct impact
on the type of security you would need on your network.
These days organizations are trying
to take advantage of all of this data and all of this technology
by the use of SOAR.
SOAR stands for Security Orchestration Automation
and Response.
The goal of SOAR is to take these processes in security
that were manual or tedious and automate them so that all of it
is done at the speed of the computer.
With orchestration, we're managing
many, many different devices and automating the access
that we have to those devices.
In some cases, we are configuring or reconfiguring
devices with this orchestration.
So we might modify firewall rules,
or change the permissions associated
with a particular account, or change
the email filters we're seeing and do this all dynamically
as this information is being evaluated by our systems.
Instead of having an individual configure our firewalls,
or our accounts, or these email filters,
we will have our systems themselves provide this
through automation.
This is an important key of this,
because the computers much faster than we happened to be.
And it can identify what may be happening
at any time of the day and put barriers or mitigation in place
to prevent those problems from happening on our network.
And the response part of SOAR means
that we're able to have this orchestration and automation
occur at any time of the day and be
able to react to anything that may
be occurring in our network.