Is your feature request related to a problem?
Gemara's schema has primitives that can express multi-party (or component) control responsibility (e.g., applicability-groups, executor), but no conventions exist for using them.
Describe the solution you'd like
Define conventions for control inheritance using existing schema primitives where possible. Define new (optional) fields where needed.
- Native: Component meets the control without configuration.
- Configurable: Component can be configured to meet the control, but does not by default.
- Inherited: Component consumes the functionality from another source and depends on that implementation
- Inherited Configurable: Inherited, but still requires configuration on the consuming side. (i.e., Shared)
- Custom: Component does not provide the functionality. Implementer is responsible outside the component's scope, or accepts the risk.
Brainstormed ideas below.
Native
controls:
- id: CTRL-1
title: Transport layer encryption
objective: Ensure all data in transit is encrypted
group: data-protection
state: Active
assessment-requirements:
- id: CTRL-1-ar1
text: All connections MUST use TLS 1.2 or higher by default
applicability: ["all"]
assessment-plans:
- id: ap-ctrl-1
requirement-id: CTRL-1-ar1
frequency: continuous
evidence-requirements: "Automated check confirming TLS enforcement"
evaluation-methods:
- id: em-ctrl-1
type: Behavioral
mode: Automated
required: true
description: Validates all connections enforce TLS 1.2+
executor:
id: tls-check
name: tls-check
type: Software
Configurable
controls:
- id: CTRL-2
title: Encryption algorithm strength
objective: Ensure encryption meets minimum algorithm strength
group: data-protection
state: Active
assessment-requirements:
- id: CTRL-2-ar1
text: Encryption algorithm MUST meet the minimum strength specified by policy
applicability: ["encryption-at-rest"]
assessment-plans:
- id: ap-ctrl-2
requirement-id: CTRL-2-ar1
frequency: continuous
evidence-requirements: "Automated check evaluation history with parameter validation"
evaluation-methods:
- id: em-ctrl-2
type: Behavioral
mode: Automated
required: true
description: Validates encryption meets minimum algorithm strength
executor:
id: encryption-strength-check
name: encryption-strength-check
type: Software
parameters:
- id: min-algorithm-strength
label: Minimum Algorithm Strength
description: Minimum acceptable encryption algorithm
accepted-values: ["AES-256", "AES-128"]
Inherited
Do we need to optionally connect capabilities to controls directly if they provide security functions?
title: Cloud Provider - Storage Capabilities
metadata:
id: provider-storage-capabilities
type: CapabilityCatalog
gemara-version: "1.0.0"
description: Capabilities provided by the cloud storage platform
author:
id: provider
name: Cloud Provider
type: Software
groups:
- id: encryption
title: Encryption Services
description: Cryptographic capabilities provided by the platform
capabilities:
- id: CAP-1
title: Default server-side encryption
description: Platform provides server-side encryption for all stored objects using provider-managed keys
group: encryption
- id: CAP-2
title: Customer-managed encryption keys
description: Platform supports customer-managed encryption keys via key management service
group: encryption
title: Example Controls - Storage
metadata:
id: example-storage-controls
type: ControlCatalog
gemara-version: "1.0.0"
description: Storage controls that inherit from upstream provider capabilities
author:
id: example-author
name: Example Author
type: Human
mapping-references:
- id: provider-controls-ref
title: Cloud Provider Controls
version: "1.0.0"
url: https://example.com/provider-controls.yaml
imports:
- reference-id: provider-controls-ref
entries:
- reference-id: provider-controls-ref
remarks: Inherited encryption controls from cloud provider
groups:
- id: data-protection
title: Data Protection
description: Controls for confidentiality and integrity of data
controls:
- id: CTRL-3
title: Resource default encryption
objective: Ensure data at rest is encrypted via inherited provider capability
group: data-protection
state: Active
assessment-requirements:
- id: CTRL-3-ar1
text: The provider MUST make a default encryption capability available
applicability: ["cloud-storage"]
state: Active
assessment-plans:
- id: ap-ctrl-3
requirement-id: CTRL-3-ar1
frequency: annual
evidence-requirements: "Provider attestation confirming encryption capability"
evaluation-methods:
- id: em-ctrl-3
type: Intent
mode: Manual
required: true
description: Verify provider makes default encryption capability available
executor:
id: assessor
name: Compliance Analyst
type: Human
Custom
risks:
accepted:
- id: risk-accept-1
risk:
reference-id: org-risk-catalog-ref
entry-id: RISK-DATA-LOSS-1
justification: >
Component does not provide application-level audit logging.
Custom logging implemented via external sidecar agent.
Residual risk accepted per annual risk review.
scope:
in:
technologies: ["cloud-storage"]
Describe alternatives you've considered
- Adding an optional responsibility enum to AssessmentRequirement
- Adding a recommended-executor field at the ControlCatalog layer
Success Criteria
Additional context
No response
Is your feature request related to a problem?
Gemara's schema has primitives that can express multi-party (or component) control responsibility (e.g.,
applicability-groups,executor), but no conventions exist for using them.Describe the solution you'd like
Define conventions for control inheritance using existing schema primitives where possible. Define new (optional) fields where needed.
Brainstormed ideas below.
Native
Configurable
Inherited
Custom
Describe alternatives you've considered
Success Criteria
Additional context
No response