🧬 Basic Concepts

As a forward-thinking CISO/CIO, you understand the critical importance of maintaining a strong security posture across your entire software lifecycle. INTERCEPT offers you:

Lightning-Fast SecConf Management: Identify potential security risks in configuration files within milliseconds. And patch them immediatly.
Streamlined Compliance Workflow: Implement a full-cycle compliance process with minimal setup time.
Proactive Risk Management: Stay ahead of threats, leaks and drift by continuously monitoring and auditing your infrastructure.

TIP

To gain a deeper understanding of INTERCEPT's architecture and how it fits into your security strategy, please refer to our Architecture page. This page provides a comprehensive overview of INTERCEPT's capabilities, operational modes, and how it can transform your security operations.

The POLICY file (also known as the configuration file) is the primary component of the INTERCEPT workflow. It configures the policy engine and provides all necessary policies, triggers, and hooks to generate a comprehensive compliance report and distribute it to the appropriate recipients.

The Policy File Structure

A policy file is a YAML document comprising:

yaml


Config: # (optional) used to configure INTERCEPT

Version: # (optional) version of the policy schema

Policies: # (mandatory) List of all the policies to be loaded
  - id:
    type:
  - id:
    type:
  - id:
    type:

POLICY FILE

Also known as INTERCEPT config file

A minimal policy file might look like this:

yaml


Policies: 
  - id: "SCAN-001 Private Keys"
    type: "scan"
    enforcement:
      - environment: "production"
        fatal: "true"
        exceptions: "false"
        confidence: "high"
      - environment: "development"
        fatal: "true"
        exceptions: "false"
        confidence: "high"
    metadata:
      name: "Detect private keys, certs, etc"
      description: "Generic long description for (metadata) policy"
      msg_solution: "Generic solution message to production issue."
      msg_error: "Generic error message for production issue"
      tags:
        - "security"
        - "encryption"
      score: "9"
    _regex:
      - \s*(-----BEGIN PRIVATE KEY-----)
      - \s*(-----BEGIN RSA PRIVATE KEY-----)
      - \s*(-----BEGIN DSA PRIVATE KEY-----)
      - \s*(-----BEGIN EC PRIVATE KEY-----)
      - \s*(-----BEGIN OPENSSH PRIVATE KEY-----)
      - \s*(-----BEGIN PGP PRIVATE KEY BLOCK-----)

The Policy Definition

The policy file can contain all types of policy definitions or be segregated by type, depending on your team's preference. Each policy has the following structure:

POLICY

An individual policy structure

yaml

- id:   # short name of your policy 
  type: # "scan","assure","api","json","yaml","toml","ini","runtime","rego"

  filepattern: # file name pattern filter to narrow down the target of the policy
  schedule: # (only for observe daemon) set the policy audit accodringly to a cron
  observe: # (only for observe daemon) set up path monitoring to trigger this policy

  enforcement: # check the Enforcement section for the value matrix.
     - environment:
       fatal:
       exceptions:
       confidence:

   metadata: # All the metadata that will populate your compliance report
     name:
     description:
     tags: # when running an audit you can filter the policies by tag
       - # the ID of the policy is always an automatic tag 
       -
     msg_solution:
     msg_error:
     score:

    # ASSURE Filetype policies
   _schema:
      patch: # (defaults false) if true and your CUE Lang schema has values instead of types 
             #                  the non compliant will have a patch created
      strict: # (defaults false) if true the target file needs to adhere to the full schema below
      structure: # here goes your CUE Lang schema to be 
                 # applied/verified against the target files

    # REGO TYPE Policies
   _rego:
      policy_file:  # your REGO policy file
      policy_data:  # (optional) additional data needed
      policy_query: # the query to access compliance of the policy

    # SCAN & ASSURE (&api) REGEX Policies
   _regex:
      - "regex_here" # a list of REGEX patterns
      -
      -

    # RUNTIME Policies
   _runtime:
      config:   # the goss configuration file 
      observe:  # (only for observe daemon) file or file path to 
                # be observed for changes and trigger this policy

The common area to all policies :

yaml

