Installation and Configuration

The previous lesson compared three operating system families over the same request set and left a warning in its final section: the results in the table belong to the family’s default configuration. A default is not a choice; it is what remains when the person doing the install selects nothing.

This lesson measures that state. When a clean install finishes, how many items remain risky, how many of them can be closed right away, how many close only if the machine is reinstalled, and how many never close.

Installation Is Not a Moment, It Is a Set of Decisions

Installation is usually spoken of as a single event: the machine was installed. Seen from a measurement standpoint, installation is a set of decisions, and not all of those decisions can be undone at the same point in time.

Some items are settled only during installation. Encrypting a volume later means moving the data; changing the partition layout later means rebuilding the filesystem; the key that generates the machine’s identity is generated at first boot, and if a weak source was used at that moment, fixing it later means changing the identity. For these items, “we will do it later” is not an option — it means reinstalling.

Some items close during the baseline hardening right after installation: default accounts, default passwords, services left open. Some can be closed even while the machine is in use. One never closes.

Counting these four moments separately turns the sentence “the install was hardened” into a number.

Twenty Items, Four Moments

The example is a newly installed branch server in the fictional regional measurement network. Both the server and the item list are fictional; the table below is a model — there is no real distribution, install tool, or vendor.

HO12: the configuration item set is 20, and each item carries a closing time. HO13: the closing time takes four values — install only at install time, initial during baseline hardening, later while the machine is in use, never at no time. HO14: the state a clean install leaves is either risky or safe. HO15: opens is the number of items reached if the item stays open; items are not summed because they can touch the same assets, the highest is written instead. HO16: the window is the set of risky items not yet closed while the machine is connected to the network.

// it/install.mjs — configuration items a clean install leaves behind (model): not a real
// distribution, install tool, or vendor. No randomness.

// time: when the item can be closed — install (only at install time; changing it later
// means reinstalling), initial (during the baseline hardening right after install), later
// (whenever wanted), never (cannot be closed, only managed). risky: whether the state a
// clean install leaves is risky. opens: items reached if the item stays open.
export const ITEM = `
  disk-encryption               install  risky   11
  separate-data-partition       install  risky    6
  boot-signature-record         install  risky    9
  machine-key-generation        install  risky    3
  install-source-verification   install  safe    14
  firmware-admin-password       initial  risky   12
  default-admin-account         initial  risky    8
  default-password              initial  risky    8
  remote-management-service     initial  risky    7
  unnecessary-service-set       initial  risky    5
  firewall-default               initial  risky    6
  automatic-login                initial  risky    4
  guest-account                  initial  safe     3
  log-collection                 initial  risky    4
  time-synchronization           initial  safe     2
  screen-lock-timeout            later    risky    2
  software-source-restriction    later    risky    5
  backup-schedule                 later    risky    9
  driver-signature-requirement    later    risky    6
  hardware-error-channel           never    risky    1`
  .trim().split("\n").map((r) => {
    const [name, time, safe, opens] = r.trim().split(/\s+/);
    return { name, time, risky: safe === "risky", opens: Number(opens) };
  });

export const TIME = ["install", "initial", "later", "never"];
export const risky = ITEM.filter((k) => k.risky);
export const countTime = (t, all = ITEM) => all.filter((k) => k.time === t).length;

// Window: risky items still open, given the phases already closed.
export function openWindow(closed) {
  const open = risky.filter((k) => !closed.includes(k.time));
  return { count: open.length, worst: Math.max(...open.map((k) => k.opens)),
    worstName: open.reduce((a, b) => (b.opens > a.opens ? b : a)).name };
}

// it/installmeasure.mjs — how many items a clean install leaves open, when each closes, and what the sequence changes.
import { ITEM, TIME, risky, countTime, openWindow } from "./install.mjs";

const write = (g, ...s) => console.log(s.map((v, i) =>
  (g[i] < 0 ? String(v).padEnd(-g[i]) : String(v).padStart(g[i]))).join(""));

console.log(`${ITEM.length} configuration items; risky items a clean install leaves behind: ` +
  `${risky.length}; closing time: ${TIME.join(", ")}`);

const A = [-30, 11, 12, 8];
console.log("\n1. closing time per item (opens: items reached if the item stays open)");
write(A, "item", "time", "default", "opens");
for (const k of ITEM) write(A, k.name, k.time, k.risky ? "risky" : "safe", k.opens);

const B = [-30, 11, 12, 8];
console.log("\n2. distribution by closing time");
write(B, "time", "items", "risky", "worst");
for (const t of TIME) {
  const r = risky.filter((k) => k.time === t);
  write(B, t, countTime(t), r.length, r.length ? Math.max(...r.map((k) => k.opens)) : 0);
}
write(B, "total", ITEM.length, risky.length, Math.max(...risky.map((k) => k.opens)));

