Secure baselines, hardening, segmentation and access control

Objective 4.1 is the largest single objective in SY0-801, and its verb is apply: given a situation, choose and use the control that fixes it. This course splits it across four lessons. This first one covers the controls that shape the systems themselves -- the baseline they are built to, how they are hardened, how the network around them is divided, which software may run on them, and the operating system features that enforce all of it.

Why this matters

Security Operations is 27% of the exam, the heaviest domain, and this is where it starts. From here on the questions stop asking what something is and start asking what you would do.

Hardening and segmentation give the best return in security operations, because most compromises use something that never needed to be there: an unused service, an unchanged default password, a flat network. The exam follows from this. It favours the control that removes the exposure over one that watches it, and one enforced automatically over one that depends on someone remembering.

The lesson

Establish, deploy and maintain: a baseline is a cycle, not a document

A secure baseline is the approved configuration for one class of system: every Windows laptop, every web server, every core switch. The work has three stages, and organisations most often skip the third.

• Establish. Decide what the configuration should be. Start from a recognised benchmark, such as the CIS Benchmarks, the DISA STIGs or the vendor's own security guide, rather than inventing one. Then adjust it for your environment and record why each deviation exists. That record turns an exception into a decision someone owns.
• Deploy. Apply it at scale with a golden image, Group Policy, a configuration management tool or infrastructure as code. A baseline applied by hand cannot be repeated or verified.
• Maintain. Keep checking that reality still matches, and correct it when it does not. Systems drift. Someone changes a setting to fix a problem, an update restores a default, a new machine is built from last year's image.

Maintenance is where configuration enforcement comes in. A baseline applied once is a snapshot of good intentions; one re-applied and measured continuously is a control. If a scenario describes systems built correctly that are now inconsistent, the answer is enforcement and drift detection. Rewriting the standard changes no running machine.

Baselines also make exceptions visible. A legacy application that genuinely needs an old protocol gets a recorded, approved deviation with a compensating control and a review date, the pattern from lesson 1. Change management (lesson 5) governs changes to the baseline itself.

Hardening workstations, servers, network devices, and the gentler touch OT needs

The recipe is the same everywhere. Remove what is not needed, restrict what remains, and record what happens. Only the details change from one kind of system to the next.

Workstations. Taking local administrator rights away from users is the most valuable single change. Then: full-disk encryption, unneeded services off, screen lock, removable media restricted, exploit protections and logging on. Configure the host-based firewall in both directions. A workstation has no reason to accept SMB or RDP from another workstation, and blocking that on the host closes a lateral-movement path the network firewall never sees.

Servers. Install the minimum, ideally one role per server, allow management only from an administrative network or jump server, and give service accounts least privilege.

Network devices. Change default credentials, switch off unused ports and services, manage over encrypted protocols on a separate management network, and log every configuration change.

Across all three, disabling legacy protocols in favour of their encrypted equivalents is a swap the exam expects you to know:

Default passwords are the most exploited single condition here. They live on printers, cameras, appliances, database installs and management consoles. The baseline should require changing them. The maintain stage should check that they were changed, because deployment is exactly when it gets missed.

Remove unnecessary software. Uninstalled software needs no patching and cannot be exploited, so removal is the one control with no running cost: preinstalled vendor utilities, unused browser extensions, development tools on production servers. Prove it by measuring the running systems with an inventory and a configuration scan, not by taking someone's word.

Operational technology needs a gentler touch. Industrial controllers and medical devices put availability and safety first, a vendor may withdraw support if the device is changed, and an aggressive scan can crash a controller. So change defaults where the vendor allows and disable unused ports, then put the real control on the network around the device: segmentation, strict allow rules and passive monitoring (lesson 21).

Segmentation and access control lists, and the blast radius they are bought to limit

Segmentation divides a network so that compromising one part does not give access to the rest. You buy it for one reason, to limit blast radius, and it should be judged on that alone.

