COMP 6660 · Enterprise Cybersecurity Operating System Security

00 Introduction

Unit 4 examined the architectures and detection technologies through which enterprises defend themselves. Unit 5 turns to the platforms themselves. This lesson begins with the platform on which everything else depends: the operating system.

The operating system is the foundation layer of every server, workstation, laptop, mobile device, and workload. It mediates access to hardware, memory, storage, and the network. It enforces the separation between users and between processes. It provides the execution environment on which applications depend. When the operating system is compromised, everything that runs on it is compromised — applications, data, credentials, and any security controls the OS is supposed to enforce.

Despite its foundational importance, operating system security is frequently under-invested. Enterprises deploy sophisticated detection platforms, advanced firewalls, and identity-aware proxies, while leaving operating systems unpatched, misconfigured, and provisioned with excessive privilege. The result is that the most advanced controls are undermined by foundational weaknesses — a pattern that recurs across documented breaches, from Equifax's unpatched systems to the ransomware campaigns that routinely exploit unpatched and misconfigured hosts.

This lesson examines operating system security in detail. It establishes why OS security is foundational. It examines the OS attack surface — the interfaces and components through which the operating system can be attacked. It examines the four principal pillars of OS security — hardening, privilege management, patch management, and configuration management. It examines host-based monitoring as the detection counterpart of those pillars. It examines platform-specific considerations for the major operating system families. And it examines the specific challenges of OS security in cloud and virtualised environments.

The material here prepares for the rest of Unit 5. Endpoint security (Lesson 5.2) builds on the OS foundation; application security (Lesson 5.3) and database security (Lesson 5.4) run on top of it; cloud security (Lesson 5.5), container security (Lesson 5.6), mobile and IoT security (Lesson 5.7), and critical infrastructure security (Lesson 5.8) each adapt the OS principles to their specific contexts.

01 Learning objectives

By the end of this lesson you should be able to:

These objectives contribute to Unit 5 outcome U5.1 (secure infrastructure), and to Module 2 outcome M2.8. See the Unit 5 learning outcomes page for the full mapping.

02 Why OS security is foundational

The operating system sits below every other component of the enterprise estate. Applications run on it; data is stored and accessed through it; network communication is mediated by it; identity and access decisions are enforced by it. When the OS is compromised, every layer above it is exposed.

The consequence of neglecting OS security

The consequences of neglecting OS security are visible across documented breaches:

• Equifax (Lesson 1.6). The breach exploited a known vulnerability in an open-source framework that had not been patched. The underlying failure was a patch-management failure at the OS-adjacent layer — compounded by asset-management gaps that left the enterprise unable to identify affected systems.
• Ransomware campaigns (Lesson 3.4). Ransomware consistently exploits unpatched systems, misconfigured services, and excessive privileges — the fundamentals of OS security.
• NotPetya and WannaCry (Lesson 1.6). Both spread globally through a vulnerability in a Windows service that had been patched months before — devastating enterprises that had not applied the patch.
• Credential-based attacks (Lesson 3.5). Excessive privileges, shared accounts, and weak authentication at the OS level are among the most frequently exploited weaknesses in enterprise breaches.

The pattern is consistent: many of the most consequential enterprise breaches exploit OS-level weaknesses that were known, fixable, and unfixed. The enterprise that invests in OS security — hardening, privilege management, patching, configuration management, and monitoring — addresses a substantial portion of its actual risk.

03 The operating system attack surface

The operating system presents a broad attack surface — a large number of interfaces and components through which adversaries can attempt to compromise the system. Understanding the attack surface informs both hardening priorities and detection strategy.

Components of the OS attack surface

Categories of OS attack

Attacks against operating systems fall into several categories:

Reducing the attack surface

The foundational principle of OS security is to reduce the attack surface to what the system actually requires. Every service that is not needed, every account that is not required, every piece of software that is not used, and every permission that is not necessary represents unnecessary risk. Reducing the attack surface to the minimum the system requires is the first and most consequential step in OS security.

04 Hardening

Hardening is the process of reducing the attack surface of an operating system to the minimum required for its function. It is the first pillar of OS security and the foundation on which the others rest.

What hardening involves

Hardening benchmarks

Hardening is informed by published benchmarks and guidance:

