Security Standards

This document describes security best practices that should be applied to all systems at UCCS and adheres to three basic security concepts: 

1. Defense in Depth - Simply stated, good security doesn't rely on only one level of protection.  
2. Principle of Least Privilege - An individual, process, or system should only have the minimum amount of  access or privilege required to get the job done. 
3. Less is More - A system should only contain information and functionality necessary to get the job done - nothing more, nothing less.

Levels of Standard

Not all systems are the same.  Some contain information that is highly sensitive and private, while others only contain publicly available information.   However, any systems with access to the UCCS network may be at risk and should follow the procedures outlined below. This document describes general practices that are required of all systems containing UCCS data.

Patching

• Use an automated patching process whenever possible. 
• Install permanent fixes, patches and upgrades as soon as possible.
•  Identify vulnerabilities and apply patches on a regular basis. 
• Mitigate vulnerabilities temporarily until patches are available and tested depending on the risk, availability of exploit and difficulty of fixing.

Server Deployment

• Keep the servers disconnected from networks or connect them only to an isolated "build" network until all patches have been applied out-of-band.
• Place the servers in a testing environment, VLAN or isolated network until configuration and testing is complete.
• Do not apply patches to production servers without first testing them on another identically configured server, whenever possible.

Remove unneeded services, applications and network protocols

A system is exposed to additional risk if any of the public services listed below are enabled.  These services should be removed or disabled if they are not needed.

• Directory services such as Lightweight Directory Access Protocol [LDAP] or Network Information System [NIS])
• Email services 
• System and network management tools and utilities, including Simple Network Management Protocol (SNMP) 
• Remote control and remote access programs
• File and printer sharing services  
• Wireless networking services and Bluetooth 
• Language compiler,  libraries and system development tools

User Authentication and Access to Resources

• Remove or Disable Unneeded  Accounts - Be especially sure to remove any accounts that came pre-installed with the system as these credentials are well known to the attacker community. 
• Disable Non-Interactive Accounts - Disable accounts that need to exist but do not require an interactive login. For Unix systems, disable the login shell or provide a login shell with NULL functionality (e.g., /bin/false). 
• Create the User Groups - Assign users to the appropriate groups. Then assign rights to the groups, as documented in the deployment plan. This approach is preferable to assigning rights to individual users, which becomes unwieldy with large numbers of users.  
• Create the User Accounts - Create only the necessary accounts. Permit the use of shared accounts only when no viable alternatives exist.  Provide ordinary user accounts for server administrators that are also users of the server. 
• Configure Automated Time Synchronization - Typically the time server is internal to the organization and uses the Network Time Protocol (NTP) for synchronization; publicly available NTP servers are also available on the Internet. 
• Check the UCCS Password Policy - Ensure that all passwords are meet the latest requirement for length, complexity, ageing and reuse.  
• Configure Systems to Prevent Password Guessing - If possible, configure features like login delay times and account lockout to prevent brute force guessing of passwords.

Configure Resource Controls (file permissions, network shares, etc.)

• Permit access to only required files - users should not be allowed to access system controls or other users' files.
•  Isolate service users to virtual environments whenever,  e.g., chroot 'jails'.

Configure Additional Security Controls

• Install anti-malware software, such as antivirus software, anti-spyware software, and rootkit detectors if feasible.
• Use host-based firewalls, to specifically limit access to just what is needed.
•  Periodically test the Operating System for vulnerabilities. 
• Use Host-based intrusion detection and prevention software (IDPS) to detect attacks or unauthorized changes to the system.
• Request network based firewall rules to specifically protect your server.
• Use good configuration management or vulnerability management software to ensure that vulnerabilities are addressed promptly. 
• Use encryption technologies for data at rest and in transit.

Securely Installing Server Software

