Security Baseline Templates Security HowTo's

Baseline Security Template | Servers

This article is a template for you to copy and modify to fit your business needs. The security baseline described here is for a business.

Scope

This document described the baseline security posture of business servers. The server may be in the cloud or local infrastructure. The operating system is irrelevant to this document.

Operating system version

The business should decide on which versions of the operating system is accepted for installation. The version should be carefully considered given that server operating systems can be in production for many years.

Create a list of acceptable operating system types and versions with the fewest choices. Ensure that all staff required to work on these systems are suitably trained. This list of operating system types and versions will change over time. Keep it current and consider a plan for upgrades to perviously installed servers.

System software updates

The operating system must be configured to check for, download and install security updates immediately. Other updates including bug fixes and feature updates should be configured to install one week after release date to ensure adequate time for vendor testing and re-distribution.

All modern operating systems have in-built software update systems. Use them to apply security updates as soon as they are released by vendors. This helps prevent zero-day (and other) attacks.

Central workstation software updates

Ensure workstations can obtain system updates from a central update server. This allows administrative control over what updates are available to workstations and policies can be put in place to ensure appropriate update schedules.

The administrative overhead is high and the downloads are greater where workstations are individually configured to get updates.

Third party software updates

Software not included in system updates should be configured individually to automatically check for, download and install without delay. Examples of such software include Java, Adobe Acrobat, web browsers and device drivers.

3rd party software is often not included in system controlled updates. These applications are also significant ways hackers attempt to access remote and local systems.

Services

Ensure each server is running the fewest services possible. Remove or disable all unnecessary services from each server. Make sure all services default to the highest level of security. For instance, ensure the web server is running on “https/443” and replace FTP with SFTP. This isn’t always a system administration matter and others such as developers and other stake-holders need to be involved.

Unnecessary services are a security risk and should be removed to prevent exploits by those services.

User logins

Most servers do not require users to log in directly using remote-access services. Therefore users should explicitly be prevented from doing so.

Administrators should be excepted from this access control. Suitable access controls could be at the network layer or application layer. That is, either (or both) control access using a firewall (permit only selected sources) or through user/group permissions.

User permissions

Servers providing file storage services should restrict users from accessing all files not specifically needed for staff to perform their duties.

A “least privileges” approach should be taken. Users are grouped into security groups and those groups are granted (or not) access to server resources. Individual users should be be specified in access controls – rather, groups should be used.

System backups

Servers should have backups configured. All servers backups should be configured for daily backups (at least). The backup scheme should consider file-level restores, server level restores and infrastructure level restores. The objective is to ensure users can recover from accidental data loss, that administrators can recover a complete server where a catastrophic failed occurred and where the administrators can recover multiple servers in the even that a multi-system catastrophe occurred.

Backups should be stored on disks or tapes in an encrypted state. The disks should be taken off-site at the soonest possible time after backup completion. Backups should be checked and tested on a regular basis. Consideration should be given to how long it will take to recover and how much time is allowed to have past before the restore is complete. In other words, how much time and data loss has the business agreed to accept in the event of a disaster?

Data backups

Staff should be trained to use the network storage locations. Office applications should be configured to store documents on network storage locations by default.

By storing documents on the network, the business can be sure all information created by staff is included in backups.

Disk encryption

Customer data must reside on encrypted storage. Two options exist to manage such storage from the administrators point of view. Full-disk encryption including the operating system and full-disk encryption for a secondary disk where customer data is located. The objective of this security measure is to protect customer data should the server be stolen

This raises the issue of reboots. Full-disk encryption requires that a password be presented to the server on boot to unlock (decrypt) the disk. And such an action can only be done if at the console. Therefore this solution is sensible for virtual environments (if console access is available) or where an administrator is onsite and available to provide the password.

The alternative approach is to encrypt a secondary disk or partition on the server that does not include the operating system. Whilst the operating system its self it not encrypted, the customer data is. An administrator is still required to enter the password to unlock the disk but it’s less of an issue as the server will be on the network and remote access available as normal.

Internet access

Internet access must be controlled and available only through the use of a Proxy. The Proxy must be used by all servers. No direct internet access should be available to servers.

The exception to this is where the server is performing a firewall or proxy role its self. A server is harder to re-image or re-provision than workstations.

Antivirus

Antivirus software should be installed with capabilities to identify, report back to a central server, block and remove malware including spyware and crypto-ware. Antivirus software should be configured to update automatically and run daily full-disk scans inclusive of all local disks. Network locations should be excluded from disk scans.

The actual time of the daily scan can be chosen and does not have to happen on boot/login. Scheduling for lunch time or afternoon may help staff work more optimally.

Antivirus central server

The antivirus system should be centralised. All updates should be stored on a server where workstations are be configured to get updates from. Workstations will report problems and infections to that server for review by the administrator.

The alternative is to have workstations and servers going direct to the Internet for updates. Just like operating system updates, this is best optimised and controlled by using a specialised server for the role of controlling updates and reporting issues.

Host-based firewall

All modern operating systems come with host-based firewalls enabled by default. The choice has to be made to use either the operating systems built-in firewall of the antivirus firewall (if installed). Choose the option that has reporting of violations and is centrally configurable.

Host-based firewalls protect individual servers from threats on the local network. If one server or workstation becomes infected with malware, it may be less effective in its goal if other systems are protected at the network level.

Share This:

Leave a Reply

Your email address will not be published. Required fields are marked *