42. The do-not-disrupt host baseline and host groups

Hardening must not break what a host is there to do. The do-not-disrupt baseline records what each host uses - its services, listening ports, installed applications, processes, scheduled tasks and network connections - and protects it: before an enforce, the planner compares what the control changes (its declared effects) with the host's baseline and blocks a change that would stop a protected service, close a protected port or connection, remove a package a protected process needs, or switch off a protocol a protected connection is seen using (41.4).

Path: Hardening > Host baseline (the Host baseline button at the top of the Hardening page). The page is titled "Do-not-disrupt host baseline".

Permissions and four-eyes. The rule: anything that adds protection is one signature; anything that removes protection needs a second administrator (critical action "Execute remediation").

The baseline needs agent 2.1.10.s or later on the host (Linux and Windows). macOS agents report no inventory.

42.1 How a baseline is built#

1. Inventory. The agent reports the host's inventory: processes (program, SHA-256, user, parent; a command line only as a SHA-256), services, installed packages, listening ports, network flows (per direction, remote address class and port, with the programs), scheduled tasks (program only), and kernel modules or drivers, mounted filesystems and a few network kernel settings where the server asks for them. A full report at start and every 24 hours; changes at most every 5 minutes when something changed.
2. Learning. The first full inventory starts a learning window (7 days by default). Everything seen in it becomes a baseline item.
3. Frozen. When the window ends the baseline freezes and waits for review: "Learning finished - waiting for review".
4. Approved. An administrator reviews and approves it. Only an approved baseline protects
   • and in strict mode, a host whose baseline is not approved holds every hardening step that declares an effect on the host ("no do-not-disrupt baseline yet (learning until <date>)"). Controls that declare no effect are not affected.

42.2 What the page shows#

• Settings card at the top (42.7).
• Hosts on the left: Filter hosts, then each host with its status, item count and mode. Click one.
• The host panel: the host name, platform, baseline version N, last report <time>, groups: ..., and "last inventory was truncated" when the agent hit its row cap. Tiles: Baseline (the status), Protected (pinned / items), Deviations, Not seen now (protected items the host no longer reports) and Mode (a list, 42.5).
• In strict mode before approval: "Strict mode: hardening steps that declare an effect on this host wait until its baseline is approved."
• Buttons: Approve baseline (frozen only), Request inventory now, the field Reason for a re-baseline, Re-learn, Freeze from current.
• Tabs: Protected items, Deviations (N), Inventory, Overrides (N).
• Group-wide items at the bottom (42.8).

42.3 Procedure: review and approve a baseline#

Permission: Run hardening. Four-eyes: no (approval adds protection).

1. Open Hardening > Host baseline and click a host whose status is "Learning finished - waiting for review".
2. Open Protected items. Use Search and All kinds (service, port, process, package, task, flow, module, mount, sysctl, protocol) to read the list. Columns: Kind, Item, Detail, Source (observed or manual), Seen now, Protected.
3. Look at flagged items ("Worth a look before approving"): seen late in learning, ordinary account (runs as an unprivileged user), no package (a program from no installed package). They may be something that should not be on the host at all.
4. Unpin what should not be protected (see 42.4; four-eyes), and add what the inventory cannot see (42.4).
5. Press Approve baseline.

What you see: "Baseline approved." The status becomes Approved, and the planner's baseline guard now compares changes with it.

If it fails: 409 "only a frozen baseline (learning finished) can be approved" - wait for the learning window to end, or use Freeze from current (42.6, four-eyes).

42.4 Procedure: pin, unpin, add and delete items#

• Pin (one signature): press not pinned on an item's row ("Pin: hardening must not disrupt it"). You see "Pinned."
• Unpin (four-eyes): press pinned ("Unpin: hardening may disrupt it (second signature)"). With dual control on: "Sent for a second signature: it applies once another administrator approves it." Then execute it from Approvals > My requests.
• Add an item the inventory does not show (one signature): at the bottom of Protected items, choose the kind and type the value, then Add:

  Kind	Example value
  Listening port	9102/tcp (a number 1-65535, optionally /tcp or /udp)
  Service	Spooler
  Process	sqlservr.exe
  Package / app	openssh-server
  Scheduled task	logrotate
  Kernel module / driver	usb_storage
  Protocol in use	ntlm (for example a protocol a legacy client needs that the inventory cannot see)

  Why it matters is an optional note. You see "Item added and protected." Network flows are recorded by the agent and cannot be added by hand.

• Delete a hand-added item (four-eyes): the bin on its row. Observed items cannot be deleted ("observed items are unpinned, not deleted; a re-baseline drops what the host no longer uses").

Risk of unpinning or deleting: hardening may then stop, close or remove that item. Rollback: pin it again or add it again (one signature).

42.5 Modes: strict, warn, off#