• CIS (Center for Internet Security) Benchmarks. Detailed configuration guidance for operating systems — Windows, Linux, macOS — and for applications and network devices. The most widely used hardening benchmarks.
• NIST guidance. NIST publishes security configuration guidance for various operating systems and platforms, along with the NIST National Checklist Program — a repository of security checklists.
• Vendor guidance. Microsoft, Red Hat, Canonical, and other vendors publish their own hardening guidance, tailored to their platforms.
• STIGs (Security Technical Implementation Guides). Detailed configuration guidance from the US Defense Information Systems Agency — strict and prescriptive; frequently adapted for enterprise use.
• Government and sectoral benchmarks. Various national and sectoral bodies publish hardening guidance tailored to their regulatory contexts.

Hardening implementation

Implementing hardening across an estate requires more than applying a benchmark to a single system. Practical considerations include:

• Role-based baselines. Different systems serve different roles — web server, database server, workstation, domain controller. Each requires a baseline appropriate to its function. Applying a single baseline to every system produces either excessive restriction (breaking legitimate function) or excessive permission (leaving unnecessary attack surface).
• Automated deployment. Hardening baselines should be deployed automatically — through configuration management tools (Ansible, Puppet, Chef, DSC), through group policy, through image deployment, or through cloud-native mechanisms. Manual configuration does not scale and does not remain consistent.
• Continuous compliance. Hardening is not a one-time activity. Systems drift from their baseline over time — through updates, through manual changes, through application requirements. The baseline should be monitored continuously, with drift detected and remediated.
• Exception management. Some systems require deviations from the baseline — for compatibility with legacy applications, for specific business requirements. Exceptions should be documented, time-bounded, and reviewed.
• Change control. Changes to hardening baselines should follow change control processes — evaluated for impact, tested, approved, and documented.

Common hardening failures

• Baseline defined but not deployed. The enterprise has a hardening standard but systems are not actually configured to it.
• Baseline deployed but not maintained. Systems drift from the baseline over time; drift is not detected; the baseline becomes aspirational rather than actual.
• Default configurations. Systems deployed with vendor default configurations — which prioritise ease of use over security.
• Legacy protocols retained for compatibility. TLS 1.0, SMBv1, NTLMv1 retained because some legacy system requires them — leaving the whole estate exposed to weaknesses in those protocols.
• Unnecessary services running. Services enabled by default, never disabled, providing attack surface that the system does not require.
• Default accounts and credentials. Default administrative accounts with default passwords, providing well-known entry points.
• Excessive privileges. Users, services, and processes running with more privilege than they require — expanding the consequence of any compromise.
• Hardening applied once, then forgotten. Systems hardened at deployment, then never reviewed — accumulating drift and falling behind on new hardening guidance.

05 Privilege management

Privilege management is the discipline of controlling who and what has elevated privilege on operating systems — and limiting the consequence when privilege is misused or compromised. It is the second pillar of OS security and one of the most consequential controls in enterprise security.

Why privilege management matters

Privilege is the objective of most enterprise attacks. An adversary who obtains unprivileged access on a system can do limited harm; an adversary who obtains privileged access can compromise the system, extract credentials, disable controls, and pivot to further systems. Privilege management determines how much access an adversary can obtain — and how difficult it is to obtain it.

Excessive privilege is a recurring theme in documented breaches. Users with administrative rights they do not need; services running as system accounts when a dedicated service account would suffice; standing administrative access held by individuals who use it rarely — each represents exposure that a sophisticated adversary will exploit.

Privilege categories on operating systems

Privilege management principles

Privilege management implementation

Implementing privilege management on operating systems involves several activities:

• Inventory privileged accounts. Identify every account with elevated privilege — on each system, at each level. This is the foundation — without an accurate inventory, privilege management is not possible.
• Reduce privilege. Remove excessive privilege — from users, from services, from applications. The principle is that privilege should be granted on the basis of genuine need, not on the basis of convenience or default.
• Separate administrative accounts. Individuals with administrative access should have distinct accounts for administrative work — not administrative rights on their day-to-day accounts. This limits the consequence if their standard account is compromised.
• Manage service accounts. Service accounts should be dedicated, documented, and provisioned with the minimum privilege required. Their credentials should be vaulted and rotated.
• Control administrative access. Administrative access should be governed — through just-in-time access, through privileged access management, through approval workflows for sensitive operations.
• Monitor privileged activity. All use of privileged access should be logged and monitored — for detection of misuse and for forensic investigation.
• Review privileged access. Privileged access should be reviewed periodically — removing access that is no longer needed and identifying accumulation.

