UC Riverside PCI Update and Training October 29, Rick Norman, QSA Christopher Dosta Coalfire Systems, Inc.

Transcription

1 UC Riverside PCI Update and Training October 29, 2014 Rick Norman, QSA Christopher Dosta Coalfire Systems, Inc.

2 Agenda Part I IT Security in the News POS Malware Threats EMV vs. Cardholder Security PCI 101 Scope and Segmentation Business as Usual New Reporting Templates SAQs New and Updated Versions

3 Agenda Part I Critical Changes to Existing Requirements New Requirements Immediate Impact Phased Requirements July 1, 2015 Third Party Vendor Management Incident Response Mobile Payments Guidance for Merchants Resources Q&A

4 Coalfire Introduction Coalfire offers demonstrated leadership in all key areas of Information Security, Risk Management and Compliance

5 IT Security in the News The Home Depot 09/02/2014-Customer credit and debit cards appear compromised by a breach of their POS systems, reportedly by the same Russian hacking group that hit Target, Michaels, Neiman Marcus and P.F. Chang's. 56 million consumers K-Mart 10/10/2014 Customer credit and debit cards appear compromised by a breach of their POS systems, with malicious software targeting their POS systems. unknown number of records

6 IT Security in the News Target Corporation 12/13/2013-Customer credit and debit cards along with the debit pin numbers were compromised in one of the largest retail breaches ever. Malware on the POS system is believed to be the same as compromised other well-known retails such as Neiman Marcus. 110 million consumers North Dakota University 02/7/2014 Current and former students along with faculty and staff personal information which included Social Security numbers and names stored on a server were compromised by an entity outside the U.S. over 290,000 records

7 IT Security in the News Albertson s 09/29/2014 This breach reportedly captured account numbers, expiration dates, other numerical information and/or cardholder names. Those stores that were affected includes Albertsons stores in Southern California, Idaho, Montana, North Dakota, Nevada, Oregon, Washington, Wyoming and Southern Utah. Unknown number of records Indiana University 02/26/2014 Personal data of students and graduates from 2011 to 2014 at seven of its campuses which included Social Security Numbers and addresses was breached. Breach occurred via webcrawlersattempting to improve search capabilities. They also announced the data was stored in an insecure location for the past 11 months. approximately 146,000 records

8 IT Security in the News Alaska Communications 1/27/2014 Desktop computer infected with a virus sending data outside the network that could have included names, addresses, dates of birth, and Social Security numbers. unknown number of records UC Davis Health System 1/30/2014 Business Associate breach -- potential records breached include names, medical record numbers, and dates of clinical visits to the provider by hacking BA system. unknown number of records

9 POS MALWARE THREATS BlackPOS Parent or base for Trojan.POSRAM Likely culprit in large-scale retail breaches Modified to be undetected by anti-virus engines Chewbacca Key logger Memory scraping/parsing Relatively new / not widely distributed yet Have you been infected? How would you know? Begin with a sample of POS systems connected to PCs Conduct a forensic review of a POS device (e.g., hard drive) Be watchful with alerts and monitoring

10 EMV vs. Cardholder Security EMV is not a data security standard nor does it reduce a merchants obligation to be PCI DSS compliant P2PE and EMV present a vision of removing the majority of Credit Card acceptance risk and a significant amount of compliance obligations in the next few years Card brand EMV compliance reduction should be seen as complementary to P2PE offerings EMV and P2PE are likely the best solutions to avoid a new data security disaster with Mobile payment acceptance By using EMV to reduce the risk of fraud and P2PE to reduce the risk of compromise, merchants will be able to get back to worrying about how to sell to their customers

11 PCI Authorization Processed 4. Account Processing PCI Security Standards Council Merchant s Acquiring Bank Cardholder s Issuing Bank 5. Settlement (next day) 1. Authorization Request 3. Authorization Request 6. Cardholder Statement Merchant Cardholder

12 What are we protecting? Cardholder Verification Number (CVN) (CID/CVV2/CVC2) CVV2 CVV Primary Account Number (PAN)

13 Who is the PCI SSC? The Payment Card Industry Security Standards Council is led by a policysetting Executive Committee, composed of representatives from the founding payment brands. Operational decisions are made by a Management Committee, also from the payment brands.

14 The Food Chain Enforcement of PCI Standards FINES FINES PCI Acquirer/ Processor Retailer Marketer Establishes standards of compliance Create Generic Compliance Tools Reporting Obligation to Card Brands First Level Mandate Interpretation Merchant ID /Ownership/Brand Owns Payment Application/System

