System and Endpoint Hardening Questions

Direct answer

SELinux (Security-Enhanced Linux) and AppArmor are two implementations of mandatory access control (MAC) for the Linux kernel. Ordinary file permissions are discretionary access control (DAC): the owner of a file decides who may read or write it, and any program running as that user inherits all of that user's rights. MAC adds a second, system-wide policy written by the administrator or the distribution, which the kernel enforces on top of the permission bits and which a user or a compromised program cannot change at will. That lets you confine a program to what it legitimately needs, so a hijacked web server running as an ordinary account cannot, for example, read every file that account happens to own. I would insist on it for anything internet-facing or handling sensitive data, and hesitate only about how fast to enforce it on software nobody understands, never about whether to use it.

DAC versus MAC, concretely

Both checks must pass. A MAC policy in effect narrows what DAC allows, which is why a permissions fix (chmod) alone does not cure a MAC denial.

SELinux and AppArmor: how they differ

An actual AppArmor profile fragment shipped on Ubuntu 24.04 (/etc/apparmor.d/lsb_release, trimmed) shows the idea: the program may read a few files, execute a few helpers, and nothing else:

profile lsb_release {
  include <abstractions/base>
  /dev/tty rw,
  /usr/bin/lsb_release r,
  /etc/lsb-release r,
  /{usr/,}bin/bash ixr,
  /usr/bin/cat ixr,
}

r is read, w is write, x execute (ix means the helper runs under this same profile), and anything not granted is denied. Letters combine, so /usr/bin/cat ixr, grants two things at once: execute cat under this same profile (ix) and read the file (r), which the kernel needs in order to load the program. A SELinux rule says the same thing in terms of types: "processes in domain httpd_t may read files of type httpd_sys_content_t".

Working example: a web server returns 403 on a correct-looking directory

Apache on a RHEL-family host serves /srv/myweb, owned by the right user with mode 755, yet returns 403. DAC is fine; the files carry the wrong type for a web server to read. The sequence:

1. getenforce to see the mode, and ls -Zd /srv/myweb to see the directory's context (ls -Z prints the security context; -d lists the directory itself). Under /srv the default label in the RHEL policy is var_t (read from the policy's file-context list), a type Apache's domain is not allowed to read. Illustrative output before and after the fix in step 3 (format user:role:type:level; the type is the third field):

   text

   before:  unconfined_u:object_r:var_t:s0               /srv/myweb
   after:   unconfined_u:object_r:httpd_sys_content_t:s0 /srv/myweb
   

2. ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent searches the audit log for denial records (an AVC, access vector cache, message is how SELinux logs a denial; the name comes from the kernel cache that holds access decisions), or sealert -l "*" for a readable explanation (-m selects the message types to list, -ts recent limits the search to the last ten minutes, and -l "*" asks sealert to describe every alert it has). A denial record for this story looks like this (illustrative, in the format SELinux writes):

   text

   type=AVC msg=audit(1728200000.123:456): avc:  denied  { read } for  pid=1840 comm="httpd" name="index.html" dev="dm-0" ino=412 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=file permissive=0
   

   Read it as: { read } is the action refused; comm="httpd" and scontext say who asked (domain httpd_t); name and tcontext say what was touched (a file of type var_t); tclass=file is the object kind; permissive=0 means the host was enforcing, so the request really was blocked.

3. Fix the label first: semanage fcontext -a -t httpd_sys_content_t "/srv/myweb(/.*)?" records the rule permanently, then restorecon -R -v /srv/myweb applies it. The semanage fcontext rule makes the labelling part of the policy, and restorecon applies it to the existing files. The pattern at the end of the path is a regular expression: (/.*)? means an optional slash followed by anything, so the rule covers /srv/myweb itself and every file and folder below it (checked with grep -E: /srv/myweb and /srv/myweb/a/b.html match ^/srv/myweb(/.*)?$, /srv/mywebsite does not).

4. If labelling is correct and the denial is a legitimate feature (the app must connect to a database), use a boolean, a switch built into the policy: setsebool -P httpd_can_network_connect_db on. A non-standard port is likewise a label: semanage port -a -t http_port_t -p tcp 9876.

