Compliance & sovereignty

The sealed ledger feeds your own incident register with timestamped events (Law 25).

This document distinguishes what is delivered from what is planned.

In plain terms

• Detection runs on your server. Nothing is sent to a central CrowdSec service. Only the security metadata your console needs is reported to it, detailed below.
• This metadata includes visitor IP addresses. It is processed at the console host. Other third parties receive it only according to your settings: collective pool, reputation enrichment, alert channels (email, Slack, Discord, Teams, Google Chat, PagerDuty).
• A sealed incident ledger. A retroactive alteration of a sealed line becomes detectable. The ledger holds what the agents reported.
• A Law 25 report to produce from the console, with proof of integrity.

Sovereignty: no CrowdSec Central API

The product rule is simple and non-negotiable: no AtriShield agent communicates with the CrowdSec Central API (CAPI). It is enforced at several levels (defense in depth):

• On the agent side: every cscli call goes through a wrapper that refuses the capi subcommand.
• Masked service: crowdsec_capi.service is masked (systemctl mask --now, idempotent) at every synchronization, to prevent any re-enrollment.
• Empty credentials: online_api_credentials.yaml is shipped empty in the bundle (url:"", login:"", password:"") and atomically overwritten on every cycle.

Practical consequence: detection relies on the rules delivered by your console, executed on your server. Results are reported to the AtriShield console, never to CrowdSec.

Data residency

• On your server: full traffic, HAProxy logs, detection engine.
• In the AtriShield console infrastructure: in the database, incident ledger, alerts, good-bot and trusted-IP passes, partitioned by organization; in memory, traffic observations over a short window.
• Console hosting: Beauharnois, Quebec. Retention period: per contract.

What the agent reports to the console

The agent does not send request bodies. The URL and the referring page are sent as they are, parameters included. It sends:

• Heartbeat: tier, bundle version, system facts, stack versions, sovereignty state, AppSec aggregates.
• Technical inventory: hostname, system, kernel, installed packages.
• Alerts and decisions from the local engine, read through the tunnel or sent to the console: source IP address, country, scenario, event count, dates, decision type and origin; host and User-Agent depending on the console version.
• Per-request observations (Business and Enterprise): IP address, method, requested URL with its parameters, host, status, User-Agent, referring page, in batches, truncated fields. A URL parameter containing personal data is sent as is.
• Honeypot hits (Enterprise): IP address, trap hit, User-Agent and client fingerprint depending on the version.

Agent connections to third parties

• packagecloud.io and the CrowdSec hub, to install the engine and its rules. These connections carry no traffic data.
• No call to the CrowdSec Central API.

Options to enable

• External reputation enrichment: the console queries AbuseIPDB with your key, if your team allows it. The queried IP address is then sent to that service.
• Collective pool (Business and Enterprise): exchange of malicious IP addresses between organizations that have agreed to it.

The sealed incident ledger

Every security event is recorded in the ledger: event type (decision, alert, honeypot, good bot, throttle, appsec), source IP, scenario, HTTP method/path, response code, country, timestamp. Ingestion is deduplicating and the source IP is validated.

Sealing

The ledger is made verifiable after the fact through a chained Merkle tree sealing:

• events are sealed in batches, each seal carrying the Merkle root of the batch, the hash of the previous seal and its own seal hash;
• hashes are computed with HMAC-SHA256 using separate domains (leaf / node / seal) to prevent pre-image attacks;

Integrity verification

A verification operation recomputes, for each seal, the Merkle root and the chaining, then compares them to the stored values (constant-time comparison). Any divergence (event count, root, chaining) is reported (affected seal + reasons). A retroactive modification of an event breaks the chain and becomes detectable.

Law 25 (Quebec): the compliance report

The console produces a structured Law 25 (Quebec) compliance report, per organization and over a given period. The generator has no side effects (no database writes): it reads the evidence and aggregates it. The report has four sections plus an integrity block:

1. Processing record: agents concerned, offer tier, retention.
2. Automated decisions: count of decisions (bans, throttle, challenge) over the period.
3. Breach log: number of events, verification of the audit chain and the Merkle seal.
4. Privacy impact assessment (PIA): encryption, sovereignty, CAPI disabled.

The integrity block attests to the verifiable state of the evidence (recomputed audit chain, verified Merkle seal) and carries an HMAC-SHA256 hash of the report (a seal of the report itself).

This report is delivered: the sealed ledger, integrity verification and Law 25 aggregation exist in the product.

What feeds the ledger

Delivered. The incident ledger is fed by the security decisions observed at the edge: CrowdSec bans and alerts, AppSec blocks (OWASP / virtual-patch), honeypot hits, good bots, throttle. It is a security incident ledger (WAF / IDS / IPS / traps), sealed and verifiable.

Soon. Automatic detection of personal data exfiltration (analysis to spot a leak of personal information and automatically feed the breach log) is not yet in the product. Today, the log reflects the decisions of the WAF and the detection engine at the edge, not a dedicated PII exfiltration detection. This capability is planned.

Technical

• Incident ledger: log partitioned by organization, deduplicating ingestion, source IP validation.
• Sealing: chained Merkle tree, HMAC-SHA256 with separate domains (leaf, node, seal), batch sealing with a stabilization window and a serialization lock.
• Verification: recomputation of the root, chaining and count, constant-time comparison, per-seal failure report.
• Law 25: report scoped to your organization, no database writes. Integrity block: recomputed audit chain, verified Merkle seal, HMAC-SHA256 hash of the report.
• CAPI sovereignty: filtered cscli calls, CAPI service masked at every synchronization, CAPI credentials emptied in the bundle and managed by reconciliation.
• Automatic detection of personal data exfiltration: planned, not yet delivered. The ledger is fed by decisions from the application firewall, detection and honeypots.

Sovereignty & architecture

Critical configuration goes through a signed channel (Ed25519 bundle, reconciliation, least privilege). An encrypted tunnel also links the console to the agent.