15 The PCI Compliance Programs PTS PIN Pad Manufacturers, Terminal Manufacturers PA-DSS Payment Application Developers PCI DSS Merchants (carry the MIDs), Service Providers (handle CHD for Merchants) Payment Terminal Security (PTS) PIN Devices, PIN Pads, Embedded Terminals Payment Application Data Security Standard (PA-DSS) POS Systems, ecommerce Platforms Payment Card Industry Data Security Standard (PCI DSS) POS Systems, ecommerce Platforms

16 Compliance vs. Validation Compliance All merchants must adhere to the full PCI DSS standard, regardless of size or number of transactions processed Validation Separate from compliance, the validation process is usuallybased on the number of transactions processed.

17 PCI DSS : Merchant Levels Merchant Level Description Validation Action Validated By Merchants processing over 6 million Visa transactions annually (all channels) or global merchants identified as Level 1 by any Visa region Any merchant that Visa, at its sole discretion, determines should meet the Level 1 merchant requirements to minimize risk to the Visa system. Any merchant-regardless of acceptance channel-processing 1,000,000 to 6,000,000 Visa transactions per year. Any merchant processing 20,000 to 1,000,000 Visa e-commerce transactions per year. Any merchant processing fewer than 20,000 Visa e-commerce transactions per year, and all other merchants-regardless of acceptance channel-processing up to 1,000,000 Visa transactions per year. Annual On-site PCI Data Security Assessment Quarterly Network Scan Annual PCI Self-Assessment Questionnaire Quarterly Network Scan MasterCard requires an onsite review by an auditor Annual PCI Self-Assessment Questionnaire Quarterly Network Scan Annual PCI Self-Assessment Questionnaire Quarterly Network Scan (if applicable) Qualified Security Assessor or Internal Audit if signed by Officer of the company Approved Scanning Vendor Merchant Approved Scanning Vendor QSA Merchant Approved Scanning Vendor Merchant Approved Scanning Vendor

18 The PCI DSS

19 The Payment Card Environment The PCI DSS applies to the cardholder data environment (CDE) The CDE consists of the following that stores, processes, or transmits cardholder data: Network and System Components (Firewall, Server, Database, Application, Terminals) Physical Environment People Handling Cardholder Data

20 The Payment Card Environment Typical Environment - Flat Environment Point-of-Sale Non-Payment Network Ecommerce Servers Systems/Servers WSUS, AV, Logging No or limited port filtering Ineffective segmentation Backoffice

21 The Payment Card Environment Good architecture can reduce risk and cost of compliance! Point-of-Sale Non-Payment Network Ecommerce Servers Systems/Servers WSUS, AV, Logging Backoffice

22 Defining your CDE (Scope) Create a data flow diagram Identify all systems, networks, and locations that process card data Identify any third-party services or equipment within your environment Specifically call out areas where card data is stored

23 Create a Network Diagram Finish it off by correlating data flow to networks What are the key networking equipment? What numbered networks are in place? Where do the key payment technologies live? What are the rules governing traffic between networks?

24 Scope Reduction Identify all assets Map the payment flow Map the network Identify responsibilities Isolate, separate, and segment

25 Key Questions for Your Organization How many different payment channels do you have (e.g. website, in-person, over-the-phone)? What applications or terminals are in use? Do you use any service providers? How many processing contracts do you have? How many different physical locations are processing cards? Are you using PA-DSS validated payment applicatons?

26 Understand your Organization

27 Understand your Organization

28 Your Responsibilities Campus responsibilities are set by your payment processor / acquiring bank (e.g., BAMS) Campus credit card coordinator (Asirra) works with BAMS to communicate campus and department specific responsibilities Each department may have different responsibilities depending upon technology and business processes

29 Your Responsibilities Know your validation reporting deadline connect with Asirra if unsure Know your transactional volume across your department and the campus as a whole (it determines validation level) Know if required to run quarterly network scans and ensure they are ran on-time

30 Due Dates Can you use a single compliance date for all organizations? What is your drop dead date for compliance? What is your start date for self-assessment? When can you run your first scan? When are your scans due?

31 Requirement 1 Install and maintain a firewall configuration to protect cardholder data Implement firewalls between public and private networks Restrict access between networks Control changes to firewall configuration Create and maintain a current network configuration diagram. All connections into and out of the cardholder environment (CDE) Firewall reviews every 6 months.

