Server Application Security

Objective
In accordance with the Information Security and Acceptable Use Policy, all applications developed, licensed, and/or operated by OCC must be adequately protected to ensure confidentiality, integrity, availability, and accountability of such systems.

Physical Location
All production server-based applications should be operated on servers in rooms that meet the
applicable minimum standards defined in the Procedure for Server Rooms.

Support Requirements
All server-based applications must have a valid support contract or, in the case of open-source software, be commercially or community supported. Costs to maintain appropriate information security must be included in the project’s budget.

Patching
All applications must be at least at version n-1. Security patches must be installed in a timely manner, depending on the likelihood and impact of vulnerability exploitation, at least within 30 days of release.

Directory Name Service (DNS) Naming
When warranted to promote application migration to alternate hardware, applications should be accessed via a DNS alias, rather than the name of the server that hosts the application.

Authentication and Access Control
Applications that host Confidential or Controlled Data must adequately limit access to view or change that data to individuals requiring such access. All applications, including those which host Public Data, must adequately limit access to change that data to individuals requiring such access. When feasible, Active Directory (AD) should be used as the authentication mechanism.

Encryption
Exchange of Confidential Data, including authentication credentials, must be performed via an encrypted channel using trusted certificates such as those provided by the IT. Use of self-signed certificates in production environments is not recommended. Confidential Data in transit must be encrypted using a minimum of 256-bit encryption.

System Logon Banner
Internet-facing applications that require authentication must be configured to present users with the College logon banner, as follows

Use of OCC Information Systems is subject to the OCC Information Security and Acceptable Use Policy. Pursuant to Michigan and Federal law: (1) Unauthorized use is prohibited; (2) Usage may be subject to security testing and monitoring; (3) Misuse is subject to criminal prosecution; and (4) Users have no expectation of privacy except as otherwise provided by applicable privacy laws.

Automatic Log-off
Applications that require authentication must be configured to automatically end a user’s session/lock screen after a time consistent with t e business purpose of the application. IT recommends 15 minutes
of inactivity for applications serving Confidential Data.

Application activity with protected data must be logged and retained for a minimum of 90 days to facilitate troubleshooting and investigations. The following types of activities must be logged:

• Successful and unsuccessful login attempts
• Any application or data modification operation, such as insertion, updates, or deletion of data, changes to application configuration, etc. Logging of read / query activities is required for applications containing HIPAA data and is recommended for other applications when feasible. Application logs should also be sent to a centralized logging server to reduce storage requirements on local systems and reduce feasibility of log tampering.

Vulnerability Assessment
All applications are subject to periodic application vulnerability scans conducted or sponsored by IT. For applications that are Internet-accessible or host Confidential or Controlled Data, these scans must be conducted at least annually. All other applications must be scanned for application vulnerabilities every two years. System owners are responsible for timely remediation of identified vulnerabilities.

Configuration and Access Control
Applications must be developed and maintained with appropriate security controls. Controls must also be documented. Some examples include:

• Files not in use should be removed from production systems.
• Directory viewing on web application server should be disabled.
• Only users tasked with making application updates should be granted write access within application root folders.
• HTML static pages must not have execute permissions.
• Logon or authentication cookies must not be persistent.
• Hostnames, usernames, or database names should not be hardcoded into applications and scripts.
• Back-end servers must verify the identity of requesting webservers.

Authentication Session Management
Authentication session management protocols will be used in web applications for testing, development, and production environments. Such access controls include, but are not limited to:

• New session IDs are generated for each new login request.
• Session IDs should be random and not sequential in nature.
• Encryption is required to protect authentication of session IDs in transit between servers and clients.
• Session data must not readily identify users or individuals.
• All session data must be destroyed when a user logs off.

Data Validation
All input of data, including usernames and passwords, must be verified on the server side of the
application. Client-side validation is encouraged but should not be relied upon for validation.

Database Interfaces
When present, database interfaces should be configured to provide adequate security controls.
Examples include:

• Storage of database names, usernames, passwords, and hostnames should reside outside of the code base.
• Web applications should use dedicated accounts that are not default database accounts and do not have administrative privileges on such databases.
• Applications must use encryption to access Confidential or Controlled Data on databases located on other systems.

Incident Management
Application owners are required to report any suspicious activity to the IT for investigation.

Backups
Unless backup functions are configured at the server level, application data must be backed up in an automated fashion consistent with the business requirements for recovery time objective (length of time the system can be offline) and recovery point objective (amount of data at risk since the most recent backup, replication, or other data protection event). Stored backups must also meet security protections comparable to the source server.

Business Continuity Planning / Disaster Recovery
All mission-critical systems must be covered by an applicable Business Continuity Plan (BCP) and Disaster Recovery (DR) plan.

Exemptions
In the event that compliance with this Server-based application procedure cannot be met, please contact itsecurity@oaklandcc.edu to submit an exemption request which will be approved or denied by IT. Denied exemption requests may be appealed to the CIO for final decision.

Change Log

• 07-01-2018  Effective date