If wireless networking is required, the ITS-managed secure wireless network must be used, and ITS must be contacted to ensure that any wireless communications are adequately encrypted.
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.
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 ITS, such configurations will be managed by the ITS Onsite team.
The minimum configuration for such devices includes:
Each department is responsible for protecting hardcopies of sensitive cardholder data, and softcopies of such data, generated or stored on devices:
NOTE: Departments/Units are also responsible for ensuring that selected point-of-sale products conform with PCI DSS Requirements.
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 ITS, such patching will be managed by the ITS 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 SANS™ Critical Vulnerability Analysis (CVA) scale – ideally, system administrators will be able to use a severity rating for the exposure reported within SANS™ publication @Risk: The Consensus Security Alert. However, in cases where such a rating does not exist (for example, for “Part II” exposures reported in @Risk), 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 SANS™ CVA scale.
Microsoft system users can take advantage of automatic updates using the ITS 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 ITS 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 ITS Associate Directors of Client Support and Technical Services.
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 ITS 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 Application Data Security Standard (PA-DSS) before the software can be implemented, including certification of the software if it is not already on the PA DSS 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.
Western has segmented its network and logically separated vitual Local Area Neworks (VLANs) for use by it's ecommerce 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 six ecommerce protected VLANs and protected by an ITS-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 ITS 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, ITS 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, ITS retains all policy management responsibilities, including verifying that the delegated activation/deactivation is being performed in accordance with ITS 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.
In Accordance with Sec. 1.1 of the current PCI DSS ITS’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:
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:
In addition, these above security policies and operational procedures for managing are to be known by all applicable NOC personal.
Any system that processes sensitive cardholder data must be built according to current ITS build standards, using standard ITS 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.
All such systems are subject to normal vulnerability scanning by ITS, 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.
All changes to systems that process sensitive cardholder data must meet the following minimum criteria:
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.
Any remote access to systems that process sensitive cardholder data must:
In the event that a suspected or confirmed technical breach, the NSO and CISO 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.