Thanks for the great document on Operational Best Practices for FFIEC, which is of great help and gives a good understanding of governing our AWS Accounts better.
We at Steampipe are relying on this to build compliance mod for FFIEC. While I was going through the FFIEC document to understand more about this, I did notice a small deviation in the Control ID for D1.G.RM.Rm.1

I believe the Control IDs in the document follow the pattern "Domain > Assessment Factor > Component > Maturity Level > Declarative Statement". Below is a screenshot from the FFIEC documentation which talks about the bits and pieces in the document.

For example:
The below screenshot talks about the declarative statement from "Domain1 > Training and Culture > Training > Baseline > 2" Annual information security training includes incident response, current cyber threats (e.g., phishing, spear phishing, social engineering, and mobile security), and emerging issues. The Control ID for this corresponds to D1.TC.Tr.B.2.

Likewise, I believe the baseline "Domain 1 > Risk Management > Risk Management Program > Baseline > 1" should have the Control Id as D1.RM.Rm.B.1 and not D1.G.RM.Rm.1

Also, the "Control Description" for D2.TI.Ti.B.3 should be Threat information is used to enhance internal risk management and controls. and not Threat information is used to monitor threats and vulnerabilities.

I could be wrong in my approach as well, happy to learn and understand the deviation in naming the Control Id as D1.G.RM.Rm.1. Let me know if you need any more information. Thank you!

Problem:
The following page lists AWS Config managed rules:
https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html

Each rule is listed by some identifier, for example approved-amis-by-id.

However, this is different to the identifier used by the API and CloudFormation (eg: APPROVED_AMIS_BY_ID), which can only be found by visiting the page for that rule specifically and looking up the Identifier which is different.

It's easy for a reader of the documentation to look at the listing and confuse the two.

Suggested Resolution:
Any of the following seem like reasonable improvements to help reduce confusion:

1. Use the Config Identifier (eg: APPROVED_AMIS_BY_ID instead of approved-amis-by-id) in the documentation pages.
2. Use plain english names for each rule in the documentation pages.
3. Put a warning on the listing page to indicate that the rule identifiers required by the API are on the pages themselves.

Commentary:
It's easy for a reader of the documentation to get confused (it tripped me up!).

It seems like the identifiers used on the listing page only exist for the purposes documentation, so I'd definitely lean towards item 1 or 2 on the list above.

