LE Premise and Cloud Security Control Procedures
Rice OIT Learning Environment mandatory security controls for all service
Learning Environments Service Security Controls Procedures
Procedures related to Rice Learning Environment Security Controls
Baseline Service Security Control Procedures
Table of Contents
- Inventory Procedure
- The operating System and OS vendor provided/supported application and library security patching and updating procedures
- Procedures for implementing administrative access and user access with the least privileges
- Procedure for system build and security configuration deployment
- Procedure for account review for access to services
- Maintenance windows and patch schedule procedures
- Change Management Procedure
- Procedures for provisioning non-production and test services
- Procedures for security incident notification
- Enrolled in the Satellite/Ansible, or AD Rice Active Directory Domain service for inventory control and management for premise hardware
- An inventory of all premise-based services will be maintained minimally including the following:
- Service Name
- Service Model (Premise or Cloud)
- Service Administration group or persons (Contact information)
- Associated Hardware Hostname/IP if Premise
- Data exchange and integration details if any
- Data Classification per Rice Policy 808 for each data integration/exchange
- Integration contact for each integration/exchange
- User authentication mechanism (Local/SSO/Other)
- Maintenance Schedule for the service
- Data Retention Practice for the service
- Data disposal requirements from the vendor contract or documentation
Vendor or Contractor provided/supported security patching and updating procedures
Procedures for implementing administrative access and user access with the least privileges
- All services managed by OIT LE administrators will be configured with administrator access that will limit access to only applications and services that are required by the admin to have access. No direct ssh or other network protocol will be allowed to access the service as an administrator. Sudo, MFA, asymmetric keys, or other suitable mechanisms should be utilized where possible.
- Persons provided administrative access rights will be required to use an account different from their Rice NetID when possible. Local administrator account passwords for all services will be set to a minimum of 12 characters with common complexity standards (mixed case, numerals, and special characters). Services accounts should utilize dynamic session keys or annually rotated randomly generated passwords of length 25 characters.
- Administrative access to the service should be logged in the service and the access logs reviewed monthly for inappropriate access. In lieu of this, if access logs can be provided to ISO programmatically, then reports or alerts can be provided via the Splunk SIEM.
Procedure for service configuration and security configuration deployment
- Premise Systems will contain only the Minimum required services to be installed to fulfill the designed purpose of the service.
- Premise Web-based services are to be front-ended by the EI-managed web service firewall.
- Access for users should require SSO integration.
- Route all requests for administrative access to the service through the Helpdesk ticketing system.
- Work with OIT Enterprise Infrastructure to ensure minimal access firewall rules on the host if it is a premise-based service and document the rules.
- Administrative access will be monitored via logs and access audited monthly to remove ineligible users.
- Disable or remove default administrator, test, or service accounts as soon as they are no longer in use.
- Deploy, enable, and configure only strong ciphers and disable deprecated encryption protocols and ciphers when implementing TLS.
- Deploy trusted public keys for SSH/TLS access to the services. Set up certificate monitoring to ensure service access is not interrupted.
- Do not employ deprecated encryption technology to support older or unsupported browsers.
- Implement and test audit log configuration and central logging services.
- If available for the service and appropriate for the data classification, configure automatic log-off due to inactivity for a reasonable time limit.
Asymmetric authentication keys used for access to the systems or services will be reviewed on a periodic basis and when changes are required. The review period should be no more than one calendar year at a minimum. Keys associated with users or admins who have left the institution shall be revoked in as soon as possible. Admins will utilize the HR-provided weekly distribution of account deactivations. Local accounts not associated with services will conform to OIT or ISO service account password guidelines. Reviews and changes will be documented in the ticketing system or other auditable documents.
Maintenance windows and patch schedule procedures
In order to reduce risks due to vulnerabilities in services or applications, maintenance windows and/or patching schedules will be adapted to fit the cadence of the customers' services or as needed to ensure the regularity of maintenance and reduction of risk of breach. Under no circumstances should patching of a known exploitable vulnerability be delayed on any high-risk services. High-risk services are those with access to or store Rice Confidential or Sensitive Information. Schedules should follow vendor deployment schedule windows to minimize risk as much be possible.
Change Management Procedure
Changes to all services will comply with the Rice OIT change management processes. All but emergency, informational and routine changes are pre-authorized. Risk and impact will be reported to the CAB and a discussion of Normal and higher changes will be communicated via the OIT Status page. Emergency changes will be communicated to management per emergency service procedures.
Procedures for provisioning non-production and test services
Procedures for security incident notification
All services managed by OIT LE will utilize the ISO security incident response protocol. Security incidents will be reported up the chain of command or in parallel as soon as an incident has been identified or suspected.