delta would be less ootb policies (though lots of github repos with examples re awesome custodian lists), and more user defined policy as code (dsl and gitops style) with integration into serverless provider platforms for continuous monitoring, along with remediation support and platform integrations (security hub, google cloud security command center, etc).
One thing people have to keep in mind when running these kinds of tools is they make tons of API calls. Depending on how you have things set up, use these tools can drastically increase your CloudTrail bill.
Also, they'll often make calls against non-existent resources or run into permissions issues. So it can clutter your CloudTrail with API errors, making actual API errors harder to locate.
You're correct about the API calls & potential CloudTrail costs.
Regarding making calls to non-existent resources that doesn't tend to be an issue. Typically we start by making a call to whatever endpoint lists resources, and then fetch additional information for these resources.
It does one thing very well: quickly grabbing a snapshot of the security posture of a public cloud account's resources with little fuss. It's an ideal solution as an outsider looking in at someone's account. But, I wouldn't use it as-is for other needs (say, those of in-house security folks) like continuous monitoring. That would be like using a Polaroid camera to create a movie.
I find it disruptive as a developer in an organization that used to run it very frequently. It aggressively crawls your infrastructure and blows up AWS API calls with low rate limits, like the EMR cluster description operations.
Have a look at the `--max-workers` and `--max-rate` arguments, which allow controlling the rate of API calls made against the cloud environment. You can use these to tweak executions against environments and ensure you don't hit API caps.
Note that this isn't a Scout Suite issue per se, but the consequence of how AWS implements rate limiting (i.e. it's account-wide, not per-principal). Any AWS tool will face the same limitations / hurdles.
I apologize for the uncharitable description. It was more of an organizational issue. They could have picked any other tool to execute a self-inflicted DoS and I would have been upset with that instead.
For what provider are you having issues? It's been complicated to support GovCloud accounts for AWS/Azure as we don't have access to any accounts. If you'd be so kind as to support us with this then please get in touch via GitHub issues (https://github.com/nccgroup/ScoutSuite/issues) or directly at scoutsuite@nccgroup.com.
Correct, Scout Suite is inherently multi-cloud and has mature support for AWS/Azure/GCP. This is very useful for organizations that want to leverage a single tool to assess the posture of all their environments.
AWS Inspector allows assessing the baseline security of EC2 instances / hosts, i.e. against CIS benchmarks (https://docs.aws.amazon.com/inspector/latest/userguide/inspe...). Scout Suite assesses the security posture of the cloud environment as a whole, across all [supported] services. It looks at things such as encryption, configuration of Identity and Access Management, resilience, backup configuration, privilege escalation vectors, etc.
delta would be less ootb policies (though lots of github repos with examples re awesome custodian lists), and more user defined policy as code (dsl and gitops style) with integration into serverless provider platforms for continuous monitoring, along with remediation support and platform integrations (security hub, google cloud security command center, etc).
other tools in this space on the detect and report side (albeit aws specific) https://github.com/toniblyx/prowler https://github.com/jonrau1/ElectricEye
on the gcp side forseti, https://github.com/forseti-security/forseti-security