1. 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

2. 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

3. 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

4. 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

6. Our role as QSA for EDB

7. Issuer compliance in EUIssuer compliance in EUIssuer 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

8. 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

9. Where are the credit card data, trend

10. The virtual bank robbery
1 mio Euro.
Spreadsheet.XLS
50.000
numbers

11. 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

12. 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

13. 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

14. The full scope
Original
scope
The full scope
The scope

15. 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?

16. High level introduction to important
PCI areas

17. Which data is sensitive?

18. 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)

19. The content of the standard
Secure systems
secure logning
for forensic
Psysical
security
Procedures
documentation
Technical security
Awar
eness
Banks
EDB
REQUIREMENTSRespons.

20. 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

21. Security – reduction of risk
This is what is all about
Keep that in mind, when you discuss PCI

22. 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.

23. 3. party / outsourcing
Does the cleaning company
needs to be PCI compliant?

24. 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.

25. PCI compliance enforcement
Card schemes
Banks
EDB
EDB 3. parties

26. 3. party / outsourcing
Bank
Cardsystems
(EDB)
CRM Processing
IT service
Mass printing
Fraud control Callcenter

27. 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

28. 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?

29. Branches, scope issues
HQ / Backend systems
Branch 1 Branch 2 Branch 3
Internal
functions
Several requirements
for each branch

30. 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

31. 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

32. 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.

33. 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

34. 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

35. 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

36. 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

37. 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)

38. Inhouse development 2
Requirement 4: Encrypt transmission of cardholder data
across open, public networks

39. 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

40. Inhouse development 4
Requirement 8: Assign a unique ID to each person with
computer
The whole section

41. 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

42. The way ahead
PCI its a way of working
Examine the gaps
Implement policies
Identify new projects and align them with PCI

43. Questions
Feel free to write me quesions:
Lars Syberg
ls@fortconsult.net