B.7 — Compromise Detection and Monitoring

Domain B.7 — Compromise Detection and Monitoring#

B.7.0. Overview#

This domain establishes requirements for detecting unauthorized use or attempted compromise of Critical Cryptographic Material. This domain is the last line of defense: if the preceding domains (storage, usage, lifecycle, architecture) failed to prevent a compromise, detection in this domain provides the ability to perform revocation (Section B.5.2) before the material is used for exfiltration.

Scope clarification: this domain covers only the protection of CCM. On-chain monitoring for AML / Travel Rule / fraud detection constitutes separate compliance domains outside the scope of CCSA (see Section 0.2.2). If the Assessed Entity's AML system incidentally detects a CCM compromise, that is a useful side-effect; CCSA assesses only the latter context.

Conceptually related PCI DSS v4.0.1 requirements: Requirement 10 (Log and Monitor All Access to System Components and Cardholder Data), Requirement 12.10 (Incident Response).

---

B.7.1 — Logging of CCM-related Events#

Defined Approach Requirement#

Every security-relevant event related to CCM must be logged. Log content for signing events must contain the mandatory fields (see below). Log storage ensures integrity through an append-only mechanism and cryptographic hash chaining. Retention is differentiated by certification level.

Mandatory Events to Log#

Log Content for Signing Events#

Minimum fields:

• Timestamp in UTC with millisecond precision (and optional local timezone)
• Operator identity: for backend signing — service identity (service principal); for customer signing — user identity (user ID, not PII)
• Transaction identifier (internal and blockchain hash after broadcast)
• Source IP and device fingerprint (if applicable)
• CCM identifier (ID from the inventory, Section B.1.1, without disclosing the key itself)
• Outcome (success / failed with reason)
• Approver(s) if multi-person (list of approver identities)
• Operation context (signing scope, destination, amount if applicable)

Log Integrity#

• Append-only storage: WORM (Write-Once-Read-Many) media or a blockchain-anchored hash chain
• Cryptographic hash chaining between log entries: hash(entry_n) = hash(entry_n-1 || entry_n_content)
• Verification of log integrity on demand (any entry can be verified)
• Tamper detection through a cryptographic MAC

Retention#

For the AOC and regulatory reporting, extended retention may be required (see Section D.6.2).

Applicability Notes#

• Mandatory for C.1, C.3, C.4 at all levels.
• For C.2, reformulated: the vendor must document the events logged on the application side (signing UX events, recovery attempts, configuration changes); end-user-side events are not subject to logging in the vendor infrastructure.

Customized Approach Objective#

Any use or attempted use of CCM is auditable after the fact; undetectable modification of log entries is impossible; retention satisfies the forensic investigation requirements for the specific level.

Defined Approach Testing Procedures#

• B.7.1.a Examine the log inventory and configuration:

  • Obtain the SIEM or log aggregation system configuration.
  • Verify that all sources from the Mandatory Events table send logs to central storage.
  • Verify completeness: check for the absence of gaps between the required events and actual logging.
  • Obtain the cryptographic hash chaining implementation; verify that an approved algorithm is used (SHA-256 minimum).
  • Obtain the retention policy and verify conformance with the applicable level.

• B.7.1.b Interview the SIEM operations and security operations team:

  • Interview the personnel responsible for the SIEM and for CCM operations.
  • Questions:
    • "What happens if log tampering is detected?"
    • "How is log integrity verified on a regular basis?"
    • "If someone attempts to modify a log entry, how is this detected?"
    • "What is the alert latency between event occurrence and log visibility in the SIEM? (Must be ≤ 5 minutes)"
    • "Describe a case in which a log helped in a forensic investigation over the last 12 months."

• B.7.1.c Observe live logging:

  • Request a demonstration: execute a test signing operation in the test environment.
  • Verify that the log entry appears in the SIEM within ≤ 5 minutes.
  • Verify that all required fields are present in the entry.
  • Verify that the hash chain includes the new entry; verify that the integrity of older entries is not broken.

• B.7.1.d Trace a signing operation through all logs:

  • Select one production signing operation from the last week.
  • Trace it through all sources:
    • Entry in the HSM/MPC log with timestamp and operation reference
    • Entry in the signing service log
    • Entry in the API gateway log (if applicable)
    • Entry in the audit log with approval references (if multi-person)
  • Verify that all entries are chronologically consistent, the hash chains are valid, and the fields match expected values.

