In this demo,
I will show you how to implement some of the ideas from the last clip.
I will start by showing a few of the interesting Zeek SSL
fields in the Kibana web UI that can be used as a metric
for continuous monitoring.
Then I will show how to generate a baseline of certificates from the
global root and intermediate certificate authorities.
After the baseline is created,
I will show how to use Watcher to create an alert that
checks for new certificates that are not signed by a
certificate authority in the baseline.
I will end the demo by triggering the alert and
looking at what we can expect to see.
Let's get started.
This is the Kibana web UI, which is a front end for Elasticsearch.
From here, we can interrogate and visualize Zeek data.
Let us take a quick look at some of the interesting fields.
First, we need to filter the data so we only see the SSL log data.
After I select the filter I want,
Kibana will reload the page and highlight the field and value pairs in yellow.
Now,
if we want to get an idea of what cipher values are being
used in the Globomantics environment, we just select the zeek.ssl.cipher field.
Notice, Kibana gives us the top five values and the distribution.
Next,
we can view the validation status field and get an idea of how
many certificates were successfully verified.
Remember,
Zeek uses the operating system's local copy of the trusted root
and intermediate certificate authorities.
So in this instance,
it would be worth investigating anything that does not have an OK status.
I'm not going to do that now, but I wanted you to have that piece of information.
That's it for the SSL log.
Now we need to filter using the x509 log.
Notice that it's not listed for quick selection.
This is because it happens to be below the top five logs.
I can manually add the filter and Kibana will do the same thing as before,
and highlight the new selection in yellow.
To save some time, I'll adjust the filter and come back once it's complete.
Here we are.
I have selected the certificate issuer field,
and once again, we see the top five values and the distribution in the dataset.
I will come back to this shortly.
Let's take a look at the certificate serial field.
You should be starting to see a trend.
Each of these fields provide a wealth of data and you can
quickly get a sense for what the most common values are
for a particular environment.
The last field I will show is the certificate expiration.
If you're doing continuous monitoring for compliance or for security,
this field should definitely be on your observation and remediation list.
Now,
let's go back to the certificate issuer field and see if we
can get a better view of the information.
I'm going to switch from the discover view to the visualization view.
Once the page loads,
I will change the default bar chart to a data table so we can see
all the certificate issuers beyond the top five.
This list is what we will need to use as the baseline for this dataset.
If you have a large list, the Download as CSV link is a nice convenience.
Now,
let's go back to the Discover tab and see if we can
identify if any of these certificate issuers are
associated with self‑signed certificates.
If we assume that the local CA store is not compromised,
then we can use the Kibana query to filter out any TLS
communications where the verification status is not OK.
To speed things up,
I've already created a saved query that will get us the results we want.
Great.
We have a few results to investigate, so let's see what
values are present for the validation status.
Remember, we're looking for self‑signed certificates,
so I will select the self‑signed certificate in certificate chain filter.
Then we can get a look at the offending values by
selecting the issuer common name field.
Perfect.
It looks like there's only one CA in the list.
In your own environment, if you have an internal CA infrastructure,
you might recognize the entries or entry you see.
If you do not, I strongly recommend you do not add it to the baseline.
First,
find out all the details you can surrounding this self‑signed CA and take
appropriate action based on the outcome of your research.
Now, if we quickly look back at our visualization,
this is the same CA that is listed.
The final section of this demo will be the creation of a Watcher
alert, and then triggering that same alert.
All of this will be done using the Kibana Dev Tool, where we
can send direct API calls to Elasticsearch.
Now for the fun part. I've taken the liberty to write out the
configuration needed to create a watch that will search for self‑signed
certificates in the Zeek dataset and email the security team with some
information about the alert that was generated.
Don't worry, I'll go over most of the lines and explain briefly what's happening.
Line 32 creates the watch and the four sections below
determine the behavior of the watch.
The first section tells Watcher to do something based on an
interval, which in this case, is 30 minutes.
The second section is where we tell Watcher to search the Zeek
index for self‑signed certificates. In order to save on resources,
I scoped the search to only search for records that have the
zeek.ssl.validation.status field. Watcher stores the results of the
search in its hits array,
so I extract the total count of results found and the rest of the payload.
The condition section controls when the last section executes.
So in this case, Watcher has to find at least one
result before it does anything.
The last section is the action to take if the condition is met. There
are several options available, but I chose to have the results emailed
to the Globomantics security team. To tell the Watcher API about this
configuration, I clicked the play button. This sends the configuration
to the API endpoint and the acknowledgement shows up in the window pane
on the right.
I have done this a few times already, which is why you see the
false next to the created. Each time you update the
configuration, it only increments the version.
There is still one more step.
All I did was create the watch.
It will not do anything until the 30‑minute trigger time.
Since I already have a self‑signed certificate in the dataset, we can force the
watch to trigger immediately by using the execute API call.
This will not disrupt the operation of the alert in the future
and is mostly used for testing purposes.
You can see the results of the execution in the window pane on the right.
If I wanted to turn off this alert, I can use the deactivate API call.
Well, that's it.
We've reached the end.
The Globomantics security team just needs to check their email and
verify that they're receiving alerts, and we're done.
See you in the next clip.