Common privilege management failures

• Everyone is an administrator. Users provisioned with administrative access for convenience — a common pattern in smaller organisations and in organisations where user productivity is prioritised over security.
• Standing administrative access. Administrative access held continuously rather than granted just-in-time — providing an always-available target for credential theft.
• Shared administrative accounts. Administrative credentials shared across teams or individuals — eliminating accountability and expanding the consequence of compromise.
• Services running as SYSTEM or root. Services running with more privilege than they require — providing escalation paths.
• Unmanaged service accounts. Service accounts whose credentials never rotate, whose permissions are never reviewed, and whose existence is frequently forgotten.
• No monitoring of privileged activity. Privileged access used without logging or monitoring — misuse cannot be detected.
• Privilege accumulation. Privileges added over time and rarely removed — producing privilege creep that expands exposure.
• Administrative accounts without strong authentication. Administrative access protected only by passwords — vulnerable to credential theft and phishing.

06 Patch management

Patch management is the discipline of applying software updates — security patches, feature updates, and configuration changes — to operating systems and the software they run. It is the third pillar of OS security and one of the most operationally demanding.

Why patch management matters

Vulnerabilities are discovered continuously. Vendors publish patches to address them; enterprises must apply those patches to remain protected. The alternative — leaving vulnerabilities unpatched — is to remain exposed to attacks that exploit known weaknesses.

Many of the most consequential enterprise breaches have exploited unpatched vulnerabilities. WannaCry and NotPetya (Lesson 1.6) spread through a Windows vulnerability for which a patch had been available for months. Equifax (Lesson 1.6) exploited a vulnerability for which a patch had been available for weeks. The pattern is consistent: adversaries exploit the gap between vulnerability disclosure and enterprise remediation.

The patch management lifecycle

07 Baseline security and configuration management

Configuration management is the discipline of maintaining operating systems in a known, secure, and consistent state. It is the fourth pillar of OS security — the discipline that ties the other three (hardening, privilege management, patch management) into a coherent and sustained programme.

Why configuration management matters

Security depends on configuration. A system with the correct security settings is substantially protected; a system with incorrect settings is vulnerable regardless of what security features it supports. Configuration management ensures that systems are configured correctly — and that they remain configured correctly over time.

Configuration drifts. Systems accumulate changes over time — through updates, through user modifications, through application requirements, through troubleshooting. Without configuration management, drift produces inconsistency — some systems remain close to their baseline, others drift far from it. The systems that drift become the exposed systems.

The configuration baseline

A configuration baseline is the defined secure configuration for a system or class of systems — the settings, services, accounts, permissions, and other configuration that the system should have. Baselines are typically:

• Defined by role. Different systems serve different roles and require different baselines. Web servers, database servers, workstations, domain controllers, and cloud instances each require baseline appropriate to their function.
• Derived from benchmarks. Baselines are typically derived from published benchmarks — CIS, NIST, STIGs, vendor guidance — adapted to the enterprise's specific requirements.
• Documented. Baselines should be documented — what settings are required, why, and what exceptions have been approved.
• Version controlled. Baselines evolve; changes should be version controlled and reviewed.
• Automated in deployment. Baselines should be applied automatically — through configuration management tools, images, policies — not through manual configuration.
• Continuously monitored. Compliance with the baseline should be monitored continuously; drift should be detected and remediated.

Configuration management practices

Configuration management challenges

• Legacy systems. Legacy systems may not support modern configuration management tools — requiring manual configuration and producing inconsistency.
• Heterogeneous estates. Enterprises operate multiple operating systems, multiple versions, and multiple platforms — each requiring its own baseline and its own tooling.
• Cloud and on-premises integration. Configuration management must span cloud and on-premises environments — with different tooling, different models, and different constraints.
• Change velocity. Rapid change — through continuous deployment, through ephemeral workloads — challenges traditional configuration management approaches. Infrastructure as code is the response.
• Skills. Configuration management requires skills that are not universally present — infrastructure as code, cloud-native configuration, automation tooling.
• Exceptions. Systems that cannot conform to baseline — for legacy compatibility, for specific business requirements — require documented exceptions and compensating controls.

