--- title: 'Installation and Configuration' source: 'https://academia.sh/en/courses/it-fundamentals/installation-and-configuration' course: 'Information Technology and Systems Fundamentals' language: en updated: '2026-10-21T05:02:56+00:00' license: 'CC BY-SA 4.0' objectives: - 'Separates configuration items into four classes by their closing time' - 'Computes the number of risky items a clean install leaves and the share baseline hardening closes' - 'Compares the items left open in the window between install and hardening across sequences' --- # Installation and Configuration Measuring the clean install itself: 17 of 20 configuration items staying risky by default, baseline hardening closing 8 of them, 4 closing only by reinstalling, and 1 never closing; when hardening happens before connecting to the network, the open items in the window drop from 17 to 9, and to 5 once later items are closed too. 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. ```js // 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 }; } ``` ```js // 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.