Hello, and welcome back.
In this clip,
we will validate Winlogbeat and ship an event log data to our Elastic cluster.
I'll start by using the Kibana web UI and exploring index
management. Then, we'll move to the Discover tab and see
if we're receiving events.
An essential part of the validation process is ensuring all
endpoints send logs to our Elasticsearch cluster.
If we have gaps, there's a potential to miss security events.
I'll wrap up the lab by showing a method for verifying your Winlogbeat
configuration matches what we see in Elasticsearch. On your screen is the Kibana
web UI. I'm going to navigate to the Index Management section, which can be
found under the stack Management link. In version 8 of Elasticsearch, we no
longer have Winlogbeat indices by default.
Instead, data streams are used. Data streams allow you to
have a single named resource you can reference, but they use
one or more back‑end indices.
The Winlogbeat agents on our endpoints should be sending event log data to
this data stream, so we're looking good so far. Since we're here, let's take
a quick look at the back‑end index. We can see some status details, such as
replicas and a storage consumption.
We can also see a few thousand documents in the data stream, so we're likely
receiving data, but let's go to the Discover tab and verify.
Nice! As shown by the chart, we have a steady flow of
events over the last few days. Notice we had an index
pattern automatically created for us.
Now, I'm curious to see how many of the five Windows hosts have sent event logs.
I can search for a host field and then select the agent.hostname field.
We can see four systems and the distribution of logs by percentage.
Now,
if we had more than four systems, which we do in this instance,
we can pivot to the Visualization section.
I like using a table here, and we get to see the spread consistent of each
host and number of event records over the last 15 days.
This list of hostnames represents unique systems that have sent
event logs to Elasticsearch. Using my asset inventory, I can
compare the list you see on the screen and confirm or deny which
systems are sending logs to the SIEM.
For longer lists, you may benefit from sorting. Now,
I know you're probably thinking, comparing 5 systems to a list
is trivial, what about 5 or 10,000 systems?
Okay, fair point.
Then we can use a metric aggregation to count how many endpoints are
reporting back. First, I need to remove the record count and replace it
with the agent hostname. Then, we see the aggregated total of endpoints
that sent logs to the Elasticsearch cluster.
In my case, there are only five systems, but if you have several thousand,
then that particular number would be reflected here.
If you have a lot of missing systems, adjust the timeframe you're
using. Some systems could be powered down or have a misconfiguration.
There are many approaches to identifying missing systems, but that's
outside the scope of this course.
Our last task for this clip is to display a sample of the unique
Windows event IDs sent to Elasticsearch. Winlogbeat uses the
Elastic Common Schema to normalize fields in the event data, so
event ID becomes event code. Okay,
so I'm going to drag and drop the event.code field and, by default,
we only see a few event IDs. Next, I'll modify the number of values
displayed to 50 so we get a few more values to look at and compare
with our configuration.
I'm going to shift gears and bring up a section of the Winlogbeat configuration.
There we go.
The general idea is to ensure that the event IDs in this file show
up in the list we had in Kibana. I would recommend triggering some
of the log events in a controlled environment so you know
everything works as intended.
Additionally,
you will see later in this course some Windows event IDs require
additional configuration before generating the event log.
That's all for this demo. See you in the following clip.