Controls with External Policies

This example demonstrates a Control that references an external Policy instead of embedding the policy logic directly within the Control. This approach is beneficial when you need to reuse the same policy logic across multiple Controls.

Control

id: aws_access_keys_rotated_x_days      # REQUIRED (unique across Controls)
title: Access Keys Rotated X Days       # RECOMMENDED (descriptive)
description: Ensure AWS IAM access keys are rotated on a periodic basis (X Days).  # RECOMMENDED
integration_type:
  - aws_cloud_account                   # REQUIRED (platform this Control applies to)
parameters:
  - key: awsIamAccessKeyAge
    value: '180'                       # Input used by the external Policy
policy:
  "@ref": "aws_iam_access_keys_policy" # REQUIRED reference to an external Policy ID
severity: medium                       # REQUIRED (choose from Critical, High, Medium, Low, None)
tags:                                  # RECOMMENDED (metadata for organization)
  score_service_name:
    - AWS Identity and Access Management (IAM)
  Category:
    - Insecure Keys

Explanation of Control Fields

Required:

  • id: A unique identifier for the Control (e.g., aws_access_keys_rotated_x_days).

  • integration_type: Specifies the environment or platform (e.g., aws_cloud_account) to which this Control applies.

  • policy: References the ID of an external Policy (e.g., aws_iam_access_keys_policy).

  • severity: Indicates the impact level if the Control fails (e.g., Critical, High, Medium, Low, None).

Recommended:

  • title: A concise and descriptive name for the Control (e.g., "Access Keys Rotated X Days").

  • description: A brief explanation of what the Control checks (e.g., "Ensures AWS IAM keys are rotated within a set number of days.").

  • parameters: Key-value pairs that provide input to the external Policy (required if the Policy uses parameters).

  • tags: Optional metadata for categorizing or grouping the Control (e.g., relevant AWS services or risk categories).

Policy

id: aws_iam_access_keys_policy           # REQUIRED (unique Policy ID)
title: AWS IAM Access Key Policy
description: Specifies the maximum age for IAM Access Keys
language: sql                            # REQUIRED (type of query)
primary_resource: aws_iam_access_key     # REQUIRED (resource for attributing incidents)
definition: |                            # REQUIRED (the policy logic)
  SELECT
    access_key_id AS resource,
    platform_integration_id AS platform_integration_id,
    platform_resource_id AS platform_resource_id,
    CASE
      WHEN status <> 'Active' THEN 'skip'
      WHEN create_date + ('{{.awsIamAccessKeyAge}}' || ' days')::interval < NOW() THEN 'alarm'
      ELSE 'ok'
    END AS status,
    CASE
      WHEN status <> 'Active' THEN 'key is not activated'
      WHEN create_date + ('{{.awsIamAccessKeyAge}}' || ' days')::interval < NOW() THEN 'key is too old'
      ELSE 'key is not old yet'
    END AS reason,
    region,
    account_id
  FROM
    aws_iam_access_key v

Explanation of Policy Fields

Required:

  • id: The unique identifier for this Policy (e.g., aws_iam_access_keys_policy).

  • language: Specifies the type of logic or query used in the Policy (e.g., sql, rego).

  • primary_resource: Identifies the primary data source used for the query (e.g., aws_iam_access_key).

  • definition: The query or code block that evaluates compliance.

Recommended:

  • title: A brief summary of what the Policy checks (e.g., "maximum IAM Access Key age").

  • description: A brief description of the Policy.

How It All Works Together

  • Control: Defines the specific compliance requirement (e.g., "IAM keys rotated every 180 days") and references the ID of the corresponding external Policy.

  • External Policy: Contains the actual query or logic used to evaluate compliance. It can dynamically use the parameters provided by the Control.

  • Reusability: This external Policy (aws_iam_access_keys_policy) can be reused by multiple Controls, each with potentially different parameter values (e.g., 90 days vs. 180 days).

Benefits

By separating the Control (what is being checked) from the Policy (how it is checked), this approach promotes:

  • Improved Maintainability: Centralized policy definitions make it easier to update and maintain policy logic.

  • Increased Reusability: Reusing Policies across multiple Controls reduces redundancy and improves efficiency.

  • Enhanced Scalability: Enables easier management of complex compliance requirements within a growing environment.

This approach facilitates a more robust and scalable "compliance-as-code" strategy within Opencomply.

Last updated