SOC 2 TSC mapped to Root Lock controls

Purpose: Vendor map of Root Lock by HeartSuite capabilities onto selected AICPA Trust Services Criteria (2017 TSC, 2022 revised points of focus), for a customer preparing a Type I or Type II examination.

A TSC is met by the entity’s control environment. HeartSuite does not hold a SOC 2 report. Use each row as a starting list of host-level activities and artefacts; the practitioner still designs the tests.

Availability (A1) and Confidentiality (C1) apply only when those categories are in the examination. Security (CC1–CC9) is always in. This page covers the CC6–CC8 rows where a host kernel MAC can contribute.

The dedicated JSONL approval log, per-decision enforcement syslog stream, and rotating application audit log are described below. They help reconstruct allowlist changes and denials. JSONL rotates at 1 MB with one .1 copy — ship it to a SIEM for Type II periods longer than that window.

Table of contents

• How to use this document
• CC6 — Logical and physical access controls
• CC7 — System operations
• CC8 — Change management
• A1 — Availability (only if Availability is in the examination)
• C1 — Confidentiality (only if Confidentiality is in the examination)
• Summary table

How to use this document

Root Lock is deployed on Linux servers to enforce a default-deny security policy at the kernel level. It is a technical control your organization operates. In a SOC 2 examination:

• Root Lock can support specific criteria as one technical activity in your control environment.
• You still need organizational controls (policies, procedures, access reviews, training) alongside it.
• Artefacts listed here are host-level items you can retain. Operating effectiveness over the period still needs walkthrough, inquiry, inspection, and sampling.

CC6 — Logical and physical access controls

CC6.1 — Logical access security: Restricting access to information assets

Official criterion: The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity’s objectives.

How Root Lock can support a customer control:

Root Lock controls, per program, which programs can execute, which files they can read or write, and which network destinations they can connect to — independently of which user account runs them, including root.

In Lockdown, every program must have an explicit allowlist entry before the kernel will permit it to execute, read or write files, or make outbound network connections.

The three dimensions of per-program access control:

Access permissions are built during Setup Mode via the Dashboard review queues. Each program’s execution, file access, and network access is presented for explicit human approval before Lockdown is activated.

Under Lockdown, root cannot change the allowlist. The files are immutable (chattr +i). The kernel refuses the write. No program can extend access at runtime.

Scope: Every allowlist approval action (programs, file paths, network destinations) is recorded in a dedicated, persistent JSONL approval log with timestamp, uid, and tty. That log provides direct session attribution for changes to the policy.

In environments where multiple administrators share root access, uid/tty-to-person attribution still requires correlating against customer-side session records (terminal session logging via auditd, a privileged access management tool, or equivalent). Dashboard access requires Linux root credentials; there is no additional authentication layer within Root Lock.

Evidence artifacts:

• Dashboard allowlist export (Programs, File Access, Internet Access queues)
• Dedicated JSONL approval log showing timestamp, uid, tty, and entry details for each approval action
• Lockdown status screenshot showing “Applied”
• hs-manage-allowlist list output showing per-program permissions
• Demonstration that a non-allowlisted program cannot execute while Lockdown is active

CC6.3 — Access authorization based on roles, responsibilities, or system design

Official criterion: The entity authorizes, modifies, or removes access to data, software, functions, and related assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties.

How Root Lock can support a customer control:

Root Lock does not implement role-based access control within the Dashboard. Every user with Linux root access has identical access to all Dashboard functions: allowlist approval, Lockdown activation and deactivation, alert configuration, log clearing, and Maintenance.

There is no operator/administrator distinction and no per-function permission check. Every allowlist approval is written to /var/log/heartsuite/allowlist-audit.log with timestamp, uid, and tty. That distinguishes sessions, not people who share uid 0. Person attribution still requires customer-side session records.

CC6.3 is an organizational control for this product. Restricting which personnel can reach root — and attributing their actions — requires customer-side controls: sudoers policy, a privileged access management tool, bastion host session recording, or equivalent.

Evidence artifacts:

• sudoers policy or PAM configuration showing which users can execute which HeartSuite commands
• Privileged access management records (bastion logs, PAM session records, or equivalent)
• Documentation of which personnel hold root access and under what job function

CC6.6 — Threats from sources outside system boundaries

Official criterion: The entity implements logical access security measures to protect against threats from sources outside its system boundaries.

How Root Lock can support a customer control:

Root Lock does not implement inbound / boundary access control. There is no inbound packet filter, VPN, or external-user authentication in the product. Inbound filtering remains a customer-side OS packet filter or cloud security group — that complementary control is what typically addresses CC6.6.

What Root Lock does on the host (the five-category chattr +i seal of OS configuration, authentication files, and related paths) is a logical access / change-protection activity. Cite it under CC6.1 and CC8.1. The inventory stays here so the seal is documented in one place.

Lockdown seals five categories of system infrastructure using chattr +i filesystem immutability. During activation the Dashboard shows a per-category inventory. The Lockdown activation log records what was sealed.

The five sealed categories:

While Lockdown is active, root cannot remove the immutable flags. The kernel disables chattr. Modifying any of these resources requires booting the maintenance kernel, which requires physical or serial-console access (keyboard and monitor, serial port, or cloud provider serial console).

An attacker who already has root over SSH cannot edit the SSH config, create accounts, change passwords, install cron jobs, or plant login-script backdoors.

Scope: Root Lock installs agetty autologin on the serial port (/dev/ttyS0). Whoever has access to the cloud provider’s out-of-band console (AWS EC2 Serial Console, Azure Serial Console, GCP serial port, DigitalOcean Console) can reach the maintenance kernel without further authentication from Root Lock.

Restricting serial console access is a customer-side organizational control enforced through cloud provider IAM — it is the final backstop of Lockdown’s protection model.

Evidence artifacts:

• Lockdown activation log showing the five sealed categories and their file counts
• Demonstration that /etc/passwd cannot be modified while Lockdown+sealed is active
• Demonstration that SSH config cannot be modified while Lockdown+sealed is active
• ls -la /.hs/sys/ showing immutable flags on allowlist files
• Cloud provider IAM policy restricting serial console access to named personnel

CC6.7 — Transmission, movement, and removal of information

Official criterion: The entity restricts the transmission, movement, and removal of information to authorized internal and external users and processes, and protects it during those activities.

Root Lock does not encrypt customer data in transit. HTTPS for the product’s own webhook covers that webhook only. Per-program outbound IP allowlisting can support a customer control that limits where programs may send data. TLS, removable media, and DLP stay on the customer side.

How Root Lock can support a customer control:

Root Lock enforces per-program outbound network controls. In Lockdown, every outbound connection attempt by every program is either on the network allowlist or blocked at the kernel. This applies regardless of user privilege.

Specific transmission controls:

• Outbound allowlist: Each program has its own set of approved destination IP addresses. Approving a destination for one program does not grant any other program access to the same destination.
• HTTPS enforcement: Webhook alert delivery requires an HTTPS URL. HTTP (non-TLS) webhook URLs are rejected at configuration time.
• C2 callback prevention: In Lockdown, any program attempting to connect to a destination not in its network allowlist is blocked. This includes malware attempting to reach command-and-control infrastructure. The Log4Shell attack (CVE-2021-44228), which works by causing a vulnerable application to reach outbound to attacker infrastructure, is blocked at the network gate.
• Exfiltration prevention: Even if an attacker compromises an approved program, that program can only connect to destinations already in its network allowlist — destinations reviewed and approved by an administrator during Setup Mode.

Scope: Root Lock enforces no inbound connection controls. Inbound network filtering (port restrictions, protocol controls) is a customer-side responsibility via an OS packet filter or cloud security groups.

Evidence artifacts:

• Internet Access queue showing per-program, per-IP approvals
• Alert log showing blocked outbound connections (in Lockdown)
• Webhook configuration showing HTTPS requirement
• Demonstration that a new outbound connection attempt generates a block alert when the destination is not allowlisted

CC6.8 — Malware and unauthorized software prevention

Official criterion: The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software.

How Root Lock can support a customer control:

This is the primary use case of Root Lock. The implementation is structural, not signature-based.

Default-deny execution: In Lockdown, the Root Lock kernel refuses to execute any program not in the allowlist. A file downloaded to /tmp — a reverse shell, a credential dumper, a dropper — cannot execute. It has no allowlist entry. The kernel refuses the execve() call regardless of file permissions, user privilege, or whether any scanner detected the file.

Interpreted code coverage: Python, Perl, and PHP scripts are covered by Secure Script Launchers. Each script gets its own allowlist entry, separate from the interpreter. The Python interpreter may be on the allowlist; a malicious .py file dropped at /tmp/attack.py is not. In Lockdown, it is blocked before the interpreter processes it.

Reduced kernel features attackers can reach: The Root Lock kernel omits eBPF, FUSE, overlay filesystems, user namespaces, and competing LSMs. Those are how attackers hide, shadow directories, and reach root.

See System Requirements and Deployment Scenarios for details.

Module loading restriction: In Lockdown, kmod, modprobe, and insmod have no allowlist entries by default and cannot execute. Module-based rootkits cannot be installed because the module loaders cannot run. Where kmod is required for hardware drivers, its file access permissions can be restricted to specific .ko paths.

Post-compromise file recovery: When an approved program is compromised and encrypts or corrupts files (for example ransomware inside an approved process), per-write backup preserves every version. Recovery starts from the moment before the damage began, not the last scheduled backup window. Under Lockdown, the kernel blocks write and delete to the backup directory (/.hs/b/) for every program except Root Lock backup tooling (hs-backup and hs-version-manager). That includes root.

Alert on new blocked programs: In Lockdown, any program path that appears in the denial log and has never appeared in any prior log session triggers an alert to all configured channels immediately.

Evidence artifacts:

• Alert log showing blocked execution attempts in Lockdown
• Dashboard Programs queue showing items blocked and denied
• Kernel configuration file (/.hs/sys/ kernel config) showing compiled-out features
• CVE status table from Kernel Security Transparency page showing features not compiled in
• Backup configuration and version history showing per-write versioning

CC7 — System operations

CC7.1 — Detection of configuration changes and new vulnerabilities

Official criterion: The entity uses detection and monitoring procedures to identify (1) changes to configurations that introduce new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.

A customer scanner remains the usual CC7.1 control. Root Lock can reduce blast radius of some unpatched flaws. Denial alerts belong under CC7.2.

How Root Lock can support a customer control:

Vulnerability surface reduction: Root Lock reduces the kernel features attackers can reach by removing them at compile time. The Kernel Security Transparency page documents every relevant CVE against the Root Lock kernel, with per-CVE “Score on Root Lock” ratings showing the actual risk after those structural mitigations. CVEs affecting kernel features not compiled in receive a Score on Root Lock of 0.0 — the vulnerable feature is not present by design.

Configuration change detection: Under Lockdown, the allowlist is sealed and cannot be changed. Any attempt to modify allowlist files, Root Lock configuration, or system integrity files (shared libraries, systemd units, SSH config) is blocked at the kernel.

The “Critical file version created outside maintenance window” alert fires when a new backup version is created for files under /etc/, /bin/, /usr/bin/, /sbin/, /lib/, or /usr/lib/ while Lockdown is active.

Threat detection in operation:

Integration with vulnerability management: Root Lock is designed to complement — not replace — vulnerability scanners (Tenable Nessus, Qualys VMDR, Rapid7 InsightVM). Root Lock can reduce the blast radius of an unpatched vulnerability; the scanner maps what needs patching. SOC 2 does not prescribe those two tools. The entity still needs a vulnerability-identification control for CC7.1.

Evidence artifacts:

• Alert channel configuration (email, syslog, webhook)
• Alert log showing state-change alerts
• Syslog forwarding configuration to SIEM (rsyslog rule capturing the heartsuite ident)
• Dedicated JSONL approval log (for change attribution)
• CVE status table showing HeartSuite’s kernel vulnerability posture
• Vulnerability scanner reports (separate tool — HeartSuite does not provide this)

CC7.2 — System monitoring for anomalies and indicators of compromise

Official criterion: The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity’s ability to meet its objectives.

How Root Lock can support a customer control:

The items below are policy-deny logging and a protection-state indicator. A customer SIEM may consume them for CC7.2. Anomaly analysis (NIST CSF DE.AE) stays outside this product.

Continuous protection state monitoring:

The Dashboard displays a full-width, high-contrast protection state indicator showing the current state at all times:

Status JSON polling surface: ~/.cache/heartsuite/status.json is updated every 60 seconds. Ansible, Nagios, Zabbix, and similar tools can read this file via SSH pull for automated health checks. No additional configuration required. The mode field is "Secure Mode", "Setup Mode", or "Unknown" — the same internal token as the webhook. The Dashboard label for the first value is Lockdown. The lockdown field is the seal bool. See the field table in Compliance Reference.

Syslog integration: After you enable Syslog on Alert Settings → Fleet, Root Lock writes denial lines and aggregated alerts to the journal under ident heartsuite. A single rsyslog rule such as :programname, isequal, "heartsuite" @@siem-host:514 forwards both.

The enforcement stream emits one record per denial (HS-PROG-DENY, HS-FILE-DENY, HS-FILE-WDENY, HS-NET-DENY), not per successful allowlisted access. Structured data includes the decision type, program, and target. Lag is typically under one second.

The alert stream carries higher-level, deduplicated events (new_program_blocked, network_burst, mode changes, and similar). Alerts are also delivered via the configured webhook and email channels; those timestamps reflect alert evaluation time rather than the original kernel event time.

Webhook integration: Every alert is POSTed immediately as a JSON payload to the configured webhook endpoint. Example payload structure:

{
  "node_id":          "prod-web-03",
  "event_type":       "new_program_blocked",
  "timestamp":        "2026-03-31T14:22:00Z",
  "mode":             "Secure Mode",
  "lockdown":         true,
  "tier":             2,
  "paths":            ["/tmp/dropper", "/tmp/payload"],
  "count":            2,
  "message":          "Previously unseen program blocked",
  "subscription":     "Active",
  "total_pending":    0,
  "pending_programs": 0,
  "pending_file_r":   0,
  "pending_file_w":   0,
  "pending_network":  0,
  "enrich_failed":    false
}

mode is the on-disk monitor token ("Secure Mode", "Setup Mode", or "Unknown"). The Dashboard and email copy say Lockdown for that first value. lockdown is the immutable-seal bool, not a synonym for mode.

This payload can drive PagerDuty, OpsGenie, Slack, or any incident management tool.

Log retention and audit channels: The on-device activity log (/.hs/sys/HS_log.txt) is a temporary denial buffer. It is cleared on every maintenance cycle and auto-cleared when all review queues drain in Setup Mode (and Secure Script Launchers is not still pending). At about 32 MiB it is rotated in place. The rotating application log (/var/log/heartsuite/ui.log) is size-capped at approximately 8 MB. For long-term retention and cross-host correlation, enable Fleet Syslog and ship ident heartsuite.

Every allowlist approval is written to /var/log/heartsuite/allowlist-audit.log with timestamp, uid, and tty. The file rotates at 1 MB and keeps one .1 copy; ship it to a SIEM for Type II periods longer than that window. Lockdown activation decisions are verdict-driven and carry provenance back to the specific allowlist state and decision records that produced them.

Evidence artifacts:

• Syslog forwarding rule in /etc/rsyslog.d/heartsuite.conf (or equivalent) capturing the heartsuite ident
• Dedicated JSONL approval log (/var/log/heartsuite/allowlist-audit.log) with timestamp, uid, tty, and entry details for every allowlist approval
• Per-decision enforcement stream records in the customer SIEM (MSGIDs for program, file, and network decisions)
• Sample alert payloads from webhook endpoint
• ~/.cache/heartsuite/status.json showing current system state
• SIEM alert records and raw enforcement events covering the audit period (customer-operated SIEM required for Type II evidence spanning months)
• Verification: journalctl -t heartsuite --since "1 hour ago" (or the equivalent facility) showing both enforcement and alert activity

CC7.3 — Evaluation of security events

Official criterion: The entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives, and, if so, takes actions to prevent or address such failures.

How Root Lock can support a customer control:

Root Lock classifies security events into two tiers:

Immediate alerts (administrative state changes) — these fire on all channels with no delay:

• Mode switch (Setup Mode ↔ Lockdown)
• Lockdown activation or deactivation
• New allowlist file pushed while Lockdown is active

Threshold-filtered alerts (operational blocks) — these apply noise reduction before delivery, while syslog and webhook receive them immediately:

• Previously unseen program blocked (appears in denial log for the first time)
• Network burst to new destinations (single program, multiple new destinations, 2-hour window)
• Critical file version created outside maintenance window

What is never alerted (documented in the product to prevent alert fatigue):

• Setup Mode, unless Fleet Setup Mode alerts is enabled
• Repeated blocks of a program-destination pair already seen in the current session
• File version activity under /tmp/, /var/tmp/, or /dev/shm/

In Lockdown, the Dashboard review queues shift from approval to read-only investigation. Denied items appear in the queues. Use [n] to navigate them. Each denied item shows the program, path, and attempt count — the same metadata used during approval.

Evidence artifacts:

• Alert Settings configuration screenshot showing configured channels
• Alert log from a known test event (using the Test Email function)
• Dashboard Lockdown queue showing denied items and investigation workflow
• SIEM correlation rules that consume the HeartSuite alert feed (customer-operated SIEM required for audit-period-length evidence)

CC7.4 — Incident response

Official criterion: The entity responds to identified security incidents by executing a defined incident response program.

How Root Lock can support a customer control:

Root Lock provides technical controls for the detection and containment phases of incident response. It does not provide a full incident response program — that is an organizational control.

Containment (structural):

• Under Lockdown, a compromised program cannot launch new programs, cannot exceed its file access permissions, cannot connect to unapproved network destinations, and cannot modify the allowlist or system configuration
• These constraints apply automatically — they do not require responder action during the incident
• Nothing the attacker ran survives a reboot (allowlist modifications are in-memory only; the on-disk allowlist is immutable)

Investigation:

• Dashboard Lockdown queue shows all denied items (blocked programs, file accesses, network connections) with timestamps and paths
• journalctl -t heartsuite provides a timestamped log of alerts and enforcement decisions (message text begins with heartsuite-alert:)
• File version history in Dashboard Backup shows what changed and when, supporting forensic timeline reconstruction

Allowlist update during active incident:

• If a compromised program must be removed from the allowlist, a maintenance window is required. After the seal is applied, reboot from a physical or serial console and select Maintenance: unseal and return to Root Lock. When the seal is not applied, Maintenance switches you to Setup Mode on the Root Lock kernel.
• Maintenance presents a readiness checklist (listening ports, SSH findings) on the unsealed path before the YES switch.

Recovery:

• File Backup allows restoring any file to any prior version, including versions from before a compromise began
• Timeline view allows batch restore of all files modified on a given date — the appropriate tool for ransomware recovery

Scope: Root Lock does not provide a customer-facing incident response policy template. An IR policy covering escalation contacts, communication plan, SLAs, and regulatory notification is an organizational control the customer must supply. Root Lock’s technical containment and investigation capabilities serve as the evidence base for that policy.

Evidence artifacts:

• Incident response policy document (organizational — customer-supplied)
• Alert logs from the incident under investigation
• Maintenance window log showing the date and steps of allowlist update
• Backup restore log from hs-version-manager or Dashboard Backup showing recovery actions

CC7.5 — Recovery from security incidents

Official criterion: The entity identifies, develops, and implements activities to recover from identified security incidents.

