Insights > Network Visibility + Security

How to Use Keysight Threat Simulator for Firsthand Detection Experience with New Google Cloud IDS Service

2021-08-06  |  9 min read 

Google Cloud just launched a native Cloud IDS service, currently available in a preview. The service is built with Palo Alto Networks’ threat detection engine. As part of an early access program, I had a chance to test it. At Keysight, we have a range of tools that are used by many security vendors to validate the efficacy and performance of their products during development. But in this case, I thought it would be beneficial to look at Cloud intrusion detection systems (IDS) from the perspective of a Google Cloud customer. As with most cloud services, there are little to no barriers in trying Cloud IDS, and so it made sense to publish a cookbook on setting up a validation sandbox any customer could follow and decide if Cloud IDS is a good fit for their environment.

For this sandbox, I went with Threat Simulator, Keysight’s breach and attack simulation tool. Threat Simulator is offered as software as a service (SaaS) and has a trial period, so anyone can build the same setup right away.

Google Cloud IDS Deployment

First, let’s review how Cloud IDS fits into a Google Cloud deployment. It operates in a passive mode by analyzing traffic from Google Cloud instances. To get access to the traffic, Cloud IDS utilizes a native Google Cloud Packet Mirroring service. Before Cloud IDS introduction, to achive similar capabilities with the PAN offering from the Google Cloud Marketplace, a customer would need to deploy one or more PAN instances, configure them to act as IDSs, and then create a Packet Mirroring policy to copy traffic from workloads to these PAN IDS instances.

With Cloud IDS, there seems to be automation and heavy lifting in the background, that  significantly simplifies the deployment from a Google Cloud customer perspective. Instead of deploying multiple PAN IDS instances from a Marketplace, we can now create Cloud IDS Endpoints for each VPC network, Google Cloud Region, and Zone where detection is needed. And there is only one parameter beyond that, which is a minimum threat severity alert.

Creating Cloud IDS Endpoint

Once the endpoints are created, we can attach them to one or more groups of workloads. This, in effect, would create a Packet Mirroring session, but with most of its intermediate steps hidden from the user.

Attaching packing mirroring policy to Cloud IDS endpoint

Google Cloud solves several maintenance overheads here for us:

  • Simplified deployment process, without unnecessary complexities of third-party deployments.
  • The IDS service is automatically scalable to handle the volume of traffic we copy to it, but this is hidden behind a single endpoint.
  • We don’t have to maintain each individual third-party IDS  instance - no version upgrades, no threat signature updates, no user access to manage.
  • Packet Mirroring policy creation is also simplified. 

Getting Ready to Misbehave with Keysight Threat Simulator

Now, once we have a Cloud IDS endpoint ready, let’s see it in action. Instead of spending efforts on deploying instances with vulnerable applications to attract bad actors, and then waiting for somebody to attack them, we will simulate threats using the SaaS-based Keysight Threat Simulator breach and attack simulation platform.

Threat Simulator acts as a Dark Cloud residing outside of the user's network, as well as one or more agent workloads we need to deploy inside our VPC network to act as a vulnerable application. Under the orchestration of the Threat Simulator service, we can initiate an attack from the Dark Cloud on our agents. We can also instruct the agent to initiate an unsafe behavior by “accidentally” accessing the Dark Cloud services and downloading malware. Finally, we can conduct an experiment where one of the agents acts as an infected workload, attacks other workloads, and uses lateral movement to spread malware. All of these could be steps of a kill-chain activity that can be launched by Threat Simulator at once. Note, this well-orchestrated activity is a completely safe simulation, and no real breaches or malware deployment can occur. But it is a very close analog to real malicious activity from the Cloud IDS perspective.

For the Cloud IDS to detect these simulated threats, we need to attach it to Google Cloud workloads where Threat Simulator agents are deployed. Once done, we are ready to misbehave.

Running CISA Top-10 Server Side Audit

To make this post relatively short, I’m going to pick a simple scenario in which a few attempts (four, to be exact) to attack our workload would come from our Dark Cloud, targeting well-known high-severity vulnerabilities in Apache Struts, Drupal CMS, Microsoft Sharepoint, and Microsoft SMB services. These attacks, which are audits from a Threat Simulator point of view, would need to reach our agent workload to be detected by the Cloud IDS. Therefore, Google Cloud firewall rules should permit inbound traffic to the agent’s public IP over ports TCP/80, 443 and 445. In this example, we are going to run the scenario over plain HTTP. 

CISA Top-10 Server Side audit results

After running the scenario, we see that from the Threat Simulator perspective, all four audits were executed without being prevented or detected. This is expected - Cloud IDS is a passive service only capable of detection, and we don’t yet have integration between Threat Simulator and Cloud IDS to validate if the detection was successful. We need to check the Cloud IDS dashboard to find that out.

Analyzing Cloud IDS Events

As we can see, the Cloud IDS was able to successfully detect all four attacks by logging a detailed record for each threat it encounters.

Threats detected by Cloud IDS

We have an option to drill down into details of each threat and see references to a unique Threat ID, which are the same IDs PAN's Threat Vault is using. This means that although there is no direct link from the Cloud IDS threat details page to the Threat Vault, it is straightforward to locate such a record. And we also get a reference to the CVE ID.

Cloud IDS detected threat details
Threat IDs identified by the Cloud IDS match those initiated by Threat Simulator. Here are details from the recommendations page for the Apache Strut vulnerability. You can see a matching Threat ID of 34221 as well as the CVE record.

Details of Apache Strut attach in Threat Simulator

Finally, there is an ability to drill down into Cloud Logging services to see raw details of the detected threats. This last bit reveals capabilities for downstream processing of Cloud IDS events by various SIEM tools.

Threat event message in Cloud Logging

How to Repeat

If you become interested in testing the efficacy of Cloud IDS for your environment and types of traffic, please refer to the cookbook I published on Github with step-by-step instructions for deploying Keysight Threat Simulator agents and setting up a Cloud IDS to monitor them.