I

Wireless Devices

If wireless networking is required, the WTS-managed secure wireless network must be used, and WTS must be contacted to ensure that any wireless communications are adequately encrypted.

Wireless point-of-sale devices should not be used on Western's networks. Wifi should be disabled on point-of-sale devices. 

Fax Devices

In compliance with Western's Data Classification Standards, financial information may only be transmitted via analogue fax machines. Transmitting financial information via digital fax machines is prohibited as these devices are not point-to-point and are, therefore, considered no more secure than email.

Voice-over-IP (VoIP)

Transmission of cardholder data via VoIP telephones is prohibited. Traffic over VoIP system is not secured and there is risk of unauthorized internal and external access. Contact the Bank Card Committee to discuss other options available. 

End-user Devices

Any time end-user devices are able to connect to the e-commerce environment for administrative or any other purpose beyond executing a standard payment transaction, that end-user device is considered within the scope of the e-commerce environment.

Each department is responsible for configuration of any such end-user computers in that department. Where a service contract exists between the department and WTS, such configurations will be managed by the WTS Onsite team.

The minimum configuration for such devices includes:

  • Maintaining up-to-date personal firewalls and anti-virus software
  • Patching systems (see below)
  • Enabling security event logging and a password-protected screen saver

Hardcopy Information

Each department is responsible for protecting hardcopies of sensitive cardholder data, and softcopies of such data, generated or stored on devices:

  • Storage, disposal, sanitization, and physical access control:
    • Reference UWO Records Management Services for guidance on disposal of sensitive cardholder data using the confidential records disposal process, and UWO MAPP 1.30 (UNIVERSITY RECORDS AND ARCHIVES POLICY).
    • Only cross cut/confetti shredders, or bonded, secure data disposal services should be used to dispose of hardcopies.
    • Restrict incidental access by restricting visibility of displays (physically, or using glare-reduction screens) and access to printers.
  • Encryption
    • Departments are responsible for ensuring that all storage, processing, transmission of sensitive cardholder data is properly encrypted.
    • Departments are strongly encouraged to use Western's preferred payment gateway for handling sensitive cardholder data electronically.
    • Sensitive cardholder data must never be emailed unencrypted.
  • Need-to-know restrictions on access
    • Physical and logical access to sensitive cardholder data must be restricted to those individuals with a legitimate "need to know."
    • Such access must include individual accountability (unique IDs and passwords) and access logs must be reviewed regularly.

NOTE: Departments/Units are also responsible for ensuring that selected point-of-sale products conform with PCI DSS Requirements.

System Patching

Departmental IT staff must patch all systems within an e-commerce environment in a timely fashion. Where a service contract exists between the department and WTS, such patching will be managed by the WTS Onsite team.

The maximum acceptable patch/update implementation timelines for UWO Bank Card systems are listed below. Administrators of such systems are free to implement patches sooner than listed below.

Severity of patches and updates is determined based on the Common Vulnerability Scoring System (CVSS). System administrators will be able to use a severity rating for the exposure reported within the MITRE Common Vulnerabilities and Exposures (CVE) framework. However, in cases where such a rating does not exist, each area IT team is responsible for identifying any relevant exposures for each e-commerce system and classifying each based on the criteria documented for the CVSS.

Microsoft system users can take advantage of automatic updates using the WTS msupdate service, or using Microsoft's msupdate service directly. All "high-priority" updates must be installed within one week of their release in order for these patching requirements to be met.

Apple system users can take advantage of Apple's Software Update service, described here.

Patching of other operating systems may require more manual intervention.

Patching is not limited solely to the operating system - other applications on a system may expose the entire system to potential compromise. As such, any applications installed on the system must also be patched in a timely manner.

If a patch or update cannot be implemented in the time specified, the system administrator is responsible for fulfilling appropriate risk acceptance requirements within the implementation timeframe.

Severity Implementation Schedule Risk Acceptance Requirements
Critical 7 calendar days H/M/L requirements + Bank Card Committee* approval required
High 14 calendar days M/L requirements + system owner** approval required
Moderate 28 calendar days L requirement + Area IT manager*** approval required
Low n/a System adminsitrator must document non-implementation decision

* The Bank Card Committee can be contacted when acceptance of risks which would be mitigated through a critical patch/update is required.

System owners, their IT managers, and system administration personnel are strongly encouraged to avoid such requests except in situations where application of the patch/update without an extended testing/validation period puts the system at greater risk than would the exposure that is addressed by the patch/update.

