Standard for System Security Controls

Introduction

Systems should be configured with standard security settings, kept up-to-date with respect to software updates, and protected with system management and security software.

Purpose

Systems, regardless of where they are hosted, the vendor who built them, or the team that manages them, are often not secure by default and require specific steps to achieve a secure configuration. This standard defines minimum security configuration requirements for systems to ensure they are secured to a level appropriate for the purpose(s) for which they are used.

Scope

This standard applies to all university systems that are used to Process Institutional Information, irrespective of whether they are maintained by The New School or a third party on the university's behalf or whether they are accessed from on-campus or off-campus locations, and to any Workforce Member or other authorized individual who accesses or in any way makes use of them, regardless of affiliation.

A “system” is any IT Resource to which the safeguards described in this standard can be applied. Examples of systems include, but are not limited to:

• Desktop, laptop, or server computers (including virtual servers) running general-purpose operating systems such as Windows, Mac OS X, and Linux
• Mobile devices (e.g., phones, tablets) to the extent they interact with New School resources and systems, such as New School G Suite, Banner, Workday, etc.
• Web-based applications (generally, any application accessed via a web browser)
• Client-server applications (generally, any application using a “fat” client)
• Network server applications, such as a VPN or an FTP server
• Databases

All of the above systems may perform their own authentication and authorization, logging, and auditing, and have their own configurations which must be managed, and each of them is considered a compliance object to be protected.

This standard does not apply to:

• End-user devices owned and used by students for purposes of attending the university and completing coursework
• End-user devices owned and used by the general public (i.e., individuals unaffiliated with the university)
• Students who are not Workforce Members

Definitions

Special terms used in this document will be Capitalized and underlined, signifying that they have special meaning. A comprehensive glossary of terms, with examples, can be found at https://ispo.newschool.edu/glossary/.

Requirements

The controls and control values specified by this standard represent minimum requirements that must be implemented by all systems. At the reasonable discretion of the Application Owner or Data Owner, or when recommended by a risk assessment, more restrictive controls may be implemented.

In the event that a system cannot be configured exactly as specified by this standard because it does not provide the necessary controls or control values, the settings that are provided must be configured to match the specifications of this standard as closely as possible. If the resulting level of security is significantly different than the level defined by this standard, and the system will be used to process information Classified at Protection Level PL-3 or higher, a risk assessment must be performed to determine whether compensating controls are needed.

Basic system security measures

Basic system security measures apply to all systems at The New School, regardless of their Protection Level or Availability Level Classifications. They represent the baseline controls that all systems must meet. For most desktop/laptop computers and mobile devices, these are the only measures that apply.

1. Password protection. All accounts and resources must be protected by passwords that meet the requirements set forth in the user authentication section of the Standard for Account and Authentication Management.
2. Mobile device lock. Mobile devices must be configured to require a PIN, pattern, biometric, or password to access them.
3. Supported operating systems and applications. Operating system software, application software, and appliances (bundled hardware, operating system, and application software) must be maintained at a version level for which the vendor continues to issue security patches to correct vulnerabilities in the product. Systems for which security patches are no longer provided must, within six months of the final security patch publication date, be upgraded to a supported version, replaced with a supported product from another vendor, or removed from service.
4. Software updates. Systems must be configured to automatically install vendor-issued security patches and updates to operating system software, server applications (web server, mail server, database server, etc.), and client applications (web browsers, mail clients, office suites, etc.). For systems Classified at Availability Levels AL-3 and AL-4, a documented plan to manually apply new updates within a reasonable time period is an acceptable alternative.
5. Firewall. Systems must be protected by a firewall which allows only those incoming connections necessary to fulfill the business need of that system. Client systems that have no business need to provide network services must deny all incoming connections. Systems that provide network services must limit access those services to the smallest reasonably manageable group of hosts that need to reach them.
6. Malware protection. Desktop, laptop, and server computer systems running Microsoft or Apple operating systems must have up-to-date, supported anti-virus software installed. The software must be configured to, at a minimum:
   1. be active at all times;
   2. automatically install agent or scanning engine updates;
   3. automatically install signature file updates (if the product uses signatures); and
   4. operate automatically without the need for user intervention.
7. Inactive sessions. Interactive sessions that have been idle (inactive) must revert to a locked user interface or locking screen saver as set forth in the idle (inactive) sessions section of the Standard for Account and Authentication Management.
8. Storage encryption. Device-level storage encryption must be enabled on laptop computers and mobile devices.

Intermediate system security measures

Intermediate system security measures are additional security controls that apply to computer systems and application servers that are Classified at Protection Levels PL-3 or PL-4 and/or Availability Levels AL-3 or AL-4. Except under special circumstances, the requirements in this section do not apply to desktop/laptop computers or mobile devices.

1. Authentication and Authorization
   1. Remove or disable accounts upon loss of eligibility. Accounts that are no longer needed must be disabled in a timely fashion using an automated or documented procedure.
   2. Separate user and administrator accounts. Administrator accounts must not be used for non-administrative purposes. System administrators must be provisioned with non-administrator accounts for end-user activities, and a separate administrator account that is used only for system-administration purposes.
   3. Use unique passwords for administrator accounts. Privileged accounts must use unique passwords that are not shared among multiple systems. Credentials which are managed centrally, such as the NetID/password combination, are considered a single account, regardless of how many systems they provide access to.
   4. Throttle repeated unsuccessful login attempts. A maximum rate for unsuccessful login attempts must be enforced. Account lockout is not required, but the rate of unsuccessful logins must be limited.
   5. Lock or disconnect inactive remote sessions. Remote (network) sessions that have been idle (inactive) for 30 minutes must be locked, requiring the user to re-enter their authentication information (password, pattern, or two-factor) to resume the session. Sessions that cannot be locked must be disconnected, and the user must be required to repeat the sign-on process to regain access.
   6. Enforce least privilege. Non-administrative accounts must be used whenever possible. User accounts and server processes must be granted the least-possible level of privilege that allows them to perform their function.
