| |
|
|
|
|
|
|
 I guess it has been almost two years now, that a news story and security researcher blog post, pointed out a vulnerability in certain types of ATM Machines. The vulnerability relates to "PCI requirement #2 - Do not use vendor-supplied defaults for system passwords and other security parameters" with a few brands of ATM machines ( generally the smaller standalone ATM’s you see in convenience stores and sold by ATM ISO’s and their agents ) whose service manuals were accessible online, and ATM operators failing to setup the ATM’s in a secure manner. I remember googling and finding the default passwords and instructions for these. With the service manual and passwords, a person was able to reprogram the value of the ATM cassettes. telling the ATM Machine that the $5 cassettes had $20’s and doing a withdrawal
Today - Wired notes that the first bust for ATM Reprogramming Scan netted its first two arrests.
It took a high-speed chase and some gunplay, but two men in Lincoln, Nebraska, are the first to face felony charges for using default passcodes to reprogram retail cash machines to dispense free money.
Jordan Eske and Nicolas Foster, both 21, are in Lancaster County Jail pending an October 1st arraignment. They’re each charged with four counts of theft by deception, and one count of computer fraud, for allegedly pulling cash from privately owned ATMs at four stores in the area. The pair allegedly reprogrammed the machines to believe they were loaded with one-dollar bills instead of tens and twenties. A withdrawal of $20 would thus net $380.
|
|
|
|
| |
|
|
Posted ( db) in podcast on September-12-2008 |
|
|
Episode #2 is live - we cover quite a few topics that were started off my a consumer experience went wrong, Also, we do not come in stereo in this one, left channel only, I think it was a configuration mistake on my part. Enjoy ! and send feedback or comments or questions to podcast@paymentsystemsblog.com
Payment Systems Podcast episode #2
Date: 8/28/2008
Intro & Exit Song: Patiently Dying by elision
1) Frustrations with Returns
2) Payment System Transaction types with Return vs. Reversal vs. Void
3) Return Authorization
4) Switching non-Payment Transactions
5) MethCheck
6) Dave on Customer Services practices
7) OboPay Experiences - www.obopay.com
9) Watching the Payment Process - CVV2 experiences - Cvv2 requsted over chat!
10) ATM, Debit & PrePaid Show/Expo
11) VMWare ESXi
 Standard Podcast [40:04m]: Play Now | Play in Popup | Download
Blogs and email links
Andy’s : www.andyorrock.com
Dave’s : www.paymentsystemsblog.com
email : podcast@paymentsystemspodcast.com
|
|
|
|
| |
|
|
Posted ( db) in General on September-8-2008 |
|
|
|
|
|
|
|
| |
|
|
Posted ( db) in General on September-4-2008 |
|
|
 While on the "A Perfect Fit: Understanding the PCI Security Standards" Webcast this morning.