Section `Setting Up Auto Remediation (Console), step 3:

On the Edit name of the rule page, in the Choose remediation action section, choose the appropriate remediation action from the recommended list.

This is not correct anymore.

The right step would be something like:

Select an existing rule, click the "Actions" dropdown menu, then choose "Manage remediation".

Problem:

Documentation for amisByTagKeyAndValue parameter in approved-amis-by-tag rule is very ambiguous when it comes to multiple values of the same tag or multiple tags:

The AMIs by tag (comma-separated list up to 10; for example, "tag-key:tag-value").

At a straightforward interpretation of the above this implies that for multiple values of the same tag this should work: tag1:value1,tag2:value2, but it does not.

Suggested Resolution:

The example in documentation could be more extensive:

The AMIs by tag (comma-separated list up to 10; for example, "tag-key1,'tag-key2:value1,value2',tag-key3:value3" would match AMIs with tag-key1 or tag-key2 having values value1 or value2, or tag-key3 with value3).

Commentary:

I couldn't find if there is any other, more extensive, examples for this config rule, but I think it would save users time debugging the issue or waiting for an explanation from support.

Note, english is a second language to me so suggested resolution text above should be proofread.

Expected Behaviour:
Documentation to be present in the repository so customers can submit pull requests.

Actual Behaviour:
Empty repository.

Notes:
Okay, I realise this is fairly obvious - but I'm about to lodge an issue for some documentation feedback and file a PR with resolution.

But it looks like this repository hasn't been populated yet, maybe it's an oversight or still in progress.

Just wanted to report it and give it a nudge!

Hi Team
We see the latest resource type support in AWS config here

Should we expect this list to be updated below and the respective config rule support available in the AWS Config console?
https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html

Or I am missing checking some other document?

Thanks in advance!

Problem:

Currently the documentation suggests this bucket policy when using AWS Config with service-linked roles:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AWSConfigBucketPermissionsCheck",
      "Effect": "Allow",
      "Principal": {
        "Service": [
         "config.amazonaws.com"
        ]
      },
      "Action": "s3:GetBucketAcl",
      "Resource": "arn:aws:s3:::targetBucketName"
    },
    {
      "Sid": " AWSConfigBucketDelivery",
      "Effect": "Allow",
      "Principal": {
        "Service": [
         "config.amazonaws.com"    
        ]
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::targetBucketName/[optional] prefix/AWSLogs/sourceAccountID-WithoutHyphens/Config/*",
      "Condition": { 
        "StringEquals": { 
          "s3:x-amz-acl": "bucket-owner-full-control" 
        }
      }
    }
  ]
}   

However, AWS Config had a change recently, where it also needs to check which region the bucket was created in. The above policy does not take that into consideration and accounts that have alerts set-up for unauthorized access attempts see a lot of noise generated by AWS Config.

Suggested resolution:

As recommended by AWS Premium Support representative, an additional s3:ListBucket permission is now required for the alerts to stop. It would be good to adjust the documentation accordingly:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AWSConfigBucketPermissionsCheck",
      "Effect": "Allow",
      "Principal": {
        "Service": [
         "config.amazonaws.com"
        ]
      },
      "Action": [
        "s3:GetBucketAcl",
        "s3:ListBucket"   # <-- NEW PERMISSION
      ],
      "Resource": "arn:aws:s3:::targetBucketName"
    },
    {
      "Sid": " AWSConfigBucketDelivery",
      "Effect": "Allow",
      "Principal": {
        "Service": [
         "config.amazonaws.com"    
        ]
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::targetBucketName/[optional] prefix/AWSLogs/sourceAccountID-WithoutHyphens/Config/*",
      "Condition": { 
        "StringEquals": { 
          "s3:x-amz-acl": "bucket-owner-full-control" 
        }
      }
    }
  ]
}   

Commentary:

When not enabled this causes AccessDenied errors with HeadBucket as eventName. Trying to add s3:HeadBucket as permission to bucket policy fails validation and thus is not possible. It is therefore hard to make a link that to fix HeadBucket - ListBucket permission is needed, unless told by AWS Support.

Assuming that whoever can action this can also see AWS support cases - I can provide an AWS Premium Support case number that has more context.

Hi,

could you add these resources to the list of "Supported Resource Types" of CloudWatch and describe wether or not they are supported by AWS Config?:

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_CloudWatch.html
AWS::CloudWatch::Alarm (already listed)
AWS::CloudWatch::AnomalyDetector
AWS::CloudWatch::CompositeAlarm
AWS::CloudWatch::Dashboard
AWS::CloudWatch::InsightRule
AWS::CloudWatch::MetricStream

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_Logs.html
AWS::Logs::Destination
AWS::Logs::LogGroup
AWS::Logs::LogStream
AWS::Logs::MetricFilter
AWS::Logs::QueryDefinition
AWS::Logs::ResourcePolicy
AWS::Logs::SubscriptionFilter

Problem:
Config rule pages in the developer guide inconsistently describe required/optional parameters.

Examples:
https://docs.aws.amazon.com/config/latest/developerguide/rds-storage-encrypted.html
https://docs.aws.amazon.com/config/latest/developerguide/encrypted-volumes.html

The RDS storage encrypted page does not specify that the kmsKeyId key is optional, however the encrypted-volumes implies it. Other pages do not describe this behaviour (and I'm not sure which ones are required or not).

Suggested Resolution:
Indicate for each parameter whether it is required or not for the Config Rule to be deployed.

The format used by the CloudFormation team documentation would be a nice, consistent experience. For example:
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-config-configrule.html#w2ab1c21c10d316b9

Commentary:
Maybe this is covered by other parts of the product documentation, and a link would suffice?

For example, on line 7 of https://github.com/awsdocs/aws-config-developer-guide/blob/main/doc_source/operational-best-practices-for-nist-800-53_rev_5.md the text should be amended to read:

AWS Region: All supported AWS Regions except Middle East (Bahrain) and AWS GovCloud (US).

The lack of exclusionary notes throughout conformance packs makes it seem to those non-technical that conformance packs are available in a GovCloud environment. Likewise, best-practice conformance pack pages including the one linked above, specifically excludes me-south-1 while being listed as 'region support' on the Conformance Packs page.

Added consistency and transparency in noting conformance packs are not available in GovCloud needs to be noted.

Hi,
consider this rule here:
https://github.com/awsdocs/aws-config-developer-guide/blob/main/doc_source/nacl-no-unrestricted-ssh-rdp.md

This control checks whether a network access control list (NACL) allows unrestricted access to the default ports for SSH/RDP ingress
traffic. The rule fails if a NACL inbound entry allows a source CIDR block of '0.0.0.0/0' or '::/0' for ports 22 or 3389.

In order to satisfy this rule it seems that there must not be any rule in the ACL (disregarding its priority) that allows SSH/RDP.
I suggest allowing explicit denial of traffic on port 22, 3389 to satisfy this rule

Instead of this:

Also allow this to satisfy the rule