Welcome to this module on using Zeek for continuous monitoring.
In the previous module, you learned how to design and deploy a Zeek cluster.
You also learned how to get the Zeek logs into an existing Elasticsearch
security information and event management platform.
In this module,
we will look at how we can use the data we collect
to support continuous monitoring.
All right, so let's start by first looking at the definition of
continuous monitoring by the National Institute of Science and
Technology, or NIST. Let's unpack this definition.
First, we need to maintain situational awareness on
everything in our environment; systems, software, protocols,
et cetera.
We need to understand what potential threats exist that can
affect the things that are being monitored.
For instance,
if Globomantics determined that power failure was a potential
threat to assets, then, with that understanding, CM should be
designed to support that threat.
Now,
using our last example, if there are controls in place to detect power failure,
then as a part of continuous monitoring, we should
know if one of those controls fail.
Lastly, we will be looking at continuous monitoring from a security
perspective, and since security is not a static process,
we should be using the data about our environment to
make improvements to the CM process.
In the definition of continuous monitoring, I told you that
we needed to gain situational awareness.
Well, that starts with the asset inventory, which is the most
important component necessary to be successful with CM.
The center for internet security has 20 critical security controls that are
designed to help organizations like Globomantics mitigate known attacks. Of
the 20 controls, this is line item number 1.
Hopefully, this conveys the importance of asset inventory.
Think about it for a second.
How can we say we're doing continuous monitoring if we do not know what we
should be monitoring? The best way to solve that problem is to ensure there is
an asset inventory which can be developed with the help of automation and using
the DHCP server logs. Mobile devices, even if they do not connect to the
network, should be included as well.
I would also recommend that part of the acquisition process
includes updating the asset inventory.
The asset inventory is not just a bunch of hardware; it also
includes software running in the environment.
All of this should be captured in an organization's asset inventory.
The Globomantics security engineers want to see if Zeek can help with
some of their continuous monitoring gaps on the network.
They've identified three priorities.
The first is rogue server detection.
There are currently no controls in place to detect if new servers are
being added to the network without authorization.
The second is SSL Certificate auditing. In a previous incident response outbrief
to the security team, they were informed that the perpetrators used self‑signed
certificates to encrypt their C2 communications.
The third priority is DNS auditing.
We will look at each of these later in the module,
but for now we will start with tackling rogue server detection using Zeek.
So where do we start with this problem?
If you guessed asset inventory, you are correct.
More specifically,
we need the list of authorized servers and subnets. In order to challenge a
server as being rogue or unauthorized, we need a reference.
Once we have that validated reference,
we can use Zeek connection log, also known as conn.log, to track
communications on the network that deviate from the list.
The Zeek DHCP log goes a step further by providing us with the Mac
and IP address of systems using the DHCP protocol.
Let's take a quick look at the conn.log. I'm not
going to cover this entire log file.
In fact, what you see on the screen is only a portion of the connection log.
I want you to focus on the fact that it captures the source IP
and the destination IP, and those are the values we will
compare with our asset inventory list.
Remember, every system that communicates on the network
where Zeek is deployed will be captured in this file, so
it's a great source for this task.
I mentioned earlier that the DHCP Zeek log file provides us
with the Mac address and the IP address.
If there is a desire to further validate systems
requesting and receiving DHCP IP addresses,
you can use this data to monitor only authorized systems are getting
assigned IP addresses from the DHCP server. Here is a network map of a
portion of the Globomantics network we started working with in the last
module. There are three enclaves that we're monitoring with Zeek sensors;
servers, DMZ, and user network.
The network engineers want the capability to detect rogue servers,
so we will focus on the servers enclave. Simply put, if a
legitimate server is added to the network,
then no alert is generated.
However, if a rogue server is deployed,
we need a way to capture that information and alert the security team.
So how can we use the Zeek data in Elasticsearch to solve this problem?
Well,
one method is to search the Globomantics dataset for all sources and
destination addresses that match the servers subnet.
Once we have that information,
we need to only return results that are not in the authorized servers list.
This can be done using the Watcher service included
with the Elasticsearch X‑Pack bundle.
Using the Kibana Dev Tools Web UI, we can create a watch that runs
every hour and searches the Globomantics Zeek dataset for all
source IP addresses in the servers subnet.
The data is then compared to a sample authorized IP list,
which has a default limit of 65,000 values.
This limit can be modified by editing the elasticsearch.yaml. I
have provided the name of the variable you need to modify on
the screen for your convenience.
The second half of the Watcher configuration will email the Globomantics
security team if there are any hits on our search criteria. I only selected
the total count, but any field can be extracted.
For instance,
if the security team wants to see the IP address that triggered the alert,
we can add the variable that stores the results called hits.hits to the
extracted list, and then add the source IP to the email body.
Once the alert triggers and someone from the security
team has investigated the situation,
the watch can be acknowledged so it does not
continue to send email notifications.
So that's pretty much all there is to it and is a
built‑in way we can detect rogue servers.
Before we end this clip,
I should point out that the search looks at all the data and
should be limited to a specific time period,
such as the last 24 hours or the last 30 days, but after
you've performed a holistic first run.