• B.7.1.e Tamper attempt simulation (for L3):

  • Request an attempt to modify a historical log entry in a test environment with a copy of production data.
  • Expected result: modification is detected through hash chain verification; an alert is generated; the integrity check fails.
  • If the modification is not detected — critical finding.

Purpose#

Logging is the foundation of forensic capability and compliance auditability. Without comprehensive logs, the organization cannot: reconstruct what happened during an incident; prove compliance with regulatory requirements; identify insider threats through behavioral pattern analysis. Cryptographic hash chaining protects against tampering by insiders — even a privileged user with access to log storage cannot covertly modify historical entries without detection through chain verification.

Good Practice#

• Use SIEM solutions with native support for cryptographic hash chaining (Splunk Smart Store, Elastic Security with frozen tier).
• Regularly (monthly) perform integrity verification of the entire log chain — this detects storage corruption or tampering at an early stage.
• For L3 — blockchain-anchoring of the log chain hash through regular submission to a public blockchain (for example, via OpenTimestamps).

Examples#

• AWS CloudTrail Lake with integrity validation enabled.
• Splunk with Cluster Manager and hash chain validation.
• Self-hosted Loki + a custom hash chaining microservice with anchoring in Bitcoin via OpenTimestamps.

Mapping to baseline standards#

• PCI DSS Requirement 10 (Logging and Monitoring): Full carry-over.
• CCSS v8.0 Domain 10 (Audit Logs): Full.
• GOST R 57580.1 (UIZ): Full.

---

B.7.2 — Anomaly Detection for Signing Operations#

Defined Approach Requirement#

Systems must detect anomalous use of CCM through a combination of rule-based, statistical, and (for L3) ML-based detection. Anomaly categories cover velocity (rate), pattern, failed attempts, and access. Alert response is differentiated by severity.

Anomaly Categories#

Velocity anomalies:

• Unusual rate of signing operations with a specific CCM
• Bulk transactions outside normal patterns
• Time-of-day anomalies (signing during non-working hours from usual IPs)

Pattern anomalies:

• Signing operations with unusual destinations (for example, a destination not on the whitelist for an institutional account, see Section B.6.5)
• Operations outside normal time windows or geographic patterns
• Use of a CCM that has not been used before (for example, a dormant key suddenly signing)
• Reverse pattern: a known frequent CCM suddenly silent (may indicate a compromised key holder)

Failed attempts:

• Multiple authentication failures on CCM-related systems
• Failed HSM PIN attempts (could indicate brute-force)
• Failed MFA for signing operations (could indicate session compromise)

Access anomalies:

• Privileged access outside maintenance windows
• Access patterns deviating from baseline (for example, new login locations, new user agents)
• Geographic anomalies in admin access

Detection Mechanisms by Level#

Alert Response#

• Severity High (clear indication of compromise): automatic temporary suspension of CCM use; immediate escalation per playbook (Section B.7.4)
• Severity Medium (suspicious pattern, may be legitimate): mandatory review before the next signing operation; escalation if the pattern continues
• Severity Low (informational, baseline drift): logged for forensics, no immediate action; aggregation for trend analysis

Applicability Notes#

