Introduction and Overview

• 1: HeartSuite Core Secure Overview
• 2: Setup Overview
• 3: System Requirements

1 - HeartSuite Core Secure Overview

Overview: HeartSuite Core Secure enforces a default-deny policy at the kernel level — only explicitly approved programs can execute, access files, or make network connections. Any program not on the allowlist is blocked before it can execute, including malware and zero-day attacks that detection-based tools might miss.

How HeartSuite Core Secure Works

HeartSuite Core Secure uses a modified Linux kernel that enforces an allowlist-based security model. No program can execute, access files, or make network connections unless explicitly approved by an administrator. Even if malware is downloaded to a HeartSuite Core Secure server, the kernel prevents it from running or causing damage.

The Dashboard is the central interface. It tracks your progress through a 7-phase setup journey, shows pending events that need review, and always suggests the next step.

The 7-Phase Model

Core Features

1. Program Allowlist

An allowlist entry defines what a program is permitted to do: which files it can access, which directories it can read or write, and which network connections it can make. The HeartSuite Core Secure kernel requires every program to have an allowlist entry before it is permitted to run.

The Dashboard review queues present pending events for approval:

• Programs queue ([p]) — programs attempting to execute
• File Access queue ([f]) — programs attempting to read or write files
• Internet Access queue ([i]) — programs attempting outbound connections

Each queue uses a tiered review model to manage volume efficiently:

• Tier 1: Individual events shown one at a time with full metadata (package name, description, category, maintainer, install date)
• Tier 2: Grouped events (e.g., “847 file reads from /usr/lib/python3/”) with a representative sample shown
• Tier 3: Informational summary of what is ahead before reviewing

File access is divided into read access and write access. Write access always includes read access. These are approved separately — approving a file read event grants read access; approving a file write event upgrades to write access.

The caching mechanism loads only a single allowlist entry into memory for a running program, even with thousands of concurrent instances, minimising impact on kernel memory.

2. Setup Mode and Secure Mode

HeartSuite Core Secure operates in two modes:

• Setup Mode: The kernel logs all denied actions without blocking them. Use this mode to build the allowlist by reviewing queues and approving legitimate programs and access patterns. The Dashboard guides this process.
• Secure Mode: The kernel enforces the allowlist. Programs without an allowlist entry are blocked. Programs that exceed their permissions are blocked.

Activating Secure Mode requires all review queues to be empty, alerts to be configured, and an active subscription. The Dashboard presents a precondition checklist and requires typing YES (case-sensitive) to confirm.

3. Lockdown

Lockdown protects the integrity of allowlist entries by making them immutable. Once applied, no changes can be made to the allowlist while the server is running — preventing attackers from modifying the security configuration, even with root access.

After activating Secure Mode, the Dashboard offers two reboot options: [r] Reboot (enforcement active, configuration remains editable) or [l] Reboot + Lockdown (enforcement active, configuration sealed with filesystem immutability). Lockdown cannot be reversed at runtime. To make changes, the Dashboard’s Maintenance screen ([t]) guides you through the correct maintenance path — including a guided 3-step process when Lockdown requires booting the Non-HS kernel.

Because access permissions are enforced inside the HeartSuite Core Secure kernel itself, HeartSuite Core Secure cannot be circumvented by any program or user, including root.

4. File Backup and Versioning

HeartSuite Core Secure automatically backs up files in designated directories and prevents all programs from accessing the backups — only HeartSuite Core Secure itself can reach them. The version manager can restore any version of a backed-up file, regardless of whether it was encrypted, deleted, or modified.

5. Secure Script Launchers

Allowlist entries can be created for interpreted code such as Python, PHP, and Perl. HeartSuite Core Secure provides Secure Script Launchers that identify the specific script being run when an interpreter is launched, enabling per-script access control with the same granularity as compiled programs.

Two Setup Paths

Cloud Path: Launch a pre-installed cloud instance. The Dashboard appears immediately. Phase 1 (System Verification) auto-completes. Proceed directly to the review queues.

Local Path: Download from heartsecsuite.com, extract, install, and boot the HeartSuite Core Secure kernel. Run hs-os-boot-setup through multiple reboots (the Dashboard shows a step counter). After Phase 1 completes, the Dashboard appears and both paths merge.

2 - Setup Overview

Overview: HeartSuite Core Secure must complete a guided setup journey in Setup Mode before it can enforce security in Secure Mode. This page explains why Setup Mode exists, what happens during each phase, and how to reach Secure Mode safely.

Why Setup Mode Is Necessary

HeartSuite Core Secure enforces a default-deny policy: every program, file access, and network connection must be explicitly approved before the system permits it. Immediately after installation, the allowlist is empty. If the system entered Secure Mode at this point, it would block the programs required for boot and shutdown, rendering the system inoperable.

