Security standard for general information systems

Low

• Create, document, and implement a patching process (can be accomplished through WSUS/SCCM, GPO, or auto patching).
• Install permanent fixes (patches, upgrades, etc.)

• Keep the systems disconnected from networks or connect them only to an isolated “build” network until all patches have been transferred to the systems through out of band means (e.g. flash drive or cd) and installed, and other configuration steps listed in this section have been performed.
• Continually identify vulnerabilities and applicable patches (unless automated).
• Place the servers on a VLAN or other network segment that severely restricts what actions the hosts on it can perform and what communications can reach the hosts---only allowing those events that are necessary for patching and configuring the hosts. Do not transfer hosts to regular networks segments until all configuration steps listed in this section have been performed.

• Administrators should generally not apply patches to production systems without first testing them on another identically configured server or have a tested and reliable rollback process implemented.
• Mitigate vulnerabilities temporarily if needed and if feasible (until patches are available, tested, and installed). Factors to consider: exploitability and difficulty to mitigate.

• Remove outdated or unused applications and software if not needed such as factory installed bloatware.
• Avoid using unencrypted services such as Telnet, instead enforce more secure protocols such as SSH.

• Public services
  • Directory services (e.g. LDAP, NIS)
  • Web servers and services
  • Email services (e.g. SMTP)
  • System and network management tools and utilities such as SNMP
  • Remote control and remote access programs such as RDP
• File and printer sharing services (e.g. NetBIOS file and printer sharing, NFS, FTP).
• Wireless networking services (unless currently in use)
• Bluetooth and infrared

• Language compilers and libraries (Disabled if a production system)
• System development tools (Disabled if a production system)

Low

• Remove or disable unneeded default accounts: The default configuration of the OS often includes guest accounts (with and without passwords), administrator or root level accounts, and accounts associated with local and network services. The names and passwords for those accounts are publicly known. When possible, remove or disable unnecessary account to eliminate their use by attackers including guest accounts on systems containing sensitive information. For default accounts that need to be retained, including guest accounts, severely restrict access to the accounts including changing the names when possible and verify that the passwords are consistent with the University’s password policy.
• Disable non-interactive accounts: Disable accounts and passwords 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 user groups: Assign users to the appropriate groups. Then assign rights to the groups as opposed to assigning rights to individual users.
• Create user accounts: Determine who will be authorized to use the system and its services. Create only the necessary accounts. Only permit shared account usage when no viable alternatives exist. Have ordinary user accounts for system admins that are also users of the system (principle of least privilege).
• Configure automated time synchronization: Some authentication protocols, such as Kerberos will not function if the time differential between client host and authenticating server is significant, so systems using such protocols should be configured to automatically synchronize system time with a reliable time server. OIT manages the time server(s) and NTP is used for synchronization with these servers.
• Follow the University’s password policy: Set account passwords appropriately. Elements that may be addressed in a password policy include the following, enforce when possible:
  • Length: A minimum length for passwords.
  • Complexity: The mix of characters required. For instance uppercase, lowercase, non-alphabetic, and non-dictionary words.
  • Aging–How long a password may remain unchanged. Many policies required users and administrators to change their passwords periodically. In such cases the frequency should be determined by the enforced length and complexity of the password, the sensitivity of the information protected, the exposure level of passwords, and if multi-factor authentication has been enabled for the system. If aging is required, consideration should be given to enforcing a minimum aging duration to prevent users from rapidly cycling through passwords to bypass reuse restrictions.
  • Reuse: Whether a password may be reused. If reuse is prohibited, if possible ensure that users aren’t simply appending incrementing characters to the original password. (“mysecret” to “mysecret1”)
  • Authority: Who is allowed to change or rest passwords and what sort of proof is required before initiating any changes.
  • Password security: How passwords should be secured, such as not storing passwords unencrypted on the server, and requiring administrators to use different passwords for their administration accounts.
• Configure systems to prevent password guessing: It is relatively easy for an unauthorized user to try to gain access to a system by using automated software tools that attempt all passwords (brute-forcing). If the OS provides the capability, configure it to increase the period between login attempts with each unsuccessful attempt or alternatively deny login after a limited number of failed attempts. Typically, the account is “locked out” for a period of time (such as 30 minutes) or until a user with appropriate authority reactivates it.

• N/A

• Install and configure other security mechanisms to strengthen authentication such as multifactor authentication.

• Permit access to only required files (e.g. users shouldn’t be allowed to access system mmc controls or other user’s files)

• Isolate service users to virtual environments (e.g. chroot ‘jails’).
• Auditing implemented as appropriate to monitor attempts to access protected resources.

• N/A

• Anti-malware software (anti-virus, anti-spyware, rootkit detectors, etc.) should be installed.
• Host-based firewalls (defense in depth mechanism, enable if supported).
• Periodic security testing of the system is a vital way to identify vulnerabilities and to ensure that the existing security precautions are effective and that security controls are configured properly.

• Patch, package and configuration management or vulnerability management software utilized to ensure that vulnerabilities are addressed promptly and to identify new vulnerabilities in the server’s OSes, services, and applications.