32 Requirement 2 Do not use vendor-supplied defaults for system passwords and other security parameters Applies to all system components and needs to occur before they are installed on the network. Applies to wired and wireless networking devices Implement hardened system configurations per NIST, SANS, or other best-practice guidelines

33 Requirement 3 Protect stored data Complete encryption of sensitive card data (AES 256 encryption methodology) Implement appropriate key management procedures

34 Requirement 4 Encrypt transmission of cardholder data across open, public networks Any transmission of cardholder data across public networks must be encrypted Includes wireless transmissions

35 Requirement 5 Use and regularly update anti-virus software Install anti-virus on all systems commonly affected by malicious software Anti-virus software is up to date Anti-virus is logging and the logs are kept in accordance with PCI DSS requirement 10.7

36 Requirement 6 Develop and maintain secure systems and applications Critical security patches installed within one month of release Change Management Secure Software Development

37 Requirement 7 Restrict access to cardholder data (Logical Access) By default users should not be able to see more than one card number at a time. Document approval of users with access to cardholder data. Default deny-all. All system components.

38 Requirement 8 Assign a unique ID to each person with computer access Unique usernames for all users with access to cardholder data and administrators Complex passwords, password histories Specific password and account lockout settings In ecommerce environment, applies to users of all system components within CDE

39 Requirement 9 Restrict physical access to cardholder data Limit access to servers Servers should be kept in a locked environment Monitor access to server environment with cameras or badge access Correlate access log and video logs to ensure traceability of physical activities Procedures to distinguish between onsite personnel and visitors Data destruction and retention of media (this includes paper).

40 Requirement 10 Monitor all access to systems and cardholder data Logging for all system components Log all changes to system components Log all access to cardholder data Implement central log analysis Time sync

41 Requirement 11 Regularly test security systems and processes Do quarterly network scans Implement Intrusion Detection Systems Penetration Testing

42 Requirement 12 Maintain a policy that addresses information security Create and distribute an information security policy to guide employees and vendors Personnel security Risk Assessment Vendor Management Incident Response Security Awareness

43 PCI DSS 3.0 Scope and segmentation Systems that provide security services to the CDE In Scope As per the PCI SSC Segmentation = Isolation Scope Identification Process

44 PCI DSS 3.0 Business As Usual Monitoring of security controls Detect and respond to failures in security controls Review all changes to the environment Organization structure changes Periodic reviews Annual hardware/software review

45 PCI DSS 3.0 New Reporting Template Guidance as to the intent of each PCI DSS requirement is now included within the standard itself. The Guidance column helps clarify the PCI SSC s intent for each and every requirement. Mandatory Reporting Template For 3.0 assessments, QSAs must submit all Report on Compliance (ROCs) on the new, SSC-controlled 3.0 Reporting Template Control Re-Numbering Many requirements have been consolidated and/or renumbered, which has cleaned up the requirements table considerably. Section-Specific Policy Requirements Security policies and daily operational procedures (formerly requirements and 12.2) have been given their own requirement in each of the PCI DSS Sections (at the end of each).

46 SAQs New and Updated Versions All SAQs have new reporting layout: SAQA & SAQA-EP SAQB & SAQB-IP SAQC & SAQC-VT SAQD Updated Response column on SAQ: Yes Yes w/ccw(compensating Controls Worksheet) No N/A (Not Applicable) Control re-numbering Section-specific policy requirements

47 PCI DSS 3.0 SAQA & SAQA-EP SAQA Card not present; all CHD functions fully outsourced to a PCI DSS validated 3 rd party service providers. SAQA-EP Partially outsourced e-commerce merchant using PCI DSS validated 3 rd party service provider(s) and website for payment processing 47

48 PCI DSS 3.0 SAQ A & SAQ A-EP SAQA-EP Subject to PCI DSS requirements not previously required under SAQ A v2.0. To a certain extent, all 12 PCI Requirements are included in the validation process. 48

49 PCI DSS 3.0 SAQB & SAQB-IP SAQB Only imprint machines or standalone, dial-out terminals; no electronic CHD storage. SAQB-IP Standalone, IP-connected POI terminals to processor; no electronic CHD storage. 49

50 PCI DSS 3.0 SAQ B & SAQ B-IP SAQ B & B-IP Requirement 9.9.x: Protect devices that capture payment card data via direct physical interaction w/the card from tampering and substitution. SAQB-IP Merchants filing SAQ B-IP are subject to PCI DSS requirements not previously required under SAQ B v2.0. To a certain extent, all 12 PCI requirements, except for 5 and 10, are included in the validation process. Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs. Requirement 10: Track and monitor all access to network resources and cardholder data. 50

