TAG_Review_-_PCRA_TVM_Replacement_v1[1]_(2).docx

Project Cybersecurity Risk Assessment TVM Replacement Project Melvina Beard, Info Systems Risk Analyst February 25, 2020 Objective The objective of this risk assessment is to identify and communicate recommendations for addressing potential operational, compliance, and vendor or contractual risks for the proposed project TVM Replacement.

The risk review is intended to provide thought provoking information about how the requester or project team might approach the product schedule, deliverables, and restrictions in a way that protects RTD and builds a more secure product.

Scope The scope of this risk assessment is limited to the activities related to TVM Replacement Project.

Definitions:

· Operational risk means the degree to which the changes introduced by the proposed project increase the probability for operational issues. Operational issues could include, but are not limited to, the exposure of confidential data, inappropriate changes to RTD systems or data (tampering), or the inability to provide service to RTD employees or customers.

· Compliance risks means the degree to which the proposed project affects RTD’s ability to comply with regulatory or legal requirements governing the management of systems and data.

· Vendor or contractual risks means the degree to which RTD’s involvement of and management of an outside party could introduce operational or compliance issues.

Methodology The risk assessor consulted the following resources to understand the intent, scope, and deliverables associated with the project and to understand and evaluate associated security and compliance risks:

· ServiceNow ticket DMND0004621

· Ticket Vending Machine (TVM) Replacement Intake Document

· RTD TVM Market Research Project Status Meeting Summary Document

· RTD TVM Market Research Report Document

Executive Summary

· Document the full system architecture including: networked physical diagram, networked logical diagram, data flow diagram, firewall configuration and placement, and connection details.

· Limit cardholder data environment (CDE) interconnections as much as possible, as this can increase the PCI-DSS scope.

· Identify which company (vendor or RTD) will be responsible for credit card data handling, and where the credit cards will be processed. If the responsibility is shared, identify how responsibilities are split or shared and for which components and data.

· In addition to requesting the solution be PCI DSS compliant, ensure vendor provides an annual attestation of compliance (AOC).

· Identify the least amount of sensitive data that needs to be transmitted and stored in the vendor’s environment. Do not capture sensitive data unnecessarily. Identify data retention and deletion requirements and timeframes.

· Limit access to the data to only those with a business need, and monitor who has access to the data.

· Use encryption to protect data in transit and in storage.

· Include vendor requirements for Cardholder Data Environments and Custodianship of Confidential and Sensitive Data, to the contract.

Risks and Recommendations

1. The solution must be Payment Card Industry Data Security Standard (PCI DSS) compliant

Summary of Risk There are operational and compliance risks to RTD, because the solution must be PCI DSS compliant.

Discussion RTD is responsible to protect sensitive data including card holder data, and is liable to ensure the solution is PCI DSS compliant.

It is in RTD’s best interest to limit the scope of the PCI DSS compliance from a resource management and liability perspective. If the vendor is wholly responsible for card data processing and customer personal information, RTD must require the vendor to meet PCI-DSS requirements and should acquire proof of compliance at least annually. If portions of the system are hosted at RTD and the scope is not clearly defined and/or technically separated from the rest of the RTD network, RTD will need to assume ALL systems related to this ecommerce solution, and anything that the ecommerce solution is connected to, is in PCI-DSS scope.

Recommendations

1. Document the full system architecture including: networked physical diagram, networked logical diagram, data flow diagram, firewall configuration and placement, and connection details.

2. Limit cardholder data environment (CDE) interconnections as much as possible, as this can increase the PCI-DSS scope.

3. Identify which company (vendor or RTD) will be responsible for credit card data handling, and where the credit cards will be processed. If the responsibility is shared, identify how responsibilities are split or shared and for which components and data.

4. In addition to requesting the solution be PCI DSS compliant, ensure vendor provides an annual attestation of compliance (AOC).

5. Include in the contract, requirements #1-10 of the Cardholder Data Environment vendor requirements

2. Sensitive data must be protected

Summary of Risk There are operational and compliance risks to RTD, because the solution transmits and stores sensitive data.

Discussion RTD and its vendors are responsible to protect sensitive data including personally identifiable information, sensitive personal information, and card holder data, and is liable to ensure this data is protected.

RTD should also be prepared to understand where personal information is captured and stored or transferred to RTD by the vendor and handle and control the information using appropriate and available technologies and in accordance with RTD’s policies and procedures.

Recommendations

1. Use encryption to transmit and store data.

2. Limit access to data to only those who have a business need to, and monitor who has access to the data.

3. Identify the least amount of sensitive data to only what is needed to perform the business function(s), do not capture data unnecessarily.

4. Implement data retention requirements and timeframes. Delete data when it’s no longer needed.

5. Include requirements #1-11 of the Custodian of Confidential and Sensitive Data vendor requirements

IT Safety, Security & Compliance Impact