const C = [-33, -29, 12, 9];
console.log("\n3. two install sequences (window: risky items open while connected)");
write(C, "sequence", "worst item in the window", "open items", "opens");
for (const [name, closed] of [["install -> connect -> harden", []],
  ["install -> harden -> connect", ["initial"]],
  ["  + later items closed too", ["initial", "later"]]]) {
  const s = openWindow(closed);
  write(C, name, s.worstName, s.count, s.worst);
}

const D = [-36, 12];
console.log("\n4. what remains after hardening finishes");
write(D, "measure", "items");
write(D, "closed during initial hardening", risky.filter((k) => k.time === "initial").length);
write(D, "closable later", risky.filter((k) => k.time === "later").length);
write(D, "closable only by reinstalling", risky.filter((k) => k.time === "install").length);
write(D, "never closes", risky.filter((k) => k.time === "never").length);
write(D, "worst opened by install-time items",
  Math.max(...risky.filter((k) => k.time === "install").map((k) => k.opens)));

20 configuration items; risky items a clean install leaves behind: 17; closing time: install, initial, later, never

1. closing time per item (opens: items reached if the item stays open)
item                                 time     default   opens
disk-encryption                   install       risky      11
separate-data-partition           install       risky       6
boot-signature-record             install       risky       9
machine-key-generation            install       risky       3
install-source-verification       install        safe      14
firmware-admin-password           initial       risky      12
default-admin-account             initial       risky       8
default-password                  initial       risky       8
remote-management-service         initial       risky       7
unnecessary-service-set           initial       risky       5
firewall-default                  initial       risky       6
automatic-login                   initial       risky       4
guest-account                     initial        safe       3
log-collection                    initial       risky       4
time-synchronization              initial        safe       2
screen-lock-timeout                 later       risky       2
software-source-restriction         later       risky       5
backup-schedule                     later       risky       9
driver-signature-requirement        later       risky       6
hardware-error-channel              never       risky       1

2. distribution by closing time
time                                items       risky   worst
install                                 5           4      11
initial                                10           8      12
later                                   4           4       9
never                                   1           1       1
total                                  20          17      12

3. two install sequences (window: risky items open while connected)
sequence                         worst item in the window       open items    opens
install -> connect -> harden     firmware-admin-password                17       12
install -> harden -> connect     disk-encryption                         9       11
  + later items closed too       disk-encryption                         5       11

4. what remains after hardening finishes
measure                                    items
closed during initial hardening                8
closable later                                 4
closable only by reinstalling                  4
never closes                                   1
worst opened by install-time items            11

The numbers belong to the measurement class; their inputs are HO12–HO16.

What a Clean Install Leaves Behind

The header line gives the first number: 17 of 20 items come out of a clean install in a risky state. Three are safe — install source verification, the guest account being closed, and time synchronization being on.

This ratio explains why hardening is a separate job. The install tool does not make a security decision; it leaves behind a working system. A working system’s defaults are chosen in the direction that makes the install easier to count as successful: services on, accounts ready, remote access usable. Each of these choices is defensible on its own; together they add up to 17 items.

The three items that come out safe are not random either. Install source verification is the install tool’s own job, and if it is not verified the entire installed system is called into question — this is why the number it opens, 14, is the highest on the list, and why it is on by default for the same reason. Time synchronization is required for records to be comparable. The guest account coming closed is the reversal of an old default: an item’s default changes according to how much trouble that item has caused in the past.

The second table gives the distribution. Ten items can be closed during baseline hardening, and 8 of these are risky. Five items are settled only at install time, and four of them are risky. Four items close while the machine is in use. One item never closes.

The rows’ worst column also gives a ranking. The worst item in baseline hardening opens 12 assets, and this is the highest risky value on the list; the worst item at install time is 11, and the worst among the later items is 9. So the riskiest item that opens the most assets sits in the cheapest-to-close class. This ranking determines the hardening sequence: the items with the highest opens value are closed first, because the gap between their cost and their payoff to close is the largest.

The Item Missed at Install Time

The third row of the fourth table gives this lesson’s most expensive number: 4 items close only by reinstalling, and the worst item count they open is 11.

What these four items share is that they correspond to a structure that cannot be added to the system later. Disk encryption is not a setting; it is how the volume was written. The separate data partition is not a preference; it is where the filesystem begins and ends. The boot signature record is the trusted key set of the boot chain counted in the previous lesson, and once the chain is built without that record, no layer above it can go back and add it. The key that generates the machine’s identity is generated at first boot.

The practical consequence of the number is this: for these four items, the checklist cannot be run after installation. An audit performed after installation finds the remaining 13 risky items and writes the other four as “missing” — but the cost of closing those four is not a setting change, it is reinstalling the machine. Considered across the measurement network’s forty branch servers, this means reinstalling forty machines, not changing four settings.

