GS&F IS Guidance: Security Hardening

Security Hardening
Target Audience for this guidance
Technology Service Providers (TSPs): IT managers responsible for TSP policies, standards and processes Project and programme managers and teams System designers and software development teams IT Operations teams Information Security Functions (ISFs) Contract owners / contract managers who contract services, which include IT services, to third parties Business owners who commission or own any IT systems

What is included in this guidance

What is the objective of this guidance Security Hardening Who should do this When this should be done What needs to be done Where hardening should be applied What should be included in hardening

Management of a hardening programme References and additional guidance If you need more information

Procedural Guidelines Section 5 Communications and Operations Security, specifically 5.1.4c Section 6 Access Control, specifically 6.5.3g Section 7 Systems Acquisition, Development and Maintenance

What is the objective of this guidance

The objective of this guidance is to ensure that systems are developed with good security so that the risks to Group Information and its supporting systems and infrastructure are controlled. It does this by explaining the concept of security hardening and its importance, and providing additional information to support the understanding of control statements 5.1.4c and 6.5.3g in the GS&F Information Security Procedural Guidelines. It links this to relevant parts of sections 5, 6 and 7, of the Guidelines, and other GS&F IS Guidance available. It also defines an approach for addressing the Procedural Guideline requirements, explaining where security hardening should be applied, what should be included, and how it should be managed. This should assist TSPs develop and manage an effective hardening programme. It is acknowledged that this approach may not represent an optimum solution for all Divisions and Business Units in the Group, and there may be other valid approaches. However, where an alternative approach is adopted it must ensure compliance with Procedural Guidelines.

Version 1.0

Page 1 of 6

GS&F IS Guidance: Security Hardening

Security Hardening
Security hardening is the process of configuring a computer system in a secure way so that it is hardened and resistant against attack. The purpose is to eliminate as many security vulnerabilities as possible, so reducing the opportunities for attack. Most Out of the Box computer software and systems have a very weak security configuration and default settings to make them easy to use. Before they can be deployed into production they must be security hardened. Security hardening provides an additional layer of protection for services based on the security principle of defence-in-depth. Hardening can make a system less vulnerable to compromise in an attack. It can also limit the amount of damage an attacker can do, and be the last line of defence in the event of a security compromise. For example, if a malicious user is able to penetrate the Groups perimeter defences, a hardened server can provide the final layer of security for information assets on internal systems. It is important to note that hardening is not a panacea for security. It is just another layer in a good security model. Any system that is accessible on a network and running services can potentially be attacked. It then only takes a single vulnerability to successfully breach the security and compromise the information. Security hardening should be a key component in securing IT systems.

Who should do this

Technology Service Providers (TSPs): IT managers responsible for TSP policies, standards and processes Project and programme managers and teams System designers and software development teams IT Operations teams Information Security Functions (ISFs) Contract owners / contract managers who contract services, which include IT services, to third parties Business owners who commission or own any IT systems

When should this be done

Security hardening should be completed and validated prior to any system going into production and during any major change. It should be validated during periodic checks and reviews. These requirements should be incorporated in all applicable IT policies, processes and standards when they are being drafted. In addition, they must also be addressed: When a new IT architecture and design standard is being established. Upon rollout of any new operating system or version. Upon deployment of any new middleware or versions. If new software (off the shelf or custom) or equipment is selected. If an IT system and project is not following a standard approved architecture and build.

What needs to be done

Security hardening processes and associated guides and build standards must be implemented by TSPs in the Group, and when IT services are outsourced to third party providers. This should include a security hardening programme/process and
Version 1.0 Page 2 of 6

GS&F IS Guidance: Security Hardening

hardening guides to support all systems within their environments. The hardening guides should be updated as new information is received about new vulnerabilities and threats (please see GS&F IS Guidance on Vulnerability Management for more information).

Where hardening should be applied

Hardening should be applied to base system builds which are to be deployed into production. This should include operating systems and any middleware such as databases. It is recommended that most applications are also hardened, although the extent that this is required is likely to vary. Hardening is particularly important for all computers and devices that are public facing, and for security and network devices. The hardening standards that are applied to these should be particularly rigorous. Guides and processes for hardening should include the following types of system: File Servers Print Servers Application Servers Email Servers Web Servers Authentication Servers Network Devices (Switches, Routers, Load balancers) Security Devices (Firewalls, IDS, IPS) Workstations Mobile Computing Devices (Blackberry, PDAs, Cell Phones) Middleware such as databases Applications Systems in development and test environments do not normally need to be security hardened, provided they are properly segregated from production (please see GS&F IS Guidance on Development, Test and Production Facilities). However, it may be beneficial to harden these as well. It is recommended that systems used in test have hardening applied to ease their deployment. Otherwise it may well be found that systems that have functioned perfectly in test suddenly fail to work when moved to pre-production or production. Hardening should also always be applied to like-live systems.

What should be included in hardening

