Transcript Overview of FishNet - ISACA Kettle Moraine Wisconsin

PCI Compliance
Building a Roadmap to success
Presented by:
John A. Otte, CISSP, CISA, CFE, MSIA, MSCE
Senior Consultant
Agenda
+
+
+
+
+
+
+
+
PCI Overview
Merchants and PCI
Merchant Validation Requirements
Merchant Reporting Requirements
The Digital Dozen - PCI Requirements
Payment Application Best Practices (PABP)
Compromise Trends – Why Companies Fail PCI Assessments
What can organizations do better?
PCI Overview
+
+
+
+
+
+
Started in 2001 as separate programs
Cardholder Information Security Program (Visa USA)
Account Information Security (Visa INTL)
Site Data Protection (SDP) Program (MasterCard)
Standards consolidated December 15, 2004 under the naming of the
Payment Card Industry (PCI) Data Security Standard (DSS)
+
+
+
+
Standards include the “Digital Dozen” – 12 core requirements
Predominantly based on the previous CISP requirements
Some influence from SCP and input from other Card companies
Quarterly Scanning Requirements mandated in 2004 for public facing
sites and systems
PCI Overview
+ Payment Application Best Practices Program launched in 2005 to
target security around payment applications
+
Everyone must comply with the standards
+ Based on what category you fall into determines what level of
validation you must provide (i.e. audits/scans)
+ Annual penetration tests are required, although not required to be
submitted
Compliance Level Definitions - Merchants
Level
Compliance Validation
Onsite Annual
Assessment
Quarterly
Perimeter
Scan
Compliance
Questionnaire
Due Date
1
• Any merchant,
regardless of
acceptance channel
that processes greater
than 6 M transactions
• Any merchant that has
suffered a hack.
• Any merchant identified
by any payment card
brand as Level 1
Required
Required
Not Applicable
Sep 30, 2004
2
•
Highly
Recommended
Required
Required
Sep 30, 2007
Highly
Recommended
Required
Required
Jun 30, 2005
Required
Required
Not Applicable
3
•
Any merchant regardless
of channel processing 1 M
to 6M transactions
Any merchant 20K – 1M
transactions
______
4
Highly
Recommended
•
<20K in transactions
PCI Data Security Standard – Merchant Validation Requirements
Level
1
2
American
Express
Discover
JCB
MasterCard
VISA
• By QSA (or internal
auditor if signed by
officer of merchant
company)
• Annual On-site review
Quarterly network scan
by ASV
•
Quarterly network
scan by ASV AND
one of the
following:
•Annual on-site review
by QSA
•Quarterly network
scans by ASV
•
Annual on-site
review by QSA or
internal auditor (if
signed by officer of
merchant
company)
•Annual on-site review
by QSA (or internal
auditor if signed by
officer of merchant
company)
•Quarterly network scan
by ASV
•Annual on-site
review by QSA (or
internal auditor if
signed by officer of
merchant company
and pre-approved
by acquirer)
•Quarterly network
scan by ASV
•Annual SelfAssessment
Questionnaire
•Quarterly network scan
by ASV
•Annual SelfAssessment
Questionnaire
•Quarterly network scan
by ASV
•Annual SelfAssessment
Questionnaire
•Quarterly network
scan by ASV
N/A
•Annual SelfAssessment
Questionnaire
•Quarterly network scan
by ASV
•Annual SelfAssessment
Questionnaire
•Quarterly network
scan by ASV
N/A
At discretion of acquirer:
•Annual SelfAssessment
Questionnaire
•Quarterly network scan
by ASV
•Annual SelfAssessment
Questionnaire
recommended
•Quarterly network
scan by ASV
recommended
•Quarterly network scan
by ASV
-OR-
3
•Quarterly network scan
by ASV
4
N/A
•
Annual SelfAssessment
Questionnaire
PCI Data Security Standard – Merchant Reporting Requirements
Level
1
American
Express
Discover
JCB
MasterCard
VISA
•If compliant, Exec Summary
of QSA/Internal review and
Quarterly Network Scan
•If not compliant, Exec
Summary of QSA/Internal
review and Remediation Plan
annually and Quarterly
Network Scan and Scan
Remediation
•Acceptable Reports
(to be provided upon
request from
Discover):
•No reporting
requirements at
this time
•Acquirers register compliant
merchants in the MC
Registration Program (MRP)
•Acquirers Report Status of
Merchants Quarterly
•Quarterly statement
of merchant
compliance/noncompliance
•Annual confirmation
of Report Accuracy
Letter
•Upon request, a
copy of Report on
Compliance (ROC)
•No reporting
requirements at
this time
•Acquirers annually register
compliant merchants in the MC
Registration Program (MRP)
•Acquirers Report Status of
Merchants Quarterly
•Quarterly statement
of compliance/noncompliance
•No reporting
requirements at
this time
•Acquirers annually register
compliant merchants in the MC
Registration Program (MRP)
•Acquirers Report Status of
Merchants Quarterly
•Quarterly statement
of compliance/noncompliance
•No reporting
requirements at
this time
No Requirements
•Set by Acquirer
2
•Quarterly network scan (and
remediation plan if not in
compliance)
•Executive summary PCI
SAQ
3
•No Requirements
4
N/A
–DISC attestation
of compliance form
-OR–Applicable SAQ
attestation of
compliance
-OR–Discover currently
accepts crosscertification and will
accept reports of
compliance
submitted to the
other payment
brands
The Digital Dozen (PCI Data Security Requirements)
+ Build and Maintain a Secure Network
▪ Requirement 1: Install and maintain a firewall configuration to protect data.
▪ Requirement 2: Do not use vendor-supplied defaults for system passwords and other
security parameters
+ Protect Cardholder Data
▪ Requirement 3: Protect stored data
▪ Requirement 4: Encrypt transmission of cardholder data and sensitive information
across public networks
+ Maintain a Vulnerability Management Program
▪ Requirement 5: Use and regularly update anti-virus software
▪ Requirement 6: Develop and maintain secure systems and applications
The Digital Dozen (PCI Data Security Requirements) (con’t)
+
Implement Strong Access Control Measures
 Requirement 7: Restrict access to data by business need-to-know
 Requirement 8: Assign a unique ID to each person with computer access
 Requirement 9: Restrict physical access to cardholder data
