Do I need network intrusion detection in the cloud?
I often speak to those from a data center background about the use of a Network Intrusion Detection System (NIDS) or NIPS (essentially the same, but with automatic blocking of traffic based on detection) in the cloud. In this article, I’ll outline why I think a traditional NIDS doesn’t make sense in the cloud, and what you should be using instead.
Don’t lose sight of why
When people ask me how they can use a NIDS in the cloud, my response is always the same - to ask why they want such a device.
Initially I’m often told that is that it is “best practice” to use one, or some variation of the same - that their security policies mandate use of one, or simply that it’s what they’ve always done. With some further questioning, you can get to the real and perfectly reasonable answer - people want to have some alerting on network traffic that might indicate they have been compromised.
This desired outcome is what we need to hold on to as we take a step back and look at our options.
The uncomfortable truth: NIDS aren’t able to use the vast majority of data they see
In recent years, the ratio of usable to unusable data a typical data center NIDS device receives has significantly reduced. The reason for this is simple - application level encryption is now commonplace, and compounding this most applications use HTTPS, meaning the data seen by a device is both opaque and relatively homogeneous.
In a modern environment, whether in a data center or in the cloud, a NIDS can therefore only usefully utilize a small percentage of the traffic it sees. The metadata that can still be utilized is at the IP level - where machines are connecting to, and how much traffic is being sent. Additionally, there is one protocol which is still typically used unencrypted - DNS.
Cloud provides more options
In the Cloud world, it’s not necessary to have a device running on a ‘mirror port’ receiving all traffic in order to get this data. In AWS, VPC Flow logs provide data on all connections made. The DNS servers provided in every subnet by AWS can log every request. By utilizing these two data sources, it is possible to do exactly the same sort of analysis a traditional NDIS does, but in a hugely more efficient way because only the useful data has to be processed.
This is exactly what AWS GuardDuty does. GuardDuty looks at VPC Flow logs and DNS lookups, alerting on ‘bad’ actions - for example, if a host has looked up DNS for a known botnet, or connected to an IP associated with a command and control endpoint. Whilst GuardDuty wouldn’t usually be described as a NIDS solution, it fulfils the same purpose and in fact uses essentially the same data, just obtained in a different way that means it doesn’t need to process unusable packets.
GuardDuty provides extra protections over and above those offered by a traditional NIDS solution because it also looks at CloudTrail logs. These provide the ability to create new, cloud specific alerts, for example to warn that credentials allocated to an EC2 instance have been used outside your environment, or that someone is logging into the AWS account from an unusual location.
Because all of the data sources used by GuardDuty have full APIs third party vendors could create similar solutions of their own. In practice, most NIDS solutions available on the AWS Marketplace are simply re-packaged versions of vendor’s on-premise software, meaning they offer less protection and require additional configuration to work - typically at a much higher price than GuardDuty itself.
You don’t want an NIDS, you want something better
As in so many other areas, when moving to a cloud environment it makes sense to re-evaluate the ‘best practice’ that was previously taken for granted. As long as we remember not to concentrate on what we believe ‘best practice’ is, and instead focus on why they evolved, it becomes relatively straightforward to decide on the right solution.
And of course, prevention is better than detection and remediation. Corrected Cloud will provide you with prioritized warnings not just about problematic network configurations, but all types of potentially insecure cloud configurations. Get a free automated audit when you sign up for a 14 day trial.
Want help with your AWS security? Get automated monitoring of your AWS security configuration.
Is it more secure to run Lambda inside a VPC?
Does it make sense to force all AWS resources to run inside a VPC? How do we square this 'best practice' with the principle of least privilege?