Skip to main content

Bedrock Model Customization Job Has Active Security Group

More Info:​

Bedrock model customization job should have active security group

Risk Level​

Medium

Address​

Security

Compliance Standards​

  • APRA CPS 234 (Australia)
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS Critical Security Controls v8
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • ISO/IEC 27018
  • ISO/IEC 27701
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • SOC2
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • StateRAMP
  • UK NCSC Cyber Assessment Framework

Triage and Remediation​

Remediation​

Using Console

Here’s how to remediate this using the AWS Console by locking down (or removing) the security group associated with the Bedrock model customization job.

1. Identify the Security Group Used by the Customization Job​

  1. Sign in to the AWS Management Console and go to Amazon Bedrock.
  2. In the left navigation pane, choose Model customization (or Custom models → Customization jobs, depending on your console version).
  3. Click the specific Customization job that triggered the finding.
  4. In the Networking / VPC configuration section, note the Security group ID(s) associated with the job. Copy those IDs.

Important: You cannot change the VPC/security group on an already-running or completed customization job. You will secure the SG itself and adjust settings for future jobs.

2. Tighten the Security Group Rules​

  1. In the console, go to EC2.
  2. In the left pane, choose Security Groups.
  3. Search for the Security group ID you copied, then select it.

2.1 Restrict Inbound Rules​

  1. Go to the Inbound rules tab, then choose Edit inbound rules.
  2. Remove any rules that:
    • Allow inbound from 0.0.0.0/0 or ::/0 (especially for SSH, RDP, or any non-required port).
    • Are broader than needed (e.g., wide CIDR like /0, /8, /16 when not required).
  3. Only keep rules that are:
    • Required for your job (for most Bedrock customization jobs, you often do not need broad inbound access at all).
    • Restricted to specific internal CIDR ranges, VPCs, or security groups.
  4. Choose Save rules.

2.2 Restrict Outbound Rules (if needed)​

  1. Go to the Outbound rules tab → Edit outbound rules.
  2. Remove or narrow any 0.0.0.0/0 or ::/0 rules unless egress to the public internet is strictly required.
  3. Prefer:
    • VPC-only or specific CIDR ranges.
    • Specific service endpoints (via VPC endpoints, if applicable).
  4. Choose Save rules.

3. (Optional) Create a Locked-Down Security Group for Future Jobs​

If the existing SG is used by multiple workloads, it’s cleaner to create a dedicated one for Bedrock:

  1. In EC2 → Security Groups, choose Create security group.
  2. Name it something like bedrock-customization-sg-restricted.
  3. Attach it to the correct VPC.
  4. Set:
    • Inbound rules: None or only the minimal, tightly scoped rules required.
    • Outbound rules: Restricted to what is necessary (VPC-only or specific CIDRs/endpoints).
  5. Save the security group.

Then:

  1. Go back to Amazon Bedrock → Model customization.
  2. When you create the next customization job, in the Networking / VPC configuration step, choose this new restricted Security group instead of the older one.

4. (Optional) If You Intended to Delete the Security Group​

If you’re getting errors deleting a security group because it is “in use” by a Bedrock customization job:

  1. Confirm the customization job has fully completed or failed (not running).
  2. Verify the SG isn’t referenced by:
    • Other EC2 instances, ENIs, load balancers, Lambda functions, etc.
  3. Once it’s no longer referenced:
    • Go to EC2 → Security Groups, select the SG, and choose Delete security group.

If you tell me the exact security check/source of the finding (e.g., Security Hub / control ID), I can tailor the remediation more precisely to that control’s requirement.

Using CLI

Below are CLI-focused steps to remediate a Bedrock model customization job that uses an insecure/overly-permissive active security group.

Assumptions:

  • You already know (or can identify) the Security Group ID(s) used in the Bedrock customization job’s VPC config.
  • The typical misconfiguration is that the SG allows broad access (e.g., 0.0.0.0/0 or ::/0) or unnecessary ports/protocols.

1. Identify the Security Group(s) Used​

If you already know the Security Group ID (sg-xxxxxxxx), skip to step 2.

If not, list security groups and filter by tag/name you used for Bedrock:

aws ec2 describe-security-groups \
  --filters "Name=group-name,Values=*bedrock*" \
  --region <REGION>

Look for the GroupId fields like sg-0123456789abcdef0.

2. Review Current Inbound and Outbound Rules​

aws ec2 describe-security-groups \
  --group-ids sg-0123456789abcdef0 \
  --region <REGION>

Inspect IpPermissions (inbound) and IpPermissionsEgress (outbound) for:

  • 0.0.0.0/0 or ::/0
  • Unnecessary ports (e.g., all ports 0–65535, or IpProtocol: -1)

3. Remove Insecure Inbound Rules​

Example: Remove all inbound rules:

aws ec2 revoke-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --ip-permissions file://ingress.json

