CSP - IT Rep - Review Controls

U3 5.1
Due to the sensitivity of Payment Card Industry (PCI) Information, it is subject to the following additional requirements:

• PCI Information must only be stored in approved Merchant Systems;
• PCI Information must never be transmitted via email or instant messaging systems. This activity is prohibited;
• PCI Information must never be transmitted unencrypted by any of the other above methods;
• media containing PCI Information must be sent by secured courier or other delivery method that can be accurately tracked; and
• management must approve the transfer of PCI Information from a secured area.

M6 5.1
Users responsible for Merchant Systems must:

• ensure that a perimeter firewall is in place between any Wi-Fi network and Merchant Systems processing Payment Card Industry (PCI) Information. These firewalls must be configured to deny or control any traffic from the Wi-Fi environment to Merchant Systems;
• test for the presence of unauthorized WAPs on a quarterly basis. Note: Methods that may be used in the process include, but are not limited to, Wi-Fi network scans, physical/logical inspections of system components and infrastructure, network access control NAC), or Wi-Fi IDS/IPS; and
• report any unauthorized WAPs as a security incident, in compliance with the Reporting Information Security Incidents standard.

M10 4.1
University IT Support staff must configure Remote Access technologies, used in Merchant Systems, to automatically disconnect User sessions after a specific period of inactivity. 30 minutes is recommended.

U4 1.2
Standards for Users to report any suspicious incidents relating to the security of UBC Electronic Information and Systems. University IT Support Staff (including both departmental IT and UBC IT staff) are responsible for handling security incidents in coordination with UBC Cybersecurity.

SC14 6.1.6
ensuring that breaches and potential breaches of this policy occurring within their unit are resolved and/or referred to the CIO, as appropriate, and that where they are so referred, continuing to assist in the investigation, preserving evidence where required

U4 2.1
Users must report the following information security incidents (if there is uncertainty about whether a violation has occurred, Users must err on the side of caution and report the incident anyway):
 

• all violations of Policy SC14, Acceptable Use and Security of UBC Electronic Information and Systems; examples include but are not limited to:
• use of UBC computing facilities to commit illegal acts;
• unsolicited or spam email originating from UBC sources;
• unauthorized access, use, alteration or destruction of UBC Electronic Information or UBC Systems, including but not limited to: software, computing equipment, Merchant Systems, network equipment and services;
• theft of any UBC Electronic Information whether it be via electronic means or physical theft of any Device containing this information; and
• loss or theft of any Multi-Factor Authentication Device (MFA Device).
• unauthorized wireless access points discovered in either merchant areas or areas accessing, transmitting or storing UBC Electronic Information; and
• use of Malicious Code, which may show up as unexplained behaviour on desktops, laptops or servers such as webpages opening by themselves, new files or folders appearing on the local hard drive, and lockouts of user accounts.

M5 6.2
Firewalls are only as effective as their Access Control List (ACL) rule set, which determines how traffic is blocked or passed. Firewall ACL rule sets must be configured as follows:

• a ”Deny by Default” policy must be implemented on all firewalls;
• services that are not explicitly permitted must be denied;
• firewalls must use ingress filtering at a minimum and must use egress filtering if it is used to protect High or Very High Risk Information;
• ACLs must restrict traffic to the minimum necessary to conduct University Business; and
• rule sets must be reviewed annually for optimization and validation of effective rules.

M5 2.5
Unpatched software is frequently exploited by malicious individuals to access information or resources. To mitigate this threat, vendor provided patches for UBC Systems (e.g. operating systems, applications, databases, etc.) must be patched, with service outages where required, in accordance with Severity Ratings for Vulnerabilities (CVSS) or as defined by the vendors or other third parties as follows:

• Critical-Severity Vulnerabilities as soon as possible, preferably within 72 hours of the patch release;
• High-Severity Vulnerabilities as soon as possible, preferably within 14 days of the patch release; and
• Medium-Severity Vulnerabilities as soon as possible once all Critical and High-Severity Vulnerabilities have been resolved.

M4 3.2
Authentication systems for User Accounts must be adequately protected from password cracking using at least one of the following methods:

• the account is locked for a period of time if an incorrect number of passwords/passphrases is entered over a specified time period (for example, if an incorrect password/passphrase is entered 10 times within a 30 minute window, the account will be locked for 30 minutes); and/or
• each time an incorrect password/passphrase is entered, the system introduces a delay before providing the failure response; this delay increases as the failed login attempts continue but will reset once the User successfully logs in (for example, the delay period could begin at 100 milliseconds, and double after each subsequent failed login).

M7 2.4
Whenever a password or passphrase is used as an encryption key (”Key”), it must follow the standards defined in the Passphrase and Password Protection standard, which details strong password/passphrase construction. Keys that are compromised (e.g. lost or stolen) must be reported immediately in accordance with the Reporting Information Security Incidents standard. The Key must be revoked or destroyed and a new key generated. Key re-assignments require re-encryption of the data.

M7 4.1
For encryption to be effective, encryption Keys must be protected against unauthorized disclosure, misuse, alteration or loss. In order to reduce the risk of loss or exposure of Keys, it is recommended that all Key management processes be performed with automated software. A Key management plan must also be in place that covers the following process areas:

• Key Generation
• Key Distribution
• Key Storage and Protection
• Key Recovery
• Key Change

M7 2.6
The following requirements apply to X.509 certificates:

• X.509 certificates used for the securing of Medium, High or Very High Risk Information during User transmission must be issued by a trusted third party CA, as part of a Public-Key Infrastructure (PKI);
• server-to-server transmissions should be encrypted and should use a trusted third party certificate;
• newly purchased or renewed X.509 certificates must be a minimum of 2048-bits; and
• X.509 certificates may be purchased under the University’s Enterprise account, via security@ubc.ca.

M8 2.1
The following key activities must be logged:

• User login, logout and access to a resource;
• action performed by the User and the time it was performed; and
• where feasible, any access to, or modification of, records.

M8 2.3
Logs provide valuable information that can be used to validate the integrity and confidentiality of UBC Electronic Information; to be effective, logs must be:

• retained for at least 90 days (except for ERP logs, which must be retained for at least 365 days) and regularly backed up whenever possible, preferably to offsite secure storage;
• retrievable in a timely manner if they are required for analysis; and
• protected against unauthorized access and modification, preferably by locating them on a separate server outside the Demilitarized Zone (DMZ), such as a Database Server protected by a firewall, and restricting access as necessary; no-one should be able to change or delete log information.

M10 3.1
Secure transmission of Medium, High or Very High Risk Information must comply with the following requirements:

• any form, application or service that requires some type of authentication, or that is used to collect or transmit information from User to server or between servers, must be encrypted using HTTPS with TLS version 1.2 at a minimum (or the equivalent, for non-web-based applications);
• information transmitted via SSH must be encrypted using a minimum of AES-256 bit encryption with mutual authentication between the server and User; and
• known weak network protocols (e.g. all versions of SSL, and TLS versions prior to 1.2) should be disabled.