Category Archives: information security

Introduction

Like most cybersecurity professionals, you’re looking for an EPP that protects against current and evolving threats, is easy to deploy and manage, and is ultimately invisible to end-users. Today, there are dozens of these platforms available, and choosing the right one for your business is a daunting task. With each vendor claiming their solution is next-gen-everything, is the highest rated, and is easiest to use, how do you select what’s best?

Last year, I conducted a bake-off amongst three endpoint security solutions. My goal was to replace an incumbent legacy system with a modern combined endpoint protection platform (EPP) and endpoint detection and response (EDR) solution. I researched online for methodologies and guides to evaluate and compare solutions but didn’t find much. The SANS Advisory Board mailing list had some good tips and together with my own curiosity and experience, I created the following walkthrough. The entire experience was one of the most fun I’ve had and I hope my guide helps you in your own evaluation process.

Determine Requirements

First and foremost, determine your requirements. Some questions to ask yourself:

What operating systems do I need to cover?

Am I worried about file-less malware and PowerShell-based attacks?

Is endpoint detection and response (EDR) capability important to me?

How will this new solution integrate and enhance my current solutions?

Do I need a solution that provides managed services such as monitoring or incident response?

Based on these questions, create a “capabilities checklist.” This will be your specific criteria for a valuable experience. A sample is below.

Vendor Communications

Reach out to the vendors you intend to evaluate. Prepare a good list of questions and have them walk through your use cases. Typically, these pre-sales calls will involve an account executive and a sales engineer that will introduce you to their solution, speak to their differentiators, and conduct demos. You may even be able to weed some of the vendors out just in this initial stage.

Throughout the process:

Don’t reveal which solution you’re leaning towards.

Document your findings.

Ask lots of questions.

Be courteous.

Testing Methodology

Truth be told, no solution is perfect, but leveraging a standard testing methodology will enable you to objectively evaluate each solution in a fair and repeatable manner. You can use the following methodology to complete your “capabilities checklist” from the Determine Requirementsphase.

Preparation

Setup test “victim” virtual machines, completely separated from your production networks, running each of the operating systems you’ll need to protect. Virtual machines will allow you to quickly revert to a clean state. Cloud or container-based solutions work well for this.

Run suspicious commands like netcat or dump password hashes and note if the activity is prevented or detected. Observe whether or not the solution brings these to your attention or if you have to dig to find what you’re looking for.

Test the ease of deployment and uninstallation. Both will be equally important to any teams that will be supporting the management and maintenance of the platform.

Test “bypass”, “detect-only”, or “disable agent” modes in the event you’re asked to disable the protections for troubleshooting purposes.

Move a system between policies and observe how long it takes for changes to apply.

Observe how easy it is to search for IOCs: hashes, filenames, IP addresses, hostnames.

Create whitelists / blacklistsfor specific files and test to see they are actually allowed or blocked.

Test network containment of an endpoint. Is the system truly isolated and unable to connect to anything other than the EPP console?

Get a feel for the UI. Are the features you care about the most easily accessible and intuitive to use? Is it slow or difficult to navigate?

Test any unique features of the platform. Do they run as well as the vendor claimed? Do they add value to your workflow?

Try to seriously break it. Click on everything in the console. Assuming you’re only running against test virtual machines, this shouldn’t break anything. If you run into issues, reach out to the vendor’s support team and evaluate how responsive they are. Better to know this now than when you’re in a real emergency.

Final Evaluation

With your completed “capabilities checklist”, review your findings and observations. If there are any follow up questions, get these answered by the vendors in writing.

It’s not an exact science, but the results from your checklist combined with your experience working with the pre-sales and support teams should give you a good idea of which solution is right for you.

Purchasing

Get quotes for all the solutions you’re evaluating. Even if you’ve decided on which solution you want to go with, use the other quotes as a way to drive down the price for the solution you want. Let each vendor know you’re looking at competing solutions and ask them to include any training, conference tickets, or additional incentives to create the most compelling offer. Don’t feel bad about this, it’s their job to sell to you.

Depending on your timeline, you may not have a choice for when to make the purchase, but typically you’ll want to go for the vendor’s year-end or quarter-endto get the best prices and incentives. Obtain in writing what the expected renewal process and prices are.

Conclusion

Choosing the right endpoint protection platform solution is critical to protecting your business from today’s ever-evolving threats. With an increasing number of EPP solutions to choose from, cutting through the marketing noise is a significant challenge. By applying a standardized evaluation and testing methodology you can ultimately make an informed and objective decision on the right solution for your business.

This is part of a larger series on building a Zeek (Bro) network sensor.

Overview

Zeek (formerly named Bro) is my favorite security monitoring platform, and I’ve used and promoted it throughout my career. It generates rich network metadata that’s incredibly valuable for incident response, forensics, and general troubleshooting.

Perhaps the main challenge with using Zeek is actually setting it up. While today there exists Corelight (an easy-to-use Zeek appliance with enterprise support), not everyone has the budget for something like this. This series will walkthrough Zeek setup, integration with Splunk, and various tips and tricks I’ve learned over the years.

In Part II, we’ll walkthrough several steps:

Configure Zeek to output logs in JSON format for consumption by Splunk.

Create an index in Splunk for Zeek data.

Installing and configuring the Corelight For Splunk app to index and parse Zeek logs in Splunk.

Create a splunk user to run the Splunk Universal Forwarder.

Installing and configuring a Splunk Universal Forwarder to send Zeek logs to a Splunk instance.

Output Zeek logs to JSON

Stop Zeek if it is currently running.

broctl stop

Edit /opt/bro/share/bro/site/local.bro and add the following.

# Output to JSON
@load policy/tuning/json-logs.bro

