Systems and Network Hardening: Frameworks and Practice

Hardening (also known as bastioning or endurecimiento in Spanish) is the process of reducing the attack surface of a system or network by configuring it to a known secure state: disabling unnecessary services, applying secure-by-default configurations, removing extra users, restricting permissions, enabling logging and integrity verification. It isn't a tool or a product: it's a discipline that applies proven configurations (from frameworks like CIS Benchmarks or NIST) over the components running operations. Well executed, it closes more vulnerabilities in one move than any antivirus or EDR, because it removes the opportunity before the signature even appears. This piece explains what systems and network hardening is, the reference frameworks used, how it gets applied in practice and the common mistakes that reduce its effectiveness.

What hardening is: technical definition

Hardening is the systematic application of a set of secure configurations over a system or component so it gets exposed only to what the business needs, not what comes from the factory. Operating systems, services, databases, firewalls, routers, cloud environments and containers ship from the vendor with configurations designed to work, not to be secure. Active default accounts, old protocols enabled, visible information banners, minimal logging: every one of those adds functionality and, at the same time, opportunities for the attacker.

Hardening flips that logic: it starts from the opposite principle (everything off except what's strictly necessary) and leaves only what has documented operational justification.

Three words often get mixed up:

• Hardening / bastioning / endurecimiento: used interchangeably.
• Securisation: broader term including hardening, identity management, patching and other disciplines.
• Hardening as code: hardening applied through code (Ansible, Chef, Puppet, IaC templates) instead of manually.

Operating system hardening

It's the most mature area and where the most complete frameworks exist. Applied on Windows, Linux, macOS, embedded systems and, increasingly, container images.

Typical actions:

• Accounts and authentication: remove default accounts, password policy, MFA on privileged accounts, separation between administrative and day-to-day accounts.
• Unnecessary services: disable anything unused (telnet, FTP, SMBv1, old remote services, NetBIOS).
• Secure protocols: TLS 1.2/1.3 mandatory, disable old SSL, strong ciphers.
• Auditing and logging: enable detailed auditing, configure forwarding to SIEM, log critical events (failed attempts, privilege changes, access to sensitive resources).
• Filesystem permissions: restrict ACLs, remove world-writable permissions, control access to sensitive binaries.
• Kernel hardening: restricted modules, ASLR, capability control, sandboxing (AppArmor, SELinux, gVisor).
• Patching: automated patch policy, defined maintenance windows.

Common reference frameworks: CIS Benchmarks (Center for Internet Security), STIG (Security Technical Implementation Guides from DoD), NIST SP 800-53/800-171 general control catalogue, Microsoft Security Baselines for Windows and M365.

Network hardening

Applied over the components that move traffic: routers, switches, firewalls, access points, load balancers, VPN concentrators.

Typical actions:

• Remove default configuration: passwords, SNMP communities, banners.
• Restrict management access: separated management planes (out-of-band), ACLs over admin interfaces, mandatory MFA.
• Secure protocols: SSH version 2, HTTPS, SNMPv3 with authentication.
• Segmentation: VLANs, microsegmentation, separation between production, management, OT and user networks.
• Secure routing: anti-spoofing filters, BCP-38, BGP validation with RPKI where applicable.
• Telemetry: NetFlow/IPFIX, firewall logs, packet capture at the perimeter, integration with SIEM.
• Updates: firmware up to date, vendor advisory monitoring.

Network hardening complements segmentation: a well-applied microsegmentation drastically reduces the lateral movement we see in incident response.

Cloud hardening

Cloud changes the nature of hardening. It's no longer just about configuring machines, but about configuring managed services (storage, databases, identity, networks) the provider exposes.

Typical actions in AWS, Azure and GCP:

• Minimal IAM: policies that meet the least privilege principle, no *:* permissions, no users with static credentials where alternatives exist (roles, workload identity).
• Default encryption: KMS, managed keys, encryption at rest and in transit across every service that supports it.
• Logging enabled: CloudTrail, Azure Activity Log, GCP Audit Log with secure destination and retention.
• Network: well-designed VPC, restrictive security groups/NSGs, no 0.0.0.0/0 rules on critical ports.
• Storage: no public buckets, Object Lock / Blob Immutability on backups.
• Databases: secure parameters (encryption, TLS connections, IAM authentication where possible), active backups and point-in-time recovery.
• SaaS services: tenant configuration per the provider's baselines (Microsoft 365 Secure Score, Google Workspace recommendations).

CSPM (Cloud Security Posture Management) platforms automate much of this verification: they compare current configuration with hardening baselines and report deviations. Detail of the responsibility model in IaaS, PaaS and SaaS.

Reference frameworks for hardening

You don't have to invent the configurations: there are public, well-maintained frameworks. The most-used:

• CIS Benchmarks: probably the most widespread in the private sector. Covers practically everything (Windows, Linux, macOS, AWS, Azure, GCP, Kubernetes, Docker, databases, browsers). Available in L1 levels (controls compatible with general use) and L2 (more restrictive, designed for sensitive environments).
• NIST SP 800-53 / SP 800-171: NIST general frameworks. SP 800-53 is the broad control catalogue serving as base for FedRAMP; SP 800-171 covers controlled unclassified information (CUI). The former SP 800-123 on server security was retired by NIST; it's better to rely on SP 800-53 directly.
• STIG (DISA): US Department of Defense requirements. Stricter than CIS L2; used in defence and critical environments.
• Microsoft Security Baselines: specific for Windows, Microsoft 365, Azure and Microsoft Defender. Ship as ready-to-apply GPOs.
• Spain's National Security Framework (ENS): in Spain, ENS requires secure configurations and provides profiles by level (Basic, Medium, High). Detail in ENS guide.
• ISO/IEC 27001 Annex A: although the standard doesn't require a specific baseline, several Annex A controls (covered in ISO 27001 explained) imply hardening: A.8.9 (configuration management), A.8.20 (network security), A.8.22 (segregation), A.8.27 (secure architecture).
• CCN-STIC from the Spanish Centro Criptológico Nacional: technical guides used in the public sector.

In practice, companies combine frameworks: CIS Benchmarks as operational baseline, ENS or ISO 27001 as regulatory requirement and, depending on sector, STIG or CCN-STIC on the most critical assets.

How hardening gets applied in practice

Four well-defined phases in a serious process.

1. Asset inventory and classification

You can't harden what you don't know. Clear inventory of servers, network devices, cloud services, identities. Classification by criticality and exposure.

2. Baseline selection

Decide which framework applies to each asset type: CIS L1 for general servers, CIS L2 or STIG for critical servers, specific baselines for cloud and SaaS, ENS for assets within regulatory scope.

3. Application: manual, assisted or as code

• Manual: for small environments or legacy systems. Slow and error-prone.
• Tool-assisted: Microsoft GPO, Ansible, Chef, hardening scripts (OpenSCAP, Lynis).
• Hardening as Code: the modern option. Configurations expressed in Ansible, Terraform or declarative templates that get applied consistently, versioned in Git and audited with CI/CD. It's the way to maintain hardening at scale without it eroding over time.

4. Continuous verification

Without recurring verification, hardening erodes: ad-hoc changes, temporary exceptions that stay, patches that reactivate services. Tools like OpenSCAP, Lynis, Wazuh (covered in Wazuh SIEM), Microsoft Defender for Cloud and CSPM platforms verify the real state against the baseline and alert on deviations.

Concrete advantages of well-done hardening

Three measurable benefits show up in organisations that get the discipline right.

1. Measurable incident reduction

Well-hardened systems resist entire classes of attacks: old protocols don't accept connections, default accounts don't allow login, useless services don't expose ports. Incident response reports show that most compromises rest on default or eroded configurations, not on sophisticated zero-days.

2. Better detection and response

A hardened system logs more relevant events and less noise. The SOC works on alerts with context, not on incomplete logs. MTTD drops because anomalies stand out more against a clean baseline.

3. Simpler regulatory compliance

ENS, NIS2, ISO 27001, DORA and PCI DSS require secure configurations. Having an applied and verified baseline turns audit evidence into something trivial: the CSPM or SCAP report is the proof.

Common hardening mistakes

Repeated patterns in audits:

1. Baseline applied once and forgotten. Without periodic verification, the system drifts back to an insecure state in months.
2. Temporary exceptions that become permanent. A service gets enabled "just for a week" and nobody disables it.
3. Hardening only servers, ignoring network, cloud and SaaS. The chain breaks at the least-covered link.
4. Applying L2 or STIG without testing. Very restrictive configurations can break legitimate applications; the right path is L1 tested and scaling up progressively.
5. Not keeping an exception inventory. Exceptions always exist (legacy systems, vendor compatibility), but they must be documented, justified, with an owner and a review date.
6. Not integrating with SIEM. Hardening leaves traces (logs, audit events) that lose value if they don't reach an analytical platform.
7. Confusing patching with hardening. They're complementary but distinct disciplines: a patched server can have insecure configurations; a hardened server without patches is still vulnerable.

Frequently asked questions

What is system hardening?

System hardening is the process of configuring a system to a known secure state, starting from the vendor's default state: disabling unnecessary services, removing default accounts and credentials, applying restrictive permissions, enabling logging, enabling secure protocols. The goal is to reduce attack surface by leaving exposed only what has operational justification.

What's the difference between hardening and patching?

Patching fixes known vulnerabilities by applying vendor updates. Hardening removes insecure configurations even when there's no published vulnerability (default accounts, obsolete services enabled, old protocols). They're complementary disciplines: a patched but misconfigured system is still vulnerable; a hardened but unpatched system also is. Both are mandatory in any serious framework (ISO 27001, ENS, NIS2).

What are CIS Benchmarks?

CIS Benchmarks are secure configuration guides published by the Center for Internet Security, a US non-profit organisation. They cover practically everything that can be configured: operating systems, databases, browsers, cloud, containers, commercial products. Each benchmark recommends specific configurations with technical justification and level (L1 for general use, L2 for sensitive environments). They're the private sector de facto standard.

How does hardening apply in cloud?

In cloud, hardening translates into configuring managed services correctly: IAM with least privilege, default encryption, logs enabled, no public buckets or databases, no permissive network rules, baselines from the provider's Secure Score. Applied with Infrastructure as Code (Terraform, CloudFormation) and verified with CSPM (Microsoft Defender for Cloud, AWS Security Hub, Wiz, Prisma Cloud). Detail of the shared responsibility model in IaaS, PaaS and SaaS.

Is hardening mandatory to comply with NIS2 or ENS?

Yes, in both cases, although no regulation literally says "apply CIS L1". ENS requires documented secure configurations with profiles by level (Basic/Medium/High). NIS2 requires technical and organisational measures in its article 21, where secure configuration appears explicitly. ISO 27001 Annex A includes several controls that imply hardening (A.8.9, A.8.20, A.8.22, A.8.27). In every case, the auditor asks to see the applied baseline and the verification evidence.

How is hardening maintained over time?

With continuous automated verification. Tools like OpenSCAP, Lynis, Wazuh with configuration modules, CSPM platforms for cloud and DSC/GPO policies on Windows compare the real state with the baseline periodically and alert on deviations. Exception management (justified, documented, with owner and review date) closes the loop.

Does an EDR work without hardened systems?

It does, but performs much worse. An unhardened system generates constant low-value event noise the EDR and SIEM have to filter. On a hardened system, anomalies stand out, false positives drop and response gets faster. The practical rule: invest first in basic hardening (patches + CIS L1) before buying the most expensive EDR on the market.

Related resources

• What is SIEM
• What is EDR
• What is Wazuh: open source SIEM
• IaaS, PaaS and SaaS: security model
• ENS Spain certification guide
• ISO 27001 explained
• NIS2 Spain: how to comply

---

Does your organisation have servers, network devices and cloud environments with security baselines unapplied or unverified? At Secra we support end-to-end hardening: baseline definition, application via hardening as code, SIEM integration and continuous verification with CSPM and SCAP. Tell us about your current environment and we'll review where it's worth starting.