Zeek is an extremely useful network security monitoring
tool, and we have seen how we can solve some of the use
cases for Globomantics. However,
there are some limitations to what we can do with Zeek and the data it produces.
If we need information that does not traverse the network,
there is a high likelihood that it cannot be monitored by Zeek.
For instance,
if we want to monitor installed software on a system, that is
not the sort of thing that is possible with Zeek. You can infer
which applications are running on a host based on the data they
sent over the network,
but that is not reliable and introduces additional complexity for
minimal gains. Zeek can capture TLS traffic metadata, as well as a
copy of the x509 certificates being exchanged on all versions of TLS
up to version 1.2; however,
Zeek cannot produce x509 logs for TLS version 1.3 communications.
This is a technology design by the Internet Engineering Task
Force that comes from the push for more privacy.
If you happen to work at an organization that does not
perform TLS inspection, or you do not have access to data
in transit before encryption,
then Zeek cannot inform on that traffic beyond the simple metadata.
This is important to understand because if a large portion
of the network traffic is encrypted,
then the value you get from deploying Zeek without
TLS inspection is severely limited.
Another limitation of Zeek is the fact that it can only provide data to your
analysis platform if it is deployed correctly using a sound sensor strategy. I
covered sense of strategy in the previous module.
One example is if we only monitored the Globomantics DMZ network,
we would not be able to see much data from the server network.
The only traffic that we would happen to see would be communications from
the server network to the DMZ network and vice versa.
We start to lose visibility when systems in the server network are
communicating with other unmonitored networks, so it is important that
Zeek is deployed to monitor the areas of concern.
Lastly,
Zeek has many protocol analyzers which helps to detect SMB, RDP, HTTP, and DNS
protocols. When considering deploying Zeek to environments that have proprietary
protocols or even unsupported protocols, Zeek will not have a native way to
parse and identify that traffic properly.
Fortunately, Zeek allows you to implement your own protocol analyzer.
So while I've listed this as a limitation,
if your organization has the capability to develop a working solution,
then this limitation would not apply in that instance. We have reached the end
of this module and have seen how Zeek can help with specific areas of
continuous monitoring. We looked at how Zeek data allows us to detect rogue
servers by using the connection log and DHCP log.
I then showed you how Zeek data in the Elastic Stack can be used to
audit SSL certificates by looking at weak ciphers,
certificate authorities, and expired certificates.
Then I gave you some examples of how DNS logs provided by
Zeek can help us monitor the type of DNS traffic
traversing the enterprise network.
We finished up the module by looking at some of the things that Zeek is not
able to do for us as a network security monitoring tool.
I hope you enjoyed the information as much as I did. See you in the next module.