51 PCI DSS 3.0 SAQ C & SAQ C-VT SAQC Payment Application Systems Connected to the Internet No Electronic Cardholder Data Storage. DSS v2.0 DSS v3.0 Brick & mortar, Mail Order / Telephone Order, e-commerce Brick & mortar, Mail Order / Telephone Order, No e-commerce SAQC-VT Web-Based Virtual Payment Terminals No Electronic Cardholder Data Storage. 51

52 PCI DSS 3.0 SAQC & SAQC-VT SAQC Departments filing SAQ C have additional requirements: Requirement 9.9.x: Protect devices that capture payment card data via direct physical interaction w/the card from tampering and substitution. Requirement 11.3: Penetration testing is used to confirm CDE is isolated from other networks when segmentation is used. SAQC & C-VT Merchants filing SAQ C or C-VT are subject to PCI DSS requirements not previously required under v

53 PCI DSS 3.0 SAQD SAQD All other SAQ-eligible merchants. Two noteworthy changes: Requirement 9.9.x: Protect devices that capture payment card data via direct physical interaction w/the card from tampering and substitution. Requirement 11.3.x: Penetration testing is used to confirm CDE is isolated from other networks when segmentation is used. 53

54 PCI DSS 3.0 Critical Changes to Existing Requirements Key Management Updates The key management testing procedures outlined in requirements 3.5 and 3.6 have been modified and clarified.

55 PCI DSS 3.0 Critical Changes to Existing Requirements Requirement 6.6 Flexibility Added options to the interpretation of this requirement by changing web-application firewall to automated technical solution that detects and prevents web-based attacks.

56 PCI DSS 3.0 Critical Changes to Existing Requirements Password Complexity Flexibility Password complexity and strength requirements have been combined into a single requirement and the PCI SSC has now allowed for some flexibility in meeting these requirements.

57 PCI DSS 3.0 Critical Changes to Existing Requirements New Logging Events Enhanced logging requirement to include stopping or pausing of the audit logs. Log Reviews for Critical Components Daily or continuous log reviews have been split into two categories: Critical systems and Everything else.

58 PCI DSS 3.0 Critical Changes to Existing Requirements Expanded Penetration Testing Expectations The penetration testing requirements are much more detailed and now require testing to validate segmentation technologies (best practice until July 2015).

59 PCI DSS 3.0 New Requirements - Immediate impact Requirement Dataflow diagrams. Requirement 2.4 -Inventory of all in-scope system components. Requirement Risk-based malware review for systems not commonly affected by malicious software. Requirement b Personnel termination processes must include all physical authentication methods.

60 PCI DSS 3.0 New Requirements - Immediate impact Requirement 8.6.x- New requirements and testing procedures around the use of Authentication Mechanisms. Requirement 9.3 -New requirement to control physical access to sensitive areas for onsite personnel. Requirement New requirement to maintain information about which PCI DSS requirements are managed by the service provider.

61 PCI DSS 3.0 Phased Requirements These requirements are considered best practices only until June 30, 2015 at which time they become mandatory for all 3.0 assessments. Requirement Broken authentication and session management. Requirement New requirement for service providers to use different authentication credentials for access into different customer environments. Requirement(s) 9.9.x - New (merchant) requirements to protect point-ofsale devices that capture payment card data from tampering or unauthorized modification or substitution. Requirement 11.3.X -Expanded requirements/expectations for penetration testing controls. PCI DSS v2.0 requirements for penetration testing may be followed until July Requirement 12.9-Service providers acknowledge in writing to customers that they are responsible for the security of cardholder data.

62 Third Party Vendor Management PCI SSC produced information supplement Third-Party Security Assurance Use of third-party service provider (TPSP) does not relieve an entity of its compliance responsibilities and obligations. Security policies and procedures and written agreements with TPSP should be established with reporting mechanisms. Conduct TPSP due diligence before engaging. Correlate TPSP services to PCI DSS requirements. Monitor TPSP compliance status. 62

63 Incident Response When is the last time you ve tested your IRP? Does it include all departments involved in payment processing? Does everyone know their role and responsibility? Have you coordinated with IT? Legal? UCOP? Do you include alerts from security monitoring systems? And finally keep record of all testing, table-top or otherwise! 63

