If you read the prior blog post, How to dynamically correlate Google Cloud Compute Engine instance network traffic using Chronicle, you understand how we can dynamically correlate IP addresses in network traffic logs, like Zeek, to the cloud compute instance hostname.

The next problem we have to solve is how we can create alerts on these data to identify when a cloud instance reaches out to a new domain.

To get a list of unique domains, you COULD take all of the Zeek http.log and ssl.log files, put them into a SIEM, and run a query for distinct domains. Then, you can look through the list to validate they are approved, add those domains to your allow list, and alert on anything outside of it.

Voila! Done!

Well…not really. Let’s look at a scenario.

Your production application reads from and writes to Google Cloud Storage (GCS). BUT, what if your nginx server reaches out to GCS? Well, that’s odd and unexpected. Unfortunately, you had a single, huge allow list that said your compute instances could reach out to GCS so you won’t be alerted.

Ok, we need to make this a little more specific and create an allow list by instance or instance type, e.g. nginx, haproxy, jump servers, and different Google Kubernetes Engine (GKE) node pools.

You can take the smart people you hired, have them manually create an alert, and spend weeks tuning it until it’s right. If they partake, buy them a few bottles of their favorite adult beverage. If not, maybe a homemade treat. They’ll need the stress relief.

With Chronicle, there’s a simpler, automated option.

First, we need to create a list of Compute Engine instance name prefixes that will be used as our “instance types.” Let’s look at 3 different categories:

1. Manually created instances:

• Example name: jump1-prod-us-east-1

• Prefix example: “jump”

2. Managed Instance Groups (MIG):

• Example name: nginx-production-2j3l; Format: {instance-group}-{GCP-created-unique-identifier}

• Prefix example: “nginx” to group environments or “nginx-production” to separate environments

3. Google Kubernetes Engine (GKE):

• Example name: gke-prod-application-flink-452f94ad-5k1jf; Format: {cluster}-{node-pool}-{GCP-created-unique-identifier}

• Prefix example: “gke-prod-application-flink

Once you’ve gone through all of the Compute Engine instances in your environments, you’ll have a list of prefixes that you can use to create unique allow lists.

The next part will leverage 4 Chronicle APIs to automate the rule creation.

1. Create rule

2. Edit rule

3. Retrohunt: Run a rule against historic data to identify detections, aka matches

4. List detections: Get matches to your rule

Let’s get going!!

Setup:

1. Download and setup the Chronicle API, api-samples-python repository, from GitHub

2. Copy the custom .py scripts from GitHub into the detect/v2 folder

3. Update the variables in the constants.py file

Now

• Grab someone from your SRE and/or engineering team

• Look through the lists to validate these domains are approved

• Make the rules live and enable alerting.

The last thing you could do is some manual combinations of these allow lists.

For example, let’s say you have gke-holding-application, gke-staging-application, and gke-production-application. If you don’t want to track domain access as it moves through the development lifecycle, you can combine all of these into one large allow list with a regex, like below.

Now, with a simple script and small amount of work, you have an allow list tailored to your environment and can alert on any deviations from that baseline!

Thanks for tuning into this blog post series about the importance of network security telemetry, and how you can use Chronicle for cloud network traffic use cases. To learn more about Chronicle, complete the Contact Sales form.