> ## Documentation Index
> Fetch the complete documentation index at: https://cloudanix.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# 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

<Tabs>
  <Tab title="Remediation">
    ### Remediation

    <AccordionGroup>
      <Accordion title="Using Console" defaultOpen="true">
        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

        4. Go to the **Inbound rules** tab, then choose **Edit inbound rules**.
        5. 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).
        6. 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.
        7. Choose **Save rules**.

        #### 2.2 Restrict Outbound Rules (if needed)

        8. Go to the **Outbound rules** tab → **Edit outbound rules**.
        9. Remove or narrow any `0.0.0.0/0` or `::/0` rules unless egress to the public internet is strictly required.
        10. Prefer:
            * VPC-only or specific CIDR ranges.
            * Specific service endpoints (via VPC endpoints, if applicable).
        11. 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:

        6. Go back to **Amazon Bedrock → Model customization**.
        7. 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.
      </Accordion>

      <Accordion title="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:

        ```bash theme={null}
        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

        ```bash theme={null}
        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:

        ```bash theme={null}
        aws ec2 revoke-security-group-ingress \
          --group-id sg-0123456789abcdef0 \
          --ip-permissions file://ingress.json
        ```

        First generate `ingress.json` from current rules:

        ```bash theme={null}
        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`:

        ```json theme={null}
        [
          {
            "IpProtocol": "-1",
            "IpRanges": [
              {
                "CidrIp": "0.0.0.0/0"
              }
            ]
          }
        ]
        ```

        2. Revoke just that:

        ```bash theme={null}
        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:

        ```bash theme={null}
        aws ec2 describe-security-groups \
          --group-ids sg-0123456789abcdef0 \
          --query "SecurityGroups[0].IpPermissionsEgress" \
          --output json > egress.json
        ```

        2. Revoke overly broad egress, e.g.:

        `revoke-egress-0-all.json`:

        ```json theme={null}
        [
          {
            "IpProtocol": "-1",
            "IpRanges": [
              {
                "CidrIp": "0.0.0.0/0"
              }
            ]
          }
        ]
        ```

        Command:

        ```bash theme={null}
        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:

        ```bash theme={null}
        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:

        ```bash theme={null}
        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:

        ```bash theme={null}
        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.
      </Accordion>

      <Accordion title="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:

        ```python theme={null}
        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

        ```python theme={null}
        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:

        ```python theme={null}
        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:

        ```python theme={null}
        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:

        ```python theme={null}
        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`:

        ```python theme={null}
        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).
      </Accordion>
    </AccordionGroup>
  </Tab>
</Tabs>