Information Technology Code of Procedure
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
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 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 Sec. 1.1 of the current PCI DSS WTS’s 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 CISO 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:
- Restrict connections between the above stated VLANS and the internet and between the above stated VLANS and the rest of campus including Connect IT;
- Restrict Inbound and outbound traffic to that which is necessary for the cardholder data environment and specifically deny all other traffic;
- Prohibit direct public access between the Internet and system components within these VLANs;
- 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);
- Deny unauthorized traffic from the card holder data environment to the Internet;
- Implement stateful inspection or dynamic packet filtering allowing only established connections on the network.
In addition, these above security policies and operational procedures for managing are to be known by all applicable NOC personal.
System Configuration, Hardening & Vulnerability Management
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:
- Operating system-specific guidance from the OS vendors
- Center for Internet Security hardening guidelines & tools
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.
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 weekly 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.
Change Management
All changes to systems that process sensitive cardholder data must meet the following minimum criteria:
- Written request for change (including the impact of the change and a backout plan where appropriate)
- Explicit written approval from management responsible for the system
- Testing of the change
- 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 sensitive cardholder data must:
- Use the WTS-provided secure remote access solution, which provides automatic disconnection of sessions
- Include controls to ensure that 3rd party/vendor remote access is activated only when needed, and deactivated immediately after use
- Prevent the copy, movement, or storage of cardholder data onto the remote system
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.