One of the first things to consider when developing hardening guides are the different roles that servers and other types of computer equipment will have. The hardening criteria (or policy) that are applied should depend on the role. One of the reasons for this is that during hardening all services and software that are not required are disabled or removed, and what is required will obviously depend on the role. For example an Email server would not normally require any Web services. Hardening therefore needs to consider roles, and a generic hardening standard which applies the same criteria for all types of server will not provide a sufficient level of security. Typical roles used in hardening include (please note this is not a complete list): Gateway Firewall Application Firewall Core switch
Version 1.0 Page 3 of 6

GS&F IS Guidance: Security Hardening

Access switch Web server, Database server Mail server DNS server File server FTP server DHCP server Application server or other limited purpose servers, for example: web application server, like Websphere SAP/R3 server

Developing System hardening guides by roles adds specific hardening based on the service/s the system is running. It removes unnecessary services and vulnerabilities by only allowing the services that are necessary for the system based on function and role. Security hardening will also depend enormously on the type, make and version of the operating system and other software. For example, specific hardening guides will be required for each type and version of the Windows operating system. Similarly, each type, variety and version of Unix will require a specific guide. There are many areas that should normally be addressed when hardening a system. These include the following: Disabling unused software and services System utilities that are capable of overriding or changing system and application controls must be removed if not required (5.1.4c and 6.5.3g). Utilities can range from stand-alone software to services that are included and are shipped with operating systems, middleware and applications. If they are considered to be required then their use must be reviewed on an annual basis by an Information Security Function and: access must be logically controlled allocated to a role, with usage auditable controlled by a process that restricts the usage of such utilities to the minimum required number of users subject to individual user identification, authentication, and authorisation. Unnecessary services, protocols & daemons should be removed or disabled. Features not required in services should be turned off. Only the essential applications, applets and scripts necessary for the system functionality should be installed. Installation of software patches and hotfixes Please see GS&F IS guidance on Vulnerability Management. Authentication and Access control. Authentication techniques and configuration, such as password policies and enforcing strong passwords Configuration of logon banners User rights assignment (least privileged access) and role based access Configuring permissions and access to files and data volumes Segregation of duties Disabling and/or renaming of default and unused system accounts
Version 1.0 Page 4 of 6

GS&F IS Guidance: Security Hardening

Restricting powerful accounts Set registry permissions Configuring access to the system via local group and user accounts Install and configure any network access control required including any local firewalls, and network port settings Please see GS&F IS Guidance on Access Control for details. Installation and configuration of anti-virus and anti-malware software Please see GS&F IS Guidance on Malicious Code and Mobile Code Protection. Installation and configuration of any encryption required Key management settings e.g Kerberos policies Disk encryption VPNs Please see GS&F IS Guidance on Cryptography Configuring audit logging, monitoring and alerting What to log and monitor Log settings Implementation of real-time exception reporting Install and configure any intrusion detection and/or prevention software Please see GS&F IS Guidance on Auditing and Monitoring.

Management of a hardening programme

Hardening guides and processes should be developed as discussed. However, to properly manage a hardening programme a number of processes are required. These include: The development of hardening guides and processes, including specific security configurations and baseline installations. Processes to identify and review system vulnerabilities and threats on an ongoing basis, and to incorporate the findings into the hardening guides as required. Processes to continually manage and enhance the hardening guides. Integration into the System Development Life Cycle and change processes (please see the GS&F IS Guidance on Information Security in the System Development Lifecycle), and continuous improvement programs. Development of configuration checks and checklists to test compliance to the hardening Guides. Deployment of vulnerability scanning (please see the GS&F IS Vulnerability Scanning Framework).

References and additional guidance

GS&F IS Guidance documents referenced: GS&F IS guidance on Vulnerability Management GS&F IS Guidance on Access Control GS&F IS Guidance on Malicious Code and Mobile Code Protection GS&F IS Guidance on Cryptography
Page 5 of 6

Version 1.0

GS&F IS Guidance: Security Hardening

GS&F IS Guidance on Auditing and Monitoring GS&F IS Guidance on Information Security in the System Development Lifecycle GS&F IS Vulnerability Scanning Framework.

Many product vendors, security organisations and some government agencies have committed resources to developing standards for security hardening. It is strongly recommended that those charged with managing security hardening programmes use these as references for developing specific guides for use within the Group. The following Websites provide examples and are recommended: US, National Security Agency (NSA) has the most extensive library on Hardening Standards. http://www.nsa.gov/snac/ US, National Institute of Standards and technology (NIST) Security Configuration. http://csrc.nist.gov/checklists/repository/vendor.html DISA Security Technical Implementation Guides (STIGS). http://iase.disa.mil/stigs/index.html

If you need more information

Please contact GS&F Information Security via email ~ GS&F Information Security or phone +44 (0) 131 523 2144 (internal: 222144) if you need more information.

Version 1.0

Page 6 of 6