+
Regularly Monitor and Test Networks
 Requirement 10: Track and monitor all access to network resources and
cardholder data
 Requirement 11: Regularly test security systems and processes.
+
Maintain an Information Security Policy
 Requirement 12: Maintain a policy that addresses information security
Specific changes in PCI V1.2
+
Hosting Providers have specific requirements (2.4 & Appendix A)
▪ Hosting providers must become compliant
▪ Merchants/Service Providers that use hosting providers will fail
assessments if their providers do not meet requirements in Appendix A
+
Requirement 5.5.1 now requires that A/V software also detect and remove
malicious software such as adware & spyware.
+
Requirement 6.6 requires application firewalls or code reviews for webfacing custom code (best practice until 6/30/2008)
+
Requirement 12.10 for service providers only, for management of
“connected entities”
+
Self Assessment Questionnaire now has 5 different areas of compliance
+
Appendix A – For hosting providers
+
Appendix B – Compensating control worksheet
Payment Application Best Practices
+
Started in 2005 by Visa in response to application related compromises
on the rise
+
Made part of the permanent standard in 2008
 Many payment application vendors are using this as a differentiator
 This is the standard and now applies to companies that franchise
+
Top 5 Vulnerabilities related to payment applications
 Full track data and/or encrypted PIN block retention
 Default accounts
 Insecure remote access by software vendors and their resellers
 Compatibility issues with anti-virus and encryption
 SQL injection
 Random Access Memory Attack
Who must comply?
+
All merchants that process, store or transmit cardholder data
+
Payment Application Vendors
▪ Point of Sale (Micros)
▪ Shopping Cart
▪ Mobile Payment Providers
+
A web site at Visa and another at Master card lists applications that have
passed PABP assessments
 This creates a market for PABP compliant applications
 Applies market pressure on other application vendors to certify their