First generate ingress.json from current rules:

aws ec2 describe-security-groups \
  --group-ids sg-0123456789abcdef0 \
  --query "SecurityGroups[0].IpPermissions" \
  --output json > ingress.json

Run revoke-security-group-ingress with that file to clear them.

If you only want to remove broad rules (e.g., all traffic from 0.0.0.0/0):

  1. Create a minimal JSON file, e.g. revoke-0-all.json:
[
  {
    "IpProtocol": "-1",
    "IpRanges": [
      {
        "CidrIp": "0.0.0.0/0"
      }
    ]
  }
]
  1. Revoke just that:
aws ec2 revoke-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --ip-permissions file://revoke-0-all.json \
  --region <REGION>

Repeat similarly for IPv6 (CidrIpv6: "::/0").

4. Restrict Outbound Rules (If Required)​

If your policy requires restricted egress (not 0.0.0.0/0):

  1. Export current egress:
aws ec2 describe-security-groups \
  --group-ids sg-0123456789abcdef0 \
  --query "SecurityGroups[0].IpPermissionsEgress" \
  --output json > egress.json
  1. Revoke overly broad egress, e.g.:

revoke-egress-0-all.json:

[
  {
    "IpProtocol": "-1",
    "IpRanges": [
      {
        "CidrIp": "0.0.0.0/0"
      }
    ]
  }
]

Command:

aws ec2 revoke-security-group-egress \
  --group-id sg-0123456789abcdef0 \
  --ip-permissions file://revoke-egress-0-all.json \
  --region <REGION>

5. Add Least-Privilege Rules Needed by Bedrock Job​

Typically:

  • No inbound rules are required for many VPC workloads if they only initiate outbound connections.
  • Outbound rules should only allow required destinations (e.g., VPC endpoints, specific CIDR ranges or ports).

Example: allow outbound HTTPS only within your VPC CIDR:

aws ec2 authorize-security-group-egress \
  --group-id sg-0123456789abcdef0 \
  --ip-permissions '[
    {
      "IpProtocol": "tcp",
      "FromPort": 443,
      "ToPort": 443,
      "IpRanges": [
        {
          "CidrIp": "10.0.0.0/16"
        }
      ]
    }
  ]' \
  --region <REGION>

If Bedrock customization uses VPC endpoints, scope egress to those endpoints’ private IP ranges or associated subnets.

6. (Optional) Create a New Hardened Security Group and Use It for Future Jobs​

Instead of fixing an old SG, you can create a dedicated locked-down one:

aws ec2 create-security-group \
  --group-name bedrock-customization-sg \
  --description "SG for Bedrock model customization with restricted egress" \
  --vpc-id vpc-0123456789abcdef0 \
  --region <REGION>

Then configure:

  • No inbound rules (default).
  • Minimal egress as in step 5.

Use that SG’s ID in the vpcConfig.securityGroupIds when starting future Bedrock customization jobs.

7. (Optional) Delete Unused Security Groups​

After confirming the SG is no longer attached to any ENIs and not referenced in other resources:

aws ec2 delete-security-group \
  --group-id sg-0123456789abcdef0 \
  --region <REGION>

If you share:

  • The current SG rules (JSON from describe-security-groups), and
  • Any Bedrock/VPC endpoint patterns you must support,

I can give exact CLI JSON payloads for your specific environment.

Using Python

For AWS Bedrock, the “Model Customization Job Has Active Security Group” finding usually means the security group associated with the job allows unnecessary inbound access (e.g., 0.0.0.0/0). You can’t update an existing Bedrock customization job, but you can remediate the underlying security group (for running jobs) and fix your configuration for all new jobs.

Below are step‑by‑step instructions and Python (boto3) code to lock down the security group(s).

1. Identify the Security Group(s) used by the Bedrock customization job​

If you know the security group ID(s) already, you can skip to step 2.

Otherwise, when you create a customization job you pass a vpcConfig with security group IDs. For reference, a creation call looks like:

import boto3

client = boto3.client("bedrock")

response = client.create_model_customization_job(
    jobName="my-custom-job",
    # ...
    outputDataConfig={
        "s3Uri": "s3://my-bucket/output/"
    },
    roleArn="arn:aws:iam::123456789012:role/BedrockCustomizationRole",
    vpcConfig={
        "securityGroupIds": ["sg-0123456789abcdef0"],   # <- HERE
        "subnetIds": ["subnet-0123456789abcdef0"]
    },
    # ...
)

Use the security groups referenced there.

2. Remove overly permissive inbound rules from the security group​

Typical misconfiguration: inbound rules like:

  • CIDR: 0.0.0.0/0 or ::/0
  • Protocol: tcp or -1 (all)
  • Ports: wide ranges or all

You want:

  • No inbound rules at all, or
  • Only strictly required internal access (e.g., from specific subnets or security groups).

