Navigation

How Can We Help?

Section 20 – Hardening

Created On
Last Updated On
byeditor
Print
You are here:
< All Topics

Section 20 – Hardening

Below is a disciplined, no-nonsense study primer on “Hardening” as typically covered in Section 20 of a security curriculum. It is organized into logical subsections, each outlining core principles, concrete steps, and key considerations.

1. Definition & Purpose

Hardening refers to the systematic process of reducing a system’s attack surface by eliminating unnecessary functions, tightening configurations, and enforcing security controls. In essence, you convert a “comfortable default” into a “lock-down fortress” (minus the moat). The goal is straightforward: make it as difficult as possible for an adversary to find and exploit weaknesses.

2. Risk-Based Approach

  1. Asset Inventory

    • Identify all systems, applications, databases and network devices within scope.

    • Classify by criticality (e.g., “Crown-jewels” systems vs. non-critical endpoints).

  2. Threat Modeling & Impact Analysis

    • For each asset, determine plausible threat actors (insiders, cybercriminals, APTs).

    • Assess potential impact: data confidentiality, integrity, availability.

  3. Prioritize Controls

    • Focus hardening efforts on high-impact/high-probability risks first (e.g., Internet-facing servers).

    • Avoid the trap of “hardening everything equally” (you’ll end up with expensive busy work and minimal return).

3. Operating System Hardening

3.1 Common Principles

  • Remove or Disable Unnecessary Components

    • Uninstall unused packages, disable default demo or sample services (e.g., FTP, Telnet).

    • Example: On Linux, run yum
      remove telnet telnet-server       (or apt
      purge telnet      ).

  • Patch & Patch Management

    • Apply vendor security updates promptly; establish a routine (monthly at minimum, more often for critical CVEs).

    • Use automated patch-management tools (WSUS/SCCM for Windows, Satellite/Spacewalk for Red Hat, or apt unattended‐upgrades for Debian/Ubuntu).

  • Configuring Secure Defaults

    • Employ vendor or community benchmarks (CIS Benchmarks, DISA STIGs) as starting points—tweaking only where necessary.

    • Example: Disable root SSH login (PermitRootLogin no), enforce PasswordAuthentication no in /etc/ssh/sshd_config.

  • File-System & Partitioning Controls

    • Mount sensitive directories (e.g., /var, /tmp) with noexec, nosuid and nodev where feasible.

    • Enforce minimal permissions (e.g., chmod 700 ~/.ssh).

3.2 Windows-Specific Steps

  • Remove or Disable Legacy Services

    • Disable SMBv1 (Set-SMBServerConfiguration
      –EnableSMB1Protocol $false      ).

    • Turn off NetBIOS over TCP/IP unless strictly required.

  • Local Security Policy Adjustments

    • Enforce password complexity and expiration.

    • Disable unnecessary Windows features (e.g., Windows Media Player, Internet Explorer).

  • Windows Firewall & Host-Based Controls

    • Create inbound/outbound rules that deny by default, then explicitly allow minimal required ports (e.g., only port 135 for RPC if RDP is in use).

    • Enable Windows Defender or an approved EDR solution with signature and behavioral detection.

4. Network & Perimeter Hardening

  • Firewalls and ACLs

    • Enforce a “deny by default” stance: only permit ports/protocols strictly required (e.g., HTTP/HTTPS to the web tier, SSH only from a jump box’s management network).

    • Ensure egress filtering so that compromised hosts can’t phone home to arbitrary C&C servers.

  • Segmentation & Zoning

    • Separate development, testing and production networks.

    • Place DMZ systems in their own VLANs/subnets; restrict lateral movement with internal firewalls or VLAN ACLs.

  • IDS/IPS Deployment

    • Deploy IDS/IPS sensors inline (for high-risk subnets) or passive mode (monitoring).

    • Regularly update signatures and tune rules to reduce false positives—an IDS that triggers 500 false alarms/day is effectively ignored.

  • Secure Remote Access

    • If remote management is required, conduct it over dedicated management VLANs, enforce MFA, and restrict to bastion/jump hosts only.

