AWS Inventory and Compliance Framework
AWS Inventory & Compliance Framework
Antiope (PRONO An-Tie-Oh-Pee) is intended to be an open sourced framework for managing resources across hundreds of AWS Accounts. From a trusted Security Account, Antiope will leverage Cross Account Assume Roles to gather up resource data and store them in an inventory bucket. This bucket can then be index by ELK or your SIEM of choice to provide easy searching of resources across hundreds of AWS accounts.
Antiope is given a list of AWS Organizational parent accounts, and will inventory all of the AWS accounts under those parents. For each of the parent & child accounts it will then gather:
All resources are dropped as individual json files into the S3 Bucket of your choosing under
Right now, the primary function of the collection is to solve the needle-in-the-haystack problem. By aggregating all the resources across all accounts & regions into a single place finding resources like IP addresses becomes much easier. Antiope is also starting to track where inter-account trust is occurring and creating a record of accounts outside your organization that are trusted by one or more accounts in your organization.
Finally, the elastic search cluster is being used as a data repository for threat hunting scripts to find things like open Elastic Search or de-referenced CloudFront origins. Those hunting scripts can be found in antiope/search-cluster/scripts/hunt-*
Antiope is somewhat modular in that there are currently three nested CloudFormation stacks that comprise the core functionality. These are intended to be used if needed and ignore if your enterprise has a better solution. The current three modules are:
This stack creates the UserPool and IDPool for Cognito authentication to the Kibana endpoint in the Search Cluster and as a way to authenticate access to the reports stored in the S3 bucket. It's a fairly bare-bones Cognito install and can be extended to leverage SAML federation with your enterprise identity store.
This stack creates the Lambda, DynamoDB, StepFunctions, and associated glue required to collect the resource data across all of the accounts under all of your organizational parents.
This stack creates the (optional) Amazon Elastic Search cluster for searching the resource objects gathered by the inventory stack. This stack also creates the pipeline for SQS & Lambda to detect when new objects are added to the bucket and make sure those objects are indexed.
Currently a work-in-progress, this stack replicates the aws-inventory stack functionality for GCP Projects.
This will be a future addition to Antiope where Turner open-sources the Cloud Security Scorecards we've built for creating executive and technical owner visibility into security issues in each account.
Because the trigger if inventory and account detection is based on SNS Topics and state machines, it is easy to add your own enterprises customizations into the Antiope fold. We're just implementing this now so more details will be here soon.
/CredentialReports/ - Individual Credential Reports for all the accounts and combined reports to see them all as a single CSV /Reports/ - Reports of AWS accounts generated by the inventory phase /Resources/ - All the json files collected in the Inventory Phase /Health/ - All the Personal Health Events /PublicIPs/ - All the public IP address in your accounts. /deploy-packages/ - location of the zip files hosting the lambda & cloudformation templates /config-files/ - place to sync config files used to manage Antiope
Most resources use the normal resource prefix (vpc- for VPC, i- for Instances, etc). Where the unique identifier for the resource didn't have a prefix, or where the resource name can be duplicated across accounts, Antiope prepends a resource prefix. The following prefixes are inventoried: