Root Lock by HeartSuite Documentation on Root Lock by HeartSuite

Confirm the Root Lock kernel is actually running

Mon, 01 Jan 0001 00:00:00 +0000

Overview: Initial setup confirms that Root Lock by HeartSuite is active and the machine is ready for allowlisting. Auto-added allowlist entries are the programs that executed at boot and shutdown; the queues hold the rest. Installer and initial setup logs are in /var/log/heartsuite/ and accessible via provider serial console (AWS, Linode, Hetzner, and others).

What complete looks like

Cloud Path

When you launch a pre-installed Root Lock cloud instance, the Dashboard confirms initial setup is complete on first boot and suggests the next step. Use the serial console to cat /var/log/heartsuite/install.log if you need the installer or initial setup logs from the image build.

Each program gets its own internet destinations

Mon, 01 Jan 0001 00:00:00 +0000

Overview: Programs make outbound connections you never approved (telemetry, update beacons, C2 callbacks). Root Lock by HeartSuite requires an allowlist entry for every outbound destination — per program, at the kernel.

In Lockdown, no program can connect to any destination unless you have approved it. The Dashboard’s Internet Access queue ([i]) guides you through reviewing and approving destinations for each program.

Per-program, per-destination enforcement

In Setup Mode, Root Lock logs every outbound connection without blocking it. Those connections appear in the Dashboard’s Internet Access queue. In Lockdown, any connection to a destination not on the allowlist is blocked and an alert is generated.

Lockdown seals the allowlist, including from root

Mon, 01 Jan 0001 00:00:00 +0000

Overview: When you lock down from Setup Mode, Root Lock by HeartSuite blocks every program not on the allowlist, including any you forgot to approve, including as root.

The Dashboard guides activation through a precondition checklist and a typed YES. Lockdown then seals the allowlist with filesystem immutability (chattr +i): no program or user, including root, can modify it while the server is running.

System states

Root Lock has two modes: Setup Mode and Lockdown. Both run on the Root Lock kernel. Lockdown is one event: blocking turns on and the configuration is sealed.

A subscription is what turns on Lockdown

Mon, 01 Jan 0001 00:00:00 +0000

Overview: A subscription is required to activate Lockdown on Root Lock by HeartSuite. The Dashboard shows subscription status alongside checklist progress and alerts.

Subscription

A subscription is required before you can activate Lockdown. The Dashboard also keeps Lockdown locked until the prior checklist items are complete. See Lockdown for the activation flow.

The subscription is a text file. One subscription can cover up to 9999 servers — at purchase, you specify how many servers it covers. You can purchase additional subscriptions if needed.

Blocked, wrong kernel, or silent fail?

Mon, 01 Jan 0001 00:00:00 +0000

Overview: When something stops working under Lockdown, the cause is usually a missing allowlist entry, a different mode or kernel than expected (Setup Mode vs Lockdown, immutable seal, or the maintenance kernel), or a kernel issue.

Root Lock by HeartSuite shows which one on the Dashboard. The indicator at the top shows the current protection state, and the Suggested Next Step tells you what to do.

Installer and Dashboard logs live under /var/log/heartsuite/. Use the provider serial console to cat them. AWS Get system log is a buffered serial snapshot — it is not CloudWatch. CloudWatch, Cloud Logging, and Log Analytics need the platform logging agent plus IAM; Root Lock does not install that agent. Paths and the three cloud surfaces are listed in Appendices → Log files.

Does this replace EDR? And other FAQs

Mon, 01 Jan 0001 00:00:00 +0000

General

How is Root Lock by HeartSuite different from other anti-malware solutions?

A: Every attack does three things: run a program, access files, make a network connection. Root Lock controls all three per program, not per user.

Unlike anti-malware tools that look for signatures or suspicious behavior, every execution, file access, and network connection must be approved through the Dashboard review queues. In Lockdown, anything not approved is blocked.

Tools shipped with Root Lock

Mon, 01 Jan 0001 00:00:00 +0000

Overview: Root Lock by HeartSuite includes a set of tools for system management, allowlisting, and security. The Dashboard is where you work day-to-day. Most CLI entries below are run automatically by the Dashboard, or kept for scripting, recovery, and advanced setup.

Except for the Secure Script Launchers, all tools are located in /.hs/sys. The installer does not add this directory to PATH. The Secure Script Launchers are in /usr/bin because it is in the default PATH. Programs and scripts that write data to Root Lock databases must be run as root.

Compliance questions, answered on one page

Mon, 01 Jan 0001 00:00:00 +0000

Detailed control mappings are in the Compliance Reference: NIST CSF & ISO 27001 and SOC 2 Control Mapping documents. This page gives direct answers to the questions that come up most often.

What does Root Lock by HeartSuite enforce?

Three gates: execution (default-deny binary allowlist), file access (per-program path restrictions), and network (per-program outbound IPv4/IPv6 allowlist). All three apply including to programs running as root.

What does Lockdown seal?

Five categories, using chattr +i: Root Lock configuration and kernel image directory; system integrity (/usr/lib/, systemd units, SSH config, sudo policy); authentication files (/etc/passwd, /etc/shadow, /etc/group); scheduled tasks and login scripts (cron/anacron, root profiles); and maintenance tools (editors made non-executable; rm/cp/mv replaced with restricted copies).

Compliance Reference: NIST CSF & ISO 27001

Mon, 01 Jan 0001 00:00:00 +0000

This document maps Root Lock by HeartSuite capabilities to NIST CSF 1.1 and ISO/IEC 27001:2022 Annex A as technical contributions a customer may cite after their own risk assessment.

ISO 27001 certifies an organization’s ISMS (clauses 4–10). Annex A is the reference set declared in a Statement of Applicability. CSF 1.1 outcomes are organizational. Put this product on the SoA only where a kernel allowlist actually treats the risk.

CSF 2.0 (February 2024) reorganized Protect (PR.AC → PR.AA and similar). This page stays on 1.1 IDs so the table is one version.