· Because the solution must be PCI DSS compliant and RTD is liable for a compliant solution, RTD must identify roles and responsibilities for credit card handling, limit PCI DSS scope, and ensure the vendor provides an annual AOC.

· Because personally identifiable information (PII), sensitive security information (SSI), and cardholder data (PCI DSS), will be transmitted and stored in this system, RTD is liable to protect this data and must ensure the vendor does too.

Other Observations

· The business owner knows the solution must be PCI DSS compliant, and that sensitive data must be protected.

· As mentioned in the research documents, plan for purchasing spare TVM parts, in case the vendor is not available in a timely manner for machine fixes.

For Reference:

1) RTD's Electronic Data Protection Policy states:

RTD employees and contractors shall always encrypt confidential and sensitive data when it is transmitted externally (ex. across the Internet). Where possible, RTD employees and contractors shall encrypt internal RTD confidential and sensitive data while in transit between or at rest on RTD systems. RTD employees and contractors shall only use encryption methods that are approved and supported by the Information Technology department (or other data custodian, as applicable). If encryption is not possible or an approved method is not yet available, RTD employees and contractors shall use standard procedural and technical security measures to protect internal sensitive and confidential data from disclosure in transit and at rest (for example, access controls, password protection).

https://thehub.rtd-denver.com/Management%20Directives/Electronic%20Data%20Protection%20Policy.pdf

2) RTD's Confidential and Sensitive Information Handling Procedure states:

Clear-Text Transmission Electronic sensitive information may never be transmitted via text (SMS), email, instant message (ex. Skype), or across any public network in clear text. Should there be a business need to share electronic sensitive information with another RTD or non-RTD party, the information must be encrypted such that only the recipient can view the sensitive data.

https://thehub.rtd-denver.com/Management%20Directives/Confidential%20and%20Sensitive%20Information%20Handling%20Procedure.pdf

3) RTD's Confidential and Sensitive Information (CSI) policy states:

RTD's records and information must be classified within one of the following categories for purposes of applying reasonable security controls: Level 4 Sensitive/Regulated: Exempt from disclosure under applicable laws. For example, this includes, but is not limited to (i) any personally identifiable information ("PII" ) such as name, address, and date of birth, (ii) sensitive personal information ("SPI" ) such as social security numbers, drivers' license numbers, bank account information, payment account numbers and other cardholder data, and health information, (iii) sensitive security information ("SSI") such as security plans, reports of security gaps or vulnerabilities, (iv) protected critical infrastructure information ("PCII"), (v) information technology security information, (vi) attorney-client privileged communications, and (vii) attorney work product.

https://thehub.rtd-denver.com/Management%20Directives/Confidential%20and%20Sensitive%20Information%20Policy.pdf image2.emf

Custodianship of Confidential and Sensitive Data.docx Custodianship of Confidential and Sensitive Data

“Confidential and sensitive data” means any information that, if exposed to an unauthorized individual, could cause harm to or reveal vulnerabilities about RTD, its staff, or its passengers. Sub-types of confidential and sensitive information may include, but are not limited to, the following:

· “Personally Identifiable Information (PII),” meaning any information that alone or in conjunction with other information could be used to identify or locate an individual;

· “Sensitive Personal Information (SPI),” meaning any information of a personal nature that could cause or be used to cause harm or embarrassment to an individual were it exposed;

· “Security Sensitive Information (SSI),” meaning information about RTD’s security plans or vulnerabilities that, if exposed, could put RTD at risk of a security breach;

· “Critical Infrastructure Information (CII),” meaning information that is so critical to the business operation of RTD, if it were to be lost, corrupted, or exposed, could prevent RTD from delivering services;

· Information that is confidential by nature, such as access codes or passwords;

· Other classes of confidential or sensitive information as defined by RTD policies.

1. Scope. If applicable and necessary under the scope of services, RTD shall define and / or approve (if generated or defined by the Contractor) what confidential and sensitive data may be created, collected, processed, transferred, or stored by the systems or processes supported by the Contractor such that it can be protected per the requirements below. Only the least amount of data required to perform the Services may be created or collected.

1. Privacy. Upon RTD’s request, the Contractor shall provide RTD with a copy of their Privacy Notice, Privacy Policy, and related documents as applicable to privacy governance.

1. Access Control. Two-factor authentication shall be used for anyone who has access to confidential and sensitive data from the Internet. Access shall be limited to only those individuals with a verified business need. Where feasible and applicable, role-based access control systems shall be implemented to enable user account administration by job role or function.

1. Logging. Record and/or field level access controls shall be implemented on all databases. Security audit logging shall be implemented for all confidential and sensitive data accesses. Log files shall be reviewed daily.

1. Data Retention. Only the least amount of confidential and sensitive data required to perform the Services and meet RTD’s record retention requirements may be retained (whichever is more stringent). RTD shall communicate applicable data retention requirements to the customer prior to the collection of production data. Expired data shall be purged from all managed systems and applications upon expiration, or within a commercially reasonable timeframe following the expiration date not to exceed 30 days.

