One of the impacts of the enterprise transition to cloud is confusion. From a security perspective, what no longer needs to be done, what needs to be done in a different way, and what new things need to be done that we never had to do before. These are questions we get from customers all the time. There are highly risk-tolerant organizations that perceive that all you need is a threat detection service done in a cloud-native way and there is no need for prevention.
There are some auditors who will even accept AWS GuardDuty to satisfy the PCI DSS and other compliance requirements for IDS / IPS. When I hear this, I have to do a double take!
GuardDuty was never intended to satisfy IDS / IPS requirements. In this blog, I’d like to set the record straight on why relying on GuardDuty alone for threat prevention isn’t enough – for security and compliance.
Decryption Is Essential to Detect the Real Cloud Threats
There are really two issues here – first, detection. Second, prevention. In the cloud, there is a temptation to throw out all we’ve learned over the years about detecting threats, because, well, cloud is different. The reality is that detecting threats is hard – and requires a bunch of techniques – decryption, deep packet inspection, signatures, anomalous behavior detection, malicious source detection, and several other approaches. These are tried and tested, and may need to be re-implemented in the cloud. The second issue, prevention, needs to be integrated with detection, otherwise the best result is a race condition (racing to block the attack with another mechanism before the attacker is successful). Besides, what folks really want is a stopped threat, not another alert.
Threats like Log4j showed us what we seem to learn time and again. Detection that’s based on high-level visibility on encrypted traffic is limited at best and misleading at worst. The only way to get true visibility in the cloud where much of the traffic is encrypted is through deep packet inspection (DPI) with signature based detection and the ability to prevent – what we more commonly discuss as IPS.
On the compliance side, much of this is settled. The current interpretation of PCI DSS is that IDS / IPS is a network-based solution requiring DPI. DPI can only be done if traffic is decrypted. In cases where traffic can’t be decrypted, examination of logs is a form of HOST-BASED IDS that can serve as a backup, but it’s not the primary and it’s limited to detection.
AWS GuardDuty Is Not IPS (And Was Never Meant To Be)
The need for IPS in the cloud still remains. In fact with multi-cloud becoming more and more adopted, with a detection based strategy alone, teams will simply be flooded with alerts. What organizations really need is the ability to block the obvious threats and only alert on what’s essential (note that this is the second issue raised above).
AWS GuardDuty analyzes your cloud environment event data in Cloudtrail event logs, VPC flow logs, DNS logs and EKS audit logs. It looks within these logs for high-level anomalous activity (e.g., traffic to known malicious domains or countries without a tie to the business – a form of URL filtering or geolocation), identifies potential malicious sources, and provides an alert for further investigation. This often means that it can’t confirm an attack until after the fact.
The actual prevention after detection can only be enforced via another tool or service. At the most, what can be done here is malicious IP addition to block traffic. This is the race condition mentioned above.
The need here is an integrated detection and prevention based on content (not just high-level traffic attributes that signify the possibility of an attack) in a cloud-native way for multiple clouds. This is where Valtix comes in to address an important security gap in the cloud.
The majority of attacks work under the covers of encrypted traffic and inside the content. If you don’t have visibility into this, you are basically flying blind for a significant portion of time – the time when the attack is launched and landed.
AWS GuardDuty has zero visibility into encrypted traffic and while it may be an interesting tool for AWS-only organizations, it’s not what enterprises need in an IPS. It’s good for understanding anomalous behavior, but solely relying on it for detection leaves organizations blind to a variety of threats. It also leaves them several steps behind an attacker by the time an alert is actually investigated.
The following table summarizes AWS GuardDuty vs. Valtix (Multi-cloud Threat Prevention / IPS)
| Feature | AWS GuardDuty | VALTIX |
| Analysis from Cloud-native logs | CloudTrail Event Logs VPC Flow Logs DNS Logs EKS Audit Logs |
CloudTrail Event Logs VPC Flow Logs DNS Logs |
| Inline Traffic Inspection | No | Yes |
| Decryption | No | Yes |
| Content Inspection | No | Yes |
| C&C Activity | Only based on 5-tuple from VPC Flow Logs (this detection is superficial at the best – only looking at where traffic is going, not what it is (e.g., C&C traffic) |
Deep Packet Inspection Based (C&C activity is much more sophisticated and uses http headers which are embedded deep inside encrypted payloads) |
| Malicious Domain or IP Activity | Yes. Integrated with threat intel from Proofpoint, Crowdstrike | Yes. Integrated with threat intel from Trustwave, Talos, BrightCloud. |
| Malicious S3 Bucket Activity | Yes | No |
| Threat Remediation | Duct-taped with CloudWatch and Lambda. Integration burden falls squarely on customers. Huge operational effort required as threats evolve and the need for maintaining backward compatibility. |
Detection and Prevention are tied together in the service. |
| High Availability, Autoscaling | Yes | Yes |
| Multi-Cloud | No | Yes |
| Pricing | Based on data processed. Very difficult from a budget planning perspective and can have surprising impact on overall cost | Predictable. Service uptime based and not based on data processed. Easy for annual budget planning. |
| Ease of Deployment | Minimal clicks. Easy. | Minimal clicks. Easy. |
| Automation | Terraform or APIs | Terraform or APIs |
Let’s take the example of log4j kill chain which was a source of major heartburn in the industry and see how AWS GuardDuty and Valtix fare.
| Gate# | Gate Description | AWS GuardDuty | Valtix |
| 1 | Ingress
Needs decryption and looking at the user-agent http header |
No | Yes |
| 2 | Lateral movement from webserver to log server
Content inspection to look for string passed to log4j. Needs decryption and deep packet inspection |
No | Yes |
| 3 | Egress to malicious LDAP server
Content inspection to look at LDAP query strings |
No | Yes |
| 4 | Response Detection
Content inspection of LDAP response looking for the malicious java class |
No | Yes |
| 5 | Malicious code execution triggering executing outbound attempts | Maybe | Yes |
As can be seen from the above, AWS GuardDuty is flying blind most of the time even from a detection point of view. Valtix on the other hand has both detection and prevention working in tandem. The need for multi-cloud detection and prevention remains, and is critical for multi-cloud enterprises (which is nearly everybody). This is what’s required to meet both security and compliance requirements for enterprises in the cloud. And meeting that need is a focus for Valtix.
