pci solna edb 101020 fortconsult
TRANSCRIPT
Tsurikov and Vladislav Horohorin
Tsurikov
SQL injection/pin cracking attack on RBS payment card network
14,000 withdrawals from 2100 ATMs in 280 countries over one
weekend
$9 million in losses
Horohorin
International carder/casher
CarderPlanet, BadB.biz
Automated online ordering system for stolen credit card info
Arrested by French police on US warrant 2 months ago
FortConsult - short
Core competence is penetration tests for financial companies
(extensive creative hacking)
Probably the largest pentest team in Europe (strong focus)
3rd largest PCI assessor (QSA) in Europe
32 people employed in Copenhagen,
We are PCI / pentest consultants only – we do not finance the PCI
projects by selling other services
First QSA (2005), PA-QSA (2008) and ASV (2004) in Scandinavia
QSA for banks and bank hosting centres, covering more than 250
banks in 13 countries in Europe
QSA for 3 out the 5. largest Scandinavian banks
AAA rating from Dun & Bradstreet
My background
Product manager for PCI since 2006
Heavily involved in communication and updates from PCI council
and the card schemes
Has been involved in 80 PCI projects
Working primary with PCI for issuing/acquiring banks and their
serviceproviders
Are chairman for the danish banks PCI working group (formed 2
years ago)
Member of the PCI compliance steering group committee for 2 very
large banks
Educated as HD in Informatics and Management Accounting from
Copenhagen Business School
PCI Council and the card brands
PCI council defines the PCI-DSS, PA-DSS and PTS
standard
VISA controls the compliance proces from London
Mastercard controls the compliance proces from
USA
Our role as QSA for EDB
Issuer compliance in EU Issuer compliance in EU Issuer compliance in EU
General requirements for banks:
Must be PCI compliant now and all the time(MasterCard
operation manual, VISA EU member letter & requirements,
American Express contract)
Special efforts to remove sensitive authenfication data
Register their service providers (2009-2010) VISA member letter 28/06 & 27/09 MasterCard Section
10.3 of the Security Rules and Procedures)
Monitor the PCI status of their serviceproviders
Acquirers must submit an action plan for compliance to
VISA at latest december 2010
VISA member banks service provider must be compliant
at 1. october 2010
The card data is a moving target
• PCI had Initial focus on merchants and POS
• Removing of carddata and EMV
implementation pass the problem
on in the chain
Where are the credit card data, trend
The virtual bank robbery
1 mio Euro. Spreadsheet.XLS
50.000
numbers
The overall issues for the banks
For consumers, banks are mostly about
• Lending some money
• Moving money around with the netbank
• Using a credit/debit card on daily basis
A lot of the processes are tied to the card data
Card data must be in most systems
This leads to things like:
All employee think they need access to card data
Card number are primary key in a lot of db and request
Decentralised systems with card data
The fact that card number is not traditionally seen as confidential data makes theese things even worse
The Self assessment, examples from
Danske Bank
Did an internal Self assessment in 2007, which
said:
90% compliant:
• Most remaining issues related to encryption on
mainframe
Scope:
Was not defined before the Self assessment (but was problaly:)
• Mainframe, part of the network, firewall
The new scope, the findings
In general: all systems in all countries
• Most backend systems in the bank stored card data
• All frontend systems had potential access to card data
• A lot of local applications (including spreadsheets) with card
data
• Much integration with 3. parties
• ATMs and the ATM network
• Callcenter
• Servicedesk
And in general some variance from country to country
The full scope
Original
scope
The full scope
The scope
Who is doing what? – an example of
the complexity
Application developer
Application updater
Daily maintenance Hardware vendor
Hardware service
Installation
Who has contracted with who, and where
are the resposibility?
High level introduction to important
PCI areas
Which data is sensitive?
Scope definition All systems which:
Transmit
Process
Store
..carddata
And all other systems on same network.
If systems are in scope all the PCI requirements apply to the
systems.
Note: Its not a carddata if:
The PAN is encrypted and there is no access to encryption
keys
The PAN truncated – 6+4 digits are shown
The Pan is hashed (one-way encryption)
The content of the standard
Secure systems secure logning
for forensic
Psysical
security
Procedures
documentation Technical security
Awar
eness
Banks
EDB
R E
Q U
I R E
M E
N T
S
Respons.
News from PCI council
New version 2.0 of the PCI-DSS effective from
1. january 2011 (obligatory from 1. janurary
2012). 3 years of lifetime.
New clarification documents for:
Bluetooth
Virtulisation
Tokenisation
Scoping
P2p encryption
EMV
Security – reduction of risk
This is what is all about
Keep that in mind, when you discuss PCI
Bank security
Many part of the PCI standard are covered by
other security standards, like ISO / BS
The largest problems here are that the carddata
has not been seen as confidential data
+ the security is designed primary to protect
from outside attacks
Most security are applied to backend systems,
not to data leaving the backend system.
3. party / outsourcing
Does the cleaning company
needs to be PCI compliant?
Outsourcing / 3. party
The bank must make sure that all outsourcing
providers (service providers) are compliant and
that all 3. party are working towards compliance.
• It’s the banks responsibility to be PCI compliant –
if some part of the it are outsourced, it is still the
banks responsibility.
• This typically require a close cooperation
between the bank & the outsourcing company.
PCI compliance enforcement
Card schemes
Banks
EDB
EDB 3. parties
3. party / outsourcing
Bank
Cardsystems
(EDB) CRM Processing
IT service
Mass printing
Fraud control Callcenter
3 types of 3. parties
3. parties with no direct or indirect access to
carddata
PCI compliance not needed
3. parties with indirect access to carddata
PCI compliance needed, part of the banks
control
3. parties with direct access to carddata
PCI compliance needed, 3. partys own
compliance program
How to split PCI responsibility
At the end of the day its the banks responsibility that
all are PCI compliant.
Backend
system
Bank system Carddata
Data
3. Party
Data owner
Access management
Etc.
Is this a standard
service?
Branches, scope issues
HQ / Backend systems
Branch 1 Branch 2 Branch 3
Internal
functions
Several requirements
for each branch
Findings – where is the real problems (and who takes care of them)
Security personnel's point of view
The business side
Likelihood of compromise
Mainframe Lack of encryption Access control
No interest Low – its in the center, and traditionally protected very well
Network Segmentation No interest Large – since many people possible get access to card data
Data Not their business
All employees has acces to card data
Large – all employees has access or can request access. Card data are traditionally not treated as confidential data, with only need to know acccess Data are present in spreadsheet
Workstation No important data there
Access to card data, local databases
Large – computers are also used to surf the web, and some are used from wireless and at home
Main issues for a bank Project management
• No final plan can be setup before the project begins (scope missing)
• Information needed are spread between many employees
• Efficient interview process must be in place
• Available resources for specialists are limited
• Partners needs to be involved
Branches
• PCI becomes a challenge when its applied on 100's of branches
• Correct design is essential
Encryption
• Encryption on mainframe has a lot of challenges – should it be done?
Risk management
• How should PCI compliance integrate with security
3. partier
• Which approach should the bank use towards 3. party
Forbidden data
It is not permitted to store trackdata, cvc and PIN after
authorization.
• That data is typically present in processing/acquiring
systems as well as in issuer systems – and it must be
removed.
• There are different exemptions for issuers & acquirers,
but the challenge is where the bank are acting as both
issuers & acquirer on the systems.
Encryption
Encryption is mandatory when storing carddata or
sending them outside the banks secure PCI zone.
• Encryption will apply to different systems on different
platforms. This means that a single solution probably
not going to work everywhere.
• Encryption will reduce the performance in systems
• Encryption can be difficult on mainframe
Internal procedures & awareness
The bank must have procedures, that makes sure that it-systems are managed in a PCI compliant manner and that all manual processes where card data are handled in secure.
• Most of the IT procedures are following IT security best practice, but
• There are a lot of things in the normal employee day-to-day work, which are affected
• Failure to address these will put a large risk to the bank, and spoil the PCI compliance work in all other areas – Examples:
Handling of paper
Sending carddata on e-mail/messenger
Using private PDA, Laptop, etc.
Making own excelsheet with customer info incl. carddata
Sending data to marketing or print department, which include cardnumber
Example of areas managed by banks
E-mails – carddata sent by mail
Datawarehouse and other datamanipulation systems (also “homebuilt”)
Spreadsheets
Papers with carddata including mass printout
Wireless scans
Marketing databases
Old data / systems
Control of access to systems
Section 9
Physical access
Surveliance
Networkplugs
Visitor badges
Shredding of paper and media like CD, HDD
Examples of areas managed by banks
Section 12
Security Policy
Employees awareness
Usage of technologies
Incident response plan
Etc.
12.8 If cardholder data is shared with service providers, maintain and implement policies and procedures to manage service providers
Inhouse development 1
Requirement 3: Protect stored cardholder data
3.1 Keep cardholder data storage to a minimum. Develop a data
retention and disposal policy.
3.2 Do not store sensitive authentication data after authorization
(even if encrypted).
3.3 Mask PAN when displayed (the first six and last four digits are
the maximum number of digits to be displayed).
3.4 Render PAN, at minimum, unreadable anywhere it is stored
(including on portable digital media, backup media, in logs)
(+key management)
Inhouse development 2
Requirement 4: Encrypt transmission of cardholder data
across open, public networks
Inhouse development 3
Requirement 6: Develop and maintain secure systems and
applications
6.2 Establish a process to identify newly discovered security vulnerabilities
6.3 Develop software applications in accordance with PCI DSS (for example, secure
authentication and logging) and based on industry best practices, and
incorporate information security throughout the software development life cycle.
These processes must include the following (patch, input validation, error
handling, encryption, role base access control, development/test enviorement,
seperation of duties, no real card and accounts in test enviorement, etc)
6.4 Follow change control procedures for all changes to system components.
6.5 Develop all web applications (internal and external, and including web
administrative access to application) based on secure coding guidelines such as the
Open Web Application Security Project Guide
6.6 Public facing web-applications must be be protected by a web application firewall
or checked for vulnerabilities yearly and after any change
Inhouse development 4
Requirement 8: Assign a unique ID to each person with
computer
The whole section
When should you remember PCI
If you install your own server
When you develop you own applications (+ externally)
Your own network
3. party access to your network
Policies, procedures
The way ahead
PCI its a way of working
Examine the gaps
Implement policies
Identify new projects and align them with PCI