5. Application & Service Hardening

5.1 Web Servers (e.g., Apache, NGINX, IIS)

  • Disable Default Pages and Modules

    • On Apache: comment out unneeded LoadModule lines in httpd.conf.

    • Remove sample applications (/var/www/html/README.html).

  • Enforce Secure Cipher Suites

    • Configure TLS to allow only strong ciphers (e.g., TLS 1.2+ with AES-GCM, ECDHE key exchange). Disable SSL v2/v3.

  • Tighten File Permissions & Ownership

    • Run web-server processes under non-privileged users (e.g., www-data or apache).

    • Ensure .htaccess or equivalent only writable by the admin, not by application‐level users.

5.2 Database Servers (e.g., MySQL, MSSQL, Oracle)

  • Remove Demo Databases

    • Drop or disable sample schemas (e.g., MySQL’s test database).

  • Enforce Least Privilege for Accounts

    • Create distinct user accounts for each application, granting only the minimal privileges needed (no GRANT ALL on *.*).

    • Disable or rename default accounts (e.g., SA in MSSQL, root in MySQL).

  • Harden Network Listeners

    • Bind only to internal interfaces (bind_address = 127.0.0.1 if no remote connections needed).

    • Enforce SSL/TLS for client connections where supported.

6. Patch & Vulnerability Management

  • Automated Scanning

    • Schedule regular (weekly/monthly) vulnerability scans with tools such as Nessus, Qualys or OpenVAS.

  • Triaging & Remediation

    • Assign a risk rating to each identified vulnerability (e.g., CVSS score, exploit maturity).

    • Patch or mitigate (e.g., apply a virtual patch via WAF) high-risk issues within 30 days, critical within 48–72 hours.

  • Validation

    • After patching, rescan to confirm the absence of the vulnerability (never assume it’s gone because “the patch was applied”).

7. Configuration Management & Baselines

  • Establish Secure Baselines

    • Develop a “golden image” per OS version or server role (web, database, application).

    • Incorporate CIS Benchmarks or DISA STIG rules into baseline.

  • Version Control & Change Control

    • Store configuration scripts (Ansible playbooks, Chef recipes, Puppet manifests) in a VCS (Git), with code reviews for changes.

    • Maintain an auditable change-request process for configuration modifications.

  • Drift Monitoring

    • Use tools (e.g., OpenSCAP, Chef’s InSpec) to detect when a system deviates from its approved baseline.

    • Automate remediations where possible, or flag deviations for manual review.

8. Principle of Least Privilege & Account Management

  • User & Service Accounts

    • Ensure each service runs under a unique, least-privileged account. Avoid running everything as root or Administrator.

    • Implement fine-grained Access Control Lists (ACLs) on both file systems and applications.

  • Privilege Elevation Controls

    • Use a vetted Privileged Access Management (PAM) solution for any “just-in-time” or temporary administrative elevation.

    • Require MFA for all privilege escalations or access to sensitive systems.

  • Account Lifecycle

    • Enforce regular reviews for orphaned accounts (inactive > 30 days).

    • Implement timely removal of user access upon role changes or termination.

9. Service & Protocol Minimization

  • Minimize Attack Surface

    • Disable or uninstall any service or daemon that is not essential (e.g., cups if no printing required).

    • Close unused TCP/UDP ports; use netstat –tulpn or ss
      -tulpn       to audit active listeners.

  • Secure Protocol Usage

    • Replace insecure protocols (e.g., Telnet, FTP, RSH) with secure equivalents (SSH, SFTP, Kerberized NFS).

    • Enforce protocol hardening: configure SSH to use only protocol 2, disable X11 forwarding unless explicitly needed.

