Create `include/check_creds_last_used` and move all logic for checking last usages of passwords and access keys there
Modify check13 and extra774 to call new function, specifying time-range of last 90 days and last 30 days respectively
Modify messages in check14 and check121 so that all mentions of 'access key's are consistent
Fixes#496
Remove the second entry in any comma-separated check IDs from each check, formatting
the check ID with leading zeros in `include/outputs` if the `-n` flag is active
According to the benchmark, only users with a console password should be considered for this check,
therefore filter out any users who do not have a console password
Fixes#513
A user who has never logged into the console, or not logged in since Oct 2014 will present as 'no_information' in the
'password_last_used' column of the credential report. Handle this scenario and output a failed message if it has been
more than MAX_DAYS days since the user was created, or an info message if it is less than MAX_DAYS
Fixes#501
- Move Security Hub related code to a dedicated include/securityhub_integration file
- Check that Security Hub is enabled in the target region before beginning checks when -S is specified
- Add error handling to the batch-import-findings call
- Add CHECK_ASFF_TYPE variables to all CIS checks to override the default
- Add support for CHECK_ASFF_RESOURCE_TYPE variables which override the default 'AwsAccount' value for the resource a finding relates to.
- Add CHECK_ASFF_RESOURCE_TYPE variables to all checks where there is a suitable value in the schema
- Remove json-asff output for info messages as they are not appropriate for possible submission to Security Hub
- Update the README to cover Security Hub integration
- Add an IAM policy JSON document that provides the necessary BatchImportFindings permission for Security Hub
- Remove trailing whitespace and periods in pass/fail messages to be consistent with the majority of messages, to prevent future tidy-up from changing the finding IDs
Buckets that log to one or more trails are logged as `PASS!` for each trail they are associated with.
Buckets that aren't associated with any trails are logged as `FAIL!` once.
```
...
PASS! : S3 bucket bucket-one has Object-level logging enabled in trails: arn:aws:cloudtrail:eu-west-2:123456789012:trail/central-trail
PASS! : S3 bucket bucket-two has Object-level logging enabled in trails: arn:aws:cloudtrail:eu-west-2:9876543210989:trail/trail-two
PASS! : S3 bucket bucket-two has Object-level logging enabled in trails: arn:aws:cloudtrail:eu-west-2:123456789012:trail/central-trail
PASS! : S3 bucket bucket-three has Object-level logging enabled in trails: arn:aws:cloudtrail:eu-west-2:123456789012:trail/central-trail
...
```
This change should also address #387
