1. PCI 3.1 Compliance Panel for CHECOby
University of Northern Colorado
Colorado School of Mines

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

3. 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

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

5. 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

6. 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

7. 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

8. 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)

9. 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?

10. 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?

11. CDE

12. 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

13. 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

14. 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?

15. 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?

16. 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
See about discussion threads from Tenable

17. 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.

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

19. 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

20. Appendix A: Assessment
Merchant Level?
DISCOVER
AMEX MC
VISA
**See PCI DSS QRG v3.1
Quick Reference Guide

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

22. 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.

23. 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.

24. 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.

25. 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.

26. 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.

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

28. 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.

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

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

31. Additional Resources https://www.pcisecuritystandards.org/

32. 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

33. 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

34. 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

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