applications
Qualifying Questions
+
Do you or any of your business units:
▪
▪
▪
▪
▪
accept credit cards as a form of payment?
build software for the processing of credit cards?
allow customers to swipe credit cards?
accept payments online?
process payments on behalf of others?
+
Do you see future strategies around mobile payments?
+
Are you currently looking to expand into retail or non-strategic B2B?
Recent Changes and Proposed updates
Recent Changes to the PCI DSS
+ PCI V1.2!
▪ 1 October 2008 – New standard
announced
▪ Requires Code Review or
Application layer firewall as of June
2008
+ Wireless
▪ WEP Encryption sunset June 2010
+ Payment Application Best Practices
now part of the standard (PA-DSS)
Proposed updates
+ Encryption still remains a core
requirement although compensating
control alternatives will be considered
+ Data Loss Prevention
+ E-Discovery and adherence to the
Federal Rules of Civil procedure in the
event of a security breach
Why are companies failing PCI assessments?
PCI Requirement
Percentage of
Failure
Requirement 3: Protect Stored Data
79%
Requirement 11: Regularly test security systems and processes.
Requirement 8: Assign a unique ID to each person with computer
access.
74%
71%
Requirement 10: Track and monitor all access to network
resources and cardholder data.
71%
Requirement 1: Install and maintain a firewall configuration to
protect data.
66%
Requirement 2: Do not use vendor-supplied defaults for system
passwords and other security parameters.
62%
Requirement 12: Maintain a policy that addresses information
security.
60%
Requirement 9: Restrict physical access to cardholder data.
59%
Requirement 6: Develop and maintain secure systems and
applications.
56%
Requirement 4: Encrypt transmission of cardholder data and
sensitive information across public networks.
45%
Source:
VeriSign Business Services
Compromised Trends
+ Unsecured physical assets.
▪ Unencrypted data may be stored on backup tapes and other mediums
that are prone to loss or theft
+
Point of sale (POS) application vulnerabilities.
▪ Applications may be creating logs that store card track data.
▪ PCI requirements prohibit the storage of track data under any
circumstance.
▪ Nefarious individuals who are interested in obtaining track data know
which applications store this data and where the information is
typically stored.
Compromised trends…..continued
+
Unencrypted spreadsheet data
▪ Users may be storing card data in spreadsheets, flat files, or other
formats that are difficult to control as they are transferred to laptops,
desktops, and wireless devices.
▪ A key source of PCI audit failure is storing unencrypted data in Excel®
spreadsheets. (Data Leakage/Loss)
+
Poor identity management.
▪ Users and administrators may not be handling authentication properly.
▪ Although password-based authentication is one of the easiest
authentication methods to implement, it is also the most prone to
compromise, because passwords can be easily shared, stolen, or
guessed.
Compromised trends……continued
+
Network architecture flaws; flat networks.
▪
▪
▪
+
Many businesses did not develop their IT infrastructure with security
in mind.
They often fail PCI assessment because they have very flat (nonpartitioned) networks in which card databases are not segmented
from the rest of the network.
The lack of a secure network enclave is a serious issue regardless of
PCI implications, and can be very difficult to remediate.
Lack of log monitoring and intrusion detection system (IDS) data; poor
logging tools.
▪
▪
▪
Without log information, it is difficult to determine whether processes
and security systems are working as expected.
In addition, insufficient data makes it more difficult to investigate
compromises that do occur.
For example, if there were no record of the timeframe of a
compromise, it would be difficult to determine the number of credit
cards exposed during the compromise.
Compromised trends…..continued
+
Card numbers in the Demilitarized Zone (DMZ).
▪ POS terminals may be storing credit card numbers in the externally
facing perimeter network.
▪ In some companies, the POS terminal acts as a card-present terminal
that sits on the Internet.
▪ Because there is no firewall between the system accepting the card
present transaction and the Internet, this arrangement does not
comply with PCI requirements (and hackers can easily find credit card
data).
▪ Frequently, these systems are also storing track data.
Top Five failed requirements
Top Five failed Requirements
Relevant Compromise
Recommended Tactics
Requirement 3: Protect Stored Data
Unencrypted spreadsheet data;
unsecured physical assets
Store less data; understand the flow of
data, encrypt data
Requirement 11: Regularly test
security systems and processes
E-commerce application vulnerabilities;
most data compromises can be
attributed to a web application
vulnerability
Rigorously test applications, scan
systems quarterly
Requirement 8: Assign a unique ID to
each person with computer access
Weak or easily guessed administrative
account passwords
Improve security awareness
Requirement 10: Track and monitor all
access to network resources and
cardholder data.
Lack of log monitoring and intrusion
detection data; poor logging tools
Install intrusion detection or
prevention devices, improve log
monitoring and retention
Requirement 1: Install and maintain a
firewall configuration to protect data
Card numbers in the Demilitarized
zone; segmentation flaws
Segment credit card networks and
control access to them
Why Comply?
+
Penalties
▪
▪
▪
▪
All FIVE major card brands reserve the right to fine acquiring
banks for the non-compliance of their members
ALL acquiring banks reserve the right to fine members for noncompliance.
ALL major Card Brands have agreed on the following fine schedule:
– $5,000 per month for 3 months
– $25,000 for months 4-6
– $50,000 for months 7-9
– $100,000 per month after 9 months of non-compliance until
compliant with the PCI DSS or a “CEASE AND DECIST LETTER IS
ISSUED”
In the case of a breach, if the vendor is found to be out of
compliance, damages can also be borne by the vendor
– Fraud replacement
– Damage control cost replacement
Why Comply?
+
+
+
Brand Security
▪ Maintain stockholder value
▪ Maintain consumer confidence
Improve Internal Processes
▪ Meeting such requirements improves overall operational security
▪ Risk reduction
Transference and Regulatory Overlap
▪ Incrementally improve compliance with other regulatory requirements
▪ PCI DSS based predominantly on ISO27002
▪ Requirements of PCI substantially comply with
– PIPEDA and Privacy Act Security Requirements
– FFIEC Guidance Documents
– GLBA (Safeguard Rule)
– HIPAA (Safeguard Rule)
– EU Data Directive Security Requirements
What can organizations do better?
+
Segregate your Cardholder Processing Environment
▪ Companies have flat networks
▪ The border of the cardholder environment is now the boundary for the
scope of the assessment
▪ The perimeter controls are evaluated, rather than every server on the
network
▪ It is equivalent to having an Internet accessible web application – the
access controls at the perimeter, and the controls in place when allowing
access from an external source are important, but you don’t assess the
system of everyone in the world.
+
Use a Translation Table
▪ Separate table which translates an ID into a credit card number
▪ Use this ID everywhere you would have normally used a credit card #
▪ Still requires encryption of the card number within the table
What can organizations do better?
+
Store Less Data
▪ Don’t store cardholder data unless there is a compelling business
reason to do so
▪ There are no auditing, regulatory, or legal reasons for a merchant to
store cardholder data
▪ Storing transaction history does not necessitate storage of the card
number
+
Better Access Controls
▪ Utilize authentication between web servers, application servers, and
database servers
▪ Lock database tables and restrict access by applications according to
the principle of least privilege
▪ Don’t allow access to tables at all – use stored procedures.
What can organizations do better?
+
Justify Storage of data
▪ Determine where credit card data exists in your organization, what it is
used for, and whether it is needed there.
▪ In addition, be sure that legacy reports have been modified to remove
data that is no longer needed.
+
Make the business prove they need access to and storage of card
holder data
 Explain the risks of storing cad holder data and the impact noncompliance could have on the organization
 Include this type of review as part of a holistic risk assessment
