Core Concepts

CSE is built around four fundamental data types that work together to create a complete compliance observation system. Understanding these concepts is essential for effectively using and integrating with the registry.

Signal

A canonical definition of a compliance-relevant technical condition

Mapping

A relationship linking a signal to framework controls

Finding

An instance of a signal observed in a specific environment

Artifact

Evidence or data supporting a finding observation

Signals

A signal is the core unit of the CSE registry. It represents a canonical definition of a specific technical condition that is relevant to compliance or security assessments.

Signal Characteristics

Stable identifier: Each signal has a unique, permanent ID that never changes (e.g., CSE-HIPAA-TECH-ENCRYPT-REST-001)
Domain-scoped: Signals are organized by compliance domain (HIPAA, SOC2, CMMC, etc.)
Categorized: Within domains, signals are grouped into categories (TECH, ADMIN, PHYS, etc.)
Versioned: Signal definitions include version numbers for tracking changes
Descriptive: Signals describe what was observed, not what to do about it

Signal ID Structure

Every CSE signal ID follows a consistent structure that encodes its origin and purpose:

CSE-{DOMAIN}-{CATEGORY}-{SHORT_NAME}-{SEQUENCE}

Example: CSE-HIPAA-TECH-ENCRYPT-REST-001

CSE          → Namespace prefix (always "CSE")
HIPAA        → Compliance domain
TECH         → Category (technical safeguard)
ENCRYPT-REST → Short descriptive name
001          → Sequence number within category

Example Signal

{
  "id": "CSE-HIPAA-TECH-ENCRYPT-REST-001",
  "domain": "HIPAA",
  "category": "TECH",
  "title": "Data at Rest Encryption Not Enabled",
  "description": "Storage resource does not have encryption at rest enabled, potentially exposing ePHI to unauthorized access if physical media is compromised.",
  "severity": "high",
  "tags": ["encryption", "storage", "ePHI", "data-protection"],
  "detection": {
    "artifact_types": ["cloud_resource", "configuration"],
    "conditions": ["encryption_enabled == false"]
  },
  "version": "1.0.0",
  "created": "2024-01-15",
  "updated": "2024-01-15"
}

Mappings

A mapping establishes a relationship between a CSE signal and one or more framework controls. Mappings are what make CSE powerful for cross-framework compliance—a single signal can map to controls in multiple frameworks simultaneously.

Mapping Characteristics

Many-to-many: One signal can map to multiple controls, and one control can be addressed by multiple signals
Framework-specific: Each mapping references a specific framework and control identifier
Relationship type: Mappings include a relationship indicator (primary, supporting, partial)
Curated: Mappings are reviewed to ensure accuracy and relevance

Relationship Types

Type	Description
primary	Signal directly addresses the control requirement
supporting	Signal provides evidence that supports control compliance
partial	Signal addresses only part of the control requirement

Example Mapping

{
  "signal_id": "CSE-HIPAA-TECH-ENCRYPT-REST-001",
  "mappings": [
    {
      "framework": "HIPAA",
      "control": "§164.312(a)(2)(iv)",
      "control_title": "Encryption and decryption",
      "relationship": "primary",
      "rationale": "Encryption at rest directly implements the addressable encryption specification"
    },
    {
      "framework": "NIST-CSF",
      "control": "PR.DS-1",
      "control_title": "Data-at-rest is protected",
      "relationship": "primary",
      "rationale": "Encryption protects data at rest from unauthorized access"
    },
    {
      "framework": "SOC2",
      "control": "CC6.1",
      "control_title": "Logical and physical access controls",
      "relationship": "supporting",
      "rationale": "Encryption provides an additional layer of access control"
    }
  ]
}

Findings

A finding is an instance of a signal observed in a specific environment at a specific time. While signals are abstract definitions, findings are concrete observations. Findings are what security tools emit when they detect conditions described by signals.

Finding Characteristics

Instance-specific: Each finding represents a single observation in a specific context
Time-bound: Findings include timestamps for when the observation occurred
Resource-linked: Findings identify the specific resource or artifact where the condition was observed
Evidence-backed: Findings can include or reference supporting evidence
Stateful: Findings track status (open, resolved, accepted, etc.)

Example Finding

{
  "id": "f-2024-001-aws-s3-encrypt",
  "signal_id": "CSE-HIPAA-TECH-ENCRYPT-REST-001",
  "observed_at": "2024-12-28T14:30:00Z",
  "status": "open",
  "artifact": {
    "type": "cloud_resource",
    "provider": "aws",
    "service": "s3",
    "resource_id": "arn:aws:s3:::patient-records-bucket",
    "region": "us-east-1"
  },
  "evidence": {
    "encryption_enabled": false,
    "bucket_name": "patient-records-bucket",
    "versioning_enabled": true
  },
  "source": {
    "tool": "aws-config",
    "rule": "s3-bucket-server-side-encryption-enabled",
    "scan_id": "scan-abc123"
  },
  "metadata": {
    "account_id": "123456789012",
    "environment": "production"
  }
}

Artifacts

An artifact is a piece of evidence or data that supports a finding. Artifacts provide the raw data that demonstrates why a finding was generated and can be used for audit purposes, debugging, or deeper analysis.

Artifact Types

Type	Description	Example
cloud_resource	Cloud provider resource configuration	AWS S3 bucket, Azure Storage Account
configuration	Application or system configuration	nginx.conf, terraform file
log_entry	Log file entries	CloudTrail event, application log
api_response	API call response data	AWS Config evaluation, API scan result
code_snippet	Source code excerpt	Vulnerable code pattern, IaC misconfiguration
screenshot	Visual evidence	UI showing misconfiguration

Example Artifact

{
  "id": "art-2024-001-config-eval",
  "finding_id": "f-2024-001-aws-s3-encrypt",
  "type": "api_response",
  "captured_at": "2024-12-28T14:30:00Z",
  "source": {
    "service": "AWS Config",
    "rule_name": "s3-bucket-server-side-encryption-enabled",
    "evaluation_id": "eval-xyz789"
  },
  "content": {
    "compliance_type": "NON_COMPLIANT",
    "resource_type": "AWS::S3::Bucket",
    "resource_id": "patient-records-bucket",
    "annotation": "Server-side encryption is not enabled",
    "ordering_timestamp": "2024-12-28T14:29:55Z"
  },
  "integrity": {
    "hash_sha256": "a1b2c3d4e5f6...",
    "signed_by": "arn:aws:iam::123456789012:role/ConfigRole"
  }
}

How They Work Together

These four concepts form a complete chain from abstract definition to concrete evidence:

Signal defines what condition to look for

Mapping links the signal to compliance controls

Finding records when a tool observes the signal

Artifact provides evidence supporting the finding

This separation of concerns enables different stakeholders to work with the appropriate level of abstraction:

Tool vendors emit findings with signal references
Compliance teams use mappings to understand control implications
Auditors review artifacts for evidence
Platform builders aggregate findings across tools using signal IDs

Next Steps

Signal Format

Complete schema for signal definitions

Mapping Format

How signals link to framework controls

Finding Format

Structure for recording observations

Browse Registry

Explore real signal examples