- id:   # short name of your policy
  type: # "scan","assure","api","json","yaml","toml","ini","runtime","rego"

  filepattern: # file name pattern filter to narrow down the target of the policy
  schedule: # (only for observe daemon) set the policy audit accodringly to a cron

  enforcement: # check the Enforcement section for the value matrix.
     - environment: 
       fatal: 
       exceptions: 
       confidence: 

   metadata: # All the metadata that will populate your compliance report
     name: 
     description: 
     tags: # when running an audit you can filter the policies by tag
       - # the ID of the policy is always an automatic tag
       - 
     msg_solution: 
     msg_error: 
     score: 

    # ASSURE Filetype policies
   _schema:
      patch: # (defaults false) if true and your CUE Lang schema has values instead of types 
             #                  the non compliant will have a patch created
      strict: # (defaults false) if true the target file needs to adhere to the full schema below
      structure: # here goes your CUE Lang schema to be 
                 # applied/verified against the target files

    # REGO TYPE Policies
   _rego:
      policy_file:  # your REGO policy file
      policy_data:  # (optional) additional data needed
      policy_query: # the query to access compliance of the policy

    # SCAN & ASSURE (&api) REGEX Policies
   _regex:
      - "regex_here" # a list of REGEX patterns
      -
      -

    # RUNTIME Policies
   _runtime:
      config:   # the goss configuration file 
      observe:  # (only for observe daemon) file or file path to 
                # be observed for changes and trigger this policy

The CLI

INTERCEPT offers two primary operating modes:

AUDIT

Performs a full audit run, cycling through all loaded policies, generating individual reports per policy, and a final compliance SARIF report.

OBSERVE

Runs a daemon that monitors file paths, mounts, services, and configs, reacting to drifts or triggering scheduled policy audits.

Usage:
  intercept [command]

Available Commands:
  audit       Run an optimized audit through all loaded policies
  completion  Generate the autocompletion script for the specified shell
  help        Help about any command
  observe     Observe and trigger realtime policies based on schedules or active path monitoring
  sys         Test intercept embedded core binaries
  version     Print the build info of intercept

Flags:
      --experimental        Enables unreleased experimental features
  -h, --help                help for intercept
      --nolog               Disables all loggging
  -o, --output-dir string   directory to write output files
      --silent              Enables log to file intercept.log
  -v, --verbose count       increase verbosity level

Use "intercept [command] --help" for more information about a command.

The Compliance Report

INTERCEPT's AUDIT output is a SARIF-compliant report containing essential metadata for data-driven decision-making. The report includes:

Individual Policy Attestation result details
Individual Policy Attestation result summaries
Overall compliance status based on configured environment enforcement levels

json

{
  "version": "2.1.0",
  "$schema": "https://raw.githubusercontent.com/oasis-tcs/sarif-spec/master/Schemata/sarif-schema-2.1.0.json",
  "runs": [
    {
      "tool": {
        "driver": {
          "name": "Intercept",
          "version": "v1.0.4"
        }
      },
      "results": [ 
        {
          "ruleId": "SCAN-001-PRIVATE-KEYS", 
          "level": "error", 
          "message": { 
            "text": "Policy violation: Detect private keys Matched text: \n-----BEGIN PGP PRIVATE KEY BLOCK-----"
          },
          "locations": [ 
            {
              "physicalLocation": { 
                "artifactLocation": { 
                  "uri": "targets/scan/long.code"
                }, 
                "region": { 
                  "startLine": 10927, 
                  "startColumn": 1103, 
                  "endColumn": 1141
                }
              }
            }
          ],
          "properties": { 
            "description": "Generic long description for (metadata) policy", 
            "error": "true", 
            "msg-error": "Generic error message for production issue", 
            "msg-solution": "Generic solution message to production issue.", 
            "name": "Detect private keys",  
            "observe-run-id": "",
            "result-timestamp": "2024-09-11T15:01:00+08:00",
            "result-type": "detail"
          }
        }
      ],
      "invocations": [ 
        {
          "executionSuccessful": true, 
          "commandLine": "./intercept audit --policy policies/test_scan.yaml --target targets -vvvv -o _my_first_run", 
          "properties": {
            "debug": "false",
            "end_time": "2024-09-11T15:01:00+08:00",
            "environment": "",
            "execution_time_ms": "364",
            "report-compliant": "false", 
            "report-status": "non-compliant", 
            "report-timestamp": "2024-09-11T15:01:00+08:00", 
            "run_id": "2lulu0kvIoO5xkZ5Te4VgkqxEVH", 
            "start_time": "2024-09-11T15:01:00+08:00"
          }
        }
      ]
    }
  ]
}

COMPLIANCE RESULTS

This comprehensive report enables organizations to make informed decisions about their security and compliance posture.

🧬 Basic Concepts ​

The Policy File Structure ​

The Policy Definition ​

The CLI ​

The Compliance Report ​

🧬 Basic Concepts

The Policy File Structure

The Policy Definition

The CLI

The Compliance Report