08 Host-based monitoring

Host-based monitoring is the detection counterpart of the four pillars of OS security. Hardening, privilege management, patch management, and configuration management reduce the likelihood of compromise; host-based monitoring detects what those controls do not prevent.

What host-based monitoring provides

• Process visibility. What processes are running, what they are doing, and how they interact — including the malicious processes that adversaries run.
• File and registry activity. Creation, modification, and access of files and registry keys — including the persistence mechanisms that adversaries install.
• Authentication and privilege events. Login attempts, privilege use, and authentication anomalies — including the credential attacks and privilege escalations that adversaries perform.
• Configuration changes. Modifications to system configuration — including the changes adversaries make to disable controls, establish persistence, or expand access.
• Network connections. Connections made by processes on the host — including the command-and-control and exfiltration connections that adversaries establish.
• Integrity monitoring. Detection of unauthorised modification to critical files, configuration, and system state.

Host-based monitoring technologies

Host-based monitoring considerations

• Coverage. Every system should be covered by host monitoring — servers, workstations, cloud instances. Gaps in coverage are blind spots where adversaries can operate.
• Configuration. Logging must be configured to capture the events that matter — authentication, privilege use, process execution, configuration changes. Default configurations frequently miss critical events.
• Centralisation. Logs should be centralised — through SIEM or equivalent — so that they are available for correlation, investigation, and retention. Local logs are lost if the system is compromised.
• Integrity. Logs must be protected from tampering — adversaries frequently attempt to delete or modify logs to cover their tracks. Centralisation and integrity monitoring address this.
• Performance. Host monitoring consumes resources — CPU, memory, disk, network. Performance impact must be managed, particularly on constrained systems.
• Volume. Host monitoring generates substantial log volume. Selective collection — focused on security-relevant events — reduces volume without sacrificing detection value.
• Integration. Host-based monitoring should integrate with network and cloud monitoring — providing the correlated view that cross-layer detection requires (Lesson 4.6).

09 Platform-specific considerations

The four pillars — hardening, privilege management, patch management, and configuration management — apply to all operating systems. But the specific implementation varies by platform. This section examines the principal considerations for the major operating system families.

Windows

Windows dominates enterprise endpoints and much of the enterprise server estate. Its security considerations include:

• Active Directory integration. Windows environments are typically managed through Active Directory — the identity and policy infrastructure. AD security is foundational; compromise of AD typically means compromise of the Windows estate. Privileged AD accounts — domain administrators, enterprise administrators — warrant the strongest controls.
• Group Policy. Group Policy is the primary mechanism for applying configuration baselines to Windows systems. Group Policy Objects define settings — password policy, audit policy, security settings, firewall rules — that are applied automatically.
• Windows Defender / Microsoft Defender for Endpoint. Microsoft's built-in security capabilities — antivirus, EDR, attack surface reduction — are integrated into the platform and provide substantial protection when properly configured.
• Credential protection. Windows has historically been vulnerable to credential theft — through techniques like Pass-the-Hash and Kerberoasting. Modern Windows versions include mitigations — Credential Guard, LSA protection — but require configuration.
• Legacy protocols. SMBv1, NTLMv1, and other legacy protocols remain supported for compatibility — and remain a source of risk. These should be disabled where feasible.
• Update management. Windows Update, WSUS, and Microsoft Endpoint Configuration Manager (formerly SCCM) provide Windows patch management. Patch deployment should be automated and verified.

Linux

Linux dominates servers, cloud workloads, and many enterprise applications. Its security considerations include:

• Package management. Linux distributions use package managers — apt, yum/dnf, zypper, pacman — to install, update, and remove software. Package management is the primary mechanism for patching, and the source of consistency — or inconsistency — across the estate.
• File permissions. Linux uses a permission model based on owner, group, and other — with read, write, and execute permissions. Misconfigured permissions are a common source of exposure.
• Sudo and privilege escalation. Sudo allows users to run commands with elevated privilege — the primary mechanism for just-in-time privilege escalation on Linux. Sudo configuration should be reviewed carefully; misconfigurations can permit unintended privilege escalation.
• Service management. Systemd (or equivalent init systems) manages services. Service configuration — what runs, as which user, with what privileges — is a primary security consideration.
• SSH. SSH is the primary remote access mechanism for Linux systems. SSH security (Lesson 4.3) is essential — disabling password authentication, restricting access, managing keys.
• Kernel hardening. Linux provides extensive kernel hardening options — SELinux, AppArmor, seccomp, and various kernel parameters. These provide strong protection when configured.