Setup Mode solves this problem. In Setup Mode, HeartSuite Core Secure logs all activity without blocking anything. The administrator reviews events through the Dashboard queues, approves legitimate activity, and builds an allowlist that reflects the system’s actual workload. Once the allowlist is complete, the administrator transitions to Secure Mode with confidence that approved operations will continue uninterrupted.

Setup Mode is the default after installation. HeartSuite Core Secure’s automated backup system also operates during Setup Mode, providing an additional layer of protection even before enforcement begins.

The 7 Phases

HeartSuite Core Secure organizes the setup journey into seven phases. The Dashboard tracks progress through each phase and always displays a Suggested Next Step.

Cloud vs. Local Path

Cloud Path

Users who launch a pre-installed HeartSuite Core Secure cloud instance (AWS AMI, GCP image) boot directly into Setup Mode. Phase 1 completes automatically. The Dashboard appears on first login with the current system state and a Suggested Next Step. No manual verification is required.

Local Path

Users who install HeartSuite Core Secure on bare-metal or custom VMs follow a longer path:

1. Download and extract the installation package.
2. Prepare GRUB and install the HeartSuite Core Secure kernel.
3. Run hs-os-boot-setup, which handles multiple reboots with a step counter.
4. After Phase 1 completes, the Dashboard appears and the journey merges with the Cloud path.

Both paths converge at the Dashboard after Phase 1. From that point forward, the workflow is identical.

Setup Workflow

The following diagram shows the primary path through the Dashboard and the advanced CLI alternative.

graph TD
    A[Install HeartSuite Core Secure] --> B{Cloud or Local?}
    B -- Cloud --> C[Boot instance — Phase 1 auto-completes]
    B -- Local --> D["Run hs-os-boot-setup — multiple reboots"]
    D --> C
    C --> E[Dashboard appears — Suggested Next Step]
    E --> F["Phase 2: Programs queue — approve programs"]
    F --> G["Phase 3: Script Launchers — if applicable"]
    G --> H["Phase 4: File Access queue — approve file access"]
    H --> I["Phase 5: Internet Access queue — approve connections"]
    I --> J["Phase 6: Configure alerts"]
    J --> K["Phase 7: Activate Secure Mode"]
    K --> L["Lockdown: [r] Reboot or [l] Reboot + Lockdown"]
    L --> M{Maintenance needed?}
    M -- Yes --> N["Dashboard Maintenance wizard guides through steps"]
    N --> K
    M -- No --> O[System secured]

Switching to Secure Mode

When phases 2 through 6 are complete, Phase 7 unlocks on the Dashboard. The Suggested Next Step will prompt you to activate Secure Mode. The mode switch requires typing YES (case-sensitive) to confirm and displays an allowlist summary and pre-condition checklist before proceeding.

After activating Secure Mode, the Dashboard offers two reboot options: [r] Reboot (enforcement active, configuration remains editable) or [l] Reboot + Lockdown (enforcement active, configuration sealed with filesystem immutability). Both are valid configurations depending on your threat model. Lockdown can also be applied later from the Dashboard’s Mode Switch screen ([m]).

Maintenance in Secure Mode

To perform system maintenance after entering Secure Mode, select the Maintenance screen ([t]) from the Dashboard. The Dashboard detects whether Lockdown is active and guides you through the correct path:

• Without Lockdown: The Maintenance screen walks you through a safety checklist, switches to Setup Mode, and reboots. The HeartSuite Core Secure kernel stays active with logging and backups running. Make your changes, then return to Secure Mode from the Dashboard.
• With Lockdown: The Maintenance screen guides you through a 3-step process across two reboots — removing immutable flags on the Non-HS kernel, making changes, then returning to the HeartSuite Core Secure kernel to review new activity. The Dashboard resumes at the correct step after each reboot.

For full details, see Protecting During Maintenance.

3 - System Requirements

Overview: HeartSuite Core Secure requires an x86 Linux system running a supported distribution — Debian/Ubuntu-derived, Alpine, or RPM-based (RHEL, Fedora, CentOS, Rocky Linux, AlmaLinux, SUSE). It ships with two HeartSuite Core Secure kernels (5.19 and 6.18) and a set of tools that enforce allowlist-based security at the kernel level.

Supported Platforms

HeartSuite Core Secure supports Debian/Ubuntu-derived, Alpine, and RPM-based distributions (RHEL, Fedora, CentOS, Rocky Linux, AlmaLinux, SUSE, openSUSE) on x86.

Kernel

HeartSuite Core Secure is distributed with two HeartSuite Core Secure kernels based on mainline Linux: 5.19 and 6.18. One of these kernels must be booted for HeartSuite Core Secure to function. The Dashboard verifies kernel activation as part of Phase 1 (System Verification) and provides orientation on every boot.