5. Only if neither fits, write a small custom module. Red Hat explicitly warns against using audit2allow to generate a local module as the first response to a denial, because it turns whatever was blocked, including a real attack, into permitted behaviour.

The temptation is setenforce 0, which switches the whole host to permissive. The better tool is to make one domain permissive while the rest stays enforcing: semanage permissive -a httpd_t, then remove it when done. Never set SELinux to disabled: with it disabled objects are not even labelled, which makes turning it back on painful.

The AppArmor equivalent: aa-status lists profiles and modes; aa-complain /path/to/bin moves one profile to complain mode while you collect what the program really does; edit /etc/apparmor.d/<profile>; apparmor_parser -r /etc/apparmor.d/<profile> reloads it; aa-enforce /path/to/bin returns it to enforcement.

When I would insist, and when I would hesitate

Insist when:

• the host is internet-facing (web servers, mail, VPN endpoints) or processes untrusted input, since confinement limits what a successful exploit can reach;
• the host is multi-tenant or runs code from several teams;
• a compliance baseline requires it (the SCAP Security Guide's CIS Server Level 1 profile for AlmaLinux 9, for example, includes the rules "Ensure SELinux is Not Disabled" and "Configure SELinux Policy", so a scan will flag a host that has it off);
• the host runs containers, where MAC is an additional layer between a container and the host (installing apparmor and apparmor-utils on Ubuntu 24.04 places profiles for runc, crun, podman and buildah in /etc/apparmor.d).

Hesitate (that is, stage it, do not skip it) when:

• a vendor application with unknown behaviour has files in unusual places and nobody can say what it legitimately touches: run it in permissive or complain mode with logging for a defined period, review the denials, then enforce with a date attached;
• the team has no one who can read a denial, in which case train someone before enforcing on a revenue system, not after the first outage;
• the application is in the middle of a migration and its file layout is still changing.

The pattern "hesitate" never means "disable". A permissive domain with logging still gives you the audit trail and a path to enforcement, while a disabled module gives you neither.

Pitfalls

• Fixing a denial by loosening DAC (chmod 777), which weakens the layer that was working and does not address the MAC denial.
• Generating a policy module from every denial without reading them.
• Restoring or copying data into place and assuming the labels are right: run restorecon on it and check with ls -Z.
• Assuming AppArmor and SELinux are interchangeable in an operating procedure: the commands, defaults and failure modes differ, so write the runbook per distribution.

Direct answer

Least privilege means every user, program and service gets only the permissions needed for its job, and only for as long as it needs them. On a host that means three layers: people (no everyday admin rights, separate admin identities, named sudo rules on Linux, managed local admin passwords on Windows), files and directories (owner and group set to the real service account, no access for "everyone", broken inheritance only where needed), and services (each running under its own low-privilege account). I enforce it with groups rather than individual grants, write the permissions as code, and then audit them with commands so I find drift rather than assume it.

Users: who can do what

Windows LAPS is built into supported Windows versions, rotates the managed local administrator password regularly, and exists to stop one shared password enabling lateral movement from machine to machine (Microsoft Learn, Windows LAPS overview). Retrieval is a deliberate act: Get-LapsADPassword -Identity 'WEB01' returns the password as a SecureString unless you add -AsPlainText, which Microsoft says to use only in support or testing situations.

Linux sudo, tested. A sudoers file with a syntax error can lock out all admins, so it is validated before install. Executed in an ubuntu:24.04 container:

$ cat good.sudoers
deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart webapp
$ visudo -cf good.sudoers
good.sudoers: parsed OK
$ cat bad.sudoers
deploy ALL=(root) NOPASSWD /usr/bin/systemctl
$ visudo -cf bad.sudoers
bad.sudoers:1:46: syntax error
deploy ALL=(root) NOPASSWD /usr/bin/systemctl
                                             ^
$ install -m 0440 -o root -g root good.sudoers /etc/sudoers.d/deploy-webapp
$ sudo -l -U deploy
Matching Defaults entries for deploy on 75de9dd7b378:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty

User deploy may run the following commands on 75de9dd7b378:
    (root) NOPASSWD: /usr/bin/systemctl restart webapp

deploy can restart one service as root and nothing else. The NOPASSWD tag removes the password prompt for that one command, which is acceptable for automation but should not be a blanket on ALL. Be careful with wildcards in command paths and with commands that can launch a shell (editors, pagers): the sudoers manual warns that wildcards can grant more than intended, and the NOEXEC tag stops dynamically linked programs from spawning further commands.

If you do three things first, make them these: remove everyday admin rights, give every machine its own LAPS password, and run each service under its own account. The finer points are details for when you write the rules: NOEXEC is a sudoers tag that stops a permitted program from launching further programs, UAC is the Windows prompt that asks for confirmation before an admin action, and a SecureString is a .NET string type that is kept encrypted in memory and does not print as plain text.

Files and directories on Linux

Set the owner and group to the account that really needs access, remove the "other" bits, and add ACLs (access control lists, per-user or per-group permissions beyond the owner, group and other triplet) rather than widening the group. Executed in the same container:

$ chmod 750 /srv/app; chmod 2770 /srv/app/shared
$ setfacl -m u:deploy:rx /srv/app
$ getfacl -p /srv/app
# file: /srv/app
# owner: webapp
# group: webapp
user::rwx
user:deploy:r-x
group::r-x
mask::r-x
other::---
$ stat -c '%A %U:%G %n' /srv/app /srv/app/shared
drwxr-x--- webapp:webapp /srv/app
drwxrws--- webapp:webapp /srv/app/shared
$ touch /srv/app/oops; chmod 666 /srv/app/oops
$ find /srv -xdev -type f -perm -0002 -print
/srv/app/oops

Reading the digits: each digit is read 4 + write 2 + execute 1, for owner, group and other in that order. 750 is 7 (4+2+1, rwx) for the owner, 5 (4+1, r-x) for the group and 0 for everyone else, which is the drwxr-x--- in the stat line. 2770 has a fourth, leading digit for special bits, where 2 means setgid: setgid, then rwx for owner, rwx for group, nothing for others, shown as drwxrws--- with the s standing in for the group x.

mask::r-x is the ceiling for every named-user entry and for the group entry: an entry's effective permission is its own bits ANDed with the mask. Here deploy has r-x and the mask allows r-x, so deploy gets r-x. Had the mask been r--, deploy would have lost execute (the right to enter the directory) and getfacl would have printed #effective:r-- beside the entry. setfacl -m recalculates the mask for you unless told not to.

other::--- means a user who is neither webapp nor deploy cannot even list /srv/app. deploy can read and traverse but not write. The setgid bit (the s in drwxrws---) makes new files in shared inherit its group. The find command is the audit for the classic mistake, a world-writable file; run it on a schedule. The same applies to setuid programs, which run with their owner's rights: list them with find / -xdev -type f -perm -4000 and review the list against what the server's role needs.

Files and directories on Windows

NTFS (the Windows file system) permissions are held in an ACL on each folder, and by default folders inherit entries from their parent. Least privilege usually means breaking inheritance on a sensitive folder and granting the service account, administrators and SYSTEM only what each needs. This script was parse-checked with PowerShell 7 and every cmdlet, method and parameter was checked against Microsoft Learn; it was not executed, because it needs a Windows host (Set-Acl is Windows-only, and Get-LapsADPassword needs the LAPS module and an AD):

# 1. Who is in the local Administrators group on this host?
Get-LocalGroupMember -Group 'Administrators' | Select-Object Name, ObjectClass, PrincipalSource

# 2. Restrict D:\AppData to the service account, Administrators and SYSTEM
$path = 'D:\AppData'
$acl  = Get-Acl -Path $path
$acl.SetAccessRuleProtection($true, $false)   # stop inheriting, drop the inherited entries
$inherit   = [System.Security.AccessControl.InheritanceFlags]'ContainerInherit,ObjectInherit'
$propagate = [System.Security.AccessControl.PropagationFlags]::None
foreach ($rule in @(
    @('CORP\svc-webapp',        'Modify'),
    @('BUILTIN\Administrators', 'FullControl'),
    @('NT AUTHORITY\SYSTEM',    'FullControl'))) {
    $ace = New-Object System.Security.AccessControl.FileSystemAccessRule(
        $rule[0], $rule[1], $inherit, $propagate, 'Allow')
    $acl.AddAccessRule($ace)
}
Set-Acl -Path $path -AclObject $acl -WhatIf    # remove -WhatIf after reviewing
icacls $path

# 3. Break-glass: read one machine's local admin password from AD
Get-LapsADPassword -Identity 'WEB01' -AsPlainText

ContainerInherit,ObjectInherit makes each entry apply to the subfolders (containers) and the files (objects) inside D:\AppData, so the grant flows down the tree; PropagationFlags::None adds no extra limit on that flow. In icacls notation the same ideas are (CI) and (OI), and RX means read and execute.

SetAccessRuleProtection($true, $false) means "protect from inheritance, and do not preserve the inherited entries", so the folder ends with only the three explicit entries. The three grants are added to the same in-memory ACL before Set-Acl writes it, so administrators are never locked out part-way. The -WhatIf switch makes Set-Acl report what it would do without doing it, so while -WhatIf is present nothing is written and icacls $path still prints the old ACL. After you remove -WhatIf and run the script for real, icacls $path lists the resulting ACL for review, one entry per line in the form name:(inheritance flags)(rights), where (M) is Modify and (F) is Full control. You should see exactly the three entries above (service account (M), Administrators (F), SYSTEM (F)); an entry marked (I) or any other name means inheritance was not removed or an extra grant exists. This describes the documented format and was not run, since it needs a Windows host. icacls $path /save <file> stores a copy of the ACL that /restore can re-apply if the change goes wrong.

Share permissions and NTFS permissions are separate layers: when a folder is reached over a network share, the access a user gets is the more restrictive of the two, so a locked-down NTFS ACL is not undone by a generous share.

Services

Each service runs under its own account with only the rights it needs, and never as root or as a domain administrator. On Linux that is a dedicated user such as webapp that owns only /srv/app. On Windows it is a dedicated service account, like CORP\svc-webapp above, granted rights only on its own folders and not given interactive logon.

Worked example

A web server hosts an app owned by webapp, deployed by a pipeline user deploy, administered by two people. Result: webapp owns /srv/app with mode 750 (full access for the owner, read and traverse for the group, nothing for others); deploy gets read via an ACL and one sudo rule to restart the service; the two administrators have personal logins with sudo for a short named list; there is no shared password anywhere; and the find audit above returns nothing. On the Windows file server the same pattern gives one service account modify rights on D:\AppData, administrators and SYSTEM full control, and everyone else no entry at all.

Trade-offs and pitfalls

• Least privilege costs setup time and generates "access denied" tickets. Pay that cost once in staging, by running the application as its real service account there.
• Group-based grants decay: people change roles. Review membership of the privileged groups quarterly, with Get-LocalGroupMember and sudo -l -U.
• Standing admin rights are the thing to remove first. Time-limited elevation (just-in-time access) is the stronger end state but needs tooling; do the cheap steps first.
• A broad sudo rule on ALL, or a sudo rule that lets someone run an editor as root, is effectively root; read rules for what they can be made to do.

Direct answer

Make the baseline a single versioned source of truth, check it at three points (image build, provisioning, and continuously at runtime), and decide per setting between report-only and auto-fix with a rule: auto-fix only when the correction is deterministic (the same input always gives the same result, with no per-host judgement), idempotent, reversible and cannot take a service or an administrator out; report and ticket everything else. Keep the scan results as dated, tamper-evident evidence (any later edit would be visible) so an auditor can see the history, not only today's state.

Design: three checkpoints and evidence

1. Image build: scan every image before it is published and fail the build on violations. On Linux, OpenSCAP (an open-source compliance scanner) can evaluate a profile and write results and an HTML report with oscap xccdf eval --profile <profile> --results-arf results.xml --report report.html <datastream>. A profile is a named subset of rules, such as a CIS level; a datastream is the single file that bundles the rules and the checks that test them; XCCDF is the XML format those rules are written in and results are reported in; on Windows, build from a hardened image and apply the settings through Group Policy.
2. Provisioning: enforce at first boot with configuration management (Ansible, Group Policy or an endpoint management tool) so no host starts life drifted.
3. Runtime: re-check continuously (for example daily) in detect mode. Ansible can run read-only with --check (and --diff), where modules that support check mode report the changes they would make. Note the documented limits: modules without check-mode support report nothing, and tasks whose conditions depend on registered results from earlier tasks produce no output in check mode.
4. Evidence: store each scan result (the XML results file or the exported report) with the host, time, baseline version and operator, in write-once storage (storage that accepts new files but refuses edits and deletions, for example object storage with a retention lock). This is what an auditor asks for.

Deciding per setting: report only or fix automatically

Rules behind the table:

• Fix automatically when the setting is a pure tightening that no workload legitimately needs and the fix is idempotent (running it twice changes nothing).
• Report only when it can interrupt service or lock people out, needs a reboot, varies by host role, or when the same setting is repeatedly reverted by a person or program. Repeated reverts mean something is fighting your baseline, so raise an alert instead of fixing again.
• Every report-only drift gets an owner and a due date, or a time-limited exception with an expiry.
• Examples of fixes that are not deterministic, so they stay report-only: "set rp_filter to whatever suits this host's routing" (the right value differs per host), "remove local administrators who look unfamiliar" (who is legitimate is a human judgement), and any change that only takes effect after a reboot.

How the pieces fit: the single versioned baseline is what everything is compared against; the three checkpoints decide when you look; the table and rules decide what happens on a mismatch. OpenSCAP and the registry script below are the detectors for Linux and Windows hosts, and Ansible check mode and Group Policy are how you detect or enforce through the tool a fleet is already managed with.

Worked example: Linux check that fixes some settings and reports others

This script reads a table of settings. Rows marked fix are rewritten when they drift. Rows marked report are only flagged. It takes a root directory so it can be tested safely.

#!/usr/bin/env bash
# Report-or-fix drift check for key/value settings in config files.
# Usage: drift-check.sh ROOT        (ROOT is / on a real host)
set -euo pipefail
root=${1:-/}
# file | key | expected value | mode (report|fix)
settings=(
  "etc/ssh/sshd_config|PermitRootLogin|no|fix"
  "etc/ssh/sshd_config|X11Forwarding|no|fix"
  "etc/ssh/sshd_config|MaxAuthTries|4|report"
  "etc/sysctl.d/99-hardening.conf|net.ipv4.conf.all.rp_filter|1|report"
)
drift=0
for row in "${settings[@]}"; do
  IFS='|' read -r file key want mode <<<"$row"
  path="$root/$file"
  have=$({ sed -E 's/[[:space:]]*=[[:space:]]*/ /' "$path" 2>/dev/null || true; } |
    awk -v k="$key" '$1 == k { v = $2 } END { print v }')
  if [[ "$have" == "$want" ]]; then
    printf 'OK     %-40s %s\n' "$key" "$have"
    continue
  fi
  drift=$((drift + 1))
  printf 'DRIFT  %-40s have=%s want=%s mode=%s\n' "$key" "${have:-<unset>}" "$want" "$mode"
  if [[ "$mode" == fix ]]; then
    if [[ ! -f "$path" ]]; then
      printf 'SKIP   %-40s not fixed, %s does not exist\n' "$key" "$file"
    else
      if grep -qE "^[[:space:]]*${key}[[:space:]]" "$path"; then
        sed -i -E "s|^[[:space:]]*${key}[[:space:]].*|${key} ${want}|" "$path"
      else
        printf '%s %s\n' "$key" "$want" >>"$path"
      fi
      printf 'FIXED  %-40s now=%s\n' "$key" "$want"
    fi
  fi
done
echo "drift_count=$drift"
exit $(( drift > 0 ))

Driver and real output (run inside a Debian container with GNU sed):

rm -rf /tmp/root && mkdir -p /tmp/root/etc/ssh /tmp/root/etc/sysctl.d
printf 'PermitRootLogin yes\nMaxAuthTries 6\n' > /tmp/root/etc/ssh/sshd_config
printf 'net.ipv4.conf.all.rp_filter = 0\n' > /tmp/root/etc/sysctl.d/99-hardening.conf
bash drift-check.sh /tmp/root; echo "exit=$?"
bash drift-check.sh /tmp/root; echo "exit=$?"

DRIFT  PermitRootLogin                          have=yes want=no mode=fix
FIXED  PermitRootLogin                          now=no
DRIFT  X11Forwarding                            have=<unset> want=no mode=fix
FIXED  X11Forwarding                            now=no
DRIFT  MaxAuthTries                             have=6 want=4 mode=report
DRIFT  net.ipv4.conf.all.rp_filter              have=0 want=1 mode=report
drift_count=4
exit=1
OK     PermitRootLogin                          no
OK     X11Forwarding                            no
DRIFT  MaxAuthTries                             have=6 want=4 mode=report
DRIFT  net.ipv4.conf.all.rp_filter              have=0 want=1 mode=report
drift_count=2
exit=1

Reading the script, line by line:

• settings=( ... ) is a table with one row per setting; the four fields in each row are separated by |. IFS='|' read -r file key want mode <<<"$row" splits one row on | into four variables (IFS is the field separator read uses, -r stops backslashes being treated as escapes, and <<<"$row" feeds the row to read as its input). For the first row that gives file=etc/ssh/sshd_config key=PermitRootLogin want=no mode=fix.
• The have=$(...) line finds the current value. The { sed ... || true; } group matters: with set -euo pipefail, a missing config file would make sed fail and silently end the whole script with status 2 and no output. With the guard, a missing file simply reads as <unset> and is reported as drift (run on a root whose sshd_config already meets the baseline and which has no sysctl file, it prints DRIFT net.ipv4.conf.all.rp_filter have=<unset> want=1 mode=report and drift_count=1). The same guard does not help a fix row, because the rewrite needs a file to edit: without the [[ ! -f "$path" ]] test in the fix branch, a root with no sshd_config made grep and then the >> append fail and the whole run stop after the first DRIFT line, with no drift_count and exit status 1, which looks the same as ordinary drift. With the test, that row prints SKIP PermitRootLogin not fixed, etc/ssh/sshd_config does not exist, stays counted as drift, and the run finishes (on an empty root all four rows are drift, two of them SKIP, drift_count=4, exit 1; run in the same container). sed -E 's/[[:space:]]*=[[:space:]]*/ /' turns a key = value line into key value by replacing the first = and the spaces around it with one space (lines already written key value pass through unchanged). awk -v k="$key" '$1 == k { v = $2 } END { print v }' then looks for lines whose first word equals the key, remembers the second word, and prints the last one remembered when the file ends. Run on a small file in a Debian container:

--- after sed:
PermitRootLogin yes
MaxAuthTries 6
MaxAuthTries 5
# X11Forwarding yes
--- awk for MaxAuthTries:
5

The commented-out X11Forwarding line is ignored because its first word is #, and when a key appears twice the last line wins. That is how sysctl files behave; sshd keeps the first value instead, one more reason the sketch's reading of a file can differ from the effective configuration.

• [[ "$have" == "$want" ]] prints OK and moves to the next row; anything else counts as drift, increments drift and prints DRIFT. Only rows with mode fix reach the rewrite, and only when the file exists: sed -i replaces the existing line, or printf ... >> appends one if the key was missing.
• exit $(( drift > 0 )) ends the script with status 1 if any drift remains and 0 otherwise, because the arithmetic comparison evaluates to 1 or 0. Run in the same container, drift=0 exits 0 and drift=3 exits 1.

The first run fixes two settings and reports two. The second run finds the fixed ones clean (idempotent) while the report-only ones stay open until a human acts. The non-zero exit code lets a scheduler or pipeline alarm on remaining drift.

Limits of this sketch, so you do not trust it blindly: it reads files, not effective configuration. The sshd manual says that for each keyword the first obtained value is used, and that keywords after a Match line apply only to matching connections, so an appended line can be shadowed or captured by a Match block (a section of the configuration whose settings apply only to connections matching a condition, such as a particular user or source address). In production, read the effective SSH configuration with sshd -T, which prints it, rather than grepping the file.

Worked example: Windows registry-backed setting

On Windows the same decision logic applies; prefer Group Policy or endpoint management to enforce, and use a script only for what they do not cover. This reports drift for SMB signing and fixes it only when run with -Fix:

param([switch]$Fix)
$path = 'HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters'
$name = 'RequireSecuritySignature'
$want = 1
$have = Get-ItemPropertyValue -Path $path -Name $name -ErrorAction SilentlyContinue
if ($have -eq $want) { "OK     $name = $have"; return }
"DRIFT  $name have=$have want=$want"
if ($Fix) {
    Set-ItemProperty -Path $path -Name $name -Value $want
    "FIXED  $name now=$want"
}

Run it on a Windows host, since the registry provider is Windows-only. RequireSecuritySignature is the registry setting Microsoft names for the "always sign" SMB policy. It is deliberately report-only by default.

Trade-offs and pitfalls

• Auto-fix everything and you will eventually take down an application at 3 a.m.; report everything and drift grows faster than people close tickets. The per-setting rule is the compromise.
• Detecting drift is half the job: find out why it happened (manual change, a package script, a stopped agent) or the same drift returns.
• Measure it: drift count per host per week, mean time to close report-only items, and number of exceptions past expiry.
• A scanner finding is only evidence if the scan could authenticate and covered the host.

Direct answer

Make the case in three parts. Claim what is true: automating baseline enforcement removes repeated manual labour and cuts the window between a change and its detection, and it makes audits evidence-driven instead of a scramble. Size the benefit in hours you can count from your own tickets, show the payback including the ramp, and say plainly what you cannot size (risk reduction). Then propose phases so leadership funds the first one and sees evidence before funding the next.

What to claim, and what not to

Claim: fewer hands-on hours per build, fewer audit findings that need chasing, faster detection of drift (a setting changing after the server was hardened), and a record of compliance on every host. Do not claim: "no more breaches", a dollar figure for risk avoided that you cannot derive, or that audits disappear.

Sizing the benefit honestly

Use inputs you pull from ticket history and time records. The numbers below are assumed inputs for the arithmetic; replace them with your own measured counts.

• Manual hardening: 80 new builds per year x 6 hours each = 480 hours.
• Audit follow-up: 120 findings per year x 3 hours each = 360 hours.
• Current total: 480 + 360 = 840 hours per year.

With automation:

• Running the automated build: 80 x 0.5 hour = 40 hours.
• Findings drop to 30 percent of today: 120 x 0.30 = 36 findings x 3 hours = 108 hours.
• New total: 40 + 108 = 148 hours per year.
• Saving: 840 - 148 = 692 hours per year, which is about 57.7 hours per month.

Cost: assume 400 hours of engineering to build and test the baseline and pipeline.

The naive payback is 400 / 692 x 12 = 6.9 months. Payback means the point where the cumulative saving has repaid the build cost. The naive figure is wrong because it assumes the full saving from month 1, but the benefit does not start on day one. A ramp is the period before the saving reaches its full size. Assume the ramp is: months 1 to 3 deliver nothing (the build phase), months 4 to 6 deliver half the monthly saving, and month 7 onward delivers the full saving. Treat the 400 hours as spent during months 1 to 3, so the whole cost is already counted before the first hour is saved.

The steps, from the sizing above:

• Full monthly saving: 692 / 12 = 57.67 hours. Half rate: 57.67 / 2 = 28.83 hours (692 / 24, unrounded).
• End of month 3: 0 saved, so the position is -400 hours.
• End of month 6: -400 + 3 months x 28.83 = -400 + 86.5 = -313.5 hours.
• End of month 12: -313.5 + 6 months (months 7 to 12) x 57.67 = -313.5 + 346.0 = +32.5 hours.

Month by month, in hours: month 3 -400.0, month 4 -371.2, month 5 -342.3, month 6 -313.5, month 7 -255.8, month 8 -198.2, month 9 -140.5, month 10 -82.8, month 11 -25.2, month 12 +32.5. The position crosses zero during month 12, so payback arrives in month 12, not month 7. Say the later number. It survives scrutiny.

All the figures in this sizing are in hours on one basis; do not convert some to money and leave others in hours.

Phasing

CIS here means the Center for Internet Security, which publishes hardening benchmarks.

Risks to name and the honest limit

• Automation applied wrongly can break production, so phase 1 is detect-only and the auto-fix list is short.
• The benefit assumes findings truly fall by 70 percent; check this at the end of phase 2 and report the real number, even if it is lower.
• Risk reduction is real but not sizeable in hours. Present it as a qualitative benefit, and tie it to the audit findings you can count.

What would change the recommendation

If you build only 10 servers a year, the manual cost is small and the case rests on audit evidence alone. If the fleet is mostly managed images already, enforcement is mostly built and the investment is smaller.

Direct answer

Check a short list of host conditions that each map to a real attack path (disk encryption, operating system patch level, a protection agent that is installed and healthy, a firewall and screen lock, and not being rooted or jailbroken), plus whether the device is managed or not. Evaluate them at sign-in and again while the session lives. A device that fails is not simply blocked: it moves down a ladder (grace period, then restricted access, with an outright block reserved for a device that cannot be trusted at all, such as a rooted or jailbroken one), and an unmanaged personal device gets a lower access tier (a level of access, such as full, browser-only or none) by design rather than being asked to meet managed-device rules. Users go looking for workarounds when failure is opaque and the fix is slow, so the design effort goes into clear messages, self-service fixes and a pilot that measures the failure rate before anything is enforced. The identity rules that assign each tier are set by access policy; the host signals and the handling of a failing device are what the endpoint side owns.

Which host conditions to check, and how the signal is read

Keep the list short. Every extra condition adds false failures, and each one should be defensible as "this blocks a specific attack". The strength of the signal matters more than the number of signals: a check that the device reports about itself proves less on an unmanaged phone than a hardware-backed result on a managed laptop, so unmanaged devices get less access instead of the same checks with less trust.

What happens to a device that fails

Written as access rules, in plain words (illustrative, not any product's syntax):

1. If the device presents a valid device certificate and its compliance report says compliant, allow the apps the user's role needs.
2. If it is enrolled but out of compliance, allow with a banner for the grace period, then restrict access until it is fixed.
3. If it presents no device certificate (unmanaged), allow only browser sessions with downloads off.
4. If the attestation result says rooted or jailbroken, block corporate resources.

How to avoid pushing users to workarounds

1. Say exactly what failed and how to fix it. The block page should name the condition ("disk encryption is off"), give the fix in one step, and show a self-service button or link where the platform allows. A generic "device not compliant" message sends people to the help desk or to personal email.
2. Make the fix quick. Push patches and enable encryption through management where you can, and keep a short path for people who cannot self-fix (a help desk queue with a target time).
3. Grace periods tied to the cause, not a single number. A newly released patch needs days. A disabled protection agent does not.
4. Leave an audited emergency path for the people who repair devices (help desk, on-call), so enforcement never blocks the fix.
5. Respect privacy on personal devices. Collect only the signals in the table, say what is collected, and on an unmanaged device remove only corporate app data (selective wipe), never the whole device.
6. Watch for workaround signals after launch: corporate mail forwarded to personal accounts, files moved through unsanctioned sharing tools, spikes in help desk tickets about access.
7. Pilot in report-only mode first (the policy is evaluated for every sign-in and the result is logged, but nothing is blocked). Log who would have failed and why without enforcing, read the numbers, fix the noisy conditions, then enforce.

Worked example

A sales manager signs in from a personal Windows laptop whose disk is not encrypted and which is four months behind on updates. The device is unmanaged, so the rule that applies is the unmanaged tier, not a compliance check: the CRM works in the browser, downloads and desktop sync are off, and the page tells them that enrolling the laptop would earn full access. A different user's managed laptop first failed the patch check yesterday: the user sees a banner each day and keeps full access, and on the eighth day after that first failure access drops to the restricted tier until the update installs. The grace clock starts at the first failed check, not at the patch release date.

Planning the help desk load for the pilot (illustrative arithmetic, not a measurement): if the report-only run shows 6% of 1,000 managed devices would fail on patch age, that is 60 devices; at 15 minutes of help desk time each, enforcement day costs 900 minutes, or 15 hours. If that is too much, extend the grace period or push the patch first, then enforce.

Trade-offs and what would change the answer

• A stricter model (managed devices only, personal devices through a virtual desktop) is simpler to reason about and right for regulated data, but it costs more and hurts contractors. The tiered model is the better default when most unmanaged users only need web apps.
• If the workforce is mostly contractors on their own devices, protect the applications and data (app-level controls) rather than depending on host posture you cannot verify.
• Continuous evaluation (re-running these rules while the session is open, not only at sign-in) catches a device that drifts after sign-in, at the price of more disruptive mid-session restrictions. Use it for the conditions that change quickly (agent stopped) and not for slow ones (patch age).