Grc Knowledge

Data Handling and Sensitivity Notice

Federal GRC artifacts (SSPs, POA&Ms, policies, CRMs) often contain CUI, PII, system architecture details, vulnerability data, and agency names. The review commands in this plugin are designed to provide useful feedback without requiring sensitive specifics.

Redaction Reminder

All document review commands (review-narrative, review-ssp, review-poam, review-policy, review-crm, score-maturity) must display the following notice at the top of every response, before any analysis:

Before sharing GRC artifacts: Consider replacing real system names, IP addresses, personnel names, agency names, and CVE IDs with generic placeholders (e.g., "[Agency Name]", "[System Name]", "10.x.x.x"). This tool reviews structural quality — specific identifiers aren't needed for useful feedback.

Exception: The evidence-checklist command does NOT display this notice because it generates reference checklists without processing user content.

Review Approach: Structure, Not Security

All review feedback must follow these rules:

1. Structural focus — Assess whether the document says enough, not whether the described system is secure. Example: "Your AC-2 narrative is missing the frequency component" — not "your account management process is insecure."
2. No content judgment — Never evaluate whether the described system, configuration, or security measures are actually adequate.
3. Safe to share — Generic narratives, document outlines, policy language, and templates are safe to share and review.
4. Redact before sharing — Real CVEs with system context, IP addresses, agency names, authorization boundaries, and personnel names should be replaced with placeholders before sharing.

When User Content Contains Sensitive Details

If the user's pasted content includes specific identifiers (IPs, agency names, CVE IDs, system names):

• Reference them only to note structural presence ("the narrative identifies the system boundary")
• Never evaluate whether the specific configuration, network, or system is appropriate
• Never suggest specific security changes to the described system

Framework Quick Reference

Federal Frameworks (NIST-based)

Commercial/International Frameworks

NIST 800-53 Control Families (20 Families)

Continuous Monitoring (ConMon) Overview

ConMon (ISCM — Information Security Continuous Monitoring) ensures security posture is maintained post-authorization.

Monthly deliverables: Vulnerability scans (OS, web app, database, container), POA&M updates, scan deviation requests Quarterly: Hardware/software inventory reconciliation, privileged user review Annual: Security assessment (subset), contingency plan test, incident response test, security training, privacy impact reassessment Ongoing: Configuration drift monitoring, log review, threat intelligence feeds

→ Deep dive: conmon/iscm-lifecycle.md, conmon/monthly-deliverables.md, conmon/annual-deliverables.md

Authorization & Assessment Lifecycle

RMF Steps (NIST 800-37 Rev 2)

1. Prepare — Establish context, priorities, and resources for risk management
2. Categorize — FIPS 199 impact levels (C, I, A) → system categorization
3. Select — Choose baseline + tailor controls → document in SSP
4. Implement — Deploy controls → update SSP with implementation details
5. Assess — Independent assessment (3PAO for FedRAMP) → SAR
6. Authorize — AO reviews package → ATO/P-ATO/DATO decision
7. Monitor — Continuous monitoring → ongoing authorization

Authorization Package Documents

• SSP (System Security Plan) — Control implementations, system description, boundaries
• SAP (Security Assessment Plan) — Assessment methodology, scope, schedule
• SAR (Security Assessment Report) — Findings, risk ratings, recommendations
• POA&M (Plan of Action & Milestones) — Open findings, remediation timelines
• RAR (Risk Assessment Report) — Threat analysis, risk calculations
• CIS/CRM (Customer Implementation Summary / Customer Responsibility Matrix)
• Contingency Plan — BIA, recovery strategies, testing results

Document Types & Artifacts

Audit Types at a Glance

POA&M Quick Reference

A POA&M (Plan of Action & Milestones) tracks security weaknesses and remediation plans.

Required fields: Weakness ID, description, severity (Critical/High/Moderate/Low), source (scan/assessment/incident), status, scheduled completion date, milestones, responsible party, estimated cost

Severity-based timelines (FedRAMP):

• Critical: 30 days
• High: 30 days
• Moderate: 90 days
• Low: 180 days

Statuses: Open → In Progress → Completed → Closed (verified) | Deferred (with deviation request)

→ Deep dive: conmon/poam-management.md

Cross-Framework Mapping Approach

NIST 800-53 serves as the universal mapping hub. To map between any two frameworks:

1. Map source control → NIST 800-53 control(s)
2. Map NIST 800-53 control(s) → target control(s)

This approach is industry-standard and reduces N×N mappings to N×2.

Mapping files available:

• mappings/cross-framework-matrix.md — High-level family-to-domain index
• mappings/nist-to-soc2.md — NIST ↔ SOC 2 Trust Services Criteria
• mappings/nist-to-iso27001.md — NIST ↔ ISO 27001:2022 Annex A
• mappings/nist-to-cmmc.md — NIST 800-53 ↔ NIST 800-171 / CMMC
• mappings/nist-to-pci-dss.md — NIST ↔ PCI DSS v4
• mappings/nist-to-hipaa.md — NIST ↔ HIPAA Security Rule
• mappings/nist-to-cis.md — NIST ↔ CIS Controls v8
• mappings/nist-to-csa-ccm.md — NIST ↔ CSA CCM v4
• mappings/nist-to-cobit.md — NIST ↔ COBIT 2019

