Building a Secure Server

All servers on campus must conform to School of Medicine minimum security standards, whether hosted by IRT or otherwise. If you are running a server that is not physically located in the data center, you will need to make sure that you're following Stanford policies about keeping the data properly secured. You may also choose to have your server moved to the data center and hosted or managed by IRT. Wherever it's physically located, you want to make sure that it's correctly configured for good security.

Think your server might be compromised (aka, hacked)? Here are some things to check.

A first priority in the planning and management of your server is what kind of data it's going to be storing. As of May 2015, a new set of classifications has been established and is now in effect for Stanford data: High Risk, Moderate Risk, and Low Risk. (The former framework - Prohibited, Restricted, Confidential, and Unrestricted - will be phased out by January 2016.)

Visit the Stanford ITS page of Minimum Security Standards, for a handy chart outlining the details of each classification of information. The new Data Classification page also has a list of examples of servers and applications that may similarly be classified High, Moderate, or Low Risk, based on the kinds of information they deal with.

All servers on campus must meet the minimum security standards for the correct risk classification.

Examples of High Risk servers and applications:

• Departmental email servers
• Active Directory
• DNS
• HR application that stores employee SSNs
• Application that stores campus network node information
• Application collecting personal information of donor, alumnus, or other individual
• Application that processes credit card payments
• Servers or applications using High Risk data
  

Examples of Moderate Risk servers and applications:

• Database of non-public contracts
• File server containing non-public procedures/documentation
• Server storing student records
• HR application that stores salary information
• Directory with phone numbers, email addresses, and titles
• University application that distributes information in the event of a campus emergency
• Online application for student admissions
• Server storing Moderate Risk data

Examples of Low Risk servers and applications:

• Servers used for research computing purposes without involving Moderate or High Risk data
• File server used to store published public data
• Database server containing SUNetIDs only
• Online maps
• University online catalog displaying academic course descriptions
• Bus schedules

Standard for ALL servers:

Patching:

• Keep your version of the operating system up to date; you should be running the most recent stable version.
• Install the all the latest security patches for your system and applications.

Inventory:

• Fill out the survey, and create a record in NetDB (update quarterly)
  

Firewall:

• Make sure that your server has a firewall running all the time.
• Protect traffic coming in AND going out (ingress and egress protection); it can stop both incoming and outgoing attacks even when you're not aware of it.
• Keep track of what ports are open and why.
• Know how to block and unblock an IP.

Control Access to Server:

• Remove, disable or change passwords to default accounts.
• All passwords should be strong passwords; they should also be unique, and changed periodically.
• Disable "guest" accounts/access.
• For data center-hosted servers, all administrative accounts must be SUNet ID accounts.
• Remove inactive user accounts regularly.
• Keep a complete list of everyone who has access to the server, and make sure you know who has which read/write privileges.
• No open file-sharing is allowed.
• All remote access should be restricted to specific IP addresses, and encrypted from end to end (via VPN).

Review Processes and Remove Extra Software

• Know everything that runs on your server, why, and which users have access.
• Disable any and all unused services.
• Install anti-virus software and make sure it stays current, is running actively, and is generating logs.

Lock /tmp, /var/tmp, and /dev/shm partitions (linux/Unix)

• Since /tmp, /var/tmp and /dev/shm are world writable directories, if left unlocked anyone can read/write/excute anything from these directories and it becomes a major security concern.
• With /etc/fstab you can limit what can be done in these partitions: if you see 'defaults' beside the /tmp line, remove it and replace it with 'noexec,nosuid'. This will stop any executables from being allowed to run.
• Do the same for /dev/shm and make /var/tmp a shortcut (symbolic link) to /tmp.

Lock down Your Software: PHP, Apache, etc.

• Lock down all your applications per the vendor's best practices.
• Use change management and version control procedures for all your software; document all changes to applications and archive previous versions, just in case.

Monitor your Server's Performance

• Keep regular track of your server's normal running speed and bandwidth usage, so you can spot abnormalities.

Watch Out for Unusual Activity

If, while monitoring any of the above, you notice any unusual activity, your server might be compromised. If you're suspicious, check these other ways to tell if your server has been compromised.

Additional Requirements for High And Moderate Risk:

Physical Protection

• If your server or its applications and data are classified High or Moderate Risk, you must locate your server in a data center.

Two-Step Authorization

• Require Duo two-step authentication for all interactive user and administrator logins.

Centralized Logging

• Forward logs to a remote log server. University IT Splunk service recommended.

Vulnerability Management

• Monthly Qualys application scan. Remediate severity 5 vulnerabilities within 7 days, severity 4 vulnerabilities within 14 days, and severity 3 vulnerabilities within 28 days of discovery.

Malware Protection

• Deploy Bit9 in high enforcement mode. Review alerts as they are received.

Intrusion Detection/Monitor Activity:

• Check your logs regularly, both automated and manually, to find out about any unusual system activity.
• IRT Security recommends running Tripwire: as the name suggests, it acts as an alert system, checking files against themselves to see if anything has been altered. (ITS also recommends Bit9 on supported platforms, otherwise OSSec.) Intrusion detection software can help identify vulnerabilities, and help establish a timeline in the event of a security incident.

Training

• Attend two days of Stanford Information Security Academy training annually.

Secure Software Development

• Include security as a design requirement of your applications. Review all code and correct identified security flaws before deployment. Use of static code analysis tools recommended.

Back Up Your Data

• Make regular (at least weekly) encrypted backups of all data; make sure onsite AND offsite backups are kept in a physically secure environment.

Extra Requirements for High Risk:

Dedicated Admin Workstation

• Access administrative accounts only via a certified Personal Bastion Host (PBH).

DBG Review

• Request a Data Governance Board (DGB) review of your data and server needs, and implement recommendations before deployment.

Regulated Data Security Controls

• Data is considered High Risk if it is required by law to be protected. Implement PCI DSS, HIPAA, or export controls as applicable.  

If you've determined that your server should be located in the data center, contact IRT Security. Someone will arrange a time to sit down with you, go through a security questionnaire and assessment, and help you with the server move. For more information about IRT's hosting and system administration requirements and services, visit the IRT Data Center Services page.