Getting the most out of Cloud IDS for advanced network threat detection

Google Cloud IDS, now generally available, delivers cloud-native, managed, network-based threat detection, built with Palo Alto Networks’ industry-leading threat detection technologies to provide high levels of security efficacy. Cloud IDS can help customers gain deep insight into network-based threats and support industry-specific compliance goals that call for the use of an intrusion detection system. In this blog, we’re diving deeper into how Cloud IDS works to detect network-based threats and how you can get the most out of a Cloud IDS implementation.

Getting the most out of Cloud IDS

The implementation of an Intrusion Detection System (IDS) into virtual cloud networks has been a requirement for many cloud customers as a key measure to help keep their networks safe.  

The best practices and design strategies to integrate such a system have changed and matured with new technologies in cloud networking. Overcoming issues such as network bottlenecks and the inability to inspect intra-VPC (east/west) traffic has historically troubled network and security teams. Google Cloud IDS is deployed “out-of-path”, abating both of these concerns. Cloud IDS uses Packet Mirroring to copy and forward network traffic, and Private Service Access (PSA) to connect to a set of cloud-native IDS instances which exist in a Google managed project. This allows a Cloud IDS to be seamlessly integrated into an existing Google Cloud Platform (GCP) network without needing to change the VPC design.

In order to provide visibility into threats and intrusions detected by IDS instances, Cloud IDS feeds Threat Logs and Security Alerts into Cloud Logging and the Cloud IDS user-interface in the customer project. This is all done under the hood, making it simple to deploy and manage Cloud IDS. Here are some finer points to know and consider when deploying Cloud IDS:

• Everything starts by creating a Cloud IDS Endpoint -- a collector of connection flows -- which, behind the scenes, deploys three Palo Alto VM-Series firewall virtual machines (VMs), which live in a Google Cloud managed project.

• During the IDS Endpoint creation process, the zone and VPC being analyzed must be specified. A specific Cloud IDS instance is capable of inspecting traffic within a region of a VPC.

• Updates from Palo Alto Networks are picked up weekly by Cloud IDS and pushed to all existing IDS endpoints

• During Endpoint creation, you’ll choose a minimum alert severity level from critical (least verbose) to informational (most verbose).  

• To feed traffic to the IDS, you will create and attach a Packet Mirroring Policy to the Endpoint.

When creating the Packet Mirroring Policy to attach to your Cloud IDS, there are three options to select the mirrored sources: subnets, tags, individual instances.

• Subnets: Subnets are useful when every instance in a subnet needs to be analyzed. A policy can contain up to 5 subnets.

• Tags: Tags are useful when groups of instances in one or multiple subnets need to be analyzed. A policy can contain up to 5 tags.

• Individual instances: Use individual instances only when very select instances need to be analyzed. 50 instances are allowed per policy.

Now that you are more familiar with some of the features and steps to create a Cloud IDS, let’s get into some key points that can help to get the most out of your deployment.

Use the right mirrored sources and filters for Packet Mirroring for better control of inspected traffic

Inside a Packet Mirroring Policy, there is an option to filter traffic. It is important to understand that an IP based filter assumes that the address range specified is the remote subnet. In other words, for ingress traffic, the filter address range would be the source network and for egress traffic it would be the destination network. Do not use IP based filters in your packet mirroring policies if the remote network is unknown, such as general, Internet-based traffic. If you do choose to use filters, be aware that you might prevent the Packet Mirroring Policy from sending traffic to the IDS leaving more chances for false negatives. Also, if you choose to use filters, make sure to keep in mind the filter order for Packet Mirroring. A misconfigured filter strategy can mirror traffic away from your Cloud IDS. Lastly, always capture bidirectional traffic in the Traffic Direction filter option.

