Compliance

OpenGovernance streamlines compliance by enabling the definition of policies as code, which can be automatically applied to discover and assess entities across platforms. This feature allows you to check these entities against set policies and view detailed results and findings to ensure adherence to standards.

Here's how the process unfolds:

• Benchmarks & Controls: Compliance starts with Benchmarks, which are groups of Controls. Controls are specific checks against resources (e.g., is disk encryption enabled?).

• Evaluation & Findings: When a Benchmark is evaluated against an Integration (like an AWS account), each resource's configuration is inspected against the Controls. The result of each check is a Finding, indicating pass/fail with evidence.

• Conformance Status: Each Finding has a Conformance Status. Failed Findings mean a Control's requirement wasn't met.

• Root Benchmark: In OpenGovernance, every benchmark is organized under a "Root Benchmark," providing a framework for compliance management across cloud environments. Think of Root Benchmark as the "main folder"

Key Components

Controls

A Control is a rule that defining clear pass/fail criteria. Here are a few example of controls that can be defined on the platform:

• Code Review Completion: Ensures all code commits are peer-reviewed and approved before merging.

• Security Scan Pass: Requires all new or altered code to pass security scans before deployment.

• Build Success Rate: Monitors and requires a high success rate (i.e. >= 90%) for software builds before testing or release.

• Incident Response Time: Track the time to respond and start resolving production issues.

Controls are defined as simple SQL Statements, and stored in a YAML file. In the community edition, there are over 2.5K+ Policies for AWS, Azure, and EntraID.

Policy and Controls in the context of OpenGovernance is the exact same thing.

Benchmarks

Just like files are organized into folders and subfolders, controls are grouped into "Benchmarks".

Benchmarks can even contain other Benchmarks, offering a deeper level of organization.

In OpenGovernance, everything starts with a "Root Benchmark" – the main folder that houses all related Controls. This root structure helps manage compliance and governance across various cloud environments.

Findings

Whenever a Benchmark is Evaluated on an Integration (like an AWS Account), every resource and its configuration is thoroughly checked. The outcome of this audit is called a Finding.

A Finding is generated for each Control applied to each resource.

Events

An Event tracks changes in a resource's compliance status over time. It's like a timestamped snapshot of a Finding, showing when it shifted from compliant to non-compliant (or vice-versa). This helps monitor compliance trends and identify potential issues.

Events, by nature, are voluminous and are only generated for Benchmarks that have "Track Drifts" enabled.

Example

Say we have a control that requires all Storage Disks be encryped.

Let's break down how Findings work in this scenario:

Scenario

• You have 50 Virtual Machines (VMs), each with 2 Storage Disks.

• A Control checks if these disks are encrypted.

• You find that 30 of these VMs do not have their disks encrypted.

• The Benchmark this Control belongs to has "Track Drifts" enabled.

How the Platform Audit Works

• Each disk's configuration is evaluated individually against the Control.

• Since you have 50 VMs with 2 disks each, there are a total of 100 disks to check (50 VMs x 2 Disks = 100 Total Disks).

• This means the system will generate 100 Findings - one for each disk.

Conformance Status and Findings

• 30 VMs have unencrypted disks. That's 60 disks in total (30 VMs x 2 Disks = 60 Unencrypted Disks).

• Therefore, 60 of the 100 Findings will have a "Conformance Status" of "failed" because they didn't meet the encryption requirement.

• The remaining 40 Findings will likely have a "Conformance Status" of "passed" (assuming the other disks are encrypted).

Evidence and Reason in Findings

• Each of the 100 Findings will provide details:

  • Evidence: Proof of whether the disk is encrypted or not (e.g., encryption settings).

  • Reason: Explanation for the "Conformance Status". For "failed" Findings, it might say "Disk encryption is not enabled".

Events - Tracking Changes Over Time

• Since "Track Drifts" is enabled, the system will also generate Events for each of the 60 "failed" Findings.

• These Events will capture the timeframe during which those specific disks remained unencrypted.

• If any of these disks are later encrypted, new Events will be generated to mark the change in their conformance status from "failed" to "passed."

Compliance Jobs

1. Scheduling Jobs:

   • The Scheduler Service checks every 60 seconds to identify jobs that need scheduling.

   • Jobs are recorded in PostgreSQL as "Queued" and written to NATS.

2. Job Execution Rules:

   • Each control per account per benchmark constitutes one job.

   • If a control is shared between two root benchmarks, it is triggered twice.

   • If a control is shared between two benchmarks under the same root, it is triggered once.

3. Job Completion and Summarization:

   • After job execution, the Summarizer is triggered to generate a compliance summary.

   • The job status in PostgreSQL is updated to "Summarizer in progress."

4. Recording Findings:

   • Findings are generated per worker and recorded in the database.

5. Accessing Summary Data:

   • Summary data becomes available after the Summarizer has processed all jobs.

In essence

• Each disk gets its own Finding, reflecting its current compliance status.

• Events provide a historical record of how the compliance status of each disk has changed over time.