Restart Zeek and view the logs in /opt/bro/logs/current to confirm they are now in JSON format.

broctl deploy
cd /opt/bro/logs/current
less conn.log

Create an index in Splunk for Zeek data

It’s best practice to create separate indexes for different types of Splunk data.

Login to your Splunk instance.

In the top right menu navigate to Settings -> Data -> Indexes.

In the Indexes page, click on New Index.

Type “zeek” for Index Name and click Saveto create your new index.

Install and configure the Corelight For Splunk app

The Corelight For Splunk app is created by the Zeek team directly for use with Corelight (enterprise Zeek) and open-source Zeek sensors. We’ll use this app to help parse, index, and visualize Zeek logs.

Note that Splunk has also published their own Splunk Add-on for Zeek aka Bro app which helps to ingest Zeek logs but does not feature any sort of dashboards or reports.

Download and install the Corelight for Splunk app onto your Splunk server. This can either be done within the Splunk server itself or by manually downloading and installing as you would all other Splunk apps.

You can navigate to the app to verify that it is installed correctly. However, since we have not yet configured our sensor to send data, the dashboards will be blank.

In the top right menu navigate to Settings -> Knowledge -> Event types.

In the App dropdown menu, select Corelight For Splunk and click on corelight_idx.

In the Search string field type index=zeek. This tells the Corelight for Splunk app to search for data in the “zeek” index we created earlier.

Create a splunk user to run the Splunk Universal Forwarder

Back in the Zeek sensor, create a splunk user and add it to the bro group.

sudo useradd splunk -g bro

Install and configure a Splunk Universal Forwarder

Login to your Splunk account and download the latest Splunk Universal Forwarder. Once logged in, click “Download Now” for the Linux 64-bit .rpm installer. Note that Splunk also generates a convenient wget command you can use from the sensor itself once you accept the license agreement. As of this writing, the latest release is version 7.2.3. If the download URL referenced in the wget command below no longer works, download directly as noted above.

Start the forwarder to accept the license agreement and create an administrative password.

cd /opt/splunkforwarder/bin
./splunk start --accept-license

Stop the forwarder.

./splunk stop

Remove the default data processing limit. Edit /opt/splunkforwarder/etc/system/local/limits.conf and add the following lines.Note that given the volume of data that Zeek generates, the forwarder may never process all log data if the default limit is not removed.

[thruput]
maxKBps = 0 # means unlimited

Edit /opt/splunkforwarder/etc/system/local/inputs.conf to monitor desired Zeek logs. An example inputs.conf is below but may or may not include the logs you wish to ingest. Note that the index and sourcetype fields are leveraging the “zeek” naming scheme to match the “zeek” index we created in Splunk.

Edit /opt/splunkforwarder/etc/system/local/outputs.conf to send data to your Splunk server. In the sample file below, replace each instance of splunkserver:9997 with your own server name/IP and port number.

This is part of a larger series on building a Zeek (Bro) network sensor.

Overview

Zeek (formerly named Bro) is my favorite security monitoring platform, and I’ve used and promoted it throughout my career. It generates rich network metadata that’s incredibly valuable for incident response, forensics, and general troubleshooting.

Perhaps the main challenge with using Zeek is actually setting it up. While today there exists Corelight (an easy-to-use Zeek appliance with enterprise support), not everyone has the budget for something like this. This series will walkthrough Zeek setup, integration with Splunk, and various tips and tricks I’ve learned over the years.

As root/sudo, edit the /etc/sysconfig/network-scripts/ifcfg-<sniffinginterface> file for each sniffing network interface and change or add the following lines. Respectively, each line will disable control from NetworkManager, disable DHCP, and add appropriate ethtool options. Note that after “rx” you want to enter the maximum ring parameter as determined in the step above.

Next, compile the PF_RING libraries, PF_RING-enabled libpcap, PF_RING-enabled tcpdump, and the PF_RING kernel module. Replace the version number placeholders for PF_RING (X.Y.Z) and tcpdump (A.B.C) with whichever versions you’re working with. Including the PF_RING version in the /opt/pfring-X.Y.Z directory name will help you easily identify which version of PF_RING you’re currently running.

If you run into errors compiling the kernel module, make sure your system is up to date and then try rebooting. Typically, the kernel section will fail if the kernel headers you’re compiling against are not the same version as the current running kernel.

sudo yum update
sudo reboot

Test that the module was compiled correctly by loading it with modprobe.

sudo modprobe pf_ring enable_tx_capture=0 min_num_slots=65534

Assuming that the module was loaded correctly, you can view module details in /proc/net/pf_ring/info.

Running the modprobe command above does not persist through reboots. To load the PF_RING module at boot time, we will create two files with the following content. Note that these must be created as root/sudo.
/etc/modules-load.d/pf_ring.conf

# load pf_ring
pf_ring

/etc/modprobe.d/pf_ring.conf

options pf_ring enable_tx_capture=0 min_num_slots=65534

Reboot the server and verify that the /proc/net/pf_ring/info file exists and shows the same details as noted in step 4 above.

Download, Compile, and Install Zeek

We will configure Zeek to install in the /opt/bro directory, using our PF_RING module, and with jemalloc (for improved performance).

As of this writing, the latest release is version 2.6.1. If the download URL referenced in the wget command below no longer works, you can download the latest stable release directly from the Zeek download page.

Add Zeek to PATH

As root/sudo, create /etc/profile.d/bro.sh and add the following.

pathmunge /opt/bro/bin

Configure Zeek

Edit /opt/bro/etc/node.cfg to configure the number of nodes and to leverage PF_RING. It is recommended to use a maximum of one or two less workers than the total number of CPU cores available on your sensor. In the example configuration below we are configuring a total of two workers, load balanced across two CPUs.