** System owner is the individual with overall responsibility for the specific bank card system - typically not an IT resource.

For CPPS-based systems, this is a collaborative process between the WTS Associate Directors of Client Support and Technical Services

*** Area IT manager is the individual responsible for IT operations for the department affected.

For CPPS-based systems, this is a collaborative process between the WTS Associate Directors of Client Support and Technical Services.

Application Security & Application Development Security

In accordance with section 6.2 of the current PCI DSS standard, each department is responsible for the security of any custom applications that it has developed for e-commerce. Section 6 of the PCI DSS includes several requirements, all of which need to be fulfilled before a custom application can be implemented - and many of which require regular activity on the part of the developers and/or system administrators as part of change management.

Contact WTS for additional support and guidance on securing custom applications.

For off-the-shelf software, it is the department's responsibility to ensure that the selected product meets the requirements of the PCI Payment Software Security Framework (PCI SSF) before the software can be implemented, including certification of the software if it is not already on the PCI SSF approved software list.

All applications that process sensitive cardholder data must be developed in a manner that incorporates the Open Web Application Security Project (OWASP) standards. Such applications must be tested to validate protection against, at a minimum, the current stable version of the OWASP Top Ten code vulnerabilities.

Developers of applications that process sensitive cardholder data must be trained yearly in secure coding techniques, through specialized education and/or by demonstrating secure coding expertise through independent reviews and testing of custom-developed code.

Firewalls

Western has segmented its network and logically separated virtual Local Area Neworks (VLANs) for use by it's e-commerce and payment card point of sales device infrastructure. This was done to facilitate Western's conformance to the current Payment Card Industry Data Security Standards (PCI DSS).

Any system that processes sensitive cardholder data must be segmented into one of five e-commerce protected VLANs and protected by an WTS-managed physical firewall that, at a minimum, isolates the application server from other non-PCI systems in a DMZ, and isolates any database server from non-PCI systems in a tightly restricted zone.

Changes to firewall policies must be explicitly approved by the CISO on behalf of the Bank Card Committee. Firewall rule changes that materially alter the security posture of these VLANs mus be documented for the Bank Card Committee by WTS and retained pending future PCI audits. Firewall ruleset reviews must be performed after each policy change, or at a minimum, on a semi-annual basis.

In specific, limited circumstances, WTS may delegate the activation/deactivation of a specific rule (e.g., to enable remote support by a 3rd party) to the Unit responsible for the relationship with that 3rd party. In such cases, WTS retains all policy management responsibilities, including verifying that the delegated activation/deactivation is being performed in accordance with WTS firewall management practices.

It is up to the Merchant to identifiy to the Network Operations Group a network connected device as being a payment card device when first being added to the network. The Network Operations Group will ensure that the device and its associated circuit are in the approved VLAN.

Western PCI VLANs Protection and Change Control

In Accordance with section 1.1 of the current PCI DSS standard, the WTS Network Operations Center (NOC) will establish and maintain a Firewall (FW) to safeguard the following VLANs designated for sole use by Payment Card Industry point of sale devices:

  • 259 - NSC
  • 262 - StvH
  • 345 - SEB
  • 565 - Book Store Private

All changes to the firewall protecting the above VLANS must be documented and tested by the NOC. Changes that materially affect the security posture of these VLANS must be approved by the Security Operations Center (SOC) on behalf of the Bank Card Committee who will also review the firewall policy of these VLANS semi-annually.

The firewall protecting the PCI VLANs will:

  1. Restrict connections between the above stated VLANs and the internet and between the above stated VLANs and the rest of campus including Connect IT;
  2. Restrict Inbound and outbound traffic to that which is necessary for the cardholder data environment and specifically deny all other traffic;
  3. Prohibit direct public access between the Internet and system components within these VLANs;
  4. Implement anti-spoofing measures to detect and block forged source IP addresses from entering the network (i.e. block traffic originating from the Internet with an internal source IP);
  5. Deny unauthorized traffic from the card holder data environment to the Internet;
  6. Implement stateful inspection or dynamic packet filtering allowing only established connections on the network.
  7. Be configured in a secure and hardened manner in accordance with the requirements set forth in the PCI DSS standards and as directed by the Secure Hardening Guidelines maintained by the PCI Working Group.

In addition, these above security policies and operational procedures for managing are to be known by all applicable NOC personnel.