The Window: Connecting to the Network Before Hardening

The third table measures the cost of the sequence. If the machine is installed and connected to the network first, then hardened, 17 risky items are open in the window, and the worst item opens 12 assets. If hardening happens before connecting to the network, the open items drop to 9 and the worst item falls to 11. If the items that can be closed later are also closed before connecting, the open items drop to 5.

The difference is achieved without adding a single new control. The items closed are the same across all three sequences; the only thing that changes is when they are closed. This is a different kind of gain than the threshold measurements in the previous lessons: the boundary was not strengthened — the time during which the boundary was not yet established was shortened.

The window never drops to zero in any sequence. Even in the best sequence, 5 risky items are still open, and the worst of them opens 11 assets; these are the items settled at install time. The only way to close the window is to close the items during installation itself — that is, to stop treating hardening as a step after installation and move it into the installation itself.

The Distinction Between an Install Profile and a Checklist

Reading the third table has a direct consequence. 12 of the risky items — the 4 belonging to install time plus the 8 belonging to baseline hardening — can be settled before the machine is powered on for the first time. When these are written not as a checklist entry but as part of the installation itself, the window never opens at all.

The distinction is this. A checklist asks about items one by one on an already installed machine and reports what is missing; each query happens at a point in time, and the time elapsed up to that point is the window. An install profile carries the same items as decisions applied during installation; when the machine is installed, the items are already closed, and the window is zero.

The scope of the two approaches also differs. A checklist can ask about all 20 items but can fix only 12 of them — the items closable in baseline hardening plus the ongoing items, that is, 8 plus 4. An install profile closes 12 items and leaves behind the ongoing items and the item that cannot be closed. The two do not substitute for each other: the profile closes the window, the checklist catches items that open over time. If an install has only one of the two, the number measured is incomplete.

This distinction has a cost too. Writing an install profile requires finding, for each of the 12 items, which option the install tool uses to set that item; this is a one-time job done per machine class. A checklist, by contrast, runs on every pass and rediscovers the same gaps on every new machine — the number that measures the gap between finding and closing is the fix repeated forty times on forty machines.

The Same Item, Two Machine Classes

The risky marker in the table is not independent of the machine class. The measurement network has two classes, and the same item falls in a different place in each.

On the branch server, remote-management-service is a requirement; it cannot be closed, only narrowed — in this case the item leaves the initial class and turns into a continuously managed item. On the field laptop, the service is not needed at all and is genuinely closed. Conversely, disk-encryption is the most important install item on the laptop, because the device can be physically lost; on a server in a locked branch room, the same item’s 11 assets sit behind another boundary too.

This is why the measurement is done per machine class, and two numbers are kept separate: the assets the item itself opens, and which other boundaries those assets sit behind. When a single organization-wide list is applied to both classes at once, it produces unnecessary work in one class and incomplete closing in the other.

The Item That Never Closes

The last row of the fourth table sets one item apart: hardware-error-channel. This item cannot be closed, only managed. A defect present in the hardware is not a configuration option; what corresponds to it are the mitigations that come with firmware and operating system updates. How updates are scheduled is a separate subject and is not measured in this course; what is counted here is only that an item exists that cannot be closed.

An item falling into this class changes the measurement. If it stands in a checklist as a row waiting for a “closed” mark, it shows up as missing on every audit and is eventually ignored. Written as a separate class instead, it asks the right question: since this item does not close, which other boundary does the 1 asset it opens sit behind. The number being small matters here — if the item that cannot be closed opens a small surface, layered defense does its job; if it opens a large surface, the machine’s role must change.

Summary

• A clean install makes no security decision: 17 of 20 configuration items stay risky by default, and only 3 are safe.
• Items split into four by closing time: 8 risky items close during baseline hardening, 4 close while the machine is in use, 4 close only by reinstalling, and 1 never closes.
• The four items settled at install time cannot be fixed later with a setting change; a gap an audit finds means reinstalling the machines involved.
• Sequence alone yields a measurable gain: when hardening happens before connecting to the network, the open items in the window drop from 17 to 9, and to 5 once the later items are closed too.
• The window never zeroes out in any sequence; the remaining 5 items belong to install time. The only way to close the window is to move hardening into the installation itself.
• The item that cannot be closed is written as its own class; kept as a row that constantly shows up missing on a checklist, it gets ignored.

Next Step

When installation finishes, a permission scheme has already been established on the machine: accounts, groups, and who has access to what on which object. This scheme was the source of the difference between families in the previous lesson, and several of the 17 items counted in this lesson set it directly.

The next lesson descends into that scheme and performs the topic’s most detailed measurement: the same access request set is run through two separate permission models, how many requests give a different result is counted, and which request each model cannot express is written down.