search

mitre / heimdall_tools

DEPRECATED: A set of utilities for converting and working with compliance data for viewing in the heimdall applications
https://heimdall-tools.mitre.org
Other
35 stars 20 forks source link

AwsConfigMapper - allow VPC endpoint & map based on source identifier #87

Closed jkufro closed 3 years ago

jkufro commented 3 years ago

Summary of Changes:

Allow use of VPC Endpoint for AwsConfigMapper

I added this just to the Ruby AwsConfigMapper class. It did not make sense to add this option to the CLI because VPC endpoints are generally locked down within VPCs and not accessible from outside of the VPC.

This allows the use case where you have a lambda with no outbound access that needs to interact with an AWS Config VPC endpoint to access AWS Config results.

Mappings now based on AWS Config Rule Source Identifier instead of AWS Config Rule name

This likely is the way this should have been set up in the first place. AWS allows you to create rules with basically any name, and then point that rule name to a specific source (this can be an AWS managed rule identifier such as IAM_PASSWORD_POLICY or a custom config rule's arn identifier).

With this change you can create an AWS Config Rule with any name and as long as it points back to a mapped source identifier, then it will be mapped to the proper NIST-IDs from aws-config-mapping.csv.

aaronlippold commented 3 years ago

@ejaronne @jkufro I was looking at the mapping file for this end it seems to be multiple 853 controls this would seem to make the map nondeterministic. Can you to take a look at this and decide if this is really what we want. As we did with the others, We may want to pick the best first control

jkufro commented 3 years ago

@ejaronne @jkufro I was looking at the mapping file for this end it seems to be multiple 853 controls this would seem to make the map nondeterministic. Can you to take a look at this and decide if this is really what we want. As we did with the others, We may want to pick the best first control

@ejaronne @aaronlippold This was originally pulled from the AWS provided mapping (linked here) where AWS managed config rules show up multiple times in the table for different controls.

ejaronne commented 3 years ago

@ejaronne @jkufro I was looking at the mapping file for this end it seems to be multiple 853 controls this would seem to make the map nondeterministic. Can you to take a look at this and decide if this is really what we want. As we did with the others, We may want to pick the best first control

@ejaronne @aaronlippold This was originally pulled from the AWS provided mapping (linked here) where AWS managed config rules show up multiple times in the table for different controls.

I have no issue with this kind of mapping. For example, many individual STIG requirements are associated with multiple 800-53 controls. In the case of https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-nist-800-53_rev_4.html, they mapped individual 800-53 controls to the a related config rule. The sample https://github.com/mitre/heimdall_tools/blob/master/sample_jsons/aws_mapper/aws_config_hdf.json shows this, and that is expected since 800-53 controls overlap and complement each other. Most times, there is no "best first control". image