PCI 3.1 Compliance Panel for CHECO by University of Northern Colorado Colorado School of Mines

Agenda Why the Hoopla? The Self Attested Questionnaire SAQ The Cardholder Data Environment CDE

Jane Rosenthal, JD, CCEP Director, Compliance & Policy About the Presenters Jane Rosenthal, JD, CCEP Director, Compliance & Policy Background: 15+ yrs University, privacy, research, contracts Legal experience, admitted Missouri & Kansas Certified Compliance & Ethics Professional

About the presenters Matt Langford, CISSP-ISSMP, PCIP Chief Information Security Officer Background QSA and PA-QSA Penetration Tester Security Auditor Anti-Malware Engineer

Why the Hoopla? Cybersecurity is a National Issue PCI Security Council cares about small merchants All card brands requiring compliance Just b/c you think it’s out-of-scope, it may not be; Outsourcing/Tokenization are not magic pills Only QSA can confirm Card brands can have differing requirements—differing merchant level assessments

Hoopla? Compliance is not a check the box activity or one and done; IT IS DAILY ACTIVITY!!! Your Bank/Acquirer will pass through the Fines to you or raise your rates Risk-based environment is drive of compliance these days

4 Steps to Compliance Scope Assess Reporting Clarifications PCI-DSS all components within or connected to CDE Assess compliance of system and testing Reporting documentation/SAQ (appendix) or ROC Clarifications

Self Attestation Questionnaire Do we qualify to fill an SAQ? Merchant Expertise There are 9 categories you might fall into for a SAQ. (See appendix)

Questions Is there a current network diagram that documents all connections between the cardholder data environment and other networks, including wireless networks? Are encryption keys changed from default at installation, and changed anytime anyone with knowledge of the keys leaves the company or changes position?

Questions Are strong cryptography and security protocols, such as TLS, SSH or IPSEC, used to safeguard sensitive cardholder data during transmission over open, public networks? Is a security policy established, published, maintained, and disseminated to all relevant personnel?

CDE

CDE Components Include items such as: Point of Sale Machines Virtual Terminals Card Swipe Machines Printers Network Devices Networking Hardware Servers Connections to the Back Office Environment

CDE Connections Connections between all CDE devices Connections between all other network resources (infrastructure components) Connections to other networks Flow of data from one device to another Flow of data from network segment to segment

Some of the things you need to know about your CDE Are all machines hardened? Are security patches applied? Are all machines defended against malware? Are the applications logs gathered and retained for the required period of time? Are those logs being monitored on a daily basis? Do you have the required documentation?

Some of the things you need to know about your CDE Are the encryption keys being managed and rotated as required? Is the environment being security tested on a regular basis? Are you completing your scanning requirements? Is there a policy, procedure and process in place regarding the vulnerability management of these systems?

Consider Scope In-Scope Out-of-Scope (maybe) Systems that connect directly to CHD environment Encrypted CHD (no key available) If provide VoIP ourselves & CHD transmitted over it Connected 2 Connected systems?? If system can impact security/CDE In-bound connections/telecom provider (such as Cable or Cell Provider) Any transmission, storage, or processing of cardholder data (CHD) Network system isolated from CDE (no connectivity 2 network) *Restricting access by IP/Port may help, but not necessarily solve problems; **Any device on network could compromise/access 2 CDE, but controls minimize risk ***Compensating controls may be acceptable, but only a QSA can confirm this PCI DSS security standards https://discussions.tenable.com/thread/6948 See about discussion threads from Tenable

VoIP? VoIP vs. POTS? (voice over IP v plain old tele system) if your payment processing is outsourced to a third-party provider, but you are accepting customer payments over the phone, then your VoIP phone solution is subject to PCI compliance standards VoIP phone systems in scope Only VoIP systems w/ strong cryptography should be used Segmenting the VoIP Requiring agents to use analog telephone lines? PBX is digital even if analog is engaged? See Tenable Discussion Forum See PCI DSS   1) Any form of transmission, storage, or processing of cardholder data (CHD) is in scope for PCI and subject to applicable PCI DSS requirements;           2) Voice over IP (VoIP) is simply another communications protocol subject to PCI DSS requirements which apply (if the transmission is over an open, public network then it would need to be encrypted (PCI DSS 4.1); and           3) Telecommunications Providers are ordinarily excluded from inclusion in lists of third party Service Providers (PCI DSS 12.8). VoIP in Scope: if your entity is providing the VoIP communications (e.g. maintaining a SIPS server) and CHD is being transmitted over VoIP then this traffic and all associated systems would be in scope for PCI compliance. But if your entity is just receiving inbound telephone calls (VoIP or POTS) that have originated from an external source, then you have no responsibility for the security of these calls, nor are you required to treat your telecommunications provider as a Third Party or Service Provider.

