View raw markdown

PRISM/CY — Cybersecurity Landscape Framework

Version: 1.0.0 Status: Draft Licence: CC BY-SA 4.0

1. Overview

PRISM/CY is a framework for describing, governing, and evolving an organization's cybersecurity posture as a landscape. It answers a class of question that no existing security framework addresses: what does our security posture look like right now, as a structured, navigable landscape?

Existing security frameworks — NIST CSF, ISO 27001, SOC 2, CIS Controls — are control checklists. They tell you which controls you should have, and whether you've implemented them. They do not describe your actual landscape: which identities have access to what, what your attack surface looks like, what threats are actively targeting which surfaces, and how your posture is evolving over time.

PRISM/CY fills that gap. It is a text-first, git-native, schema-validated landscape description that any organization can author, version, and validate — without proprietary tooling.

What PRISM/CY is not

• Not a control framework. It does not prescribe controls or measure gap-to-standard. Use NIST CSF or ISO 27001 for that.
• Not a live CSPM (Cloud Security Posture Manager). PRISM/CY describes the landscape as of as_of. For live drift detection, use Prisma Cloud, Wiz, or equivalent.
• Not a penetration testing methodology. PRISM/CY models your understanding of the attack surface; it doesn't enumerate all possible exploits.
• Not a ticketing system. Security programs and findings reference remediation work; they don't replace it.

Relationship to PRISM (Enterprise Architecture)

PRISM/CY and PRISM EA are independent frameworks. They share authoring conventions and cross-reference by artifact ID.

PRISM EA's Reality/systems lists what systems exist. PRISM/CY's Surface dimension describes which of those systems are exposed and how. Cross-reference using the prism_ea_system link field — no schema enforcement, soft reference by ID.

Relationship to PRISM/I (Infrastructure)

PRISM/I describes how infrastructure runs. PRISM/CY describes how it's secured. The relationship is:

• PRISM/I Control dimension: network-level controls (VPCs, firewalls, IAM policies, certificates)
• PRISM/CY Controls dimension: the full security control posture — technical + organizational

They overlap at network controls. Cross-reference PRISM/I control artifacts using the prism_i_artifact link field.

2. Foundational Principles

PRISM/CY inherits three principles from PRISM EA.

2.1 YAML for Artifacts, JSON for Schemas

Security landscapes are authored in YAML. Schemas are in JSON Schema format. YAML because security teams, architects, GRC analysts, and CISOs need to read and write these files — not just developers. Comments, block scalars, and minimal syntax noise matter.

2.2 Git-Native Governance (Architecture as Code)

Security architecture in PRISM/CY is architecture as code: posture lives in git, not a spreadsheet or a slide deck.

Security posture in a git repo means: every posture change is a commit with an author, timestamp, and reviewers. This is more auditable than a spreadsheet.

2.3 Temporal Axis

Every PRISM/CY landscape is positioned on a temporal axis.

Artifacts declare their own temporal state. A control being retired is decommissioning. A planned control is planned. The combination of artifact-level states describes the migration from current to target posture.

2.4 Who & Where is Inherited

Security teams and organizational structure live in PRISM EA's P layer. PRISM/CY does not duplicate stakeholders or geographies. It references them by ID.

This is intentional: the organization chart, geography, and jurisdiction structure is the same whether you're describing EA or security posture. PRISM/CY focuses on the security-specific concerns.

3. The Five Dimensions

Why five?

Identity stands alone because identity is the new perimeter. In a cloud-native, zero-trust world, network boundaries are secondary to identity boundaries. Who (or what) has a credential matters more than where the traffic originates.

Surface is separate from Identity because exposure and access are different concerns. A system can be exposed without a credential (e.g., a misconfigured public S3 bucket). A credential can exist without a public exposure. Surface describes the shape of the attack surface; Identity describes who has keys to it.

Controls stands alone because controls are the defensive response. They span Identity (MFA enforces it), Surface (WAF protects it), and Threats (SIEM detects them). Burying controls inside another dimension obscures the governance question: "what's actually protecting us?"

Threats stands alone because active threat intelligence is a separate concern from the landscape it targets. A threat actor doesn't become irrelevant because the surface is patched — it stays in the landscape as a documented risk. Threats reference Surfaces and Identities but are not subordinate to them.

Posture is last because it synthesizes the other four. Posture artifacts describe where the organization stands relative to external compliance frameworks, and which programs are addressing identified gaps.

4. Dimensions — Artifact Types

4.1 Identity

Key fields on identity artifacts:

4.2 Surface

Key fields on surface artifacts:

4.3 Controls

Key fields on control artifacts:

4.4 Threats

Key fields on threat artifacts:

Dependency modeling in Threats:

Threat artifacts use depends_on to link to the surfaces, identities, or controls they exploit or reference. This enables blast radius analysis:

• Selecting a surface shows which threats target it (impacted threats)
• When a surface is decommissioned, linked threats light up as "at risk of becoming unresolvable" — the threat record may need closure or reassignment

- id: threat-zos-eol
  type: threat
  threat_category: eol-risk
  depends_on: [surf-zos-jcl-batch]   # threat tied to this surface
  # if surf-zos-jcl-batch decommissions, this threat should be closed

4.5 Posture

Key fields on posture artifacts:

5. File Structure

<org-name>/
  .prism-cy/
    config.yaml             # landscape metadata
  identity/
    landscape.yaml
  surface/
    landscape.yaml
  controls/
    landscape.yaml
  threats/
    landscape.yaml
  posture/
    landscape.yaml

.prism-cy/config.yaml

prism_cy_version: "1.0"
organization: "ACME, INC"
description: "Cybersecurity landscape — insurance operations, cloud migration"
domain: insurance
scope: enterprise
temporal_state: transition     # mid cloud migration; security posture in flux
as_of: "2025-01-01"
active_dimensions:
  - identity
  - surface
  - controls
  - threats
  - posture
security_frameworks:
  - GDPR
  - SOX
  - ISO-27001

Dimension landscape file

# identity/landscape.yaml
dimension: identity
as_of: "2025-01-01"
temporal_state: transition

iam_roles:
  - id: role-soc-analyst
    name: "SOC Analyst"
    type: iam_role
    ownership: self
    access_level: read
    mfa_enforced: true
    ...

service_accounts:
  - id: svc-acct-claims-ai
    name: "AI Claims Triage Service Account"
    type: service_account
    ownership: self
    pam_controlled: false
    ...

Each dimension file uses its artifact type as the top-level key (plural). The id must be unique within the landscape.

6. Cross-Referencing

PRISM/CY artifacts can reference artifacts from other PRISM frameworks using links:

- id: surf-claims-portal
  type: public_endpoint
  links:
    prism_ea_system: sys-claims-portal    # PRISM EA Reality/systems
    prism_i_artifact: svc-claims-api      # PRISM/I Runtime/services

Cross-references are soft — no schema enforcement across frameworks. PRISM/CY does not import other frameworks' schemas.

7. Dependency Modeling and Blast Radius

PRISM/CY supports depends_on on all artifact types. The key use cases:

Threat → Surface: A threat depends on the surface it exploits. When the surface decommissions, the threat record should be closed.

Security program → Threat: A remediation program depends on the threat it addresses. When the threat is resolved, the program can be closed.

Identity → Control: A privileged identity depends on the PAM control managing it. If the control is decommissioned, the identity is unmanaged.

Blast radius analysis surfaces these relationships visually. Select any artifact to see what depends on it (impacted) and what it depends on (upstream).

8. Temporal Representation

# threats/landscape.yaml
temporal_state: transition

threats:
  - id: threat-zos-eol
    name: "z/OS EOL Risk"
    type: threat
    status: active
    temporal_state: baseline   # this threat exists in current state
    target_resolution: "2025-12-31"

  - id: threat-zos-eol-resolved
    name: "z/OS EOL Risk (resolved)"
    type: threat
    status: decommissioned
    temporal_state: target      # when migration completes, this threat closes

9. What PRISM/CY Does Not Cover

• Live security posture. PRISM/CY is a landscape description, not a real-time dashboard. For live drift detection, use Wiz, Prisma Cloud, or equivalent.
• Penetration test methodology. PRISM/CY models your understanding of the surface; it doesn't enumerate all possible exploit paths.
• Security event data. PRISM/CY records that a SIEM exists and what it covers; the actual alerts live in your SIEM.
• Detailed access policies. PRISM/CY captures the shape of IAM (which roles exist, what access level, whether MFA-enforced); specific policy JSON/YAML lives in your IaC repo.

Paper

Palakurthi, V.G. (2026). PRISM: Enterprise architecture frameworks for the source-first era.

• Site: https://prism-framework.org/
• PDF: https://prism-framework.org/PRISM_Framework_V1.0.pdf
• SSRN: https://ssrn.com/abstract=7037719
• Zenodo (DOI): https://doi.org/10.5281/zenodo.21325668