64 Mobile Payments Mobile payments are a fact of life today. Consider the risk and campus / UCOP policy before proceeding with an implementation. Require validated service providers and payment applications regardless of PCI requirements. Obtain acquiring bank written approval for scope or controls reduction. Mobile payments are NOT without risk no firewalls, logs, etc. Tokenization Apple Pay

65 Guidance to Merchants Don t store cardholder data if you don t need to. Consider solutions that enhance data security, such as encrypt at the swipe or tokenize cardholder data. Improve network security (don t let the bad guys/gals in). If they get in, don t let them get the data out. Make sure your TPSP treats your customer s data securely. Harden POS systems and e-commerce platforms. Test, test, test to make sure your security controls WORK!

66 Resources Coalfire Systems Navis Login, Whitepapers, and Resources -Login PCI Security Standards Point of Interaction (POI) Device Validation, Standards Visa Global Registry of Service Provides Verify Payment Processor is PCI Validated Privacy Rights Clearing House Data Breach Notifications

67 Questions?

68 Agenda Part II Point-to-Point Encryption Scoping Your Environment System Components Penetration Testing to Validate Segmentation Wireless In or Around the CDE Physical Security of POS and POI Devices Q&A

69 What is a Point-to-Point (P2PE) Solution? A point-to-point encryption (P2PE) solution is provided by a third party solution provider, and is a combination of secure devices, applications and processes that encrypt data from the point of interaction (for example, at the point of swipe or dip) until the data reaches the solution provider s secure decryption environment.

70 What is a Point-to-Point (P2PE) Solution? A PCI P2PE solution must include all of the following: Secure encryption of payment card data at the point-of-interaction (POI) P2PE-validated application(s) at the point-of-interaction Secure management of encryption and decryption devices Management of the decryption environment and all decrypted account data Use of secure encryption methodologies and cryptographic key operations, including key generation, distribution, loading/injection, administration and usage.

71 PCI SSC P2PE Certification Path So many solutions, so many claims a standard was needed The Encryption Special Interest Group provided feedback to the SSC in creating a PCI standard The SSC created a certification standard and program for P2PE Initial focus was certifying solutions targeted at Level 4 merchants First standards addressed only hardware-to-hardware and hardware-to-hybrid solutions Solutions, and not technology, was the focus of certification

72 PCI SSC P2PE Certification Path Solution requirements, assessment program and certification of assessors is now in place Acquirers are now front and center in both certifying their solutions but also accepting PCI DSS scope reduction of solutions Challenges with the certification program are just being understood Current program does not align well with the reality of Level 1 and 2 merchant environments Acquirers, processors, application vendors and gateways have current solutions in the market that are not certified and may not be certified under current program

73 What does SSC P2PE-listed mean? Three solutions currently certified and listed today (Bluefin payment systems, European Payment Services, The Logic Group) Program primarily focused on removing scope Level 4 merchants can remove their retail systems from scope Merchants must still meet all PCI DSS controls. If using a P2PE solution, they still must assess and validate their use and implementation of P2PE listed solution which has a pre-defined scope reduction P2PE SAQ Acquirer and processors offer P2PE solutions that are not validated by the SSC and still provide merchants PCI DSS scope reduction Level 1 and 2 merchants can work with their QSA and Acquirer to validate the impact of P2PE on their ROC whether it is a listed solution or not.

74 Risk or Compliance Reduction? Merchants are always responsible for risk of compromise Best ROI is reducing this risk PCI DSS scope and validation reduction does not reduce any responsibility or risk of non-compliance. Merchants must always be PCI DSS compliant Level 1-2 Merchants are drawn to P2PE because it allows them to manage risk and focus controls at an appropriate level no merchant is ripping out their firewall or uninstalling AV to deploy P2PE Acquirer/Processors see P2PE as the best way to reduce the overall risk of compromise while finally delivering a way for their merchants to validate compliance The acceptance of risk and compliance resides with the Acquirer Only work with QSAs that understand all aspects of risk and compliance

75 Risk-based approach to PCI QSAs working with Acquirers are able to take a risk based approach to P2PE solutions similar to segmentation or compensating controls today in validating merchants PCI DSS compliance When an Acquirer/Processor offers a P2PE solution they should be providing a risk based PCI DSS compliance program for their L1-L2 merchants and their QSAs This guidance should address scenarios where certain card types or exceptions are not encrypted with direction on how this would effect compliance and what other controls are required for these scenarios Software based P2PE encryption solutions have a different risk level and therefore have a significantly different impact on controls. A software solution must demonstrate how it compensates at or above those control intents for any requirements it is removing