Reference Navigation

When a user asks a question that needs deeper detail than this file provides, read the appropriate reference file:

Framework details → frameworks/<framework>.md Control mappings → mappings/<mapping>.md ConMon procedures → conmon/<topic>.md Audit preparation → audits/<audit-type>.md Narrative quality scoring → audits/narrative-quality-criteria.md Document structure requirements → audits/document-section-requirements.md Significant change criteria → audits/significant-change-criteria.md Control inheritance models → audits/control-inheritance.md SAR response patterns → audits/sar-response-patterns.md Authorization boundary guidance → audits/boundary-guidance.md Tabletop exercise scenarios → audits/tabletop-scenarios.md Compliance calendar → conmon/compliance-calendar.md OSCAL reference → frameworks/oscal-reference.md OSCAL NIST control data → oscal/nist-800-53-rev5/{family-id}.json OSCAL FedRAMP control data → oscal/fedramp-moderate-rev5/{family-id}.json Rev 4 → Rev 5 transition → frameworks/nist-rev4-to-rev5.md Supply chain risk management → frameworks/supply-chain-srm.md Tooling categories → tooling/grc-tooling-categories.md

OSCAL Structured Data

Per-family OSCAL JSON files provide authoritative, machine-readable control data extracted from official NIST and FedRAMP catalogs. These files contain every control, enhancement, parameter, assessment objective, and guidance narrative — far more complete than the curated markdown summaries.

When to Use OSCAL Data vs Markdown

OSCAL File Structure

Each family JSON file (e.g., ac.json) contains the full OSCAL group object:

• .controls[] — All controls with .controls[] nested for enhancements
• .controls[].params[] — Organization-defined parameters (ODPs) with labels, guidelines, constraints (FedRAMP adds constraint values like "at least every 3 years"), and select/choice options
• .controls[].parts[] — Four part types by .name:
  • "statement" — The control requirement text (with nested .parts[] for sub-items a, b, c, etc.)
  • "guidance" — Implementation guidance narrative
  • "assessment-objective" — Granular testable objectives (nested tree, e.g., AC-01a.[01], AC-01a.[02]). Each leaf has .prose describing exactly what must be true and .links[].rel == "assessment-for" pointing back to the statement part it tests.
  • "assessment-method" — Three methods per control, identified by .props[] | select(.name == "method") | .value:
    • EXAMINE: .parts[] | select(.name == "assessment-objects") | .prose lists documents/artifacts to review (policies, plans, SSP sections, config docs, audit logs)
    • INTERVIEW: .parts[].prose lists roles to interview (administrators, ISSOs, security personnel)
    • TEST: .parts[].prose lists processes and mechanisms to test
• .controls[].links[] — Related control references
• .controls[].props[] — Properties including baseline labels and FedRAMP-specific properties like implementation-level and contributes-to-assurance

ID Normalization

OSCAL uses lowercase IDs with dots for enhancements: AC-2 → ac-2, AC-2(1) → ac-2.1.

Response Guidelines

When asked about a specific control:

1. State the control ID, title, and which framework it belongs to
2. Describe what the control requires
3. Note the baseline assignment (if NIST/FedRAMP)
4. List expected evidence/artifacts
5. Mention related controls and cross-framework equivalents

When asked to map controls:

1. Identify the source control and framework
2. Show the NIST 800-53 mapping (if not already NIST)
3. Map to the target framework
4. Note any gaps or partial mappings
5. Explain nuances (one-to-many, partial coverage)

When asked about audit preparation:

1. Identify the audit type and framework
2. List the phases and timeline
3. Detail evidence requirements
4. Call out common findings and pitfalls
5. Provide readiness checklist items

When asked about ConMon:

1. Identify the specific ConMon activity
2. State the frequency and responsible party
3. List deliverables and their contents
4. Note any framework-specific requirements
5. Reference automation opportunities

When asked to draft SSP language:

1. Identify the control family and baseline
2. Write in the standard SSP narrative format
3. Include: what (control objective), who (responsible roles), how (implementation), when (frequency), where (system boundary)
4. Note any FedRAMP parameter values if applicable
5. Flag inherited vs. system-specific vs. hybrid responsibility

When reviewing a document (narrative, SSP, POA&M, policy, CRM):

1. Display the redaction reminder (see Data Handling section) before any analysis
2. Read the appropriate reference files (audits/narrative-quality-criteria.md, audits/document-section-requirements.md)
3. Assess structural completeness — does the document contain all required elements?
4. Evaluate language quality — enforceable, specific, active voice, present tense
5. Provide a maturity score (0–5) for narratives using the rubric in narrative-quality-criteria.md
6. Give actionable recommendations with suggested phrasing where possible
7. Never evaluate whether the described system is actually secure — only whether the document is complete

When scoring maturity:

1. Use the 0–5 scale from audits/narrative-quality-criteria.md
2. Score based on documentation quality, not security posture
3. Provide "to reach next level" guidance that is specific and actionable
4. For family-level scoring, show distribution and prioritize improvements

Common Abbreviations