How Root Lock can support a customer control:

Per-write versioned backups:

Root Lock creates a backup version of every file write in protected directories. Unlike scheduled snapshot tools, there is no backup window — if a file is encrypted or corrupted at 3:47 AM, the version from 3:46 AM exists.

That is the gap ransomware exploits in schedule-based backup tools, and the gap CVE-2024-40711 for Veeam Backup & Replication exploited by targeting the backup agent itself.

Under Lockdown, root cannot overwrite or delete the backups. The kernel blocks write and unlink to /.hs/b/ for every program except Root Lock backup tooling. There is no backup agent to kill.

Recovery workflow:

System recovery after Root Lock kernel failure:

If the Root Lock kernel fails to load, the startup script isolates the primary network interface and removes all immutable flags. The host is then without Root Lock protection and without network access. Recovery requires booting to the maintenance kernel from physical or serial-console access.

Scope: Backup files are versioned filesystem copies — there is no encryption at the Root Lock layer. If backup confidentiality at rest is required, disk-level encryption (dm-crypt/LUKS) must be configured at the OS level by the customer. An alert fires when backup transitions from enabled to disabled, and when any previously-covered directory is removed from coverage.

Evidence artifacts:

• Backup configuration showing protected directories
• Test restore log demonstrating successful file recovery
• Backup directory listing showing version history for a protected file
• Recovery procedure documentation (this document and the product’s Maintenance guide)

CC8 — Change management

CC8.1 — Controls for changes to infrastructure and software

Official criterion: The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.

How Root Lock can support a customer control:

All changes require a maintenance window:

Any change to system configuration, installed software, or network access patterns requires switching to Setup Mode first. This is enforced by the kernel — in Lockdown, package installations fail because dpkg cannot create temporary directories that the kernel blocks. Software updates cannot be installed silently while Lockdown is active.

The required change management flow:

1. Open a maintenance window from the Dashboard (Maintenance [m])
2. Complete the safety checklist (network isolation, daemon shutdown, SSH restriction)
3. If Lockdown is applied: reboot from a physical or serial console and select Maintenance: unseal and return to Root Lock. If the strip already says Lockdown not applied: type YES and reboot once
4. Make changes — install packages, update configuration, apply updates
5. Review new activity in the Dashboard queues (new programs, file accesses, network destinations)
6. Approve new entries explicitly before re-engaging Lockdown ([l])

Update integrity verification:

Updates are delivered as a single self-extracting bundle (heartsuite-install.sh). Before running the installer, the SHA-256 checksum must be verified against the published value:

sha256sum -c heartsuite-install.sh.sha256

The installer will not overwrite protected files while the Root Lock kernel is booted. From a terminal in Setup Mode, type YES for one stock boot. See Updating Root Lock.

Allowlist as change record:

The allowlist is the authoritative record of every program, file access, and network connection that has been reviewed and approved. Every entry was created through the Dashboard review queues. Each approval action is written to a dedicated, persistent JSONL approval log that records the timestamp, uid, tty, and the exact entry details. The allowlist itself, stored in /.hs/sys/, is immutable under Lockdown.

Scope: Update integrity relies on SHA-256 checksum verification — there is no GPG or PGP signature authenticating the bundle’s origin against a HeartSuite-controlled signing key. The checksum verifies the file arrived intact; supply-chain authentication depends on retrieving the bundle and checksum over HTTPS from the HeartSuite distribution endpoint.

Machine-readable supply-chain artifacts are published at /advisories/: CONFIG-gate SBOM, OSV, and CycloneDX. SPDX dual-format and GPG/cosign signing are not generally available.

There is no built-in multi-host push from a HeartSuite server. Policy is applied per-host by your automation (Ansible, Terraform, scripts, GitOps, ServiceNow, etc.), with rich export for central consumption and attribution. See Central Policy Management and External Control for patterns.

In fleet deployments, allowlist changes are applied per server by the customer’s control plane. Lockdown entitlement still requires per-host subscription activation.

