Policy Template for Server Security

Edited

1.0 Purpose 

The purpose of this policy is to establish standards for the base configuration of internal server equipment that is owned and/or operated by {{organization.name}}. Effective implementation of this policy will minimize unauthorized access to {{organization.name}} proprietary information and technology.

2.0 Scope

This policy applies to server equipment owned and/or operated by {{organization.name}}, and to servers registered under any {{organization.name}}-owned internal network domain.

Based on the type of servers, such as Cloud Managed Systems, Cloud Managed Instances or Physical Servers, the policy for handling patching, configuration, backups and monitoring shall vary. See the table below.

 

 

Cloud Managed System

Cloud Managed Instance

Physical Servers

Infrastructure Ownership 

Service Provider

Service Provider

{{organization.name}}

Configuration & Backup

Managed by Provider

Managed by {{organization.name}}

Managed by{{organization.name}}

Monitoring

Managed by Provider

Managed by {{organization.name}}

Managed by {{organization.name}}

Patch Management

Managed by Provider

Managed by {{organization.name}}

Managed by {{organization.name}}

Decommissioning

Not Applicable

Not Applicable

Applicable

 

3.0 Definitions 

Demilitarized Zone (DMZ): A network segment external to the corporate production network. Server for purposes of this policy is defined as an internal {{organization.name}} Server. Desktop machines and Lab equipment are not relevant to the scope of this policy.

Intrusion Detection System (IDS): A system that monitors network traffic for malicious activity.

Intrusion Prevention System (IPS): A network security prevention technology that examines network traffic flow to detect and prevent vulnerability exploits.

SSH (Secure Shell): SSH is a network protocol that allows data to be exchanged using a secure channel between two networked devices.

IPSec (Internet Protocol Security): IPSec is a suite of protocols for securing IP communications by authenticating and encrypting each IP packet of a data stream.

4.0 Policy 

4.1 Ownership and Responsibilities 

All servers deployed at {{organization.name}} must be the responsibility of corporate IT. Approved server configuration guides must be established and maintained by each operational group, based on business needs and approved by {{organization.name}} IT. Operational groups should monitor configuration compliance and implement an exception policy tailored to their environment. Each operational group must establish a process for changing the configuration guides, which includes review and approval by {{organization.name}} IT.

Servers must be registered within the corporate enterprise management system. At a minimum, the following information is required to positively identify the point of contact:

  • Server contact(s) and location, and a backup contact

  • Hardware and Operating System/Version

  • Main functions and applications, if applicable

  • Information in the corporate enterprise management system must be kept up-to-date

  • Configuration changes for production servers must follow the appropriate change management procedures

Policy Conditions:

  • Physical security and maintenance of the infrastructure (hardware, software, networking, and facilities that run the Cloud services) is the responsibility of the Provider in the case of Cloud Managed Systems and Cloud Managed Instances.

  • Physical security and maintenance of the infrastructure (hardware, software, networking, and facilities that run the server) is the responsibility of {{organization.name}} in the case of Physical servers being used.

4.2 General Configuration and Backup Guidelines 

Operating System configuration should be in accordance with approved {{organization.name}} IT guidelines. Services and applications that will not be used must be disabled where practical. 

  • Access to services should be logged and/or protected through access-control methods such as TCP Wrappers, if possible.

  • The most recent security patches must be installed on the system as soon as practical, the only exception being when the immediate application would interfere with business requirements.

  • Trust relationships between systems are a security risk, and their use should be avoided. Do not use a trust relationship when some other method of communication will do.

  • Always use standard security principles of least required access to perform a function. Do not use root when a non-privileged account is acceptable.

  • If a methodology for secure channel connection is available (i.e., technically feasible), privileged access must be performed over secure channels, (e.g., encrypted network connections using SSH or IPSec).

  • Servers should be physically located in an access-controlled environment.

  • Servers are specifically prohibited from operating from uncontrolled cubicle areas.

  • The production servers shall be backed up once a day.

  • There might be other servers that may require fewer backups. Define the frequency for regular backups of such servers.

