Intrusion Detection in AWS, Azure and GCE Environments.

Managing Security At Scale

Your cloud based IDS implementation need to do these 3 things or GTFO.

Rapid And Automated Deployment Of IDS Agents

In cloud-based environments instances go up and down all the time either due to auto-scaling activities or simply due to de-provisioning and provisioning for new stacks.

Whatever the reason, if you think you will be able to open tickets and send your engineers to deploy agents by hand, you’re in for a surprise. Read my lips. A-U-T-O-M-A-T-I-O-N.

Thankfully traditional DevOps approaches deploying IDS agents via Chef, Puppet or Ansible get you there about 80% of the way but they fall short of addressing non-configurational aspects of IDS agent deployment. Pffffff. Let me explain.

Chef, Puppet and Ansible are good for installing and configuring IDS agents but they are not designed to execute non-idempotent tasks such as agent registration, linking or any other runtime aspect of deploying an IDS agent.

Work with your DevOps or SecOps team and to make sure that they overcome this challenge. At Cloudaware we give our customers an IDS agent and all the corresponding SecOps deployments artifacts such as recipes, cookbooks and playbooks that handle not only installation and configuration but also take care of one time activities such as registration and linking.

Cloud Provider Specific Identifiers For Agents and Events

If your IDS relies on IP addresses for agent registration or relies on the IP address for describing event source, throw it in the garbage can.

IP Based IDS Event

Because IP addresses are not only continuously recycled in cloud based environments but also often overlap across multiple AWS Accounts, Azure subscriptions and GCE projects, relying on IP address for identifying agents or intrusion event is careless and misleading.

An IDS designed for cloud will leverage instance id, vmid or whatever cloud provider specific identifier.

Cloudaware IDS Uses cloud provider specific identifies for events and agents

IDS event from Account A, Instance-123 is much faster to respond to than from 10.3.4.2. I might not even know what that server is or which cloud provider or which cloud account it is in or which instance owned that IP address 10 minutes ago.

Do not use IP for agents or IDS events source in the cloud. Use Cloud Provider ID as instance id.

Another common issue with IP based intrusion detection systems is that they cannot handle scaled down instances or essentially do not have auto-forget capability. We have customers who recycle at least several thousand instances per day. But even if it was just a dozen per day, imagine logging into the IDS management console and seeing all those ghost instances that no longer exist or IDS agents in error states because those IP addresses have been re-assigned to different hosts. Nightmare with zombies.

Cloud based IDS needs to know how to handle terminated instances.

Inventory-aware IDS

What in the world does that mean? So you login to your IDS console and it gives you thumbs up. Nobody from Romania is trying to desperately break into your Wordpress database which also happens to be the database with email addresses of every single one of your customers.

What your IDS is not telling you is which of your AWS, Azure or Google instances have no IDS agents installed or broken or stopped.

Cloud based IDS needs to show you which cloud instances have no IDS agent running.

This is my favorite feature in Cloudaware Intrusion Detection. Using its SPOT technology, Cloudaware actually reconciles data from IDS agents with your cloud provider inventory and points out which machines are actually not running IDS agents at all.