• Host-based IDS or IPS to detect attacks performed against the server, including DoS attacks (e.g. file integrity checking software can identify changes to critical system files).
• Network based firewall should be configured as additional protection.
• Disk encryption technologies (and portable –as possible)

Low

• No authentication credentials should be stored on or around system (e.g. sticky notes on monitors, or under keyboards.)
• Any mobile system such as a laptop should be stored securely when not in use (e.g. locked cabinet, laptop lock, removed from publicly accessible areas)

• Systems such as servers with confidential data must be off limits to unauthorized individuals. Options to achieve this include:
  • Implement locked doors with only authorized individuals having keys.
  • Implement limited card swipe access or proximity reader access.

• Systems with extremely sensitive data should be housed in the data center or in an approved location that is monitored by staff with intrusion detection enabled such as security camera footage.
• Proof of identity should be displayed to access such systems.
• Logging should occur of when individuals access systems physically and these logs should be audited daily.
• Other controls should be implemented to ensure system availability:
  • Fire prevention, detection, and suppression.
  • Temperature, humidity, and static electric controls
  • Other environmental controls such as water damage prevention and detection.

• Apply any patches or upgrades to correct for known critical vulnerabilities in the system software (e.g. Apache, IIS, Oracle, MS-SQL, Cold Fusion, etc.)

• Install the system software either on a dedicated host or on a dedicated guest OS if virtualization is being employed. (Single network service/role per server –Web, database, DNS, SMTP, etc.)
• Apply any patches or upgrades to correct for known critical, high and medium vulnerabilities in the system software (e.g. Apache, IIS, Oracle, MS-SQL, Cold Fusion, etc.).
• Create a dedicated physical disk or logical partition to separate system data from OS and system application.
• Remove or disable all services installed by applications but not required (e.g. gopher, FTP, HTTP, remote administration
• Remove or disable all unneeded default user accounts created by the system installation.
• Remove all example or test files from the system, specifically for servers, including sample content, scripts, and executable code (for production).
• Remove all unneeded compilers.
• Apply the appropriate security template or hardening script to the system.
• 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 manufacturer’s documentation for the system.

• N/A

• For Server: Limit the access of the server application to a subset of computational resources if possible. This can be accomplished through virtualization, but not easy in many modern OSes.
• Limit the access of users through additional access controls enforced by the system, where more detailed levels of access control are required.
• Typical files to which access should be controlled are:
  • 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 non-repudiation 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 (e.g. not running as root, administrator, or equivalent).
• Service processes can only write to system content files and directories if necessary.
• Temporary files created by the system software are restricted to a specified and appropriately protected subdirectory if possible. Access to these temporary files is limited to the system processes that created the files if possible.

• N/A

• N/A

• Install server content on a different hard drive or logical partition than the OS and server software. Place a limit on the amount of hard drive space that is dedicated for uploads, if uploads to the server are allowed. Ideally, uploads should be placed on a separate partition to provide stronger assurance that the hard drive limit cannot be exceeded.
• 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. This measure prevents the server from being used to propagate malware or traffic pirated software, attack tools, pornography, etc. It is also possible to limit the size of each uploaded file, which could limit the potential effects of a DoS attack involving uploading many large files.
• Ensure that log files are stored in a location that is sized appropriately. Ideally, log files should be stored on a separate partition. If an attack causes the size of the log files to increase beyond acceptable limits, a physical partition helps ensure the server has enough resources to handle the situation appropriately.
• Configure the maximum number of server processes and/or network connections that the server should allow.

• N/A

• Systems should employ encryption technologies when transmitting or storing sensitive information and authentication credentials.
• Centralized management for encryption is preferred.

• Systems should authenticate to a central system, such as OIT Active Directory to allow access to non-public resources.

• N/A

• N/A

• Identify logging capabilities and requirements.
  • Logs should capture successful and failed authentication attempts
  • If possible, logs should capture privileged user attempts.
  • Logs should capture account management activities.
  • Logs should capture, as much as possible, system configuration changes, schema changes, or state changes.
• Review and retain log files
  • Log files should be retained for at least one year.
  • Log files should be reviewed weekly for anomalies

• Log files should be reviewed through the University’s SIEM

• Backup media should be protected from theft and/or disclosure at the same level as the system itself (physical, encryption, etc.)

• Minimum of differential backups should occur at least nightly.
• Full backups should occur at least twice a month.
• Backup recover testing should be performed at least twice a year.
• Backups should be maintained in a separate physical location/building from the system itself.
• At least three full backups are recommended to be kept, but environment may dictate differently.

• Full back up recovery test should be performed at least twice a year.

• Systems should be scanned for common external vulnerabilities at least 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 scans need to be addressed within one week of them being provided to the administrator of the system.

• Penetration testing should be performed on an annual basis.

• Restrict which hosts can be used to remotely administer the system.
• Restrict by authorized users.
• Restrict by IP address.
• Restrict to hosts on the internal network or those using the university’s remote access solution.
• Use secure protocols that can provide encryption of both passwords and data (e.g. SSH, HTTPS); do not use insecure protocols (e.g. FTP, NFS, HTTP) unless absolutely required and tunneled over another encrypted protocol such as SSL or IPsec.
• 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)

• N/A