Cloud Intrusion Detection System (IDS)

Cloud IDS – the newest Google Cloud security feature

Cloud Intrusion Detection System (IDS) is Google Cloud’s solution for detecting network-based threats at both the network and application layers. This includes malware, spyware, command-in-control attacks, and many more. Cloud IDS recruits the best-in-class infrastructure and security for advanced threats from GCP and Palo Alto Technologies respectively. This gives you a cloud-native, managed, and industry-leading security service, without the downside of managing the infrastructure required to host an advanced IDS. It allows you to detect exploit attempts and evasive techniques including remote code execution, buffer overflows, obfuscation, and protocol fragmentation. How does it achieve this?

Cloud IDS is responsible for analyzing and managing the threats that come into your system. It relies on other GCP services within GCP’s ecosystem along with your settings to accomplish this. Traffic from your virtual private cloud (consisting of instances made from Compute or Kubernetes engines) needs to be directed to IDS for analysis. To direct traffic to VMs hosting the IDS system, you first need to specify a Cloud IDS endpoint.

After an endpoint has been specified, traffic from specific instances is cloned by setting up a packet mirroring policy. All the data from the traffic along with packet data, payloads, and headers is forwarded to Cloud IDS for examination. Here, you can select the packets that get mirrored as a result of the high flexibility allowed. You can choose to forward packets from a single or multiple subnets, instances with specific network tags, or even select instances by name.

From here, Cloud IDS VMs analyze the forwarded traffic. It recruits Palo Alto’s security for advanced threats to detect threats within this traffic. Suppose threats are detected, they are logged into Cloud Logging as a result of its integration into the GCP ecosystem. You can view alerts on the Cloud Logging interface and use tools such as BigQuery or PubSub to execute automatic actions depending on the threats that were discovered by Cloud IDS.

Cloud IDS and Palo Alto Networks

Google has been using container technology for a long time; since 2003-2004 when Borg was developed as a small-scale internal project alongside Google’s search engine. It grew with the search engine, as its potential in container technology was used to build virtually everything on Google today. Gmail, Google Docs, GCP, and all other services offered by Google run on Borg. Borg has a basic structure of a single master node, known as the Borgmaster, relaying instructions to agent machines, known as Borglets, responsible for running the nodes in a cluster. The Borgmaster directly interacts with the user to uptake instructions and orchestrate their execution in containers, provided the user has the authority. 

Up to 2013, container technology was entirely internal until Docker came into the picture. At that time Docker was an open-source tool that permitted online software developers to package their applications to be rapidly moved between machines. Docker was embraced by Google the following year as a way to reveal to the general public what had been made possible by Borg. At that time, Docker had one key limitation: it could only run on a single node. This meant that automation was not possible and that each development had to be packaged manually. This could quickly get tedious when workloads moved to tens up to hundreds.