What can organizations do better?
+
Understand the Flow of Data
▪ Many companies have no diagrams or documentation showing how
credit card data flows through their organization.
▪ Unless you have performed a system-wide audit of all data repositories
and then continue to perform audits regularly, you have no way of
determining where data lives and whether you’re complying with PCI
standards.
▪ Companies can curtail many of the compromises discussed earlier by
tracking the flow of data and then correcting the associated problem.
+
One Fishnet Security customer tracked data flows to over 25
locations within the enterprise with multiple copies of card
holder data stored in flat files and unsecure databases.
Forstyhe's consultants identified the card holder data
repositories and assisted the organization with remediation
efforts to mask, truncate or eradicate the data.
What can organizations do better?
+
Document the flow of credit card data throughout your organization.
▪ Understand where data goes—from the point where you acquire it
(either from a customer or third party) to the point where the data is
disposed of or leaves your network.
+
Encrypt Data.
▪ Encryption is a key component of the “defense-in-depth” principle that
the PCI attempts to enforce through its requirements.
▪ Even if other protection mechanisms fail and a hacker gains access to
data, the data will be unreadable if it is encrypted.
▪ Unfortunately, many companies store credit card data on mainframes,
databases, and other legacy systems that were never designed for
encryption. For these companies, encrypting stored data (data at rest)
is a key hurdle in PCI compliance.
▪ Typically, companies choose one of the following options in order to
remediate encryption problems:
What can organizations do better?
+
Retrofit all applications.
▪ With this approach, encryption is rolled into the coding of the payment
application.
▪ Instead of writing the card number to a database, the payment
application encrypts the number first.
▪ The database receives and stores the already-encrypted number.
▪ This approach is popular with companies that outsource their payment
applications to other vendors, for example, small banks that provide
online banking.
▪ In these cases, the vendor handles the encryption.
What can organizations do better?
+
Use an encryption appliance.
▪ A new class of appliance sits between the application and the database.
It encrypts the card data on the way into the database and decrypts
the number on the way out.
▪ Most companies use this approach because the trade-off between
expense and business disruption versus time to deployment is very
good.
+
Use an encrypting database.
▪ An encrypting database offloads encryption to the storage mechanism
itself, so companies don’t have to significantly modify their applications
or buy an appliance.
▪ This product, which is new from Oracle, also provides fairly good key
management. However, it is very expensive.
▪ In addition, it does not operate on IBM® mainframes and AS400®s,
which financial institutions—especially card processing and fulfillment
banks—tend to rely on.
What can organizations do better?
+
Obfuscate without encryption.
▪ Another way around encryption is to not use it.
▪ The PCI Data Security Standard calls for obfuscation—making the
credit card unreadable—not encryption.
▪ One-way hashing, truncation, and other approaches are less costly to
implement than encryption, and in many cases, companies can still
perform all necessary business functions related to credit card
numbers.
+
Incorporate encryption at the development phase.
▪ Use an encryption framework during development instead of
developing applications and then retrofitting them for encryption.
What can organizations do better?
+
Have an overall encryption strategy.
▪ A typical company has multiple encryption requirements—for
everything from VPN tunnels using IPSec, email secured by SMIME, and
SSL certificates, to mainframe, database, and disk encryption (e.g., for
users with laptops).
▪ To minimize costs and avoid problems associated with managing
multiple keys, consider a strategy that encompasses not only PCI
requirements but the entire range of encryption requirements within
your organization.
▪ Then, consolidate key management to the fewest number of points
possible.
What can organizations do better?
+
Improve Your Systems Development Life Cycle (SDLC)
▪ Companies have long had a habit of considering security an add-on
▪ When developing projects, ensure that security expertise (and don’t
forget Internal Audit) is engaged during the scoping, planning, and
design stages of the project
▪ This will ensure that security is integral to the final product
▪ This will reduce the costs of retrofitting or re-architecting a product or
reversing a project after it is nearing its deployment date
▪ It will reduce risk acceptance where the justification is time to market
▪ All stakeholders become more aware of regulatory and policy
requirements surrounding security
▪ All the above benefits are applicable to a complete range of regulatory
or contractual security requirements, not just PCI
Want to really improve your PCI compliance?
Engage Fishnet Security as a Qualified Security
Assessor (QSA) to assist with all of your PCI
needs
Thank you!