Python: strip all inbound rules from the SG​

import boto3

ec2 = boto3.client("ec2", region_name="us-east-1")  # set your region
security_group_id = "sg-0123456789abcdef0"          # your SG ID

def remove_all_ingress_rules(sg_id: str):
    # Get current ingress rules
    resp = ec2.describe_security_groups(GroupIds=[sg_id])
    sg = resp["SecurityGroups"][0]
    ip_permissions = sg.get("IpPermissions", [])

    if not ip_permissions:
        print(f"No ingress rules to remove for {sg_id}")
        return

    # Revoke all ingress rules
    ec2.revoke_security_group_ingress(
        GroupId=sg_id,
        IpPermissions=ip_permissions
    )
    print(f"Removed all ingress rules from {sg_id}")

remove_all_ingress_rules(security_group_id)

If you only want to remove 0.0.0.0/0 or ::/0 rules and keep internal rules, filter them:

def remove_public_ingress_rules(sg_id: str):
    resp = ec2.describe_security_groups(GroupIds=[sg_id])
    sg = resp["SecurityGroups"][0]
    to_remove = []

    for perm in sg.get("IpPermissions", []):
        ip4s = [ip for ip in perm.get("IpRanges", []) if ip.get("CidrIp") == "0.0.0.0/0"]
        ip6s = [ip for ip in perm.get("Ipv6Ranges", []) if ip.get("CidrIpv6") == "::/0"]
        if ip4s or ip6s:
            new_perm = {
                "IpProtocol": perm["IpProtocol"],
                "FromPort": perm.get("FromPort"),
                "ToPort": perm.get("ToPort"),
                "IpRanges": ip4s,
                "Ipv6Ranges": ip6s,
            }
            to_remove.append(new_perm)

    if not to_remove:
        print(f"No public ingress rules found for {sg_id}")
        return

    ec2.revoke_security_group_ingress(
        GroupId=sg_id,
        IpPermissions=to_remove
    )
    print(f"Removed public ingress rules from {sg_id}")

remove_public_ingress_rules(security_group_id)

3. Lock down outbound rules if required by your policy​

Some security baselines also require outbound to be restricted (not 0.0.0.0/0 / all protocols).

To remove all outbound rules:

def remove_all_egress_rules(sg_id: str):
    resp = ec2.describe_security_groups(GroupIds=[sg_id])
    sg = resp["SecurityGroups"][0]
    ip_permissions_egress = sg.get("IpPermissionsEgress", [])

    if not ip_permissions_egress:
        print(f"No egress rules to remove for {sg_id}")
        return

    ec2.revoke_security_group_egress(
        GroupId=sg_id,
        IpPermissions=ip_permissions_egress
    )
    print(f"Removed all egress rules from {sg_id}")

remove_all_egress_rules(security_group_id)

If Bedrock customization needs outbound access (for example to S3 via a VPC endpoint), add only those explicit rules (e.g., to VPC endpoint security groups or CIDRs).

4. Use a hardened SG for all future Bedrock customization jobs​

Create a dedicated, locked‑down SG once, and reuse it:

def create_locked_down_sg(vpc_id: str, name: str, description: str):
    resp = ec2.create_security_group(
        GroupName=name,
        Description=description,
        VpcId=vpc_id
    )
    sg_id = resp["GroupId"]
    print(f"Created SG {sg_id} in VPC {vpc_id}")

    # By default, SG has no ingress and one broad egress rule.
    # Optionally remove default egress:
    remove_all_egress_rules(sg_id)

    return sg_id

vpc_id = "vpc-0123456789abcdef0"
locked_sg_id = create_locked_down_sg(vpc_id, "bedrock-customization-sg", "SG for Bedrock Model Customization")

Then, when creating new customization jobs, always reference locked_sg_id:

client = boto3.client("bedrock", region_name="us-east-1")

client.create_model_customization_job(
    jobName="my-secure-custom-job",
    # ...
    vpcConfig={
        "securityGroupIds": [locked_sg_id],
        "subnetIds": ["subnet-0123456789abcdef0"]
    },
    # ...
)

If you share the exact policy/finding text (e.g., from Security Hub/Config), I can tailor the Python to match that control precisely (e.g., specific ports or CIDRs to remove).

Using Terraform
# There is currently no Terraform resource for a Bedrock model customization job
# (no aws_machinelearning_bedrock_job / aws_bedrock_* equivalent that manages jobs),
# so this setting cannot be remediated via Terraform.

# You must configure the security group(s) when creating the customization job
# via the AWS Console or API/CLI (bedrock create-model-customization-job) using
# the VpcConfig.SecurityGroupIds field, or recreate the job with the desired SGs.

Terraform cannot manage Bedrock model customization jobs today, so it cannot add or change their security groups; use the Bedrock console or AWS CLI instead. Since no Terraform change is possible, terraform plan will show no diff related to this finding.