Policy Conditions:

  • Configurations and backups for Cloud Managed Systems shall be managed by the provider.

  • Configurations and backups for Cloud Managed Instances and Physical Servers shall be managed by {{organization.name}} in accordance with the Server Security Policy.

4.3 Monitoring

All security-related events on critical or sensitive systems must be logged and audit trails saved as follows: 

  • Logs are accessible only to appropriate applications and trusted users (via sudo or similar access control).

  • A review of logs will only be done with read-only access tools (e.g., view, more, less, graphical web tools for accessing/filtering logs, etc.).

  • All security related logs will be kept online for a minimum of 1 week.

  • Security-related events will be reported to {{organization.name}} IT, who will review logs and report incidents to IT management. Corrective measures will be prescribed as needed. Security-related events include, but are not limited to:

    • Port-scan attacks

    • Evidence of unauthorized access to privileged accounts

    • Anomalous occurrences that are not related to specific applications on the host

    • Loss or breach of sensitive data

  • The server shall also be monitored for capacity and performance requirements. The incident management process shall be followed for confirmed events and anomalies.

  • Forecast future processing demand of system components on an ongoing basis and compare with schedule capacity. In addition, forecasts shall be reviewed and approved by IT management. Change requests must be initiated as needed based on approved forecasts.

Policy Conditions:

  • Logging and monitoring for Cloud Managed Systems shall be managed by the provider.

  • Logging and monitoring for Cloud Managed Instances and Physical Servers shall be managed by {{organization.name}} in accordance with the Server Security Policy.

4.4 Patch Management 

All servers under {{organization.name}} will be maintained with the latest security patches to their operating systems and key applications. 

Each department is responsible for servers under their control. When a patch is announced, an authorized system administrator must enter a change ticket according to the change management policy. A criticality rating of high or normal must be assigned. All high/critical patches must be applied as soon as practically possible, but not longer than thirty (30) calendar days after public release for any critical production server.  All patches that are medium/high severity or for non-critical systems must be rolled out within ninety (90) calendar days.  Any low priority patches will be installed on a case-by-case basis.  All patches should be tested on development systems before being rolled out to production, where possible.

In case the patches cannot follow the aforementioned schedule, a document must be produced explaining why the patch must be deferred. Permissible deferrals may include a lack of appropriate change windows within the appropriate timeframe or a conflict with other critical changes scheduled at that time. Approvals shall be granted by CTO. 

IT/Information Security is responsible for performing a vulnerability scan on their systems after each patch window to show that the patches were installed correctly.  Clean vulnerability scan reports should be reviewed periodically.

Policy Conditions:

  • Patch Management for Cloud Managed Systems shall be managed by the provider.

  • Patch Management for Cloud Managed Instances and Physical Servers shall be managed by {{organization.name}} in accordance with the Server Security Policy.

4.5 Decommissioning a Server 

Policy Condition:

  • Applicable to Physical Servers only.

  • A set of defined measures should be followed to decommission servers.

  • A “final” backup shall be made before decommissioning the server. This backup is kept for a year and then will be deleted sometime after the year is up.

  • The data on the servers must be completely destroyed before the machine is taken out of service. The machine should be labelled accordingly.

4.6 Compliance 

Audits will be performed on a regular basis by authorized organizations within {{organization.name}}. 

Audits will be managed by the internal audit group or {{organization.name}} IT, in accordance with the Internal Audit Policy. {{organization.name}} IT will filter findings not related to a specific operational group and then present the findings to the appropriate support staff for remediation or justification. 

Every effort will be made to prevent audits from causing operational failures or disruptions. 

Policy Conditions:

  • Applicable to Cloud Managed Systems and Cloud Managed Instances.

  • {{organization.name}} shall obtain and review ISO 27001/SOC 2 or equivalent compliance certificates for all Cloud Servers.

5.0 Enforcement 

Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.