|
|
|
|
|
by david_obrien
1570 days ago
|
|
Thanks! Based on my understanding of CloudGuard we differentiate again by the "automated investigation" we do. It's not just a "you have misconfigured this thing here" but then also "because of that misconfiguration this following resource is now exposed to the internet (we checked, it is!) and it's exposing these other resources as well, look, here's a diagram that shows you this." This is what products like CloudGuard expect you to manually do. They approach security from a compliance point of view. "You are violating control XYZ from framework ABC, so you are less secure."
Unfortunately, it's not that simple. An AWS EC2 instance should not have a Security Group on it that allows RDP from the internet, that's true and should probably be flagged, but in itself is not a security issue. It only is if the EC2 has a public IP (or a public Load Balancer), the VPC has an internet gateway and there's no NACL blocking the traffic.
This is just one part of what ARGOS checks, what others just don't and expect you to do manually, for each of their hundreds and thousands of critical detections. |
|
> Based on my understanding of CloudGuard we differentiate again by the "automated investigation" we do. It's not just a "you have misconfigured this thing here" but then also "because of that misconfiguration this following resource is now exposed to the internet
CloudGuard does this exact same thing. WE just had our AWS env. scanned and they did tell us that one of our S3 buckets had a wildcarded principle. It documented the exact bucket name and the policy we used.
I agree that the diagram is something I haven't seen from other vendors in the space.
But I am still struggling to understand the differentiation of the other features.