PCI Compliance (for developers)

16
PCI COMPLIANCE Introduction for developers mostly

Transcript of PCI Compliance (for developers)

Page 1: PCI Compliance (for developers)

PCI COMPLIANCEIntroduction for developers mostly

Page 2: PCI Compliance (for developers)

• Goal of the standard is to protect cardholder data• Statistics for US and Europe:• 81% store payment card numbers• 73% store payment card expiration dates• 71% store payment card verification codes• 16% store other personal data

• Internet • Public

Networks• WirelessPOS

• Internet • Public

Networks• WirelessMerchant

• Internet • Public

Networks• WirelessService Provider

• Internet • Public

Networks• WirelessAcquirer

Page 3: PCI Compliance (for developers)

• PCI DSS compliance process

RepairReportAssess

Page 4: PCI Compliance (for developers)

• PAYMENT CARD INDUSTRY SECURITY STANDARDS

ManufacturersPCI PTS

PIN Transaction Security

Software DevelopersPCI PA-DSS

Payment Application

Vendors

Merchants & ProcessorsPCI DSS

Data Security Standard

Page 5: PCI Compliance (for developers)

• PCI DSS version 1.2 common sense steps that mirror best security practices

Goals PCI DSS Requirements

Build and Maintain a SecureNetwork

1. Install and maintain a firewall configuration to protect cardholderdata2. Do not use vendor-supplied defaults for system passwords andother security parameters

Protect Cardholder Data 3. Protect stored cardholder data4. Encrypt transmission of cardholder data across open, publicnetworks

Maintain a VulnerabilityManagement Program

5. Use and regularly update anti-virus software or programs6. Develop and maintain secure systems and applications

Implement Strong AccessControl Measures

7. Restrict access to cardholder data by business need-to-know8. Assign a unique ID to each person with computer access9. Restrict physical access to cardholder data

Regularly Monitor and TestNetworks

10. Track and monitor all access to network resources and cardholderdata11. Regularly test security systems and processes

Maintain an InformationSecurity Policy

12. Maintain a policy that addresses information security foremployees and contractors

Page 6: PCI Compliance (for developers)

• Do NOT request, send or accept payment card information by email

• If you receive cardholder data via email, do NOT process the transaction

• Make the sender aware that, for their safety, they should never email credit card information

• Remove the cardholder data when responding and direct them to an approved processing method

• Delete the email containing cardholder data completely from your email account.

• Many of the above practices can be applied to Personal Information or PI (SSN, home address, anything that can uniquely identify a person)

Page 7: PCI Compliance (for developers)

In majority of the cases we can use cryptographic primitives, methods and protocols (refer to my previous presentation on the topic) to ensure secure path our data travels (card data and PI) from initiator (data storage, POS, etc.) to the end-point.

Sometimes we need to make sure we also reflect country or project specific legal requirements.

Always think of where your data might end-up and do NOT STORE or TRANSMIT it without strong business

reasons !

If you absolutely need to do it think of tokenizing sensitive data.

Page 8: PCI Compliance (for developers)

• The PA-DSS is a standard for developers of payment applications.• Its goal is to help development of secure commercial payment

applications that do not store prohibited data, and ensure that payment applications support compliance with the PCI DSS.

• Merchants and service providers should ensure that they are using Council-approved payment applications; check with your acquiring financial institution to understand requirements and associated timeframes for implementing approved applications.

• PA-DSS has 14 requirements: For details and a list of approved Payment Applications, see PCI website.

Why building applications with PA-DSS in mind is important even if your applications is not going to

participate in the PCI pipeline?

Because it might! And chances are it will if you work with financial industries.

Page 9: PCI Compliance (for developers)

When should we comply with the PCI requirements?

• We accept payments (credit card or debit card) in-person

• -”- over the phone• -”- over the internet• -”- over mail• We act as a service providers (accept payments

for others)

PCI standard applies to all actors that store, process or transmit cardholder data.

Page 10: PCI Compliance (for developers)

Extract from the PCI guide:“Requirement 3: Protect stored cardholder dataIn general, no cardholder data should ever be stored unless it’s necessary to meet the needs of thebusiness. Sensitive data on the magnetic stripe or chip must never be stored. If your organizationstores PAN, it is crucial to render it unreadable (see 3.4, and table below for guidelines).3.1 Limit cardholder data storage and retention time to that required for business, legal, and/orregulatory purposes, as documented in your data retention policy.3.2 Do not store sensitive authentication data after authorization (even if it is encrypted). Seeguidelines in table below.3.3 Mask PAN when displayed; the first six and last four digits are the maximum number of digitsyou may display. Not applicable for authorized people with a legitimate business need to seethe full PAN. Does not supersede stricter requirements in place for displays of cardholder datasuch as on a point-of-sale receipt.3.4 Render PAN, at minimum, unreadable anywhere it is stored – including on portable digitalmedia, backup media, in logs, and data received from or stored by wireless networks.Technology solutions for this requirement may include strong one-way hash functions,truncation, index tokens, securely stored pads, or strong cryptography. (See PCI DSS Glossary fordefinition of strong cryptography.)3.5 Protect cryptographic keys used for encryption of cardholder data from disclosure and misuse.3.6 Fully document and implement all appropriate key management processes and procedures forcryptographic keys used for encryption of cardholder data.”

Page 11: PCI Compliance (for developers)

Extract from the PCI guide:“Requirement 4: Encrypt transmission of cardholder data across open, public networksCyber criminals may be able to intercept transmissions of cardholder data over open, public networksso it is important to prevent their ability to view these data. Encryption is a technology used to rendertransmitted data unreadable by any unauthorized person.4.1 Use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitivecardholder data during transmission over open, public networks (e.g. Internet, wirelesstechnologies, global systems for communications [GSM], general packet radio systems [GPRS]).Ensure wireless networks transmitting cardholder data or connected to the cardholder dataenvironment use industry best practices (e.g., IEEE 802.11ix) to implement strong encryptionfor authentication and transmission. For new wireless implementations, it is prohibited toimplement WEP after March 31, 2009. For current implementations, it is prohibited to use WEPafter June 30, 2010.4.2 Never send unencrypted PANs by end user messaging technologies.”

Page 12: PCI Compliance (for developers)

Regarding developing and maintaining secure systems and applications PA-DSS certified applications will have an Implementation Guide.

In general there are many secure software development and deployment guidelines, for example OWASP for web applications, or Microsoft security checklists, and it is a good idea to pick any and follow it.

Page 13: PCI Compliance (for developers)

Annual penetration testing and quarterly wireless and vulnerability testing is a part of testing efforts and

should be performed.

Remember, using penetration testing frameworks during development phase builds a solid foundation

for your software!

Page 14: PCI Compliance (for developers)

If you don’t have to comply with the PCI standards, breaching your application will bring you unsatisfaction with the clients and will hurt your reputation, at the very least. The real trouble begins when your organization and your software do need to comply. In that case:

“Breach Consequences- Even if a company is 100% PCI compliant and validated, a breach in cardholder data may still occur. Cardholder Breaches can result in the following losses for a merchant.$50-$90 fine per cardholder data compromisedSuspension of credit card acceptance by a merchant’s credit card account providerLoss of reputation with customers, suppliers, and partnersPossible civil litigation from breached customersLoss of customer trust which effects future sales”

And these are just a small part if the forthcoming troubles.

Page 15: PCI Compliance (for developers)

Project implementation examples

Page 16: PCI Compliance (for developers)

Questions?