Archive for September, 2008
| |
|
|
|
|
|
|
Since becoming an Obopay user, I’ve noticed that very recently that they have implemented a multi-factor authentication for transactions initiated from their mobile website. I needed to pay $2.14 to a friend who picked up a lunch for me yesterday: Monday is $1.00 Maid-Rites :) When sending the money I received the following (see picture on left) screen, and my phone rang shortly after - requiring me to type in my obopay PIN to complete the transaction. Very well done! I know that Chase uses a similar process (out of band verification) for its Internet banking. Authentify is a company that provides a service like this — please leave a comment below if you know of any others. Also - if you noticed in the picture I’ve updated my Nokia E51 to a Nokia E71 - a very nice phone - (I really missed the QWERTY keyboard)
|
|
|
|
| |
|
|
Posted ( db) in General on September-30-2008
|
|
|
|
|
|
|
|
| |
|
|
Posted ( db) in General on September-29-2008
|
|
|
Scott Fendley writes a good post on Check Fraud and Information Security at the SAN’s Internet Storm Center Handlers Diary after watching Catch Me If You Can which is inspired off of Frank Abagnale Jr. early life of thievery and deception.
We have developed interfaces to external 3rd party check authorization providers as well as developed a local check authorization module which is a blacklist based on a bad check subscription service, and velocity checking. But many of Scott’s steps to reduce risk based on his research are not as much based on accepting checks, as much as being the check writer, and are not all logical controls but preventative and detective procedures to reduce risk of check fraud. Some good points here.
Also:
Frank’s Book The Art of the Steal is a good read and add this [SAN's Internet Storm Center Handlers Diary] to your RSS Feeds and regular reading if you are a security manger/analyst.
|
|
|
|
| |
|
|
|
|
|
|
According to CNet and a few Visa Press Releases:
We see a P2P like money transfer service for card and mobile phone holders:
Under a pilot program with U.S. Bank, which is scheduled to begin by the end of the year, Visa will offer mobile money transfers from one Visa cardholder’s account to another. A U.S. Bank Visa cardholder would use a Web browser on their phone to access funds and transfer it directly to the recipient’s account. The recipient could then withdraw the funds from an ATM machine, or use the money to make purchases.
and working will cell phone manufactures Google Android Platform.
The Visa-Android deal calls for Chase Visa cardholders to use their Android phone for not only transferring money, but also to receive real-time email alerts when transactions happen on their Visa account, receive offers from merchants, and view images on Google maps to find the location of those merchants who are offering the specials. The Google-Visa deal is expected to begin sometime by the end of the year.
and we begin to see the merging between the card and a phone as a contact-less payment vehicle at the point-of-sale.
The Nokia 6212 classic includes integrated Near-Field Communications chipsets (NFC) which lets the mobile device behave like a contactless payment card, where consumers simply wave it within a few inches of a special point of sale reader to complete a Visa transaction. Nokia and Visa first demonstrated NFC technology in December 2005 with the launch of the first large scale NFC trial in the United States at the Phillips Arena in Atlanta.
|
|
|
|
| |
|
|
|
|
|
|
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.
|
|
|
|
|
|