10. Auditing, Logging & Monitoring

  • Centralized Log Aggregation

    • Forward system logs (syslog/journald), application logs and firewall logs to a central SIEM (e.g., Splunk, ELK Stack, QRadar).

    • Ensure logs are immutable (write-once) or protected with WORM storage.

  • Audit Policy Configuration

    • On Windows: enable “Advanced Audit Policy Configuration” to log account management, privilege usage, object access, process creation, etc.

    • On Linux: configure auditd rules to watch sensitive files (/etc/shadow, /etc/sudoers) and critical binaries (/usr/bin/sudo).

  • Alerting & Response

    • Define actionable alerts (e.g., repeated failed SSH logins, creation of new privileged accounts).

    • Establish a documented incident response workflow: who gets paged, how tickets are escalated, timelines.

11. Virtualization & Cloud Hardening

11.1 Hypervisor & Virtual Machine (VM) Hardening

  • Hypervisor Configuration

    • Disable unnecessary features or modules (e.g., USB passthrough if not needed).

    • Enforce strong credentials and MFA for hypervisor management consoles (vCenter, Hyper-V Manager).

  • VM Templates & Snapshots

    • Maintain hardened golden VM templates; regenerate periodically to include latest patches.

    • Use snapshots sparingly—long-standing snapshots can degrade performance and complicate patching.

11.2 Cloud-Native Controls

  • IAM & Role-Based Access

    • Define least-privilege IAM roles; avoid use of long-lived root/owner credentials.

    • Enforce MFA for console access, restrict API scopes to only necessary permissions.

  • Secure Networking (VPC/VNet)

    • Leverage security groups or network security groups (NSGs) to restrict inter-subnet traffic.

    • Use private subnets for sensitive workloads; avoid public IPs unless absolutely required.

  • Cloud Configuration Benchmarks

    • Follow CIS Cloud Provider Benchmarks (AWS, Azure, GCP) or vendor-supplied best practices.

    • Enable logging services (CloudTrail, Azure Monitor, Cloud Audit Logs) and aggregate to SIEM.

12. Verification & Testing

  • Vulnerability Scanning

    • As noted, schedule scans; pay special attention to CVEs affecting hardening controls (e.g., misconfigurations).

  • Configuration Audits

    • Periodically run automated compliance checks against CIS or STIG profiles (e.g., using OpenSCAP on Linux, SCAP-Workbench).

  • Penetration Testing & Red-Team Exercises

    • Conduct at least annual pen tests focusing on configuration weaknesses (e.g., default credentials, open ports).

    • Red-team exercises should validate that hardening measures hold up under realistic adversary tactics.

13. Ongoing Maintenance & Governance

  • Policy Review Cadence

    • Revisit system hardening policies quarterly or after any major architectural change (e.g., moving from on-prem to cloud).

  • Change Management

    • Any deviation from the approved baseline must go through change control: document why an exception is needed, who approved it, and when it will be revisited.

  • Metrics & Reporting

    • Track key performance indicators (KPIs): percentage of systems compliant with baseline, mean time to patch critical vulnerabilities, number of successful drift corrections.

    • Report metrics to senior leadership to ensure continued funding and priority.

14. Dry Reality Check

“Implementing hardening checklists is not the same as security. If you blindly apply controls without understanding your environment, you’ll either break critical business functions or sleep poorly, worrying you’ve missed something. Exception handling and continuous validation are non-negotiable.”

In Summary

Hardening is not a one-time checkbox exercise—it is a disciplined, ongoing effort that spans multiple layers (OS, network, application, cloud), leverages community-recognized benchmarks, and demands continuous verification. By adopting a risk-based approach, enforcing least privilege, minimizing attack surface, and instituting rigorous auditing, you significantly reduce the odds that an adversary can find an easy way in.

Keep the focus on “secure by default,” automate where possible, and verify relentlessly. Any sloppiness in baseline maintenance or lapse in patch-management discipline will undo months of hardening work—so treat this as a core, perpetual operation rather than a “project.”

Tags:
Table of Contents