There is no remote unseal from Ansible. Fleet-scale software updates are applied by reprovisioning instances from an updated image, or by the per-host maintenance window above. See Enterprise Adoption Guide.

Evidence artifacts:

• Maintenance window log showing dates of mode changes
• Update installation log at /var/log/heartsuite/install.log (visible on cloud serial consoles such as AWS EC2 Serial Console or Get system log)
• SHA-256 verification output from update procedure
• Dedicated JSONL approval log with timestamp, uid, tty, and the specific program, file, or network entries approved in each change
• Allowlist showing programs, file accesses, and network destinations approved for each maintenance cycle
• Dashboard queue review records showing items approved during each maintenance window

A1 — Availability

A1.2 — Environmental protections, backup, and recovery infrastructure

Official criterion: The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data backup processes, and recovery infrastructure to meet its objectives.

A1 applies only if Availability is in the examination.

How Root Lock can support a customer control:

Root Lock does not provide environmental protections (power, HVAC, fire, physical site). Those remain the customer’s or cloud provider’s controls.

The product can contribute to the backup and recovery clause of A1.2: per-write versioned copies under /.hs/b/, kernel-protected under Lockdown. Those copies stay on the host and are unencrypted at the Root Lock layer. Offsite DR and LUKS stay with the customer.

Ransomware (separate from environmental protections above). Root Lock addresses it at two layers:

1. Prevention layer: In Lockdown, programs not on the allowlist cannot execute — a ransomware binary dropped on the server cannot run.
2. Recovery layer: If ransomware runs inside an approved process (e.g., malware that hijacks a legitimate application), per-write backups preserve all file versions. Under Lockdown, the kernel protects backup files from the compromised process.

Malware persistence prevention: Nothing an attacker installs survives a reboot. Cron jobs, systemd units, and shell profile backdoors are sealed under Lockdown. A rebooted system returns to the state at Lockdown activation.

Maintenance safety checklist: Before any mode change, the Dashboard presents a checklist that flags network exposure, active daemons, and SSH configuration. This reduces the risk of an attacker exploiting the maintenance window (the period when blocking is temporarily suspended).

Scope: Root Lock does not prevent denial-of-service (DoS) at the application or network layer. Root can kill -9 approved services or panic the kernel. Availability hardening against DoS requires a separate control.

An alert fires when backup is disabled or a covered directory is removed from coverage. Ransomware prevention and per-write recovery remain in place regardless.

Evidence artifacts:

• Backup configuration showing protected directories and version history
• Alert log showing ransomware-related blocked execution attempts
• Maintenance window log showing safety checklist completion

C1 — Confidentiality

C1.1 — Identification and maintenance of confidential information

Official criterion: The entity identifies and maintains confidential information to meet the entity’s objectives related to confidentiality.

C1 applies only if Confidentiality is in the examination.

How Root Lock can support a customer control:

Classification and inventory of confidential information remain a customer process. File-access allowlists can support protection of paths the customer has already classified.

File access containment (protection of classified paths, not identification): Every program can only read the files in its file access allowlist. A compromised application cannot read credentials, private keys, or confidential data that it was never approved to access during Setup Mode. This applies regardless of user privilege.

Exfiltration prevention: Even if a program can read confidential data within its file access allowlist, it cannot send that data to an unapproved destination. The network allowlist restricts each program to specific IPs. A program with no approved outbound destinations has no exfiltration path at all.

Scope: An attacker who already has root can read disk content with direct kernel-level access. Confidentiality during a live breach session is the role of disk encryption (dm-crypt/LUKS), not Lockdown.

Backup files are versioned filesystem copies with no encryption at the Root Lock layer; disk-level encryption covers backup files if applied at the OS level. Root Lock limits what data can be exfiltrated, not what data can be read from a running kernel session.

Evidence artifacts:

• File access allowlist showing that programs are scoped to their required paths
• Network allowlist showing outbound destinations per program
• Disk encryption configuration (separate control — customer-supplied)

Summary table

Last Updated: 2026-08-20