2. Audit and Accountability
   1. Synchronize system clock. The system clock must be synchronized to an authoritative time source. In order of decreasing preference, acceptable synchronization methods are:
      1. Network Time Protocol to multiple clocks from pool.ntp.org
      2. Network Time Protocol to time.newschool.edu
      3. Windows Time Service
      4. Once-per-day sync (set clock) with time.newschool.edu
   2. Enable system logging and auditing. The facilities required to automatically generate, retain, and expire system logs must be enabled.
   3. Follow an appropriate log retention schedule. System logs must be retained for 30-90 days and then destroyed unless further retention is necessary due to legal, regulatory, or contractual requirements.
   4. Audit successful logins. Generate a log message when a user successfully logs on.
   5. Audit failed login attempts. Generate a log message when a user attempts to log on without success.
   6. Audit when a system service is started or stopped. Generate a log message when a system service is started or stopped.
   7. Audit serious or unusual errors. Generate a log message when a serious or unusual error occurs, such as a system or program crash.
   8. Audit resource exhaustion errors. Generate a log message when a resource exhaustion error occurs, such as an out-of-memory error or an out-of-disk-space error.
   9. Audit failed access attempts. Generate a log message when an attempt to access a file or resource is denied due to insufficient privilege.
   10. Audit permissions changes. Generate a log message when the permissions of a user or group are changed.
   11. Include appropriate correlation data in audit events. For each audit event logged, include sufficient information to investigate the event, including timestamp, IP addresses, port numbers, hostnames, usernames, application name, and other details as appropriate.
3. Configuration and Maintenance
   1. Follow vendor hardening guidelines. This standard cannot be comprehensive for all systems available. Follow basic vendor recommendations to harden and secure systems.
   2. Disable vendor default accounts and passwords. Many systems come with default accounts which are publicly known. Disable those accounts that are not needed; change the passwords on those accounts that are.
   3. Disable all unnecessary network services. Processes and services that are not necessary to complete the function of a system must be disabled.
4. Additional Requirements
   1. Physical access. The system must reside in a locked facility, to which only authorized personnel have access.
   2. Backup and recovery. The system must be backed up regularly, according to a schedule that meets business recovery time and recovery point objectives. The ability to restore data and the entire system from backups must be periodically tested. Backups must be protected according to the Protection Level of the data they contain.
   3. Documentation. Create and maintain documentation recording the Application Owner, Data Owner, business purpose of the system, major system components, and network communications associated with the system.

Advanced system security measures

Advanced system security measures are additional security controls that apply only to computer systems and application servers that are Classified at Protection Level PL-4 and/or Availability Level AL-4.

1. Audit and Accountability
   1. Enable process auditing or accounting. Enable process auditing or accounting, which generates logs information about the creation of new processes and their system activity.
   2. Audit privilege escalation or change in privilege. Generate a log message whenever a user changes their level of privilege.
   3. Audit firewall denial. Generate a log message when the host-based firewall denies a network connection.
   4. Audit all significant application events. Log all significant application events.
   5. Write audit events to a separate system. System logs must be written to a remote system in such a way that they cannot be altered by any user on the system being logged. (Logs may also be written to local files, but only in addition to remote logging, not in place of it.)
2. Configuration and Maintenance
   1. Follow advanced vendor security recommendations. This standard cannot be comprehensive for all systems and applications available. Conform to best practices and recommendations outlined in vendor security whitepapers and documentation.
   2. Host-based and network-based firewalls. Systems must be protected by both a host-based and a network-based firewall that allows only those incoming connections necessary to fulfill the business need of that system.
   3. Configuration management process. Configuration changes must be regulated by a documented configuration and change management process.
3. Additional Requirements
   1. Physical access. The system must reside in a secured, managed data-center.

Exceptions

In some cases, a system may be incapable of implementing a control required by this standard, or there may be a valid business justification for not doing so.

For systems Classified at Protection Levels PL-1 or PL-2 and Availability Levels AL-1 or AL-2, the exception should be documented and approved by the Application Owner.

For systems Classified at Protection Levels PL-3 or P4 and/or Availability Levels AL-3 or AL-4, the risk management process must be used to formally document the exception, identify compensating controls (if applicable), and obtain risk acceptance from all relevant stakeholders.

References

• Standard for Account and Authentication Management
• Standard for Security and Privacy Risk Management
• Standard for Event Logging

Review

This standard is reviewed on a periodic basis and updated as necessary by the Information Security and Privacy Office to ensure it remains accurate, relevant, and fit for purpose.

Document history

Date	Author	Description
Jun 2020	D. Curry	Initial publication
Jun 2020	D. Curry	Corrected reference citations (cosmetic)

Parts of this standard are adapted from New York University's Data and System Security Measures Standard, the contents of which are used with permission.