AWS Security Hub member accounts deny allow policy

SecurityHub does not have inbuilt option to disable this permission. You can use SCP to achieve it.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyDisablingControlsFromNonAdminAccounts",
      "Effect": "Deny",
      "Action": "securityhub:BatchUpdateStandardsControlAssociations",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalAccount": "123456789012"  // Replace with your Security Hub admin account ID
        }
      }
    }
  ]
}

As a delegated administrator for AWS Security Hub managing hundreds of member accounts, you have a more elegant solution available than listing individual security operations team members in your policy.

AWS Security Hub offers central configuration capabilities that allow you to manage security controls across your organization. As the delegated administrator, you can create and apply policies that control how member accounts interact with Security Hub, including enabling/disabling controls and managing findings.

Instead of using a Deny policy with individual user conditions, you can:

1. Create configuration policies in the Security Hub delegated administrator account's home Region
2. Apply these policies to member accounts to enforce consistent security control settings
3. Use the "Exclude organization units or accounts" feature to manage exceptions

This approach allows you to centrally manage which controls are enabled or disabled across your organization, preventing delivery teams from making unauthorized changes. The delegated administrator can create policies that specify exactly which controls should be enabled, which parameters should be customized, and apply these consistently across member accounts.

For your specific concern about teams disabling controls or suppressing findings, central configuration ensures that only authorized personnel (the delegated administrator) can make these changes, and the settings will be consistently applied across your organization according to your policies.

To implement this, you'll need to ensure you've integrated Security Hub with AWS Organizations and designated a home Region. This approach provides a more scalable and maintainable solution than managing individual IAM policies across hundreds of accounts.
Sources
Creating a policy as the delegated administrator to manage member accounts - AWS Security Hub
Top four ways to improve your Security Hub security score | AWS Security Blog
Attaching the delegation policy statement for Security Hub - AWS Security Hub

Configuring Security Hub locally in hundreds of accounts and attempting to block configuration changes with policies is quite precarious and usually leads to high management effort. I strongly suggest that you switch your Security Hub to use its native central configuration feature: https://docs.aws.amazon.com/securityhub/latest/userguide/central-configuration-intro.html. Standards and control settings cannot be changed by member accounts, when they are configured via a organisation-level central configuration policy.

There's a summary table of the actions that central configuration allows in each member account and those that can only be performed by the delegated administration account. The table is under the first expandable subheading "Allowed actions if you integrate with Organizations and use central configuration:" https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-accounts-allowed-actions.html

Note that workload accounts can still suppress findings locally, but you can limit who can do it with an SCP (Service Control Policy) in your AWS Organization, by restricting the use of the BatchUpdateFindings API. There are various policy examples on this page: https://docs.aws.amazon.com/securityhub/latest/userguide/finding-update-batchupdatefindings.html

Note that the aws:PrincipalArn condition key contains the ARN of the IAM role, not an individual user's name.