There were a few things that I took note of that are worth repeating:
- PCI Compliance (Fines, Dates, etc) is enforced by Card Associations/Brands and their Acquirers not the PCI Council.
- There was a neat chart that depicted the relationship between the different standards:
I learned of three new "Fact Sheets" published by PCICo From: https://www.pcisecuritystandards.org/education/fact_sheets.shtml
Payment Card Industry Security Standards Overview
PCI security standards are technical and operational requirements set by the Payment Card Industry Security Standards Council to protect cardholder payment data.
Getting Started with PCI Data Security Standard
PCI security for merchants and payment card processors is the vital byproduct of applying information security best practices in the Payment Card Industry Data Security Standard (PCI DSS).
Ten Common Myths of PCI DSS
The Payment Card Industry Data Security Standard (PCI DSS) secures cardholder payment data that is stored, processed or transmitted by merchants and processors.
The Ten Commons Myths of PCI DSS is quite good (I especially like the first 4 of these),
Myth 1 – One vendor and product will make us compliant
Many vendors offer an array of software and services for PCI compliance. No single vendor or product, however, fully addresses all 12 requirements of PCI DSS. When marketing focuses on one product’s capabilities and excludes positioning these with other requirements of PCI DSS, the resulting perception of a “silver bullet” might lead some to believe that the point product provides “compliance,” when it’s really implementing just one or a few pieces of the standard.
– Take a second and read through the audit procedures, especially section 12, how is a product going to to this ? find all of the other sections that a product cannot address., in my experience products can address a fraction of the requirements, they are met by processes around systems and their logical controls. Products can you you address Encryption, Log Management, Firewalling, IDS/IPS, File Integrity Monitoring, Anti-Virus/Malware, Vulnerability Assessment, among others — but each of these still will require operational processes and monitoring controls.
Myth 2 – Outsourcing card processing makes us compliant
Outsourcing simplifies payment card processing but does not provide automatic compliance. Don’t forget to address policies and procedures for cardholder transactions and data processing. Your business must protect cardholder payment data when you receive it, and process charge backs and refunds. You must also ensure that providers’ applications and card payment terminals comply with respective PCI standards and do not store sensitive cardholder data. You should request a certificate of compliance annually from providers.
– There are other business processes in place that deal with payment cards that are not necessary apparent, and while you can use out-sourcing to reduce scope, you will still have work to do. There are no real shortcuts here.
Myth 3 – PCI compliance is an IT project
The IT staff implements technical and operational aspects of PCI-related systems, but compliance to the payment brand’s programs is much more than a “project” with a beginning and end – it’s an ongoing process of assessment, remediation and reporting. PCI compliance is a business issue that is best addressed by a multi-disciplinary team. The risks of compromise are financial and reputational, so they affect the whole organization. Be sure your business addresses policies and procedures as they apply to the entire card payment acceptance and
processing workflow.
– Too many times have I seem IT Audits or IT Reviews dropped on a IT Manager because it has "IT" in it, There is much more business and process and operational and organization controls then logical controls in the PCI Standard. IT supports business processes and is an enabler, you need business and department heads involved with PCI Compliance, especially to explain and understand the flow of cardholder data that IT may not know about.
Myth 4 – PCI will make us secure
Successful completion of a system scan or audit for PCI is but a snapshot in time. Security exploits are non-stop and get stronger every day, which is why PCI compliance efforts must be a continuous process of assessment and remediation to ensure safety of cardholder data.
– Compliance != Security && Security != Risk Management (Compliance does not equal Security and Security does not equal Risk Management) — The PCI Standard is a baseline that is a best-practice approach to payment card security, it is not a risk based approach that is tied to your your organizational Risk Assessments and will not address non-payment assets or information. Compliance is a snapshot in time, you need to make sure that the processes are operating effectively after the review/audit has been performed. The process should also include continuous assessment of risk and implementation of controls to reduce the risk of new threats.
|
|
|
|
| |
|
|
Posted ( db) in General on September-3-2008 |
|
|
 |
I just signed up for the Certified Payment-Card Industry Security Manager or CPISM. So I’ll be in Dallas, TX from November 5th - November 7th — If you are in the area or are also taking the exam, please feel free to drop me a note.
Here is the link to sign up:
CPISM Training and Exam on Wed 5-Nov-08 8:30 AM
|
The CPISM measures aptitude in eight knowledge domains that were were generated and validated by industry experts. These domains constitute the knowledge that a security manager in the payment card industry needs to protect data. The domains follow:
* Payment card industry structure
* Payment card structure and data
* Payment card transaction processing
* Compromise fraud statistics and trends
* Merchant risk analysis
* Laws and the regulatory environment
* Payment card security programs
* Third party relationships
See more info here: http://www.paymentsecuritypros.com/CPISM/
Since I’m in payment processing, and a former QSA this just really makes sense for me and will help us serve and support our clients better.
|
|
|
|
|
| |
|
|
Posted ( db) in General on August-19-2008 |
|
|
 |