macOS

macOS is increasingly common in enterprise environments — particularly for knowledge workers. Its security considerations include:

• System Integrity Protection (SIP). macOS provides SIP — protecting critical system files from modification, even by root. SIP should remain enabled.
• Gatekeeper and notarisation. macOS restricts which applications can run — through Gatekeeper and application notarisation. These controls reduce the risk of malicious software.
• FileVault. macOS full-disk encryption — should be enabled on every managed device.
• MDM integration. macOS devices are typically managed through Mobile Device Management (MDM) — through which configuration, security settings, and application management are applied.
• Managed Apple IDs and enterprise integration. macOS integration with enterprise identity — through managed Apple IDs, federation, or enterprise identity providers — provides the identity context for security controls.

Mobile operating systems

iOS and Android are examined in more detail in Lesson 5.7. At this stage, the key considerations are:

• Application sandboxing. Mobile operating systems sandbox applications — limiting what each application can access. This provides substantial protection against malicious applications.
• Centralised update mechanisms. Updates are delivered through the platform vendor — providing consistent and timely updates.
• MDM and enterprise management. Mobile devices are managed through MDM platforms — through which configuration, security policies, and application management are applied.
• Jailbreaking and rooting. Bypassing the platform's security controls — jailbreaking on iOS, rooting on Android — removes protections and should be detected and prevented in enterprise contexts.

Server and cloud operating systems

Server and cloud operating systems — Linux distributions, Windows Server, and cloud-provider-specific images — share the four pillars with endpoint operating systems, with specific considerations:

• No interactive user. Server operating systems typically do not have interactive users — no one sits at the console. This changes the security model — the concern is not what users do, but what services and applications do.
• Service-focused. Servers run services — web, database, application, management. Each service is attack surface; each requires specific hardening.
• Cloud-provider images. Cloud providers offer pre-built images with their own configurations. These should be hardened — the provider's defaults are not the enterprise's baseline.
• Immutable infrastructure. Modern server patterns emphasise immutable infrastructure — systems are replaced, not modified. Security posture is defined in images; running systems are treated as ephemeral.
• Ephemeral workloads. Container and serverless workloads are ephemeral — they exist briefly and are replaced. Security controls focus on image integrity, orchestration policy, and runtime monitoring.

10 OS security in cloud and virtualised environments

Cloud and virtualised environments change several aspects of OS security. The principles — hardening, privilege management, patching, configuration management — remain the same, but their implementation adapts to the specifics of cloud environments.

What changes in cloud environments

Virtualisation security

Virtualisation introduces specific security considerations:

• Hypervisor security. The hypervisor — the layer that runs and manages virtual machines — is the highest-privilege component of a virtualised environment. Compromise of the hypervisor compromises every VM it manages. Hypervisors require strong hardening, patching, and access controls.
• VM isolation. Virtual machines should be isolated from each other — one VM should not be able to affect another. Hypervisor escapes — techniques that break VM isolation — are a rare but consequential attack.
• VM sprawl. VMs are easy to create; without governance, they accumulate. Unmanaged VMs are unpatched, misconfigured, and frequently forgotten.
• Snapshot and template management. VM snapshots and templates must be managed — old snapshots with vulnerabilities and sensitive data should be removed; templates should be hardened and version-controlled.
• Management plane. Virtualisation management platforms — vCenter, Hyper-V Manager, cloud management planes — should be strongly protected. Compromise of the management plane permits compromise of every managed VM.

Cloud security posture management

In cloud environments, OS security is closely coupled with cloud security posture management (CSPM). CSPM tools continuously assess cloud configuration — including the configuration of cloud instances — against best practice and enterprise policy, detecting misconfigurations and supporting remediation. CSPM is examined further in Lesson 5.5.

11 Common pitfalls

Enterprise OS security programmes fail in predictable ways. Recognising the pitfalls accelerates improvement.

