AWS Cloud provides endless amount of the capabilities and services. Unleashing all this power on the without proper security review process is extremely risky.
Each service and quite often even each api call should be reviewed and evaluated according to the organizational security standards and compliance requirements. Yes, but.. curently AWS has about 170 services and endless amount of APIs. AWS constantly evolves, introduce new services, APIs and modifying existing.
One of the biggest challenge for me was finding a way to automatically fetch up-to-date annotated list of the services and api provided by AWS. Luckily,
Matt Weagle suggested to use AWS GO SDK as a source of truth. This
SDK provides well documented lists of the AWS APIs (
docs-2.json)
I crafted small python program that builds/updates following yaml files (one per each service) using json files as a source:
guardduty:
description: Assess, monitor, manage, and remediate security issues across your
AWS infrastructure, applications, and data.
links: [http://guardduty.docs.here]
security_risk: Cloud IDS
Allowed_on
- Prod_en
Denied_on:
- none
AcceptInvitation:
description: Accepts the invitation to be monitored by a master GuardDuty account.
links: [https://awsdocs.com]
security_risk: should be allowed only from trusted accounts
Allowed_on:
- none
Denied_on:
- none
ArchiveFindings:
description: Archives Amazon GuardDuty findings specified by the list of finding
IDs.
links: []
security_risk: Not defined
Allowed_on:
- none
Denied_on:
- none
Structure of this file is quite self-explanatory and simplifies security review(still manual process) of the AWS APIs. During security review, you specify which services/api are enabled/disabled and on which environments by adding environment name to the
Allowed_on and
Denied_on lists. Files are stored in the git repo.
After the review, using these files as a source of truth, I (actually another python program) generate an SCP (Service Control Policy) for AWS Organization's accounts, IAM policies and permission boundaries (it depends on the case.)
Due to the
very strict SCP size restrictions , generating this policy using automation allows you:
- aggregate APIs using wildcards to reduce SCP size
- validate API wildcards preventing unintentional service exposure/blockage
- perform cross check for the API to avoid whitelisting/blacklisting conflicts
- re-generate/validate SCP if AWS introduces new API calls/services
Everything mentioned above is valid not only for the SCP, but for the IAM policy/permission boundaries generation process.
This automated approach opens another possibility - automated compliance validation for AWS: using the same yaml files as a source of truth , perform API calls to the AWS to ensure that these calls will fail. This step could be done after deployment (to validate deployment) or on a regular basis(audit).
PS. Unfortunately code of the tools can't be open-sourced as of now.
-