1. Sanitization. All confidential and sensitive data shall be removed from systems by overwriting the media 3 times with 1s and 0s before disposal or transfer of assets outside of RTD’s use or the Contractor’s custodianship.

1. Encryption. Confidential and sensitive data stored in the system must be encrypted using strong encryption. Confidential and sensitive data transmitted across the Internet to or by the system must be protected by strong transport encryption. Contractor must use encryption key management strategies that are designed to prevent the corruption or exposure of encryption keys or abuse by individuals without a business need.

1. Vulnerability Scanning. All systems that store, collect, transmit, or process confidential and sensitive data that are accessible from the Internet shall undergo vulnerability scanning quarterly. All high risk defects must be corrected with scans re-performed to demonstrate defects no longer exist.

1. Risk Assessments. A risk assessment must be performed for any major changes to the hosted systems that impact the storage, collection, transmission or processing of confidential and sensitive data, to include addition of new systems, removal of systems, major upgrades, changes in data flows affecting confidential and sensitive data, or changes in security controls related to confidential and sensitive data. Mitigation for noted risks must be addressed in the change implementation plan. Risks that cannot be mitigated must be presented to RTD for review and acceptance prior to change implementation.

1. Privacy Impact Assessments. A Privacy Impact Assessment must be performed for any major changes to the hosted systems that impact the storage, collection, transmission or processing of PII, to include addition of new systems, removal of systems, major upgrades, changes in data flows affecting PII, or changes in security controls related to PII. Mitigation for noted risks must be addressed in the change implementation plan. Risks that cannot be mitigated must be presented to RTD for review and acceptance prior to change implementation.

1. Data Replication. Contractor shall not duplicate confidential and sensitive data to other systems, including but not limited to test systems and databases, portable storage media, hardcopies, or other locations where it is not necessary for the business or technical function of the services.

1. SOC 2 Report. Practices used to maintain security in accordance with the above must be included in an annual SOC 2 Type 2 report.

image1.emf

Cardholder Data Environments.docx Cardholder Data Environments

“Cardholder Data (CHD)” means the full magnetic stripe contents of a credit card plus any of the following: cardholder name, expiration date, service code.

“Cardholder Data Environment (CDE)” means an area of a computer system or network that possesses cardholder data or sensitive authentication data (related to cards) and those systems that directly attach to such environments or otherwise support cardholder processing, storage, or transmission.

1. PCI-DSS Compliance. Cardholder Data Environments shall comply with all requirements of the current effective version of the Payment Card Industry Data Security Standard (PCI-DSS) for Level 2 merchants throughout the lifecycle of the environment.

2. Scope. If applicable and necessary under the scope of services, RTD shall disclose to the Contractor where cardholder data is stored in the target architecture such that it can be protected per the requirements below.

3. CDE Boundary Controls. To limit the scope of PCI controls, Contractor shall separate systems that collect, store, process, or transmit cardholder data from those that do not using network security control methods that are (a) deemed sufficient under the PCI-DSS standard and (b) validated for sufficiency to the frequency required in the PCI-DSS.

4. Multi-Tenancy. It is preferred that CDEs be separated by function and by customer. Should any of the CDEs be combined (across RTD, or across RTD and multiple customers, ex. multi-tenancy), in accordance with the PCI-DSS, Contractor shall implement and maintain access controls to adequately separate the functions of each environment such that actions taken in or for one CDE do not affect the security of other CDEs on the same architecture.

5. Supporting Systems Compliance. Contractor shall maintain all systems that do not contain cardholder data but provide supporting services to those systems that do (for example, to provide support, reporting functions, or similar) in a manner consistent with PCI-DSS requirements.

6. Control Responsibilities. Contractor shall participate with RTD in developing and reviewing a compliance scope matrix to document responsibility for the design and execution of PCI-compliant controls.

7. Attestation of Compliance. Contractor shall provide to RTD on request, and otherwise no less than annually, an Attestation of Compliance signed by a qualified or internal security assessor (QSA or ISA) as validation of the controls under vendor’s scope.

8. Compliance Auditing. Contractor shall permit RTD to test, inspect, or audit Contractor systems assigned to RTD or data residing on Contractor hosted systems in order to support RTD’s compliance responsibilities.

9. Corrective Actions. Should defects in security or PCI compliance be discovered by Contractor or by RTD, Contractor shall provide a Plan of Actions and Milestones that details the actions and timeline to resolve. Contractor shall resolve security and compliance defects in scope of the Contractor’s supported services at no additional charge to RTD.

10. Compliance Impact Assessments. A Compliance Impact Assessment must be performed for any major changes to Cardholder Data Environment, including but not specifically limited to the addition of new systems, removal of systems, major upgrades, changes in data flows affecting cardholder data, or changes in security controls related to cardholder data. Identified risks and mitigation plans must be reviewed with RTD prior to change implementation. Risks that cannot be mitigated must be presented to RTD for review and acceptance prior to change implementation.