Pitfall 1 — Baseline defined but not deployed

The enterprise has a hardening standard but systems are not configured to it. The gap between documented and actual configuration is where risk accumulates.

Mitigation: Automate baseline deployment. Use configuration management, images, or group policy to apply baselines consistently.

Pitfall 2 — Configuration drift

Systems drift from their baseline over time — through updates, manual changes, or application requirements. Drift is not detected; the baseline becomes aspirational.

Mitigation: Implement continuous compliance monitoring. Detect drift and remediate automatically where feasible.

Pitfall 3 — Patch coverage gaps

Patching most systems while leaving others unpatched — unmanaged endpoints, legacy systems, appliances, cloud instances not integrated with patch management.

Mitigation: Assess patch coverage across the estate. Expand coverage where feasible; apply compensating controls where not.

Pitfall 4 — Excessive privilege

Users provisioned with administrative access for convenience; services running as root or SYSTEM; excessive privilege accumulated over time.

Mitigation: Apply least privilege systematically. Review privilege periodically. Use just-in-time access for administrative work.

Pitfall 5 — Weak authentication for privileged accounts

Administrative accounts protected only by passwords — vulnerable to credential theft, phishing, and reuse.

Mitigation: Require strong authentication — multi-factor, preferably phishing-resistant — for all privileged accounts.

Pitfall 6 — Legacy protocols retained for compatibility

TLS 1.0, SMBv1, NTLMv1, and other legacy protocols retained because some system requires them — exposing the whole estate to their weaknesses.

Mitigation: Identify what requires legacy protocols; address through upgrades, isolation, or compensating controls. Disable legacy protocols where feasible.

Pitfall 7 — Unmanaged service accounts

Service accounts whose credentials never rotate, whose permissions are never reviewed, and whose existence is frequently forgotten.

Mitigation: Inventory service accounts. Document their purpose. Vault and rotate credentials. Review permissions.

Pitfall 8 — Insufficient host logging and monitoring

Systems running with default logging — missing critical events, not centralised, not monitored. Detection is limited; investigation is difficult.

Mitigation: Configure logging to capture security-relevant events. Centralise logs. Monitor for anomalies.

Pitfall 9 — Cloud responsibility misunderstanding

Assuming that cloud providers patch everything, or that the customer is responsible for everything. Misunderstanding the shared responsibility model leads to gaps.

Mitigation: Understand the shared responsibility model for each cloud service. Implement controls for the layers the enterprise is responsible for.

Pitfall 10 — Under-investment in OS security

Investing heavily in advanced controls — Zero Trust, XDR, identity-aware proxies — while neglecting OS security fundamentals — patching, hardening, privilege management.

Mitigation: Recognise that OS security is foundational. Advanced controls depend on the OS; they cannot compensate for foundational weaknesses.

12 Key concepts

The terms below are used throughout Unit 5. Capture them in your own words as you work through the lesson.

Operating system security

The discipline of securing the operating system — the foundation layer on which applications, data, and security controls depend. Includes hardening, privilege management, patch management, and configuration management.

Attack surface

The set of all points through which an adversary could attempt to access, extract data from, or disrupt a system. Reduced through hardening.

Hardening

The process of reducing the attack surface of an operating system to the minimum required for its function — removing unnecessary software, disabling unnecessary services, closing unnecessary ports, and applying secure configuration.

Hardening baseline

The defined secure configuration for a system or class of systems — derived from benchmarks, adapted to the enterprise's requirements, and deployed through automation.

CIS Benchmarks

Published hardening guidance from the Center for Internet Security — the most widely used hardening benchmarks for operating systems and applications.

STIG

Security Technical Implementation Guide — detailed configuration guidance from the US Defense Information Systems Agency. Strict and prescriptive; frequently adapted for enterprise use.

Privilege management

The discipline of controlling who and what has elevated privilege on operating systems — and limiting the consequence when privilege is misused or compromised.

Least privilege

The principle that every subject — user, service, or process — should run with the minimum privilege required for its function.

Just-in-time access

The practice of granting administrative access on demand, for a defined period, rather than holding it continuously. Reduces standing privilege.

Service account

An account under which a service runs. Frequently provisioned with excessive privilege; frequently shared; frequently with credentials that never rotate.

Patch management