System Configuration, Hardening & Vulnerability Management

Any web server and/or application hosted on campus or operated in the cloud by a unit of Western University, or a third-party vendor on behalf of said Western units, that engages in the collection, processing, transmission and storage of cardholder data for any type of financial transaction is defined as an e-commerce server and is considered in-scope of our PCI cardholder data environment (CDE). These servers and/or applications must adhere to the requirements set out in PCI-DSS.

In accordance with section 1.5 of the current PCI DSS standard, all devices that process, transmit or have the ability to connect to both trusted PCI networks as well as the internet must be hardened as set forth in the Western Hardening Guidelines as maintained by the PCI Working Group.

  • If your server and/or application is hosted on campus, you are responsible for ensuring that the PCI DSS requirements set out in SAQ A-EP are being fulfilled. The PCI working group will work with you to complete a responsibility matrix and document your adherence to these requirements.
  • If your Ecommerce storefront is hosted by a 3rd party in the cloud, please follow the requirements listed on the next page (3rd Party Service Providers).
  • If your Ecommerce storefront is a PurplePay application, the hardening of the servers is being managed by WTS. 

 

You must be aware of your responsibilities when taking on application, network and system administrative roles (https://wts.uwo.ca/administrator_responsibilities). Roles and responsibilities must be documented, assigned and understood. 

If your unit has questions about the content of these guidelines or your responsibilities, please contact pci-wg@uwo.ca.

Any system that processes sensitive cardholder data must be built according to current WTS build standards, using standard WTS products and, incorporating industry and security best practice configurations including:

In addition, all components of such systems (as well as any non-PCI systems that enable access to such components) must enforce the use of automated access controls and a "deny all" configuration for any user who is not explicitly authorized to access the system. All such components must also be registered in RAMP, with up-to-date information about the device owner/contact and purpose.

In accordance with sections 7.2.4 and 7.2.5 of the current PCI DSS standard, all user accounts, system accounts and access privileges for systems in the CDE must be reviewed and verified at least every 6 months, with any inappropriate access being remediated.

In accordance with section 10.2 of the current PCI DSS standard, full audit logging must be enabled and configured to capture all required information. See the Hardening Guidelines maintained by the PCI Working Group for full details, contact pci-wg@uwo.ca with any questions or to request a copy of the Hardening Guidelines.

All such systems are subject to normal vulnerability scanning by WTS, both to validate the initial configuration as well as to ensure that a secure configuration is maintained throughout the life of the system.

Administrators of such systems are responsible for verifying the results of vulnerability scans on a monthly basis, remediating any gaps identified by those scans, and updating build standards based on any configuration changes resulting from such gap remediation efforts.

Alerts from security monitoring systems must be submitted to the Bank Card Committee for review.

In accordance with section 10.6 of the current PCI DSS standard, all such systems must have their time services configured to synchronize the system clock to a WTS approved network time server. Please contact pci-wg@uwo.ca for guidance.

Change Management

In accordance with section 6.5 of the PCI DSS standard, all changes to systems that process or transmit sensitive cardholder data must meet the following minimum criteria:

  1. Written request for change (including the impact of the change and a backout plan where appropriate)
  2. Explicit written approval from management responsible for the system
  3. Testing of the change
  4. Written confirmation that the change has been completed and/or backed out

These requirements apply to system configurations, network/firewall policies, application code changes, and system access changes.

Change request/approval history must be retained securely for a minimum of one year subsequent to the change being implemented.

Remote Access & Administration

Any remote access to systems that process or transmit sensitive cardholder data must:

  1. Use the WTS-provided secure remote access solution, which provides automatic disconnection of sessions
  2. Include controls to ensure that 3rd party/vendor remote access is activated only when needed, and deactivated immediately after use
  3. Prevent the copy, movement, or storage of cardholder data onto the remote system

In accordance with section 8.3 of the current PCI DSS standard, all administrative access to systems in the CDE must be protected by WTS approved Multifactor Authentication (MFA) software. For guidance on what MFA solutions are available for use, please contact pci-wg@uwo.ca .


Technical Breaches

In the event that a suspected or confirmed technical breach, the NSO and CISO (nso@uwo.ca) must be engaged to lead the assessment of the technical risk (in conjunction with the system administrators responsible for the specific systems of concern).  This ensures the activation of Western's Security Breach Protocol and notification of all appropriate authorities.