Overview

Exposed services are defined as systems and applications hosted on the university network that are accessible over the internet, with common examples being hosted web applications or file shares. The purpose of this standard is to ensure that these services are operating with the least privileges required to perform their intended functions, thereby limiting the potential attack surface.

Authentication

Exposed services hosting sensitive or user-specific data must require SSO (CAS or Entra) authentication for access. The information security office (ISO) strongly encourages the usage of CAS or Entra ID for this purpose. If university-provided SSO cannot be integrated into the system, an exception must be filed with the ISO as outlined in the Systems and Application Security Policy.

Firewall

All university-managed applications hosted on the university network or hardware should be behind at least 1 university-managed firewall. The application administrator must review the vendor’s documentation (if applicable) for firewall configuration for each system hosting exposed services and use it to determine the least privilege access required for the system’s intended operation. While this information can and should be used to inform the firewall configuration, further restrictions should be applied where possible to limit unnecessary access. A proposed firewall rule configuration should be submitted to the ISO for implementation on the appropriate university firewall.

For example: if only a specific subset of devices/networks will be accessing the service, the firewall rules should be adjusted such that they are only applicable to those devices. Suggestions from vendors to open rules allowing all traffic over a port or protocol should be heavily scrutinized prior to submission to ensure that they align with the intended use case.

Encryption in Transit

Exposed services must be configured for encryption in transit using a supported version of TLS. The use of HTTP Strict Transport Security (HSTS) should be configured on all web servers. UConn ISO recommends aligning with the intermediate configuration applicable to your server software available at TLSRef TLS Configurator (formerly operated by Mozilla.)

Certificate Management

Must have valid SSL/TLS certificate; services that require bypassing browser protections are prohibited. Services requiring that users bypass SSL/TLS services are prohibited. TLS certificates are available, fully subsidized through the University’s InCommon.

As of 2025, the security certificate industry is moving to shorter, more frequently renewed certificates (45-90 days) as opposed to longer renewal periods. As a result, automated cert deployment/renewal process is highly recommended to reduce the amount of maintenance required to maintain up-to-date certificates.

Endpoint Detection & Response (EDR)

Systems hosting exposed services must each be onboarded to the university-managed EDR solution to enable continuous security monitoring and threat protection. In the event that the application owner can produce demonstrable evidence that EDR is preventing the exposed services' from performing its intended function, owners must coordinate with the Information Security Office to determine the root cause and participate in troubleshooting these issues to determine if they can be resolved. If the ISO determines that these issues are unresolvable, the owner may request an exception to this requirement.

No exceptions will be approved without first demonstrating that the installed agent is preventing the service from fulfilling its intended function and participating with the ISO to resolve any identified issues. Any granted exceptions will be subject to increased hardening standards, the extent of which will be determined by the ISO as deemed appropriate for the service’s role and risk factors.

Application Security Scanning

Owners of university web applications hosting protected or confidential data (as defined by the data classification policy) or authentication services are required to contact the ISO to conduct an assessment to determine if it is a candidate for application security scanning. AppSec scans are also available and encouraged for web applications that are not storing protected or confidential data.

Patch and Vulnerability Management

Owners of exposed services are required to comply with the university’s vulnerability management standards for patch and vulnerability management. This applies to application, firmware and operating system patches. For services hosted on unmanaged devices, scanning credentials must be supplied to the ISO to allow for authenticated scanning. Additionally, servers hosting these services should align with at least L1 CIS security benchmarks applicable to the operating system.

All systems must be enrolled in University patch management. The university’s managed server offering provides OS patch management for through SCCM and RedHat Satellite for Windows and RedHat servers respectively. In the absence of either option, system administrators must have an alternative patch management system in place to ensure systems stay up to date.

Server Architecture

Test and development web applications should be blocked from external access; only production web applications should be exposed to and accessible by the intended end users.

Distributing applications in this manner ensures that firewall rules can be configured appropriately for each server role individually and limits exposure of backend servers to the internet when configured with least privilege access.

Log Collection

All systems and applications with exposed services must be configured to forward both system and application logs to the University’s Splunk instance and must comply with any additional requirements outlined by the UConn Logging Standard.

Lifecycle Management

System owners are required to maintain up‑to‑date operating systems, codebases, applications, and hardware for all exposed services. Components that are past vendor end of life (EOL) or no longer receiving security updates must not be used to host exposed services unless an exception has been approved by the ISO with documented compensating controls and a defined retirement date.

A documented system lifecycle plan must be in place for each exposed service. At a minimum, this plan should:

Identify all critical components (OS, application frameworks, databases, hardware, third‑party services) and their vendor support/EOL dates.

Describe the strategy and timelines for upgrades and technology refresh (e.g., planned OS and application version changes).

Define criteria and procedures for decommissioning the service, including data migration/archival, secure data destruction, removal of DNS entries, certificates, firewall rules, and access accounts.

Security Contacts

Manages servers/services must have a functional and technical owner declared and documented and these records must be contained in the University’s instance of Jira assets.