The discipline of applying software updates — security patches, feature updates, and configuration changes — to operating systems and the software they run.

Patch lifecycle

The stages through which patches pass: discovery, assessment, prioritisation, testing, deployment, verification, and reporting.

Compensating control

A control used in place of a preferred control when the preferred control is not feasible. Used when patching cannot be performed — segmentation, monitoring, and access restrictions compensate for unpatched systems.

Configuration management

The discipline of maintaining operating systems in a known, secure, and consistent state — through baseline definition, automated deployment, and continuous compliance monitoring.

Configuration baseline

The defined secure configuration for a system or class of systems. Baselines are derived from benchmarks, adapted to enterprise requirements, and deployed automatically.

Configuration drift

The tendency for system configuration to change over time from the intended state — through updates, manual changes, or application requirements. Drift should be detected and remediated.

Infrastructure as code

Defining infrastructure — servers, configurations, networking — in code, so that it can be versioned, reviewed, tested, and deployed consistently.

Desired state configuration

Defining the desired state of each system and ensuring systems conform to that state. Supported by configuration management tools.

Host-based monitoring

Detection capability on individual systems — process visibility, file activity, authentication events, configuration changes, and integrity monitoring.

File integrity monitoring (FIM)

Monitoring files for unauthorised changes — detecting modification of system files, configuration, and content.

Audit logging

Detailed logging of security-relevant events — authentication, privilege use, configuration changes — for detection and forensic analysis.

Golden image

A predefined, hardened, version-controlled image from which systems are deployed. Used in cloud and virtualised environments to provide consistency and eliminate drift.

Immutable infrastructure

The practice of replacing systems rather than modifying them — running systems are ephemeral, and security posture is defined in the image.

Shared responsibility model

The division of security responsibilities between a cloud provider and its customer. The provider secures the underlying platform; the customer secures what they run on it.

13 Activities

The activities below help you test your understanding and prepare for the unit discussion and Assignment 2. They are not graded, but completing them will substantially improve your preparation.

14 Self-check

Answer the questions below before moving to Lesson 5.2. If you cannot answer a question confidently, revisit the corresponding section.

15 Summary

This lesson has examined operating system security — the foundation of every other control in the enterprise. The essential points are:

• OS security is foundational. The operating system enforces security policy, is ubiquitous, is a primary target, and supports every control above it. Compromise of the OS exposes everything.
• The OS attack surface is broad. Kernel, services, network interfaces, accounts, privileged programs, filesystem permissions, configuration, software, management interfaces, and boot/firmware.
• Hardening reduces the attack surface. Removing unnecessary software, services, ports, and accounts; applying secure configuration; reducing privilege; hardening the boot process. Informed by published benchmarks (CIS, NIST, STIGs).
• Privilege management controls who has elevated access. Least privilege, just-in-time access, separation of duties, and privileged access management. The objective of most enterprise attacks.
• Patch management addresses known vulnerabilities. Discovery, assessment, prioritisation, testing, deployment, verification, and reporting. Automation is essential at scale. Coverage gaps are where risk accumulates.
• Configuration management maintains consistency. Baseline definition, automated deployment, continuous compliance monitoring, and drift detection. Ties the other pillars into a coherent programme.
• Host-based monitoring is the detection counterpart. Process visibility, file activity, authentication events, configuration changes, network connections, and integrity monitoring. Centralised for correlation and retention.
• Platform-specific considerations vary. Windows (Active Directory, Group Policy, Defender); Linux (package management, permissions, sudo, SSH, kernel hardening); macOS (SIP, Gatekeeper, FileVault, MDM); mobile (sandboxing, MDM); server and cloud platforms (shared responsibility, immutable infrastructure, ephemeral workloads).
• Cloud and virtualised environments change the implementation. Shared responsibility, golden images, cloud-native management tools, scale and ephemerality, hypervisor security, and CSPM.
• Common pitfalls recur. Baseline defined but not deployed; configuration drift; patch coverage gaps; excessive privilege; weak authentication for privileged accounts; legacy protocols retained; unmanaged service accounts; insufficient logging; cloud responsibility misunderstanding; under-investment in OS security.

These ideas prepare for Lesson 5.2, which examines endpoint security — the controls that protect the devices through which users access enterprise resources, building on the OS foundation established in this lesson.