This document discusses trends in account data compromises and provides advice for forensic investigators. It notes that while attack methods are becoming more sophisticated, the target remains cardholder data. The document outlines best practices for responding to an incident such as engaging a forensic investigator, documenting events, and avoiding altering compromised systems. It emphasizes that response priorities for payment entities and card schemes may not be aligned. Statistics show retail and food/beverage industries experience most compromises. The document examines an incident involving a multi-national issuer and provides recommendations for reducing risk like reviewing data policies and network architecture.

1. 08/02/2012
The diary of a forensic investigator:
Secrets Revealed
Andrew Henwood
Dear Diary – who do ADCs affect?
• Smallest merchant
• Largest merchants with multitudes of sites
• Issuers and Acquirers
IR Plan should be similar, irrespective of entity size!
1

2. 08/02/2012
ADC Trends & Targets
Cybercriminals are using:
• Same old vulnerabilities (SQL, backdoor trojans,
malware etc).
• Increasingly sophisticated attack methods.
• Targeted attacks.
• More automated tools.
• Quicker developing trends.
• Repeat attacks to maximise harvest.
• Increasingly powerful systems and techniques.
• Decrease in time between compromise and fraud
spend.
ADC Trends & Targets
…But the target remains the same.
Cardholder Data.
2

3. 08/02/2012
Dear Diary - How are ADC’s typically identified?
• Cardholders report fraud on their card => their card is
compromised
• Issuers and/or Schemes trace back legitimate spend
• If multiple compromises, this trace identifies Common
Points of Purchase (CPP)
Compromise Timeline
7+:;A>-,*)B+(&);
&
!"#$%&9:-,,;5::%& 4"*-1+"$
&
!"#$%&'()*+,,-".&/0(1,
& 5"0<0(+&);&=>/ &
)33"4"&32'!+5'*66' ?90<"#>'$:'@9#1">A:4'
0%783$9:; ' 7%&" '
!"#$%&
/)23()2-,+1& '?4&?)(+",-*,&
@"1+(<0% '
()*+, !#",)*+
! ' !"#$%&'%(')*+' --..
' /"0%1"#2'
&!"#$%& -B%:"A>9A%:-'
' ' =#9C&-'
4,,5+(,&6&7*8+2+,&
1+$+*$&/''&
5:1%<"'!+5'=%#":>$0>'
3

4. 08/02/2012
How not to respond
Compromise Penalties!
4

5. 08/02/2012
Compromise Penalties!
Type Initial Lack of Monthly Monthly Monthly PCIDSS
Fine removing PCIDSS PCIDSS Violation
SAD Violation Violation (>=6 months)
(90 days) (4 months) (5 months)
L1 !50,000 !30,000 !50,000 !75,000 !75,000
L2 !25,000 !15,000 !25,000 !50,000 !50,000
L3&4 !10,000 !5,000 !10,000 !15,000 !15,000
Members !50,000 !30,000 !50,000 !75,000 !75,000
PSPs !25,000 !15,000 !50,000 !30,000 !30,000
Others !10,000 !5,000 !10,000 !25,000 !25,000
Card Scheme / Acquirer vs. Entity
Priorities
In most cases, these priorities are NOT aligned!
• Card Schemes & Acquirers
• Containment, Limit Exposure, Identify “At Risk” card data, Fines
• Entities
• Containment, root cause identification, remediation, get on with
business
For potentially compromised entities, ensure the PFI
selected / engaged has your priorities at heart
5

6. 08/02/2012
Facilitating a Forensic Investigation
1. Invoke IR plan
2. Engage a PFI (ASAP!)
3. Document and collate all current and ongoing events, all people
involved, and all discoveries into a timeline for evidentiary use
4. Do not access or alter any aspect of the suspect system(s)
5. If you suspect the attack is currently ongoing, remove the system
connectivity to the network. i.e. pull the network cable / down the
adapter
Do not power the system down!
Facilitating a Forensic Investigation
Re-Emphasise:
Do not access or alter any aspect of the
suspect system(s)
…or at least minimise access!
6

7. 08/02/2012
PCI Forensics vs. Traditional Forensics
1. PCI Forensics does not equal traditional forensics
2. Majority of attacks are coordinated, focused, highly sophisticated
and custom to the environment
– Custom malware (targeted memory scraping)
– Payment application manipulation (source code modifications and
manipulation of limits / controls)
– Custom Rootkits and built in defense mechanisms
– Hacker SDLC
– Anti-Forensics
Real-World Forensic Statistics
Affected Industry (example)
Trustwave Verizon 7Safe
Category
(2011) (2011) (2010)
Hospitality 10% 40% 5%
Financial
6% 22% 7%
Services
Retail 18% 25% 69%
Food and
57% ? ?
Beverage
Government 6% 4% 2%
Education 1% ? ?
Other ? ? ?
* References to reports in conclusion of presentation
7

8. 08/02/2012
Statistics & Trends
Individual company statistics are “interesting” but
impossible to correlate except broadly!
Statistics & Trends
• Utilise public combined sources:
www.datalossdb.org
http://www.privacyrights.org/ar/ChronDataBreaches.htm
• Hospitality / Food & Beverage / Retail compromised the most
• Majority of ADC are from external sources
• Majority of breaches are focused and well organised criminal
businesses
• Majority of victims had evidence of the breach in their log files thus
should have been aware!
• Majority of attacks were trivial
• Only a fraction reported in CEMEA
8

9. 08/02/2012
GoldenDump.com (2011)
GoldenDump.com (2011)
9

10. 08/02/2012
GoldenDump.com (2011)
Incident
Incident Overview
• Subject : Multi-national Issuer / Acquirer
• Incident Date : 2010
• Investigation Date : Late 2010
• Initial Vulnerability : SQL Injection
• Exploited Weaknesses :
– Poor network segregation
– Lack of log review
– Let down by security partners
• Exposure :
– 2.4 million PAN
– 780,000 Track 2
– > ! 90,000 in cash
10

11. 08/02/2012
The Environment
Backend Online Payment
Systems Servers
DEVDB DB04 DB03
AS400 DB02 DB01
Branch Application Internet Banking
Offices Servers Servers
DEVDB DB04 DB03
AS400 DB02 DB01
2010
11

12. 08/02/2012
SO…..What went wrong? (Underlying Causes)
• Phase 1: Initial Compromise – SQL Injection
– The site had been tested by multiple external parties and had
“passed” three penetration tests (Code had NOT changed since
2005!).
– Logs were collected (plenty of them – 4.5 Billion events) but never
reviewed.
– Network architecture was “temporary” but never resolved.
– Poor password policies.
• Phase 2: Reconnaissance & Exploration
– Poor network architecture design decisions.
– Poor password policy.
– Lack of log review.
• Phase 3: Account Data Extraction (PAN)
– Inappropriate data retention policies.
– Lack of awareness regarding Account Data storage (where is it?)
– Poor system management.
• Phase 4: Account Data Extraction (Track 2)
– Inappropriate data retention policies (again).
– Poor network segmentation.
• Phase 5: Internet Banking Manipulation
– Application made “blind” use of data within a database.
– Application unable to detect “tampering”.
– Failed transfers were not reviewed or followed up.
12

13. 08/02/2012
How could things have been Done? (Means of Reducing Exposure)
• Fundamentally – An awareness of Account Data
– Review & revise data retention policies.
– Know where the stuff is. (Get Rid)
• Regular & thorough testing of external attack surfaces.
– Reputable companies (not always the big players).
– Speak with your peers (word of mouth is invaluable).
• Log retention is great! Log review is better! Both are needed.
• Review & revise network architecture designs.
Approach.....!
• PCI Prioritised by thesystem build policies (including password
Review & revise VISA
Also supp orted
policies). Innovation
Technology
Program!
None of this is new and should sound familiar
proach.....!
PCI Prioritised Ap e VISA
Also supp orted by th
vation
Technology Inno
Program!
13

14. 08/02/2012
Means of Reducing Exposure
• Fundamentally – An awareness of Account Data
– Review & revise data retention policies.
– Know where the stuff is. (Get Rid) Milestone #1
• Regular & thorough testing of external attack surfaces.
stone #2 / #6
– Reputable companies (not always the big players). Mile
– Speak with your peers (word of mouth is invaluable). / #6
Milestone #4
• Log retention is great! Log review is better! Both are needed.
• Review & revise network architecture designs. / #2
Milestone #1
• Review & revise system build policies (including password
policies). / #3 / #4
Milestone #2
Summary
• Identify, remove / protect your sensitive data
• Segment / scope the network
• Regularly: Test & Review
• Maintain full logs but pointless if no review
• Define, build and test an incident response plan
• Build a partnership with a security business to
independently review
14

15. 08/02/2012
Stay Safe & Risk Aware
www.foregenix.com
15