76 Scope of PCI DSS Requirements

77 Scope of PCI DSS Requirements The PCI DSS security requirements apply to all system components included in ORconnected to the cardholder data environment. The cardholder data environment (CDE) is comprised of: People, Processes and Technologies that Store, Process, or Transmit Cardholder data (CHD) or Sensitive authentication data (SAD).

78 System components System components include: Network devices (Switches, Firewalls, Routers, IPS/IDS ) Servers (Database, Application Server, NTP, DHCP, Logging, Patch Mgmt ) Computing devices(workstations, Terminals ) Applications Examples of system components include but are not limited to the following: Systems that provide security services (e.g. authentication servers like AD, TACACS, RADIUS) Facilitate segmentation (e.g. internal firewalls), or May impact the security of (e.g. name resolution or web redirection servers) the CDE.

79 System components Virtualization components such as: Virtual machines Virtual switches/routers Virtual appliances Virtual applications/desktops, and Hypervisors Don t forget the supporting equipment and systems, such as a SAN, the SAN switches, etc.

80 System components Network components including but not limited to Firewalls Switches Routers Wireless access points Network appliances, and Other security appliances (e.g. IPS/IDS, Web Application Firewall).

81 System components Server types including but not limited to Web Application Database Authentication Mail Proxy Network Time Protocol (NTP) Domain Name System (DNS) Applications including: All purchased and Custom applications Including internal and external (for example, Internet) applications. Any other component or device Located within or Connected to the CDE

82 Network Segmentation

83 Network Segmentation Network segmentation of, or isolating (segmenting), the cardholder data environment from the remainder of an entity s network is not a PCI DSS requirement. However, it is strongly recommended as a method that may reduce: The scope of the PCI DSS assessment The cost of the PCI DSS assessment The cost and difficulty of implementing and maintaining PCI DSS controls The risk to an organization (reduced by consolidating cardholder data into fewer, more controlled locations) Without adequate network segmentation (sometimes called a "flat network") the entire network is in scope of the PCI DSS assessment. Network segmentation can be achieved through a number of physical or logical means, such as properly configured internal network firewalls, routers with strong access control lists, or other technologies that restrict access to a particular segment of a network. To be considered out of scope for PCI DSS, a system component must be properly isolated (segmented) from the CDE, such that even if the out-of-scope system component was compromised it could not impact the security of the CDE.

84 Network Segmentation An important prerequisite to reduce the scope of the cardholder data environment is a clear understanding of business needs and processes related to the storage, processing or transmission of cardholder data. Restricting cardholder data to as few locations as possible by elimination of unnecessary data, and consolidation of necessary data, may require reengineering of long-standing business practices.

85 Network Segmentation Documenting cardholder data flows via a dataflow diagram helps fully understand all cardholder data flows and ensures that any network segmentation is effective at isolating the cardholder data environment. If network segmentation is in place and being used to reduce the scope of the PCI DSS assessment, the assessor must verify that the segmentation is adequate to reduce the scope of the assessment. At a high level, adequate network segmentation isolates systems that store, process, or transmit cardholder data from those that do not. However, the adequacy of a specific implementation of network segmentation is highly variable and dependent upon a number of factors, such as a given network's configuration, the technologies deployed, and other controls that may be implemented. Appendix D: Segmentation and Sampling of Business Facilities/System Components provides more information on the effect of network segmentation and sampling on the scope of a PCI DSS assessment.

86 Network Segmentation The first step of a PCI DSS assessment is to accurately determine the scope of the review. At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of their PCI DSS scope by: Identifying all locations and flows of cardholder data and Ensuring they are included in the PCI DSS scope. To confirm the accuracy and appropriateness of PCI DSS scope, perform the following: The assessed entity identifies and documents the existence of all cardholder data in their environment, to verify that no cardholder data exists outside of the currently defined CDE. Once all locations of cardholder data are identified and documented, the entity uses the results to verify that PCI DSS scope is appropriate (for example, the results may be a diagram or an inventory of cardholder data locations).

87 Network Segmentation The entity considers any cardholder data found to be in scope of the PCI DSS assessment and part of the CDE. If the entity identifies data that is not currently included in the CDE, such data should be securely deleted, migrated into the currently defined CDE, or the CDE redefined to include this data. The entity retains documentation that shows how PCI DSS scope was determined. The documentation is retained for assessor review and/or for reference during the next annual PCI DSS scope confirmation activity. For each PCI DSS assessment, the assessor is required to validate that the scope of the assessment is accurately defined and documented.