• Mandatory for C.1, C.3, C.4 at all levels.
• For C.2, reformulated: the vendor must provide anomaly detection for events observed on the application side (for example, multiple failed unlock attempts, unusual transaction patterns); end-user-side anomaly detection (in the user's custody operations) is not within the vendor's scope.

Customized Approach Objective#

Anomalous use of CCM is detected and triggers an alert workflow with the appropriate severity; response time corresponds to the value at risk; the baseline continuously adapts to legitimate behavior changes without drifting into overlooking emerging threats.

Defined Approach Testing Procedures#

• B.7.2.a Examine detection rules:

  • Obtain the detection rules / statistical models / ML model configurations.
  • For L1 verify: thresholds for all anomaly categories; threshold values proportional to the expected baseline.
  • For L2 verify: the baseline calculation methodology, a minimum of 30 days of historical data, deviation criteria.
  • For L3 verify: ML model metadata (training data, features, validation metrics — accuracy / recall / precision; retraining frequency); model performance reports.

• B.7.2.b Interview the anomaly detection lead:

  • Interview the person responsible for detection engineering.
  • Questions:
    • "What is the false positive rate over the last 12 months?"
    • "Describe a case in which detection found a real incident."
    • "Describe a case in which detection missed an incident. What was the cause?"
    • "How does the baseline adapt to legitimate changes in the business (for example, a new product with a different signing pattern)?"
    • "For L3: when was the model last retrained? What were the changes in accuracy?"

• B.7.2.c Observe negative testing:

  • Request simulation of anomalous patterns in a test environment:
    • L1: trigger a velocity anomaly (100 signing requests in 1 minute) — verify an alert within 5 minutes
    • L2: inject a statistical anomaly (signing outside the baseline 3-sigma) — verify an alert
    • L3: craft an adversarial test case (looks normal but has subtle anomalous markers) — verify the ML model catches it OR the ML team explicitly accepts the false negative
  • Sample 5 historical alerts from the last 30 days — verify that for each there was a proper response action.

• B.7.2.d Trace an alert from detection to resolution:

  • Select one severity High alert from the last 90 days.
  • Trace: detection event -> alert generation -> notification -> initial response action (for example, temporary suspension) -> investigation -> resolution -> post-incident review.

Purpose#

Anomaly detection provides proactive defense beyond static rules. Signing operations have natural patterns (time-of-day, frequency, typical destinations); a CCM compromise usually breaks these patterns in a detectable way. Rule-based detection at L1 catches obvious attacks (rapid mass withdrawal of funds); statistical and ML catch more sophisticated attacks that mimic normal behavior. The combination of all three levels provides detection of both mass and targeted attacks.

Good Practice#

• Include seasonal patterns in the baseline (for example, a different signing rate on working days vs weekends).
• Use a feedback loop from incident postmortems into model retraining: new attack patterns should make it into the training data.
• Cross-organizational threat intelligence sharing (for example, via an ISAO for the crypto industry) — attack patterns on other organizations often predict attacks on you.

Examples#

• Splunk Enterprise Security with UEBA for behavioral baselines.
• A custom ML model in TensorFlow with features (rate, destination novelty, time-of-day deviation, geographic deviation) for L3.
• The open-source SIEM Wazuh with custom rules for CCM-specific patterns.

Mapping to baseline standards#

• PCI DSS Requirement 10.4 (Suspicious Activity Detection): Partial.
• GOST R 57580.1 (UIZ): Full.

---

B.7.3 — Watch-Only Address Monitoring (Reconciliation)#

Defined Approach Requirement#

Watch-only monitoring (Section B.6.2) must be used for real-time reconciliation between on-chain activity and internal signing logs (Section B.7.1). Any movement of funds from a production address without a registered approved signing operation is a critical compromise indicator and must trigger an immediate alert.

This requirement is a Critical Requirement (see Section D.2.5). The Customized Approach and Compensating Control are not permitted for B.7.3.

Required Reconciliation Logic#

For each on-chain balance change at a watched address:
    Find the corresponding entry in the signing log (Section B.7.1)
        Match by: source address, destination, amount, timestamp (with tolerance for propagation delay)
    If no match is found -> CRITICAL ALERT
        Severity: highest
        Action: immediate revocation procedure (Section B.5.2)
        Response: see playbook (Section B.7.4)

SLA for Detection and Response#

In crypto infrastructure, a blockchain transaction is immutable once confirmed; the window for intervention is the period between detection and the achievement of finality (typically 10–60 minutes for major blockchains). The SLAs above are chosen on the basis of this realistic window: even the L1 SLA of 5 minutes for detection leaves operations time for revocation in most scenarios.

Procedure on Detection#

1. Immediate revocation of the potentially compromised CCM (Section B.5.2 with an SLA of ≤ 15 minutes for category A)
2. Halt signing operations with the related CCM
3. Forensic investigation begins in parallel (Section B.7.4 playbook)
4. Customer / counterparty notification within the applicable time and legal/regulatory obligations
5. Regulatory notification (for example, FinCERT within 3 hours for the Russian jurisdiction, or per MiCA for the EU)

Applicability Notes#

• Mandatory for C.1, C.3, C.4 at all levels.
• Critical Requirement: the Customized Approach and Compensating Control are not permitted.
• Not Applicable for C.2 (absence of server-side wallets at the vendor; reconciliation is performed by the user on their own side).

Customized Approach Objective#

Not Applicable. B.7.3 is a Critical Requirement (Section D.2.5). The Customized Approach is not permitted (Section 0.7.2). Compensating Control is fully forbidden (Section 0.8.2 — fully-forbidden CC). Conformance is achieved solely through the Defined Approach.

Defined Approach Testing Procedures#

• B.7.3.a Examine the reconciliation system:

  • Obtain documentation of the reconciliation system: which watched addresses, which signing log sources, what matching logic, what SLAs.
  • Obtain the configuration of timeouts and alert routing.
  • Obtain a sample reconciliation report from the last 30 days; verify that every on-chain event has a matching signing log entry or an alert.

• B.7.3.b Interview the operations and engineering leads:

  • Interview separately.
  • Questions:
    • "What is the detection SLA in production over the last 90 days?"
    • "How many false-positive alerts were there? How were they handled?"
    • "What happens if the reconciliation system itself is unavailable?"
    • "Describe the most recent case in which reconciliation triggered a real alert (not a drill)."

• B.7.3.c Observe the alert flow:

  • Request an end-to-end demonstration in a test environment:
    • Trigger a transaction at a watched address (test environment)
    • Record it in the signing log with a time delay (for example, +30 seconds)
    • Verify that during the delay the alert does NOT fire (the reconciliation window is expected)
    • After recording in the log — verify that the alert does not fire (match found)
  • Alternative test: trigger a transaction WITHOUT a corresponding signing log entry
    • Verify that the alert fires within the applicable SLA
    • Verify that the alert triggers automated revocation initiation

• B.7.3.d Trace historical reconciliation:

  • Select a date 30 days ago with known signing activity (for example, sample 20 production signing events from one day).
  • Verify that for each event the reconciliation log contains a corresponding matched record.
  • Verify that the reconciliation SLA in the historical data conforms to the applicable level.

Purpose#

Watch-only reconciliation is the primary mechanism for detecting unauthorized signing. If a CCM is compromised and the attacker signed a transaction through direct access to the key material (without using the approval workflow), that transaction will not appear in the Assessed Entity's signing log but will appear on-chain. Reconciliation compares these two sources and detects the discrepancy. This is the only mechanism that provides detection of out-of-band signing — all other mechanisms (B.7.1 logging, B.7.2 anomaly detection) work only within the Assessed Entity's signing infrastructure.

Good Practice#

• Use independent blockchain nodes for reconciliation (not shared with the signing infrastructure).
• Cross-check multiple nodes (consensus reconciliation) to detect blockchain reorganization.
• Include in the reconciliation a matching tolerance for propagation delay (for example, ±2 minutes), but no larger, so as not to dilute detection.

Examples#

• Chainalysis Reactor with a reconciliation API for real-time alerts.
• A self-hosted reconciliation service on an event-driven architecture with Kafka for streaming.
• A custom watchdog service monitoring on-chain events through the Etherscan/Blockchain.info APIs and triggering alerts in PagerDuty.

Mapping to baseline standards#

B.7.3 is a Critical Requirement (Section D.2.5). Carry-over does not apply (Section A.0.3). Compensating Control is fully forbidden (Section 0.8.2). The mapping below is reference material only.

• PCI DSS Requirement 10.2 (Audit Logs of Cardholder Data Access): conceptually close.
• CCSS v8.0 Domain 9: conceptually close.

---

B.7.4 — Incident Response Playbook for CCM Compromise#

Defined Approach Requirement#

A documented playbook for CCM compromise events must cover all realistic scenarios; for each scenario, trigger conditions, initial response steps, escalation path, customer communication, regulatory notification, and post-incident review are defined. Annual tabletop exercises are mandatory for L2; quarterly tabletops + an annual full drill for L3.

Required Scenarios Coverage#

Per-Scenario Required Elements#

For each scenario, the documentation must include:

• Trigger conditions (what initiates execution of the playbook)
• Initial response steps (including halt mechanisms, Section B.5.2)
• Escalation path (names + 24/7 contacts; primary + backup; ranked by seniority)
• Customer communication template (in the applicable languages, for the applicable channels)
• Regulatory notification requirements:
  • Russian jurisdiction: FinCERT — within 3 hours from the moment of confirmed compromise (applicable to VASPs and credit institutions)
  • EU: national FIUs per the MiCA Regulation, in accordance with the applicable national implementation
  • Other applicable jurisdictions: per local regulation
• Post-incident review process (timing, participants, deliverables, integration of lessons learned into playbook updates)

Applicability Notes#

• Mandatory for C.1, C.3, C.4 at all levels.
• For C.2, reformulated: the vendor must provide a documented incident response procedure for events on the vendor side (compromised build infrastructure, mass-leaked vulnerability in the wallet software), as well as user-facing guidance for individual users who suspect a compromise of their device.

Customized Approach Objective#

Upon the occurrence of any realistic CCM compromise scenario, the response team has a documented playbook, can begin execution within minutes of detection, and the entire incident lifecycle (detection -> containment -> recovery -> lessons learned) is auditable.

Defined Approach Testing Procedures#

• B.7.4.a Examine the playbook documentation:

  • Obtain the full Incident Response Plan document.
  • Verify that all required scenarios are covered (or that there is an explicit explanation of why a scenario is not applicable to the Assessed Entity).
  • Verify the per-scenario required elements: trigger, initial steps, escalation, communication, regulatory notification, post-incident review.
  • Obtain the 24/7 contact list: names + phone + backup contacts.

• B.7.4.b Interview the incident response lead:

  • Interview the person responsible for IR.
  • Questions:
    • "Walk me through the hot wallet drain scenario step by step."
    • "Who is the decision-maker for CCM revocation? What is the SLA for decision-making?"
    • "How is it verified that customer notification was delivered within the required timeframe?"
    • "Describe the most recent real incident over the last 24 months. What was done? What deviated from the playbook?"

• B.7.4.c Observe a tabletop exercise:

  • Request (or facilitate) a mock CCM compromise scenario with the participation of the IR lead, operations, security, legal, and customer comms.
  • Measure the actual time from alert to escalation to decision.
  • Verify: the participants actually contact FinCERT (or the applicable regulator) in the mock; communication templates are applied; revocation is initiated within the applicable SLA.

• B.7.4.d Validate historical incidents:

  • Obtain incident postmortems from the last 24 months.
  • For each incident verify: the response actually matched the playbook; lessons learned were identified and integrated into a playbook update; follow-up actions were completed.
  • If there were no incidents during the period — verify that quarterly tabletops (for L3) or the annual drill (for L2) were conducted.

Purpose#

The playbook turns chaotic emergency response into structured execution. During an incident, the team works under stress and time pressure; the playbook provides clear next steps, reducing the risk of forgetting a critical action (for example, regulatory notification with a 3-hour deadline). Tabletop exercises test the playbook on realistic scenarios without real-world consequences — they uncover gaps before they manifest in a real crisis. The post-incident review with lessons-learned integration ensures that the playbook evolves with experience.

Good Practice#

• Use chatops integration for real-time coordination during an incident (a Slack channel with a playbook bot, PagerDuty integration).
• Pre-position communication templates in the applicable languages (for Russian customers — Russian, for international — English, for regional — the applicable language).
• Include in the playbook an explicit "do not" list — actions to avoid (for example, a public statement before coordinated disclosure, contacting the media without legal approval).

Examples#

• PagerDuty Runbook Automation with pre-defined response procedures.
• Atlassian Statuspage for customer communication during incidents.
• Splunk Phantom for SOAR (Security Orchestration, Automation, Response) automation.

Mapping to baseline standards#

• PCI DSS Requirement 12.10 (Incident Response): Full carry-over.
• GOST R 57580.1 (UIZ): Full.

---

B.7.X. Applicability Summary Table#

Legend: M = Mandatory, R = Recommended, N/A = Not Applicable. Critical = Critical Requirement (see Section D.2.5).

Related#

• 08 — B.6 — Wallet Architecture for CCM — previous (B.6.2 Watch-only)
• 10 — B.8 — Personnel and Access Control — next
• 07 — B.5 — Lifecycle Management — B.5.2 Revocation

Sources#

See Section 0.4 Normative References in the Front Matter.

Conceptually related PCI DSS v4.0.1 requirements:

• Requirement 10 (Log and Monitor All Access) — Full carry-over for B.7.1
• Requirement 12.10 (Incident Response) — Full carry-over for B.7.4

Conceptually related requirements of other standards:

• CCSS v8.0 Domain 9 (Compromise Detection)
• CCSS v8.0 Domain 10 (Audit Logs)
• GOST R 57580.1 (UIZ — incident management)