When considering the implementation of log capture and analysis,
would you be shocked to know that there is a standard for it?
Probably not.
If you were to look NIST Special Publications 800‑92,
Guide to Computer Security Log Management,
it focuses on the log being a record of events that have occurred within an
organization's systems and the organization's network.
And when you think of what is composed of the things in the log,
there could be many sources. It could be filled with events that are
completely innocuous. Elements of log collection are focusing on what is
regulatory or a compliant requirement that we have.
What is the non‑repudiation? If we have looked at the authentication,
the authorization, and the identification of an entity,
how do we know that that entity is actually doing what it's
supposed to be doing? The performance is also a good key reason
in our motivation for log collection.
This is performance both of the cloud service provider's platform
and anything that we have created on top of it.
We need to be aware of the separation between real‑time alerts
and the recording of things inside of logs.
So the real‑time alerts can be something that we put on top of
the logging event correlation that says that this is a matter
that needs higher escalation.
Why?
Because that event could actually be part of an incident that deserves
an investigation. A little bit later, we'll look through a
demonstration of creating something that has the full lifecycle
management of the monitoring, the collection,
the real‑time alerts, and even event correlation. When it comes to
log management in the log management process,
we first have to define the logging requirements and the goals.
What is it that the organization wants to accomplish?
That means that there has to be prioritization of log
management appropriate to the organization's risk
tolerance and risk management behaviors.
The idea is to reduce risk. Policies need to be developed that
clearly define the mandatory requirements and suggested
recommendations for log management activities.
It includes log generation, the transmission,
the storage, the analysis, and the disposal of the logs.
There needs to be a step‑by‑step process for collecting logs needed as evidence.
Organizations may wish to acquire copies of original log files,
centralized log files, and to interpret the log data.
This may mean additional conversations with the cloud service
provider to have access to resources that may not be part of what
is naturally supplied inside of the SLA.
Additional factors that will influence the log design could be the cost and the
volume of the data that's going to be processed or stored.
Typically, with cloud service providers,
it's not the management of the log in their platform that has cost, but it's
typically the storage of it and also the movement of that log outside of the
platform that tends to exponentiate the cost.
You also should be concerned about the disposition of the logs,
whether it's in transit or at rest so that it's secure. The information
that's coming from these logs could actually be quite detrimental if
exposed to eyes that should not be seeing it.
The security concerns for logs have to do with what the logging status is.
When we talk about logging status,
we're saying there should be monitoring of the log sources
and monitoring of the logs themselves.
What kind of archival process do the logs go through?
Is there some kind of overriding that takes place at
the end of a particular period?
How about checking for upgrades and patches to logging software and
acquiring the testing and deploying them in a correct way?
Logs also need to be concerned about synchronizing time,
ensuring that each log's host clock is synchronized to a
common time source. Also, reconfiguring logging as needed
based upon policy changes,
technology changes, and other factors that may take place. And then
the operational existence of the log so that we can detect anomalies
that may occur that need to be addressed.
The SIEM system is the centralized collection and monitoring of
security and event logs from different systems.
The SIEM system allows for the correlation of different events and
early detection of attacks. At the most basic level, a SIEM system can
be rules based or employ a statistical correlation engine to establish
relationships between event logs.
So, what are some common characteristics? That you're pulling in raw
information from various system logs. Going through a process of aggregating
those many different systems into a single repository.
You're normalizing that information so that it conforms to a particular
format, and the comparisons can be more meaningful.
You're doing the analyzing of the capabilities. You're analyzing and using
analyzation tools in order to map and extract target information.
And then, you also may be doing some type of alerting as well.
Different SIEM characteristics and benefits.
If you have a locally hosted SIEM,
it offers easy access and lowered risk of external disclosure.
You can have externally hosted, which may prevent an attacker from tampering
with the data based upon the expertise of the one hosting it.
It could be a hybrid because you're consuming
services both locally and in the cloud.
It could be done from an external storage perspective to support policy so that
the administrators locally do not have access to the log.
It could be part of your disaster recovery in that it is taking
place based upon transactions, and it is creating a transaction
log that you can recover based upon.
And like we said, with privilege users,
we want to make sure that we're screening out and preventing the capability
for those privilege users from managing their own logs.
Next generation capabilities and log management says that the SIEM
system may be based upon a modern data lake technology like Amazon's
S2 or Hadoop or Elasticsearch. Having large amounts of low‑cost
space can afford greater retention when it comes to doing this on a
large‑scale basis.
You also may be using other types of analytics,
like user and entity behavior,
which utilizes machine learning and behavioral profiling for deeper
intelligence in identifying threats that may not seem like an anomaly
from a log that is looking just at two dimensions.
There is growing usefulness in this world as we connect the SIEM
along with other security orchestration and automation technology
that assist in identifying and responding to security incidents
that are inside the SOC.
Large amounts of telemetry data also supports the continuous
improvement of a zero trust architecture.