As I wrote yesterday on the summary of changes to PCI DSS 1.2 coming October 1st to a city near you.
Requirement 5: Clarified that requirement for use of anti-virus software applies to all operating system types. |
I was a little surprised because the prevailing wisdom that only Anti-virus protection applies to Microsoft windows platform really applied for PCI.
While still on the "marathon morning" webinar this morning: Graham Cluley (his blog is here) of Sophos had an excellent and informative presentation "Viruses and Spam in 2008 - A look a the current security landscape and future trends"
Two Items of note related to PCI DSS and Anti-virus:
I would say that the risk is low to OSX and Linux, but we are seeing attacks in 2008 on these platforms which does make the PCI DSS 1.2 Anti-Virus requirement clarification more reasonable. Expect to see AV for Linux, Mac and other platforms products being marketed towards the end of this year and 2009 and on.
|
|
|
|
| |
|
|
Posted ( db) in General on August-19-2008 |
|
|
 |
So I’m on a webinar right now, listening to a gentlemen from Verisign talking about how the EV (Extended Validation) SSL Cert’s prevent Phishing among other things. You have probably seen the Green Bar and SSL Certificate — The name next to the lock is embedded in the certificate, and the theory is that this cannot be modified by the attacker or phisher. Here is a picture courtesy of Versign: |
I’ve asked the presenter to address the following XSS Attacks:
But, I’m hearing mostly about the “Green Bar”, and seeing statistics on how users like the “Green Bar” and sites that get increased transaction volume, transaction ticket sizes, as well as as reduced cart abandonment. Unfortunately the “Security” presentation has turned to a “Sales” presentation…
But with these XSS attacks:
The green address bar displayed by the web browser would assure users that they are looking at a website that can be trusted, even though the page they are looking at may contain scripts or HTML created by a remote attacker.
|
|
|
|
| |
|
|
Posted ( db) in General on August-18-2008 |
|
|
There were two press releases released by the Payment Card Industry Security Standards Council (PCIco) today:
The first item lists a summary of changes we should expect in PCI 1.2 which will be released in October 2008
Changes to the PCI DSS include clarifications and explanations to the requirements,
with these clarifications offering improved flexibility to address today’s security challenges in the payment card transaction environment
The following are the main highlights:
- WEP is no longer allowed and is being phased out
- Wireless must now be implemented according to industry best practices (e.g., IEEE 802.11x) using strong encryption for authentication and transmission.
- New implementations of WEP are not allowed after March 31, 2009.
- Current implementations must discontinue use of WEP after June 30, 2010
- Use of anti-virus software applies to all operating system types
- Flexibility to the patching requirement by specifying that a risk-based approach may be used to prioritize patch installation
- Various re-wording of items for clarification purposes.
Get the details here:
The Payment Card Industry Data Security Standard (DSS) v 1.2 will replace the DSS v. 1.1 on October 1, 2008. This Summary of Changes document provides an overview of the significant differences between the two versions.
https://www.pcisecuritystandards.org/pdfs/pci_dss_summary_of_changes_v1-2.pdf
The last item relates the the webinar:
"A Perfect Fit - Understanding the Interrelationship of the PCI Standards,” to be held on Thursday August 21, 2008 at 9:00 a.m. EDT and a second session the same day at 7:30 p.m. EDT.
Webinar participants will discover:
• How the PCI DSS, PA-DSS and PED Security Requirements interrelate;
• Why merchants should know about PA-DSS and PED;
• Why incorporating PCI standards is your best approach to protecting cardholder
data;
• Using PCI standards as a model for data security.
To register for the Thursday, September 4, 2008 session at 9:00 a.m. EDT session, visit
http://www.webcastgroup.com/client/start.asp?wid=0650904084240 or
http://www.webcastgroup.com/client/start.asp?wid=0650904084241 for the 7:30 p.m. EDT session. The morning webinar
|
|
|
|
|
|
Andy