The forms, from coarsest to finest:

• Physical separation, up to a true air gap with no network path at all. This is the strongest form and the most painful to run, and people quietly defeat it with a USB drive.
• VLANs and subnets, with traffic between them controlled by ACLs or firewalls.
• A screened subnet for internet-facing services. Outsiders can reach it, but it cannot freely open connections into the internal network.
• Microsegmentation, where policy applies to each workload, so two servers on the same VLAN still cannot talk unless policy allows it. This is the zero trust principle from lesson 4 applied to the network.

An access control list enforces the boundary: an ordered list of permit and deny entries matching source, destination, protocol and port, ending in an implicit deny. The first matching entry wins, so a broad permit above a narrow deny silently cancels it, and you permit the narrowest thing that meets the need. Permissions on files, shares and databases follow the same least privilege thinking.

Segmentation is the right answer for lateral movement, a flat network, a system that cannot be patched, or two populations of different trust sharing infrastructure: guest and staff Wi-Fi, IoT and corporate, OT and IT. It is the wrong answer when an attacker uses valid credentials where they are meant to work. That is an identity problem, caught by the access reviews in lesson 36.

Application allow and block lists, and why an allow list stops what you did not foresee

Application control decides which software may execute at all.

• An allow list permits only approved applications and denies everything else by default.
• A block list permits everything except named, known-bad applications.

Which way the list points is the whole point. A block list can only stop what someone has already identified. An allow list stops what nobody foresaw: a new piece of malware with no signature, a renamed tool, a user's unapproved download. That is why allow listing is so effective against zero-day and fileless techniques that evade detection. If a scenario stresses unknown or novel threats and both options appear, choose the allow list.

The cost is maintenance, and how a rule identifies software decides how fragile it is:

• Hash rules are exact and break on every update.
• Path rules are easy to write and weak if users can write to that path.
• Publisher (code-signing) rules trust whatever a named vendor signs. They survive updates and are usually the practical middle ground.

Block lists remain useful as a quick, narrow supplement, such as banning one remote-access tool. Either kind is often run first in audit mode, logging what it would block, before enforcement.

Group Policy and SELinux as the operating system's own enforcement

The exam names one enforcement mechanism for each of the two main operating system families.

Group Policy is how Windows domains deliver configuration centrally. Policy objects are linked to sites, domains or organisational units in Active Directory and carry password, lockout and audit policy, firewall rules, removable media restrictions, application control and most of what a benchmark specifies. It re-applies on a schedule, so a setting changed by hand is put back: the maintain stage of the baseline, done automatically.

SELinux (Security-Enhanced Linux) adds mandatory access control to Linux. Normal Linux permissions are discretionary: a file's owner decides who may use it, and a process running as root can do almost anything. SELinux labels every process and file and enforces a system policy about which labels may interact, whatever the owner wants. A compromised web server confined by SELinux can be stopped from reading files outside its own domain even while running as root. That is a genuinely different guarantee. AppArmor is a similar Linux mechanism that confines programs with per-application profiles.

SELinux runs in three modes:

• Enforcing applies the policy and blocks violations.
• Permissive only logs what it would have blocked. This is useful for building or troubleshooting a policy.
• Disabled turns it off.

The classic finding is a server left in permissive after troubleshooting. "We disabled SELinux so the application would work" is a wrong answer; fix the policy or labels and keep enforcing.

What to take into the exam

• A baseline is establish, deploy, maintain; drift makes the third stage matter, and enforcement beats documentation.
• Removing local admin is the top workstation change. Know the legacy swaps (Telnet, FTP, HTTP, SNMPv1/2c, LDAP, SMBv1).
• OT is hardened lightly on the device and heavily on the network around it.
• Segmentation limits blast radius; ACLs are first-match with an implicit deny.
• An allow list stops the unforeseen; a block list stops only the known.
• Group Policy re-applies settings on a schedule. SELinux confines a process even as root; permissive mode only logs.