Discussion Questions? Topics Segmented networks for virtual POS terminals Legacy PCI DSS environments Log management Storage of CHD

Appendix A: PCI Standards 6 Goals 12 PCI DSS Requirements Build & Maintain Secure Network & Systems 1. Install & maintain firewall configuration to protect CHD 2. Don’t use vendor-supplied defaults for system passwords & other security parameters Protect Cardholder Data (CHD) 3. Protect stored CHD 4. Encrypt transmission of CHD across open, public networks Maintain Vulnerability Management Program 5. Protect all systems against malware & regularly update AV software or programs 6. Develop & maintain secure systems & applications Implement Strong Access Control Measures 7. Restrict access to CHD by business need-to-know 8. ID & authenticate access to system components 9. Restrict physical access to CHD Regularly Monitor & Test Networks 10. Track & monitor all access to network resources & CHD 11. Regularly test security systems & processes Maintain Info Security Policy 12. Maintain policy that address info security for all personnel PCIDSS Quick Guide v3.1

Appendix A: Assessment Merchant Level? DISCOVER http://www.discovernetwork.com/merchants/data-security/identifying-organizations.html AMEX https://www.americanexpress.com/in/content/merchant/support/data-security/merchant-information.html MC https://www.mastercard.us/en-us/merchants/safety-security/security-recommendations/merchants-need-to-know.html VISA https://usa.visa.com/support/small-business/security-compliance.html http://www.discovernetwork.com/merchants/data-security/identifying-organizations.html https://www.americanexpress.com/in/content/merchant/support/data-security/merchant-information.html https://www.mastercard.us/en-us/merchants/safety-security/security-recommendations/merchants-need-to-know.html https://usa.visa.com/support/small-business/security-compliance.html **See PCI DSS QRG v3.1 Quick Reference Guide

Appendix B-SAQ types Self Attestation Questionnaire (SAQ) types A A-EP B-IP C C-VT P2PE D (Merchant and Service Provider)

SAQ A Card-not-present (e-commerce or mail/telephone-order), that have fully outsourced all cardholder data functions to PCI DSS compliant third-party service providers, with no electronic storage, processing, or transmission of any cardholder data on the merchant’s system or premises. Not applicable to face-to-face channels. This is when a PCI validated third party runs all your transactions through a web, mail or telephone order system.

SAQ A-EP E-commerce merchants who outsource all payment processing to PCI DSS validated third parties, and who have a website(s) that doesn’t directly receive cardholder data but that can impact the security of the payment transaction. No storage, processing, or transmission of cardholder data on merchant's systems or premises. Applicable only to e-commerce channels. This is when you redirect from your environment to a PCI validated third party runs all your transactions through a web, mail or telephone order system.

SAQ B Merchants using only: Imprint machines with no electronic cardholder data storage, and/or Standalone, dial-out terminals with no electronic cardholder data storage. Not applicable to e-commerce channels.

SAQ B-IP Merchants using only standalone, PTS-approved payment terminals with an IP connection to the payment processor with no electronic cardholder data storage. Not applicable to e-commerce channels.

SAQ C-VT Merchants who manually enter a single transition at a time via a keyboard into an Internet-based, virtual payment terminal solution that is provided and hosted by a PCI DSS validated third-party service provider. No electronic cardholder data storage. Not applicable to e-commerce channels.

SAQ C Merchants with payment application systems connected to the Internet, no electronic cardholder data storage. Not applicable to e-commerce channels.

P2PE Merchants using only hardware payment terminals included in and managed via a validated, PCI SSC-listed P2PE solution, with on electronic cardholder data storage. Not applicable to e-commerce merchants.

SAQ D SAQ D for Merchants: All merchants not included in descriptions for the above SAQ types.

SAQ D SAQ D for Service Providers: All service providers defined by a payment brand as eligible to complete an SAQ.

Additional Resources https://www.pcisecuritystandards.org/ https://www.pcisecuritystandards.org/documents/Understanding_SAQs_PCI_DSS_v3.pdf

Appendix B – Q1 Is there a current network diagram that documents all connections between the cardholder data environment and other networks, including wireless networks? Expected Response Review current network diagram Interview responsible personnel Examine network configurations

Q2 Are encryption keys changed from default at installation, and changed anytime anyone with knowledge of the keys leaves the company or changes position? Expected Testing Review policies and procedures Review vendor documentation Interview personnel

Q3 Are strong cryptography and security protocols, such as TLS, SSH or IPSEC, used to safeguard sensitive cardholder data during transmission over open, public networks? Expected Testing Review documented standards Review policies and procedures Review all locations where CHD is transmitted or received Examine system configurations

Q4 Is a security policy established, published, maintained, and disseminated to all relevant personnel? Expected Testing Review the information security policy