Server Hardening Policy - Examples and Tips
Every organization should have a hardened Windows build standard, a hardened Linux build standard, a hardened SQL Server / Oracle database build standard, a hardened firewall standard etc. However, determining what is an appropriate server hardening policy for your environment will require detailed research of hardening checklists and then an understanding of how this should be applied to your operating systems and applications.
All governance, regulatory and compliance standards such as NIST SP 800-53, NIST 800-171, SOX, NERC CIP, ISO27001, PCI DSS, DISA STIG and HIPAA all call for strong cyber security defenses, with a hardened build standard at the core. This is maintained using file integrity monitoring to highlight any significant changes or 'drift'.
Any server deployed in its default state will naturally be lacking in even basic security defenses. This leaves it vulnerable to compromise. In order to mitigate potential exploits it is vital that servers are hardened:
Getting access to a hardening checklist or server hardening policy is easy enough. For example, the Center for Internet Security provides the CIS hardening checklists, Microsoft and Cisco produce their own checklists for Windows and Cisco ASA and Cisco routers, and the National Vulnerability Database hosted by NIST provides checklists for a wide range of Linux, Unix, Windows and firewall devices. NIST also provides the National Checklist Program Repository, based on the SCAP and OVAL standards.
However, any default checklist must be applied within the context of your server's operation – what is its role? For example, if it is internet-facing then it will need to be substantially more hardened with respect to access control than if it is an internal database server behind a perimeter and internal firewall. Once you have established your hardened server policy and have applied the various security best practice checklists to your hardened server build, you will now need to regularly audit all servers and devices within your estate for compliance with the build standard.
Ideally, the hardened build standard for your server hardening policy will be monitored continuously, with any drift in configuration settings being reported. In conjunction with your change management process, changes reported can be assessed, approved and either remediated or promoted to the configuration baseline. NNT Change Tracker provides Intelligent Change Control, which means that changes only need to be approved once, for one server only, for any other occurrences of the same change pattern to be automatically approved. This intelligent learning approach removes the biggest problem with most FIM and SIEM systems in that 'change noise' can easily become overwhelming.
In any large estate, commercial systems like NNT Change Tracker or Tripwire® Enterprise provide automated means of auditing and scoring compliance with your chosen server hardening policy.
The CIS Benchmark Checklists are an ideal reference source because the configuration hardening recommendations are consensus base.
Applying the hardened build settings can also be automated using NNT Threat Mitigation Kits, comprising the appropriate hardened build templates for deployment using Group Policy or Puppet.
To try examples of NNT Threat Mitigation Kits, request a trial system here
Prevention of security breaches is the best approach to data security. By locking out configuration vulnerabilities through hardening measures, servers can be rendered secure and attack-proof.
Using file integrity monitoring not only provides an initial audit and compliance score for all servers against standardized hardening checklists but ensures all platforms remain securely configured at all times.