88 Identify All Assets Campus Department IT Administrator Workstation Manager Workstation Location Group 1 Point-of-Sale Firewall Backoffice Workstation Webserver

89 Map the Payment Flow Card Data Origin Systems that Store, Process, or Transmit Systems that Connect to 3 rd Parties Processor/ Acquirer Gateway Processor Point-of-Sale Backoffice Server Campus Firewall BAMS Webserver Dept. Firewall

90 Map the Network No filtering or ACLs between networks VPN Access Remote Support Point-of-Sale A payments transmitted through XYZ gateway to BAMS / / /24 POS Terminal POS Terminal Mgmt Workstation Backoffice Webserver (On Premise)

91 Map the Network Implement new zones for sensitive card data systems and non-sensitive systems Add ACLs between networks Deny * from * Allow TCP 443 to Authorize.NET / / /24 POS Terminal POS Terminal Mgmt Workstation Deny * from * Allow outbound TCP 123 to Campus NTP Servers Allow outbound TCP to WSUS Patch Server Allow outbound TCP to Log Server Backoffice Webserver (On Premise)

92 Network Diagram

93 Penetration Testing to Validate Segmentation Requirement 11.3 has new requirements and sub-requirements: Implement a methodology for pen testing Clarifies pen test scope to include components that support network functions and operating systems Includes testing from inside as well as outside the network Includes coverage for the entire CDE perimeter and critical systems Requirement if segmentation used to isolate CDE: Perform pen tests annually; After any changes to segmentation controls; and, That the segmentation controls isolate all out-of-scope systems from in-scope systems.

94 Wireless

95 Wireless If wireless technology is used to store, process, or transmit cardholder data (for example, point-of-sale transactions, line-busting ), or if a wireless local area network (WLAN) is part of, or connected to the cardholder data environment, the PCI DSS requirements and testing procedures for wireless environments apply and must be performed (for example, Requirements 1.2.3, 2.1.1, and 4.1.1). Before wireless technology is implemented, an entity should carefully evaluate the need for the technology against the risk. Consider deploying wireless technology only for non-sensitive data transmission.

96 Physical Security The assessor must have a complete understanding of the physical locations that have systems that store, process, or transmit cardholder data. Physical Locations Data Centers Call Centers Offices (e.g. Ticketing, Giving, University Extension, etc.) Systems that store process or transmit cardholder data PC Terminals Workstations Servers Dial-out terminals

97 Securing the Systems POS systems Workstations/PCs Servers Dial-out terminals

98 Requirement Are appropriate facility entry controls in place to limit and monitor physical access to systems in the cardholder data environment? (a) Are video cameras and/or access-control mechanisms in place to monitor individual physical access to sensitive areas? Note: Sensitive areas refers to any data center, server room, or any area that houses systems that store cardholder data. This excludes pubic-facing areas where only point-of-sale terminals are present such as the cashier areas in a retail store." (b) Are video cameras and/or access-control mechanisms protected from tampering or disabling? (c) Is data collected from video cameras and/or access control mechanisms reviewed and correlated with other entries? (d) Is data collected from video cameras and/or access control mechanisms stored for at least three months unless otherwise restricted by law?

99 Requirement Are physical and/or logical controls in place to restrict access to publicly accessible network jacks? For example, network jacks located in public areas and areas accessible to visitors could be disabled and only enabled when network access is explicitly authorized. Alternatively, processes could be implemented to ensure that visitors are escorted at all times in areas with active network jacks Is physical access to wireless access points, gateways, handheld devices, networking/communications hardware, and telecommunication lines restricted?

100 Requirement (a) Are procedures developed to easily distinguish between onsite personnel and visitors, which include: Identifying new onsite personnel or visitors (for example, assigning badges), Changing access requirements, and Revoking terminated onsite personnel and expired visitor identification (such as ID badges) For the purposes of Requirement 9, onsite personnel refers to full-time and part-time employees, temporary employees, contractors and consultants who are physically present on the entity s premises. A visitor refers to a vendor, guest of any onsite personnel, service workers, or anyone who needs to enter the facility for a short duration, usually not more than one day." 9.2.(b) Do identification methods (such as ID badges) clearly identify visitors and easily distinguish between onsite personnel and visitors? 9.2.(c) Is access to the badge system limited to authorized personnel?