There are some use cases, however, where filters may be quite useful. For example, consider the case where you want to have different alert severities for trusted and untrusted remote networks. In this case, you could create two IDS Endpoints with the same mirrored sources but different filters and “Minimum Alert Severity”. This configuration would push the more trusted remote network traffic to the IDS Endpoint with a more moderate Alert Severity Level and general Internet traffic to the IDS Endpoint with more verbose alerting.

In this example, traffic sourced from trusted network 10.2.0.0/16 would be analyzed by ids-endpoint2 and alert on “Medium” level (and above) severity. However, traffic sourced from the untrusted Internet would be mirrored to ids-endpoint1 and alert on “Informational” (and above) level threats. Note that “Internet IP” in the following screenshot will actually show the source address as seen by the mirrored VM.

Attach multiple Packet Mirroring Policies to the same IDS Endpoint

Cloud IDS offers flexibility when attaching Packet Mirroring Policies. Multiple Packet Mirroring Policies can be attached to the same IDS Endpoint. For example, a Packet Mirroring Policy that mirrors traffic for “app1” tagged instances and a second policy that captures traffic for “app2” tagged instances can both be attached to “ids-endpoint-1”.  An alternative is a single policy that captures traffic for both network tags. Because a policy can only have up to 5 tags today, when you need to add a 6th tag to the policy, you would have to attach a 2nd policy to the IDS Endpoint.

Once a policy is attached, it can be edited as with any other Packet Mirroring Policy. To remove the policy from the endpoint, simply delete the policy; it can always be recreated. There is currently no “detach” option.  

Use Shared VPCs and a single Cloud IDS for multiple projects

If your organization has a centralized networking and security team supporting various projects, and multiple projects require IDS coverage, consider using a Shared VPC. By using a Shared VPC, a single Cloud IDS can support multiple projects as these projects share network resources, including Cloud IDS. The IDS Endpoint must be created in the Host project where the shared VPC actually exists. Cloud IDS in a Shared VPC supports the same three types of mirrored sources as in a conventional VPC, including individual instances that exist in the service projects.

Use HTTPS load balancers to offload SSL

Cloud IDS inspects not only the IP header of the packet, but also the payload. In the case where the payload is encrypted, such as with HTTPS/TLS/SSL traffic, consider placing the application behind a L7 Internal Load Balancer (ILB) or HTTP(S) External Load Balancer. By using these types of load balancers, SSL decryption can be addressed at a layer above the mirrored instances and Cloud IDS would see SSL decrypted traffic and thus be able to inspect and detect intrusions and threats. To learn more about encryption from Google Front Ends to the load balancer backends, see this document.

Integrate with SIEM/SOAR solutions for additional analytics and action

Logs from Cloud IDS can be sent from Cloud Logging to 3rd-party tools (e.g., Security Information and Event Management (SIEM) systems and Security Orchestration Automation and Response (SOAR) systems) for further analysis and responsive mitigating action, as defined by your security operation teams. Third-party SIEM and SOAR systems can be configured to run playbooks that will automatically block an attacker’s IP address based on the information ingested from Cloud IDS. Whether using automation or manual efforts, be careful when blocking the recorded source IPs for targets behind proxy based External or Internal Load Balancers. Proxy based load balancers will translate the true source address with a proxy address and denying a perceived attacking address may result in also blocking legitimate traffic.  Consider using Cloud Armor for this level of security. The Web Application Firewall (WAF) and Layer 4 based access control features of Cloud Armor occur before the Cloud Load Balancer’s source NAT, making for a great combination in a security suite.

Adding Cloud IDS to your security toolbox

Being cloud-native and Google Cloud integrated, Cloud IDS is simple to deploy, provides high performance and can be up and ready in just a few clicks. Adding Cloud IDS to your existing VPC is easy and requires little to no network redesign because it is placed “out-of-path”. It can be fully deployed, running and alerting quickly. It may also help satisfy your compliance requirements that mandate the use of an intrusion detection system. 

To help you get started with Cloud IDS, watch this video, and to sign up for access to the preview, visit our webpage.