pci dss for engineers
DESCRIPTION
PCI DSS can be one of the most infuriating set of standards on the compliance landscape. While it seems simple--six domains and twelve requirements--the art of interpreting PCI can lead to full blown war in an organization--with the security team at the center. In this session we’ll demystify some of the more difficult and misunderstood aspects of PCI DSS. We’ll cover the important changes from recently announced PCI DSS 3.0. We’ll also discuss the best practices for starting (and maintaining) a PCI DSS initiative in an organization and how to avoid battles with the QSA.TRANSCRIPT
-
PCI DSS for Engineers: Adventures in PCI
Wonderland
Michele Chubirka [email protected] Postmodern Security
1
-
2 Postmodernsecurity.com 2014 PCI DSS for Engineers
Revision history
2014-06-21 First draft
-
3 Postmodernsecurity.com 2014 PCI DSS for Engineers
Who Are You?
Michele Chubirka aka @MrsYisWhy Security architect, engineer,
analyst. Writer for Network Computing
and TechTarget Blogs and hosts a security
podcast, Healthy Paranoia, www.healthyparanoia.net
Researcher and pontificator on topics such as security architecture and best practices.
Hates the color brown.
-
4 Postmodernsecurity.com 2014 PCI DSS for Engineers
The Bigger Picture: Security Webinars
Availability Live sessions Recordings of individual webinars Yearly subscription
Other options Customized webinars ExpertExpress On-site workshops
Inter-DC FCoE has very limited use and requires no bridging More information @ http://www.ioshints.info/Webinars
Security
Data Center Networking
PCI DSS for Engineers
DMVPN, IPv6 Security
Virtual Firewalls
Virtualization
-
5 Postmodernsecurity.com 2014 PCI DSS for Engineers
Begin at the beginning, and go on till you come to the end: then stop.
-
6 Postmodernsecurity.com 2014 PCI DSS for Engineers
Overview
Purpose and Background of PCI DSS Compliance vs. Non-compliance Basics of Standard Whats New in PCI 3.0 The Jabberwocky: Scoping and Compensating
Controls Common Myths Getting it Right
-
7 Postmodernsecurity.com 2014 PCI DSS for Engineers
The time has come, the Walrus said, To talk of many things: Of PINs and POS and ASVs, And why the sea is boiling hot and whether QSAs have wings.
-
8 Postmodernsecurity.com 2014 PCI DSS for Engineers
*This is one of Ivans filler slides. Who are these children and why are they so intrigued by network cables?
Please Ask Questions!
-
9 Postmodernsecurity.com 2014 PCI DSS for Engineers
Will you, won't you, will you, won't you, will you join the dance?
PCI DSS applies to any entity that accepts processes stores transmits member-branded card data
Put in place to reduce credit card fraud. Compliance with standard is a binary yes | no.
Its like a game of cooties, if you touch credit card data, youre infected.
-
10 Postmodernsecurity.com 2014 PCI DSS for Engineers
were all mad here. Im mad. Youre mad." "How do you know Im mad?" said Alice. "You must be," said the Cat, or you wouldnt have come here.
Should You Be In the Business of PCI?
-
11 Postmodernsecurity.com 2014 PCI DSS for Engineers
Get out of the PCI business; youre not good at it, you havent (usually) applied the lessons learned and you will eventually lose. - Anonymous QSA
-
12 Postmodernsecurity.com 2014 PCI DSS for Engineers
Proprietary framework released in 2004 by PCI Security Standards Council to ensure secure handling of credit card data. www.pcisecuritystandards.org
Founded by five global payment brands. Enforcement of compliance and penalties for non-
compliance determined by each brand, not the council.
Related standards include: Payment Application Data Security Standard (PA-DSS) and PIN Transaction Security (PTS)
PCI DSS: Payment Card Industry Data Security Standard
-
13 Postmodernsecurity.com 2014 PCI DSS for Engineers
Why Does PCI DSS Matter?
2014 MILESTONES The PCI Data Security
Standard (DSS) turns ten years old
DSS 3.0 becomes effective and validation assessments start (January 1)
DSS 2.0 expires and compliance validation against version 3.0 becomes mandatory (December 31)
Verizon 2014 PCI Compliance ReportINTRODUCTION2014 will be a pivotal year for merchants and service providers looking to comply with PCI standards.
A DECADE ON, AND MORE IMPORTANT THAN EVER
Payment card data is becoming more important as cards supplant cash, and as our DBIR data shows, its a prime target for attackers. As we are putting the finishing touches to this report, the FBI has issued a warning to retailers to be wary of card-targeting malware thought to already be responsible for the breaching of over 100 million peoples card data.1
The PCI DSS is designed to standardize and assess how organizations are protecting the card data they hold from this and other threats. The PCI Security standards apply to all organizations that handle cardholder data. The core standard, the PCI DSS, has been around for nearly a decade; and service providers, merchants, and financial companies of all sizes and from around the world have adopted it. PCI DSS is the most widespread and established standard of its kind: its broadly accepted, widely discussed, and its not going away.
So its widespread. But is it effective in achieving security? Our evidence suggests that it is.
ORGANIZATIONS THAT ARE BREACHED TEND TO BE LESS COMPLIANT WITH PCI DSS THAN THE AVERAGE OF ORGANIZATIONS IN OUR RESEARCH.
As we enter the tenth year of PCI DSS, there has been important progress. With version 3.0, PCI DSS is more mature than ever, and covers a broad base of technologies and processes such as encryption, access control, and vulnerability scanning to offer a sound baseline of security. The range of supporting standards, roadmaps, guidance, and methodologies is expanding. And our research suggests that organizations are complying at a higher rate than in previous years.
After an uncertain start, many organizations now feel comfortable with and better understand what the DSS is about, and accept that complying with it is not only a necessary part of accepting card payments, but also a solid baseline of controls for protecting cardholder data.
Most analysts agree that, while the PCI standards are imperfect, they have evolved to clarify expectations and address feedback from the industry, and today they provide an increasingly mature framework for organizations to work toward.
So why is PCI compliance still worth talking, and indeed writing a major piece of research, about?
$10B
$12B
$0
$6B
$4B
$2B
$8B
Global Card Fraud Losses ($Billions)
00 01 02 03 04 05 06 07 08 09 10 11 12Data from The Nilson Report, August 2013Figure 2: The cost of card fraud; data from The Nilson Report, August 2013
5VERIZON 2014 PCI COMPLIANCE REPORT
-
14 Postmodernsecurity.com 2014 PCI DSS for Engineers
Payment card data remains one of the easiest types of data to convert to cash, and therefore the preferred choice of criminals. 74% of attacks on retail, accommodation, and food services companies target payment card information. - Data from Verizon Data Breach Investigations Reports (DBIRs), 2011, 2012 and 2013
-
15 Postmodernsecurity.com 2014 PCI DSS for Engineers
Whos Compliant?
Payment card data remains one of the easiest types of data to convert to cash, and therefore the preferred choice of criminals. 74% of attacks on retail, accommodation, and food services companies target payment card information.Data from Verizon Data Breach Investigations Reports (DBIRs), 2011, 2012 and 2013
COMPLIANCE REMAINS A MAJOR ISSUE
But our research also shows that the vast majority of organizations are still not sufficiently mature in their ability to implement and maintain a quality, sustainable PCI Security compliance program, and they continue to struggle to provide the required compliance evidence at the time of the annual compliance validation assessment.
Theres significant variation across the individual requirements, controls, and subcontrols; as well as across industries and regions. Despite a decade of discussion, clarification, and education, there are fundamental disagreements and misunderstandings around critical areas of security and compliance, including how to define the scope of compliance itself, and how compliance is assessed. Some even regard the DSS, even in its latest 3.0 guise, as taking fundamentally the wrong approach to security.
According to our research, only around one in ten organizations were fully compliant with PCI DSS 2.0 at the time of their baseline assessment. Despite the increasing maturity of the standard and organizations understanding of it, attaining compliance remains far from easy and so it should. Protecting cardholder data is important and the threats to it are very real.
And the drivers for investing in security and compliance are more pressing than ever. The very payment card data breaches that PCI DSS was designed to help avoid are growing in frequency and scale, with compromised records often numbering in the millions. As consumers and businesses continue to ditch cash and do more of their shopping online, the risk and impact of breaches is set to grow further. The related disciplines of security and compliance are, consequently, still a top business priority.
100%
0%
50%
25%
75%
Percentage of companies that passed
2 3 4 5 6 7 8 9 10 111Number of requirements
% co
mpa
nies
12
11.1%
95.6% 95.6%
77.8%
71.1%
60.0%
51.1%44.2% 42.2%
31.1%24.4%
100.0%
11.1% of companies passed all 12 requirements
Over half (51.1%) of companies passed 7 requirements.
Figure 3: Percentage of companies that passed; dataset 2013
6 VERIZON ENTERPRISE SOLUTIONS
Verizons 2014 PCI Compliance Report
-
16 Postmodernsecurity.com 2014 PCI DSS for Engineers
Pass or Fail?
11.1% met all requirements of DSS 2.0 in 2013, an increase of 3.6 percentage points from 2012. In 2013, companies were compliant with an average of 85.2% of controls. one in five organizations came close to complying they passed 95%+ of controls. Of these organizations, more than half failed Requirement 11 [Regularly test security systems and processes]. - From Verizons 2014 PCI Compliance Report
-
17 Postmodernsecurity.com 2014 PCI DSS for Engineers
Does PCI DSS Work?
Effectiveness is determined by the organizations implementation, not the auditor.
Considered a snapshot in time.
-
18 Postmodernsecurity.com 2014 PCI DSS for Engineers
Compliance != Security
Venn diagram courtesy of @grecs
-
19 Postmodernsecurity.com 2014 PCI DSS for Engineers
Off With Her Head!: The Consequences of Non-compliance
-
20 Postmodernsecurity.com 2014 PCI DSS for Engineers
Lawsuits and countersuits Insurance claims Suspension of merchant status with processor
or in-depth assessments if breached. Payment card issuer fines Possible government fines (depending upon
where you do business) Damage to reputation and business
-
21 Postmodernsecurity.com 2014 PCI DSS for Engineers
Example: Target Breach
Target CIO resigned after breach of 40 million credit card and debit records.
At least 80 100 lawsuits filed. Earnings down 46% in 2013 4th
quarter. Total losses could reach one billion. Reportedly validated as
compliant Targets QSA, Trustwave, is also in
litigation with banks.
-
22 Postmodernsecurity.com 2014 PCI DSS for Engineers
Others Recent Breaches
Neiman Marcus - 350k Sally Beauty 282k Michaels 2.6 MM P.F. Changs 7MM (estimate) California DMV - ?
-
23 Postmodernsecurity.com 2014 PCI DSS for Engineers
PCI DSS 101
-
24 Postmodernsecurity.com 2014 PCI DSS for Engineers
Important Taxonomy Merchant any entity that accepts payment cards Payment Card card/device bearing logo of founding members of PCI SSC Issuer entity issuing payment cards or performs, facilitates or supports issuing services. Service Provider or Merchant Service Provider (MSP) - furnishes all or some of payment services for a merchant Payment Processor type of MSP Acquiring Bank connects to card brand network for payment processing QSA qualified security assessor SAQ self assessment questionnaire ASV approved scanning vendor PAN primary account number CVV card verification value CSC card security code POS point of sale CDE cardholder data environment ROC report on compliance AOC attestation of compliance AOV attestation of validation Scoping process identifying all system components, people and processes included in an assessment From PCI DSS and PA DSS Glossary of Terms, Abbreviations, and Acronyms V. 3.0, January 2014
-
25 Postmodernsecurity.com 2014 PCI DSS for Engineers
Speak English! I don't know the meaning of half those words, and I don't believe you do either!
-
26 Postmodernsecurity.com 2014 PCI DSS for Engineers
Typical Processing Chain
1. Cardholder
2. Merchant
3. Payment Processor
4. Acquiring
Bank
5. Card Brand
Customer with credit or debit card received from issuing bank
Accepts credit or debit card for goods/services
Provides payment service for merchant
Connects to card brand network for payment processing
Visa
MasterCard
Amex
Discover
JCB
-
27 Postmodernsecurity.com 2014 PCI DSS for Engineers
-
28 Postmodernsecurity.com 2014 PCI DSS for Engineers
Sometimes PCI is a hill, and sometimes its a mountain.
Six domains, 12 requirements The goal is to reduce risk of fraud Simple, right?
-
29 Postmodernsecurity.com 2014 PCI DSS for Engineers
Validation Requirements
Compliance vs. validation, whats the difference?
Merchant and/or service provider status
Based upon volume of transactions.
Method of acceptance Whether the merchant has ever
been breached. Varies by payment card brand. Can change. Expect stricter
requirements in the future.
-
30 Postmodernsecurity.com 2014 PCI DSS for Engineers
Merchant Levels
Level 1 processes > 6MM Visa, MC or Discover transactions annually, 2.5MM Amex, 1MM JCB
Level 2 1 to 6MM Visa, MC or Discover, 50k to 2.5MM Amex, < 1MM JCB
Level 3 20k to 1MM Visa or Discover card-not-present transactions, >20k MC ,
-
31 Postmodernsecurity.com 2014 PCI DSS for Engineers
Service Provider Levels
Level 1 All 3rd party providers (TPP), all data storage entities (DSE) that store, transmit or process > 300k MC, >=2.5MM Amex, >300k Visa
Level 2 DSEs < 300k MC, 50k to 2.5MM Amex,
-
32 Postmodernsecurity.com 2014 PCI DSS for Engineers
Validation Requirements
Level 1 ASV scan, QSA on-site assessment Level 2 ASV scan, Visa SAQ, MC QSA/ISA on-site
assessment or assisted SAQ. Level 3 ASV Scan, SAQ Level 4 ASV scan if requested, SAQ
Amex requirements differ slightly: https://www209.americanexpress.com/merchant/services/en_US/data-security Make sure you know your level, because it can impact your validation requirements!
-
33 Postmodernsecurity.com 2014 PCI DSS for Engineers
Self Assessment Questionnaire (SAQ) Validation Types
Type A Merchants who keep only paper reports or receipts with cardholder data, do not store cardholder data in electronic format and do not process or transmit any cardholder data on their systems or premises. Does NOT apply to face-to-face merchants.
Type B - Imprint-only merchants with no electronic cardholder data storage, or standalone, dial-out terminal merchants with no electronic cardholder data storage.
Type C-VT - Merchants who process cardholder data only via isolated virtual terminals on personal computers connected to the Internet. This SAQ option applies only to merchants who manually enter a single transaction at a time via a keyboard into an Internet-based virtual terminal solution.
Type C Those with payment application systems (for example, point-of-sale systems) that are connected to the Internet (for example, via DSL, cable modem, etc.) either because: The payment application system is on a personal computer that is connected to the
Internet (for example, for e-mail or web browsing), or The payment application system is connected to the Internet to transmit cardholder data.
Type D All others
-
34 Postmodernsecurity.com 2014 PCI DSS for Engineers
Caution: Make sure to carefully read the Self-Assessment Questionnaire Instructions and Guidelines document, not just the questionnaire itself.
-
35 Postmodernsecurity.com 2014 PCI DSS for Engineers
PCI DSS Domains
1. Build and maintain a secure network. 2. Protect cardholder data. 3. Maintain a vulnerability management program. 4. Implement strong access control measures. 5. Regularly monitor and test networks. 6. Maintain an information security policy.
-
36 Postmodernsecurity.com 2014 PCI DSS for Engineers
That Doesnt Seem So Bad
-
37 Postmodernsecurity.com 2014 PCI DSS for Engineers
Requirements
1. Install and maintain a firewall configuration to protect cardholder data. 2. Do not use vendor-supplied defaults for system passwords and other
security parameters. 3. Protect stored cardholder data. 4. Encrypt transmission of cardholder data across open, public networks. 5. Protect all systems against malware and regularly update anti-virus
software or programs. 6. Develop and maintain secure systems and applications. 7. Restrict access to cardholder data by business need to know. 8. Identify and authenticate access to system components. 9. Restrict physical access to cardholder data. 10. Track and monitor all access to network resources and cardholder data. 11. Regularly test security systems and processes. 12. Maintain a policy that addresses information security for all personnel.
-
38 Postmodernsecurity.com 2014 PCI DSS for Engineers
Curiouser and curiouser!
PCI DSS V3.0 is 112 pages. Every requirement has sub-
requirements, testing procedures and guidance (new in 3.0).
Requirement One has 23 sub-requirements.
Over 200 requirements in total.
That doesnt include the additional guidance documentation.
-
39 Postmodernsecurity.com 2014 PCI DSS for Engineers
Payment Card Industry (PCI) Data Security Standard, v3.0 Page 24 2006-2013 PCI Security Standards Council, LLC. All Rights Reserved. November 2013
PCI DSS Requirements Testing Procedures Guidance 1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment.
1.3 Examine firewall and router configurationsincluding but not limited to the choke router at the Internet, the DMZ router and firewall, the DMZ cardholder segment, the perimeter router, and the internal cardholder network segmentand perform the following to determine that there is no direct access between the Internet and system components in the internal cardholder network segment:
A firewall's intent is to manage and control all connections between public systems and internal systems, especially those that store, process or transmit cardholder data. If direct access is allowed between public systems and the CDE, the protections offered by the firewall are bypassed, and system components storing cardholder data may be exposed to compromise.
1.3.1 Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.
1.3.1 Examine firewall and router configurations to verify that a DMZ is implemented to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.
The DMZ is that part of the network that manages connections between the Internet (or other untrusted networks), and services that an organization needs to have available to the public (like a web server).
This functionality is intended to prevent malicious individuals from accessing the organization's internal network from the Internet, or from using services, protocols, or ports in an unauthorized manner.
1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ.
1.3.2 Examine firewall and router configurations to verify that inbound Internet traffic is limited to IP addresses within the DMZ.
1.3.3 Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment.
1.3.3 Examine firewall and router configurations to verify direct connections inbound or outbound are not allowed for traffic between the Internet and the cardholder data environment.
Examination of all inbound and outbound connections allows for inspection and restriction of traffic based on the source and/or destination address, as well as inspection and blocking of unwanted content, thus preventing unfiltered access between untrusted and trusted environments. This helps prevent, for example, malicious individuals from sending data they've obtained from within your network out to an external untrusted server in an untrusted network.
-
40 Postmodernsecurity.com 2014 PCI DSS for Engineers
Say what you mean
The requirements seem simple, but the meaning is nuanced.
Sometimes interpreted differently by QSAs and ISAs. PCI DSS 3.0 adds a guidance column with more
detail to clarify intent of requirements. Best defense is to read the standard. Ignorance is not an acceptable excuse. If assessor and merchant disagree, an acquiring bank
may accept the risk and consider merchant compliant.
-
41 Postmodernsecurity.com 2014 PCI DSS for Engineers
Whats New in 3.0: Highlights
Moved from 2 year to 3 year standards development lifecycle.
Requirements are the same, but with modifications to sub-requirements.
V2.0 active until Dec. 31, 2014, some new V3.0 requirements not mandatory until July 2015.
Clarifies scoping and reporting Focus on consistency, proactivity and best practices Addition of security policy/procedure into each
requirement. Clarifies handling of sensitive authentication data
(SAD).
-
42 Postmodernsecurity.com 2014 PCI DSS for Engineers
When Should You Be Compliant with 3.0?
If youre filing an AOC on 12/01/14 for PCI-DSS 2.0 you could be considered non-compliant on 01/01/15.
Confirm with your acquiring back if they will accept the risk until the next annual reassessment.
-
43 Postmodernsecurity.com 2014 PCI DSS for Engineers
Specific Requirement Additions
Req 1. Current diagram with cardholder data flows in addition to network diagrams. Req 2. Maintain inventory of in-scope system components and change default passwords on application/service accounts. Req 3. More options for secure storage of crypto keys. Clarification regarding dual control. Req 5. Evaluate evolving malware threats for systems not commonly affected by malware.
-
44 Postmodernsecurity.com 2014 PCI DSS for Engineers
Requirement Additions Continued
Req 6. Update list of common vulnerabilities, align with OWASP, NIST, SANS for secure coding practices. Req 8. Security considerations for authentication mechanisms such as tokens, smart cards and certs. Enhanced guidance on good password practices. More flexibility to accommodate variations in secure implementations. Req 9. Protect POS terminals and devices from tampering or substitution. Req 10. Clarifies intent and scope of daily log reviews by focusing on identifying suspicious activity. Req 11. Implement pentesting method to validate segmentation. Req 12. Maintain info about status of PCI DSS for 3rd party providers.
-
45 Postmodernsecurity.com 2014 PCI DSS for Engineers
Scope
According to PCI SSC, the CDE consists of people, processes and technology that store, process or transmit cardholder data or sensitive authentication data. Firewalls Switches Access Points Network and Security Appliances Servers
-
46 Postmodernsecurity.com 2014 PCI DSS for Engineers
Scoping
Anything included or connected to CDE is in scope. Isolating (segmenting), the CDE from the rest of the network
is not a requirement. Technique that shrinks the scope of the assessment, reducing
cost and difficulty. Reduces risk. Without scoping, entire network is in scope of the assessment. To be out of scope, the component must be properly
segmented from the CDE, so that if compromised it could not impact CDE.
Encryption can reduce scope, but it depends
-
47 Postmodernsecurity.com 2014 PCI DSS for Engineers
Network Before PCI
Dev/QA/Lab
Prod/UAT
Backup MGMT
SOX
Users
Corp
DMZ
Database
Application
Services: SharePoint, file sharing email and web
DMZ
Database
Application
Users have access to everything, with minor restrictions based upon role. Data is segmented, but still flows freely between categories.
-
48 Postmodernsecurity.com 2014 PCI DSS for Engineers
After PCI
Corp
Dev/QA/Lab
Prod/UAT
Backup
MGMT
PCINon-PCI
Non-PCI PCIUsers
Services: Sharepoint, file sharing, email
and web
Jumphosts and VDI
General Network and System
Services:DNS, RADIUS, NTP, LDAP,
Vmware Management, etc...
PCI debug and storage
database
application
DMZ
database
application
DMZ
database
application
DMZ
SOX
NOTE: Direction of arrows implies logical direction of data flow
Data/Network Segmentation
ESX Hosts
NMS App and DB support systems
ILO and Console Access
-
49 Postmodernsecurity.com 2014 PCI DSS for Engineers
Reducing Scope with Point-to-Point Encryption (P2PE)
A P2PE solution encrypts data from the point-of-interaction (POI) until the data reaches a 3rd party solution provider.
Uses a PCI SSC P2PE-validated application Will only reduce scope if the devices and people
between the two encryption endpoints have no access to keys.
If the person or device can decrypt the stored or transmitted CHD, then its in scope.
-
50 Postmodernsecurity.com 2014 PCI DSS for Engineers
Compensating Controls
Compensating controls may be considered for most PCI DSS requirements when an entity cannot meet a requirement explicitly as stated, due to legitimate technical or documented business constraints, but has sufficiently mitigated the risk associated with the requirement through implementation of other, or compensating, controls.
From Appendix B, PCI DSS, v3.0
-
51 Postmodernsecurity.com 2014 PCI DSS for Engineers
Compensating Controls Must
Meet intent of original requirement. Provide similar level of defense. Go above and beyond. Be commensurate with additional risk. Be more work to implement, not less. Pass an audit.
-
52 Postmodernsecurity.com 2014 PCI DSS for Engineers
PCI DSS Myths
-
53 Postmodernsecurity.com 2014 PCI DSS for Engineers
1. I only process a small number of credit card transactions, so its not a big deal.
You MUST be compliant with PCI DSS, regardless of number of transactions processed.
If you outsource, you must verify that organizations PCI DSS compliance status in accordance with requirement 12.
Outsourcing simplifies your requirements by reducing scope, but doesnt eliminate the need to address them.
-
54 Postmodernsecurity.com 2014 PCI DSS for Engineers
2. I only have to submit an SAQ, so all the requirements dont apply.
All requirements still apply. The questionnaire is misleading. There are fewer questions because the categories assume
reduced scope. Check the decision tree in the SAQ Instructions and
Guidelines document.
-
55 Postmodernsecurity.com 2014 PCI DSS for Engineers
PCI DSS Self-Assessment Questionnaire Instructions and Guidelines, v2.0 October 2010 Copyright 2010 PCI Security Standards Council LLC Page 17
Which SAQ Best Applies to My Environment?
-
56 Postmodernsecurity.com 2014 PCI DSS for Engineers
3. Wireless requirements only apply if card data transits the WLAN.
Wireless is perceived as a vulnerable medium. You must still validate that wireless is out of scope to meet
fewer requirements. See requirements 1.2.3, 9.1.3, 10.5.4, 11.1
-
57 Postmodernsecurity.com 2014 PCI DSS for Engineers
4. To reduce scope, I need to have physically separate networks.
You have to implement controls which segment and restrict access to the CDE.
Sometimes, it may be easier to make them physically separate.
-
58 Postmodernsecurity.com 2014 PCI DSS for Engineers
5. Mixed-mode virtualized environments arent permitted From PCI DSS Virtualization Guidelines 2011 document: any VM or other virtual component that is hosted on the same hardware or hypervisor as an in-scope component would also be in scope for PCI DSS, as both the hypervisor and underlying host provide a connection (either physical, logical, or both) between the virtual components.... In order for in-scope and out-of-scope VMs to co-exist on the same host or hypervisor, the VMs must be isolated from each other such that they can effectively be regarded as separate hardware on different network segments with no connectivity to each other.Even if adequate segmentation between virtual components could be achieved, the resource effort and administrative overhead required to enforce the segmentation and maintain different security levels on each component would likely be more burdensome than applying PCI DSS controls to the system as a whole.
-
59 Postmodernsecurity.com 2014 PCI DSS for Engineers
6. Supporting systems arent in scope.
REMEMBER: included in or connected to the cardholder data environment. Its just like a game of cooties.
-
60 Postmodernsecurity.com 2014 PCI DSS for Engineers
7. Compliance requirements are based upon merchant or service provider level.
No, VALIDATION requirements differ. Everyone must comply with ALL of PCI DSS, regardless of level. This is not optional.
-
61 Postmodernsecurity.com 2014 PCI DSS for Engineers
8. I can just use a compensating control to meet a requirement thats too difficult.
Compensating controls are stricter. The key phrase is above and beyond.
-
62 Postmodernsecurity.com 2014 PCI DSS for Engineers
Getting It Right
Data inventory and classification. Data flow and inventory of CDE. Reduce scope wherever possible. Identify data custodians and stakeholders outside of IT. Embed ownership
in entire organization. Learn the language of your compliance peers. Get comfortable with the
PCI DSS taxonomy. Invest in audit and configuration reporting tools, especially for the
firewall. Many compliance people are not very technical, so this will help them (and you).
Avoid Compensating Controls, use as last resort. Remove CC data wherever possible. If you cant remove, tokenize. Encrypt, encrypt, encrypt. Point-to-point encryption (P2PE) can reduce
scope. If > level 4 merchant or SP and you qualify for SAQ D, consider using
QSA or auditor for initial assessment and/or occasional follow-up.
-
63 Postmodernsecurity.com 2014 PCI DSS for Engineers
Final Advice
Get out of the PCI business: outsource to experts.
-
64 Postmodernsecurity.com 2014 PCI DSS for Engineers
References
Chuvakin, Anton, Branden R. Williams, and Ward Spangenberg. PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance. Burlington, MA: Syngress, 2010. Print. "Documents Library." PCI Security Standards Documents: PCI DSS, PA-DSS, PED Standards, Compliance Guidelines and More. Payment Card Industry Security Standards Council, n.d. Web. 17 Mar. 2014. Van Oosten, Ciske. PCI Compliance Report. Rep. no. GL00648-17. Verizon, Feb. 2014. Web. .
-
65 Postmodernsecurity.com 2014 PCI DSS for Engineers
Questions?
-
66 Postmodernsecurity.com 2014 PCI DSS for Engineers
Where Can You Find Me?
Spending quality time in kernel mode practicing and refining my particular form of snark.
www.healthyparanoia.net www.postmodernsecurity.com Twitter @MrsYisWhy Google+ MrsYisWhy [email protected] [email protected] http://www.networkcomputing.com http://searchnetworking.techtarget.com http://searchsecurity.techtarget.com
-
67 Postmodernsecurity.com 2014 PCI DSS for Engineers
Questions?
Paperwork issues
Follow-up by email Please fill in the evaluation form Recording available within 24 hours PDF materials always available for download Discount for future webinars use wlp10 discount code Upgrade to yearly subscription Help me spread the word!
Send them to [email protected] or @MrsYisWhy on Twitter and Google+