• Apply any patches or upgrades to correct for known critical vulnerabilities in the server software.
• Install the server software either on a dedicated host or on a dedicated guest OS if virtualization is being employed. 
• Apply any patches or upgrades to correct for known vulnerabilities in the server software.
• Create a dedicated physical disk or logical partition for server data, if applicable. 
• Remove or disable all services installed by the server application but not required.
•  Remove or disable all unneeded default user accounts created by the server installation. 
• Remove all example or test files from the server, including sample content, scripts, and executable code (for production).
• Remove all unneeded compilers. 
• Reduce the permissions that a service account has to only those required. 
• Apply the appropriate security template or hardening script to the server. 
• For external-facing servers, reconfigure service banners not to report the server and OS type and version, if possible. 
• Configure warning banners for all services that support such banners.
•  Configure each network service to listen for client connections on only the necessary TCP and UDP ports, if possible.  
• Remove all manufacturers' documentation from the server.

Configuring Access Controls 

• Limit the access of the server application to a subset of computational resources. 
• Limit the access of users through additional access controls enforced by the server, where more detailed levels of access control are required. 
• Typical files to which access should be controlled are as follows:    
  • Application software and configuration files    
  • Files related directly to security mechanisms:        
    • Password hash files and other files used in authentication        
    • Files containing authorization information used in controlling access        
    • Cryptographic key material used in confidentiality, integrity, and nonrepudiation services
  • Server log and system audit files
  • System software and configuration files    
  • Server content files
• Service processes are configured to run as a user with a strictly limited set of privileges (i.e., not running as root, administrator, or equivalent). 
• Service processes can only write to server content files and directories if necessary. 
• Temporary files created by the server software are restricted to a specified and appropriately protected subdirectory (if possible). Access to these temporary files is limited to the server processes that created the files (if possible).

Server Resource Constraints

• Installing server content on a different hard drive or logical partition than the OS and server software. Placing a limit on the amount of hard drive space that is dedicated for uploads, if uploads to the server are allowed.
• If user uploads are allowed to the server, ensuring that these files are not published by the server until after some automated or manual review process is used to screen them. 
• Ensuring that log files are stored in a location that is sized appropriately. Ideally, log files should be stored on a separate partition.
• Configuring the maximum number of server processes and/or network connections that the server should allow.

Maintaining the Security of the System

• Ensure adequate logging of system and user events:
  • Logs should capture successful and failed authentication attempts.
  • Logs should capture privileged use attempts Logs should capture account management activity.
  • Logs should capture system configuration changes, schema changes, or state changes.
• Reviewing and Retaining Log Files:
  • Log files should be retained for a period of time sufficient to meet compliance or records retention policy.
  • Log files should be reviewed regularly for anomalies.
• Log files should be submitted to IT for automatic review by the Intrusion Detection System (IDS).

Backup Procedures

• Backup media should be protected from theft and/or disclosure at the same level as the system itself.
• Minimum of Differential backups should occur at least nightly.
• Full Backups should occur at least twice a Month.
• Backup recovery testing should be performed at least twice a year.
• Backups should be maintained in a separate physical location/building from the system itself. 
• Recommend at least 3 full backups be kept, but environment may dictate differently.

Security Scanning

These services will be performed by the UCCS Information Security Office.  Make sure you register your system with the ISO.  You can request a security scan at any time.

• Systems should be scanned for common external vulnerabilities quarterly, or as new, significant vulnerabilities are discovered.
• Some findings may result in the immediate removal of the system from the network until remediation is performed.
• The results of these scans need to be addressed as soon as possible. 
• Penetration testing should be performed on an annual basis if feasible.
• Some operating systems have self-remediation tools such as the Microsoft Baseline Security Analyzer, that may allow a user to determine what needs to be fixed prior to performing a broader security scan.

Remotely Administering a Server

• Restrict which hosts can be used to remotely administer the server.
• Restrict by authorized users.
• Restrict by IP address (not hostname).
• Restrict to hosts on the internal network or those using a UCCS enterprise remote access solution.  
• Use  only secure protocols that can provide encryption of both passwords and data (e.g., SSH, HTTPS). 
• Enforce the concept of least privilege on remote administration (e.g., attempt to minimize the access rights for the remote administration accounts).
• Do not allow remote administration from the Internet through the firewall unless accomplished via strong mechanisms, such as VPNs.  
• Use remote administration protocols that support server authentication to prevent man-in-the-middle attacks.
• Change any default accounts or passwords for the remote administration utility or application.
• Use a strong authentication mechanism (e.g., public/private key pair, two-factor authentication) whenever possible.