M10, Security Architecture and Firewalls

Information Security Standard

1. Introduction

• 1.1 This document defines minimum standards to be followed by University IT Support Staff for the security architecture, Firewall configuration, and secure network protocols of UBC Systems and UBC Electronic Services to ensure they are adequately protected. Without adequate security, these systems and services provide an avenue for malicious activity such as theft of UBC Electronic Information or the denial of service to UBC resources.
• 1.2 These standards apply to all UBC Systems and UBC Electronic Services.
• 1.3 These standards are critical for UBC Systems that are Client-facing (e.g., Web Servers, or other Servers that are visible or accessible from the Internet) as they are prime targets for exploitation and therefore pose a high risk to the University.
• 1.4 The Chief Information Officer has issued this standard under the authority of Policy SC14, Acceptable Use and Security of UBC Electronic Information and Systems. Questions about this standard may be referred to information.security@ubc.ca.

2. Security Architecture Requirements

• 2.1 When processing High or Very High Risk Information, web, application and database functions must either be hosted separately, or have compensating controls approved by the CISO implemented commensurate with the risk, such as:
  • 2.1.1 Web Application Firewall;
  • 2.1.2 file integrity monitoring;
  • 2.1.3 Intrusion Detection Systems/Intrusion Prevention Systems;
  • 2.1.4 log monitoring (e.g., SIEM); and
  • 2.1.5 network segmentation.
• 2.2 In all other cases, web, application and database functions should be either hosted separately or have compensating controls.
• 2.3 Controls must be implemented to prevent unnecessary network communication between functions that are hosted separately. For example, Web Servers are permitted to communicate with Application Servers but not with Database Servers.
• 2.4 All Servers and services must be accessed exclusively via a controlled, Boundary‑protected Interface where technically possible (e.g., Network Firewall, security group, ACL, WAF).
• 2.5 All Client-facing Servers and services must be logically separated from non-Client-facing Servers and services.
• 2.6 All non-Client-facing Servers and services (e.g., Database Servers) must have their network access controlled by the Principle of Least Privilege, strictly limiting connectivity to securely-managed and explicitly approved subnets or IP address ranges necessary for their operational function.
• 2.7 Client-facing Web Servers that transmit, store or process High or Very High Risk Information must be located behind an approved Web Application Firewall (WAF). In all other cases, a WAF is recommended.
  • 2.7.1 Vendor-delivered SaaS and PaaS solutions are not required to have a WAF, unless specified through an assessment, such as a Privacy Impact Assessment (PIA) or Security Threat Risk Assessment (STRA).
• 2.8 Access to all Medium, High and Very High Risk Information on Servers must be authorized and limited following the Principle of Least Privilege.
• 2.9 Client-facing UBC Electronic Services such as websites or Web Applications used to conduct University Business must be provisioned within the ubc.ca domain name space, e.g., widget.ubc.ca, unless not technically possible.

3. Network Protocol Requirements

• 3.1 Transmission of Medium, High or Very High Risk Information must be encrypted and comply with the following requirements:
  • 3.1.1 all TLS communications must use the Intermediate configuration as defined in Mozilla Security/Server Side TLS recommendations, and should use the Modern configuration where possible;
  • 3.1.2 information transmitted via other protocols (e.g. SSH) must be encrypted using a minimum of AES-256 bit Encryption with mutual authentication between the Server and User;
  • 3.1.3 known weak network protocols must be disabled; and
  • 3.1.4 where possible, post-quantum encryption protocols for asymmetric key exchange must be used.
• 3.2 Transmission of Low Risk Information is strongly recommended to comply with the requirements in Section 3.1.
• 3.3 Where technically possible, all HTTP requests must be re-directed to HTTPS.
• 3.4 Users frequently access desktops, laptops, and Servers remotely. Remote Access covers a broad range of technologies, protocols and solutions (e.g., RDP, SSH, VNC, VDI, terminal services, etc.). Remote Access must comply with the following requirements, where possible:
  • 3.4.1 For remote privileged access, a Privileged Access Management (PAM) proxy service (preferred), limited access VPN pool, bastion host, or reverse remote protocol proxy must be used.
  • 3.4.2 For remote user access, a VPN, bastion host, or reverse remote protocol proxy must be used.
• 3.5 VPN connections must be encrypted and restricted at both ends to the minimum number of systems necessary. To support this:
  • 3.5.1 DNS or service-based split tunneling (e.g., Dynamic Split Tunneling) may be used with authorization of specific services by the CISO;
  • 3.5.2 When the VPN is active, access to the local LAN must be disabled except with authorization by the CISO; and
  • 3.5.3 IP or subnet-based split tunneling must not be enabled.

4. Firewall Configuration

• 4.1 UBC Systems storing Medium, High or Very High Risk Information must be protected by a Network Firewall.
• 4.2 Firewalls are only as effective as their Access Control List (ACL) rule set, which determines how traffic is blocked or passed. Where Firewalls enforce ACL rule sets, rules must be configured as follows:
  • 4.2.1 a ”Deny by Default” policy must be implemented;
  • 4.2.2 enabled "Any-Any-Allow" rules must not exist anywhere in the rule set;
  • 4.2.3 ports for services that are not required or have no corresponding service on destination hosts must be denied, e.g., TCP/443 (HTTPS) or TCP/22 (SSH);
  • 4.2.4 Firewalls must use ingress filtering at a minimum, and should use egress filtering if it is used to protect High or Very High Risk Information;
  • 4.2.5 ACLs must restrict traffic to the minimum necessary to conduct University Business; and
  • 4.2.6 rule sets must be reviewed annually for optimization and validation of effective rules.
• 4.3 Network Firewalls configured to control access to different zones must be dedicated Firewalls. Firewalls should never be used for multiple purposes beyond access control and monitoring. Next-generation Firewalls, Unified Threat Management (UTM), and virtual Firewalls are still considered to be dedicated;
• 4.4 Boundary-protected interfaces must use Access Control Lists that restrict traffic to only the minimum necessary to conduct University Business;
• 4.5 Boundary-protected interfaces directly facing the internet must also perform automated traffic inspection on ingress traffic sufficient to ensure that unauthorized or malicious traffic that would otherwise pass the boundary is blocked or mitigated as required. This same principle must also be applied to egress traffic;
• 4.6 Where high-availability is required, standby Firewalls should be configured to take over the services of primary Firewalls in the event that the primary fails. This also implies that standby Firewalls must be kept up-to-date with changes made to the primary Firewall to properly support this capability;
• 4.7 If a Firewall is a single point of ingress and it fails, it must fail in a closed state and not allow passage of data traffic through it;
• 4.8 Network Firewalls must be capable of ”stateful packet inspection”, and this capability must be turned on;
• 4.9 All Firewall critical alarms must generate an automatic notification to the Firewall administrator;
• 4.10 To facilitate defense in depth, Servers must also be protected by a Host-based Firewall if available;
• 4.11 Firewall audit logs must be stored and monitored in accordance with the Logging and Monitoring of UBC Systems standard; and,
• 4.12 Firewalls must be hardened, patched and scanned in accordance with the Vulnerability Management standard.

Related Documents and Resources

Policy SC14, Acceptable Use and Security of UBC Electronic Information and Systems

Vulnerability Management standard

Logging and Monitoring of UBC Systems standard

Case Studies in Security Architecture and Firewalls

Standard Last Revised: 2026-01