Tuesday, February 26, 2019

Revamping AWS APIs' security review and SCP policy generation process.

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:

  description: Assess, monitor, manage, and remediate security issues across your
    AWS infrastructure, applications, and data.
  links: [http://guardduty.docs.here]
  security_risk: Cloud IDS
  - Prod_en
  - none
  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
  - none
  - none
  description: Archives Amazon GuardDuty findings specified by the list of finding
  links: []
  security_risk: Not defined
  - none
  - 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.

No comments:

Post a Comment