101 Requirement Is physical access to sensitive areas controlled for onsite personnel, as follows: Is access authorized and based on individual job function? Is access revoked immediately upon termination Upon termination, are all physical access mechanisms, such as keys, access cards, etc., returned or disabled? 9.4 Is visitor identification and access handled as follows: Are visitors authorized before entering, and escorted at all times within, areas where cardholder data is processed or maintained? (a) Are visitors identified and given a badge or other identification that visibly distinguishes the visitors from onsite personnel? (b) Do visitor badges or other identification expire?

102 Requirement Are visitors asked to surrender the badge or other identification before leaving the facility or at the date of expiration? (a) Is a visitor log in use to record physical access to the facility as well as for computer rooms and data centers where cardholder data is stored or transmitted? (b) Does the visitor log contain the visitor s name, the firm represented, and the onsite personnel authorizing physical access? (c) Is the visitor log retained for at least three months?

103 Requirement Are all media physically secured (including but not limited to computers, removable electronic media, paper receipts, paper reports, and faxes)?for purposes of Requirement 9, media refers to all paper and electronic media containing cardholder data (a) Are media back-ups stored in a secure location, preferably in an off-site facility, such as an alternate or backup site, or a commercial storage facility? (b) Is this location s security reviewed at least annually? 9.6.(a) Is strict control maintained over the internal or external distribution of any kind of media?

104 Requirement (b) Do controls include the following: Is media classified so the sensitivity of the data can be determined? Is media sent by secured courier or other delivery method that can be accurately tracked? Is management approval obtained prior to moving the media (especially when media is distributed to individuals)? 9.7 Is strict control maintained over the storage and accessibility of media?

105 Requirement (a) Is all media destroyed when it is no longer needed for business or legal reasons? 9.8 (b) Is there a periodic media destruction policy that defines requirements for the following? Hard-copy materials must be crosscut shredded, incinerated, or pulped such that there is reasonable assurance the hard-copy materials cannot be reconstructed. Storage containers used for materials that are to be destroyed must be secured. Cardholder data on electronic media must be rendered unrecoverable via a secure wipe program (in accordance with industry-accepted standards for secure deletion), or by physically destroying the media.

106 Requirement 9 9.8(c) Is media destruction performed as follows: (a) Are hardcopy materials cross-cut shredded, incinerated, or pulped so that cardholder data cannot be reconstructed? (b) Are storage containers used for materials that contain information to be destroyed secured to prevent access to the contents? Is cardholder data on electronic media rendered unrecoverable via a secure wipe program in accordance with industry-accepted standards for secure deletion, or otherwise by physically destroying the media, so that cardholder data cannot be reconstructed?

107 Requirement Are devices that capture payment card data via direct physical interaction with the card protected against tampering and substitution as follows? Note: This requirement applies to card-reading devices used in card-present transactions(that is, card swipe or dip) at the point of sale. This requirement is not intended to apply to manual key-entry components such as computer keyboards and POS keypads. Note: Requirement 9.9 is a best practice until June 30, 2015, after which it becomes a requirement. 9.9 (a) Do policies and procedures require that a list of such devices maintained? 9.9 (b) Do policies and procedures require that devices are periodically inspected to look for tampering or substitution?

108 Requirement (c) Do policies and procedures require that personnel are trained to be aware of suspicious behavior and to report tampering or substitution of devices? (a) Does the list of devices include the following? Make, model of device Location of device (for example, the address of the site or facility where the device is located) Device serial number or other method of unique identification (b) Is the list accurate and up to date? (c) Is the list of devices updated when devices are added, relocated, decommissioned, etc.?

109 Requirement (a) Are device surfaces periodically inspected to detect tampering (for example, addition of card skimmers to devices), or substitution (for example, by checking the serial number or other device characteristics to verify it has not been swapped with a fraudulent device) as follows? Note: Examples of signs that a device might have been tampered with or substituted include unexpected attachments or cables plugged into the device, missing or changed security labels, broken or differently colored casing, or changes to the serial number or other external markings (b) Are personnel are aware of procedures for inspecting devices?

110 Requirement Are personnel trained to be aware of attempted tampering or replacement of devices, to include the following? (a) Do training materials for personnel at point-ofsale locations include the following? Verify the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices Do not install, replace, or return devices without verification. Be aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices). Report suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a manager or security officer).

111 Requirement (b) Have personnel at point-of-sale locations received training, and are they aware of procedures to detect and report attempted tampering or replacement of devices? 9.10 Are security policies and operational procedures for restricting physical access to cardholder data: Documented In use Known to all affected parties?

112 Questions?