Information Technology and Security of Credit Card Processing Procedures
Device and Network Restrictions
Only computing devices including servers, end-user devices and networks managed by IT Services will be authorized to perform credit card transactions by the PCI Steering Committee.
Wireless Devices
TRU's network excluding cellular networks may not be used for payment card transactions. If wireless networking is deemed to be required, an exception must be requested from the TRU PCI Steering Committee.
Fax Devices
In compliance with TRU's Information 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.
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.
All end-user devices must be authorized, configured and managed by the TRU ITS Division.
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 faculty, school and division 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 Records Retention/Destruction for guidance on retention periods.
- For disposal of sensitive cardholder data please reference TRU's Information Classification Standards.
- 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
- Faculties, schools and divisions are responsible for ensuring that all storage, processing and transmission of sensitive cardholder data is properly encrypted.
- Faculties, schools and divisions are required to use TRU's preferred payment gateway for handling sensitive cardholder data electronically.
- Sensitive cardholder data is never to be emailed.
- 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 the use of the ASAR process which incorporates authentication by a supervisor and authorization by data owner, unique IDs and passwords. Access logs must be reviewed regularly.
NOTE: Faculties, schools and divisions are also responsible for ensuring that selected point-of-sale products conform with PCI DSS Requirements.
System Patching
ITS must patch all systems within an e-commerce environment in a timely fashion.
The maximum acceptable patch/update implementation timelines for TRU Credit 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), ITS 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 WSUS service. 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.
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 within the CDE cannot be implemented within 30 days, the system administrator is responsible for ensuring that risk is accepted by TRU PCI Steering Committee.
* The PCI Steering Committee can be contacted when acceptance of risks which would be mitigated through a critical patch/update is required but cannot be applied for a legitimate technical or business reason.
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.
Application Security
All eCommerce applications must be approved by Financial Services and IT Services.
ITS 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 responsibility of the faculties, schools and divisions 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.
Firewalls
Thompson Rivers University has segmented its network and logically separated virtual Local Area Networks (VLANs) for use by it's e-commerce and payment card point of sales device infrastructure. This was done to facilitate TRU'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 the e-commerce protected VLANs and protected by an ITS-managed 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 director technical services on behalf of the TRU PCI Steering Committee. Firewall rule changes that materially alter the security posture of these VLANs must be documented for the TRU PCI Steering Committee by ITS and retained pending future PCI audits. Firewall rule-set reviews must be performed after each policy change, or at a minimum, on a semi-annual basis.
It is up to the Merchant to identify to the Network and Technical Services a network connected device as being a payment card device when first being added to the network. The Network and Technical Services will ensure that the device and its associated circuit are in the approved VLAN.
TRU PCI VLANs Protection and Change Control
In Accordance with Sec. 1.1 of the current PCI DSS, ITS will establish and maintain Firewalls to safeguard the following VLANS designated for sole use by Payment Card Industry point of sale devices:
- 128 bkcashreg
- 128 bkserver
- 124 TRU PCI
- 125 TRU PCI
All changes to the firewall protecting the above VLANS must be documented and tested by ITS. Changes that materially affect the security posture of these VLANS must be approved by AVP Digital Strategy and CIO on behalf of the PCI Steering 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 the campus network;
- 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 ITS personal.
System Configuration, Hardening & Vulnerability Management
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:
- 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 TRU CMDB, 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 quarterly 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 Information Security Office for review.
Change Management
All changes to systems that process sensitive cardholder data must comply with the ITS Change Management Policy.
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 ITS provided secure remote access solution, which provides automatic disconnection of sessions
- Use the ITS provided 2 factor authentication solution
- 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 of a suspected or confirmed technical breach, the Information Security Office 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 the TRU Incident Response Guidelines and TRU's Breach Protocol and notification of all appropriate authorities.