The mode decides what the baseline guard does on a host:

Modes are set at four levels; the most specific wins: host -> group -> profile -> site. A host listed (by agent id) in several groups takes the strictest of their modes. A group the host is in only by an asset tag can make its mode stricter, never weaker (a tag is not a way to switch protection off). With no setting anywhere the mode is strict ("strict (built-in)").

Procedure: choose the mode in the host's Mode tile (the list shows "inherit (<mode>, <source>)" for the inherited value), in a group's mode list (42.8), or the site's Default mode in the settings card. Profile-level modes (strict and standard hardening profiles) are set through the API (PUT /api/v1/hardening/baseline/modes with scope_type profile).

Four-eyes: yes for warn, off and inherit; no for strict. Risk: warn and off let hardening disrupt what the baseline protects. Rollback: set strict again (one signature).

42.6 Re-baseline and overrides#

Procedure: re-learn or freeze from current#

When the host's role changes (a new application, a decommissioned service), start a new baseline version. The old version is kept.

Permission: Run hardening. Four-eyes: yes (it can drop protected items).

1. Type the Reason for a re-baseline (at least 3 characters).
2. Press Re-learn (a new learning window starts: "New baseline version is learning.") or Freeze from current (the new version is frozen at once from the current inventory: "New baseline version frozen from the current inventory.").
3. Approve the request in Approvals, execute it, then review and approve the new baseline (42.3).

Risk: in strict mode, every hardening step that declares an effect waits again until the new version is approved. Rollback: none for the version itself; the previous version stays on record, and you can pin or add items again.

Request inventory now asks the agent for a full inventory at its next heartbeat ("Asked the agent for a full inventory at its next heartbeat."). One signature.

Overrides#

An override lets hardening disrupt listed protected items of one host for a few hours, for one control or for every control. The Overrides (N) tab lists the active ones: the item keys, "for <control>" or "for every control", "until <time>", the reason and who asked.

Overrides are made in two ways:

• From the planner: Override baseline with approval (41.7) - the usual way.
• Through the API (no console form): POST /api/v1/hardening/baseline/overrides with agent_id, keys (the item keys), optional control_id, reason (at least 10 characters) and hours (1 to 72, default 4). Four-eyes: yes. Revoke one early with DELETE /api/v1/hardening/baseline/overrides/{override_id} (one signature).

An override expires by itself, within 72 hours at most.

42.7 Deviations, inventory and settings#

Deviations (N): items present on the host but not in its baseline - "Add what is expected so hardening protects it; investigate the rest." Columns Kind, Item, Detail, First seen. Add to baseline adds it (one signature): "Added to the baseline."

Inventory: the host's raw inventory, with Search, the kind list, and gone only to list what disappeared. Columns Kind, Item, Detail, Last seen.

Settings card (top of the page):

Collection caps and the kinds collected are changed through PUT /api/v1/hardening/baseline/settings; lowering a cap or collecting fewer kinds is four-eyes (it can freeze learning or hide what hosts use).

If something looks wrong:

42.8 Host groups and group-wide items#

A host group is one list shared by three features:

• the baseline: group-wide items protect every host of the group, and a group can carry a mode;
• compliance exceptions scoped to a group (25.2);
• framework scores and signed reports for a group (chapter 43).

A group made for one of them scopes the others. A group lists hosts by agent id, and can also match hosts by asset tag (for example db). Tag matches count only where a scope widens - more baseline protection, a report covering more hosts - never where a scope relaxes a control: an exception covers only the hosts listed by id when it was requested.

Procedure: create a group and protect an item on all its hosts#

Permission: Run hardening. Four-eyes: no.

1. Open Hardening > Host baseline and scroll to Group-wide items ("Protected on every host of the group - listed by agent id or carrying one of its asset tags - whether or not the inventory shows them.").
2. Type a Group name, e.g. DB servers, Agent ids: 3, 7 (find a host's id in Environment > Hosts), and optionally Asset tags: db, backup. Press New group. You see "Group created." (A name already used is refused: "a group with this name exists".)
3. In the group's box, choose the kind, type the value (for example 9102/tcp for the backup agent's port) and press Add: "Group item added."
4. Optionally choose the group's mode in its list (anything but strict is four-eyes).

Procedure: remove a group item or delete a group#

Four-eyes: yes for both (every member loses the protection at once).

• Press the bin beside the item (Remove <name>), or the bin on the group's line (Delete group <name>). With dual control on, approve and execute the request.

Changing a group's members or tags is done through the API (PUT /api/v1/hardening/baseline/groups/{group_id} with name, agent_ids, match_tags); it is four-eyes when a host would lose the group's items or join a group with a weaker mode.

Risk: hosts leaving a group lose its protection, and a deleted group no longer scopes reports or new exceptions. Rollback: create the group or item again (one signature).