Opsec Domain: New Sections & Benchmarks

[dyasmanovych-hacken]

Intent

Add a set of implementation-oriented OpSec sections that focus on how teams operate securely day-to-day — distinct from existing Identity, Endpoint, Communications, Data Security, Cloud, Vendor, Physical, IR, and Travel content. Each section ships with:

• an index.md overview,
• at least one actionable doc (runbook/checklist/guide),

Why these sections?

• They fill operational security gaps and extend wallet security (runbooks, checklists, drills, SLOs) that typical control families don’t cover well.
• They avoid overlap with: IAM, Endpoint Protection, Communications Security, Data Security, Wallet Security (already present), DRP/Brand, Cloud Security, Vendor/Third-Party, Physical Security, Incident Response, and Travel Security.
• They’re directly measurable via benchmarks and easy to cross-link from certifications/maturity models.

Summary

Wallets & Key Material Security — Ops Execution

• Focuses on how keys are generated, handled, sealed, transported, backed up, and restored — day-to-day ceremonies and evidence. Needed to turn high-level wallet controls into repeatable, auditable runbooks.

Observability, Logging & Telemetry Hygiene

• Defines what to log for people/process security, anti-tamper, retention, and alert routing. Needed to make ops actions investigable and measurable without duplicating IR or cloud-specific logging.

Vulnerability & Exposure Management — Operational Loop

• Puts cadence, ownership, SLAs, and closure evidence around findings (scans, pentests, bug bounty). Needed to ensure “report → fix → verify” actually happens with traceable proof.

Data Leakage / Exposure Prevention with AI & LLMs

• Guardrails for prompt safety, redaction, tenant/model scoping, and human review queues. Needed to prevent inadvertent sensitive-data spillage via AI tooling — a gap not covered by generic PoLP/classification.

Capacity Management & Redundancy — Human & Process

• Ensures quorum availability, on-call coverage, key-holder redundancy, and drill SLOs. Needed so critical ops aren’t blocked by people availability or single-points-of-failure.

Threat Modeling & Attack-Path Management — Ops View

• Lightweight threat-path reviews for operational processes (wallet ops, vendor payouts, comms). Needed to catch process-level risks that classic AppSec modeling doesn’t cover.

SDLC for Operational Artifacts

• Versioning, review, and sign-off for runbooks, ceremony scripts, registries, and rosters. Needed to keep operational documents controlled like code — auditable, diffable, and revertible.

Change Management — Risk-Aware Releases

• Pre-flight checks, approvals, rollback plans for operational changes (quorum/signers/pager). Needed to reduce blast radius of ops changes and create consistent evidence of control.

Directory Tree

domains/
  opsec/
    index.md
    opsec-benchmark.js

    wallets-ops/
      index.md
      docs/
        key-generation-ceremony.md
        backup-and-restore-runbook.md
        storage-and-transport.md
      wallets-ops-benchmark.js

    observability/
      index.md
      docs/
        opsec-logging-profile.md
        alert-triage-and-escalation.md
      observability-benchmark.js

    vuln-ops/
      index.md
      docs/
        triage-to-remediation-loop.md
        external-report-intake.md
      vuln-ops-benchmark.js

    ai-data-guardrails/
      index.md
      docs/
        llm-usage-guardrails.md
        prompt-redaction-and-review.md
      ai-guardrails-benchmark.js

    capacity/
      index.md
      docs/
        quorum-and-coverage-slo.md
        rotation-and-drills.md
      capacity-benchmark.js

    threat-modeling/
      index.md
      docs/
        opsec-mini-threat-model.md
        attack-path-review-workshop.md
      tm-benchmark.js

    sdlc-ops/
      index.md
      docs/
        runbook-versioning-standard.md
        change-review-workflow.md
      sdlc-ops-benchmark.js

    change-mgmt/
      index.md
      docs/
        risk-based-change-checklist.md
        emergency-change-runbook.md
      change-mgmt-benchmark.js

[DicksonWu654]

Hi @dyasmanovych-hacken This is awesome stuff and really excited since this directly feeds into some SEAL Certs stuff! We have some existing content about multisig security in a pending pr inside of #220 - which are relevant to some of the topics you talked about above you can also view the materials here:
Hardware wallet: https://frameworks-4qlh1gkyb-theredguild.vercel.app/multisig-for-protocols/hardware-wallet-setup.html
Seed phrase security: https://frameworks-4qlh1gkyb-theredguild.vercel.app/multisig-for-protocols/seed-phrase-security.html
Emergency Multisig proceedures: https://frameworks-4qlh1gkyb-theredguild.vercel.app/multisig-for-protocols/emergency-procedures.html
And generally inside of https://frameworks-4qlh1gkyb-theredguild.vercel.app/multisig-for-protocols/index.html

(or you can just view the md files inside of the #239 pr :)

[mattaereal]

Hi @dyasmanovych-hacken . Thanks for this contribution. We'll have to ponder this with #226. I asked @Greyshaws to help me with this task as well.

Also @DicksonWu654, you're referencing a PR that you've closed, I think you updated it in #239?

[DicksonWu654]

Yep #239 now thx

[mattaereal]

So, I've been reading #226 and this one, and by these categorizations I seem to understand they do not overlap. Right now I am not that scared about overlapping, I rather we get to dump and work on the contents and in any case that we feel it does, we troubleshoot it when the moment comes. Sometimes it's easier when you got all the content laid down rather than anticipate it from a simple description.

@dyasmanovych-hacken if you're willing to contribute all this, please go ahead, and let me know how we can help you!

[mattaereal]

Also, following via telegram

[dyasmanovych-hacken]

Hello @mattaereal

Thank you! While leaving my comments, I also reviewed some existing commits and PRs — so I tried to approach it in a unique way.

Just wanted to clarify: what’s the preferred format of collaboration here? Should I go ahead and start drafting content for the sections I mentioned (and that I’m interested in) directly via pull requests/commits? Or would you prefer we discuss and iterate on the content in Telegram or shared docs first?

I’m asking because when working on frameworks, even the exact phrasing can matter a lot and sometimes requires a few ping-pong discussions to get right — just want to make sure GitHub is the right place for that level of back-and-forth.