Crowdsourcing Payment Security

In my inaugural post to this blog, I wrote about many of the religious wars that break out today regarding payment security and specifically PCI. In the post I mentioned the OWASP PCI project, which is a solid step in the right direction, but to be clear, payment security encompasses a lot more than just PCI. PCI does a decent job at setting an audit bar for merchants and service providers, but now I’d like to focus on the broader topic of card not present security.

Recently, I was lucky enough to participate and contribute to a new O’Reilly book, Beautiful Security. While I’d love to tell you my chapter out-shined them all, in reality Mark Curphey’s contribution on Tomorrow’s Security Cogs and Levers was brilliant. Since the publishing, I have been speaking to a lot of people on the topic of payment card security and what I felt were some of its fundamental flaws that needed to be addressed. In my view, the root cause of many of the security pains around online payments is the reliance on a shared secret that is ultimately shared with hundreds or even thousands of parties within the life of a card. If there is a security crack in the armor within even a single organization of these thousands of handlers, the card account may become breached. Within my chapter, I laid out seven fundamental requirements for a new payment security model. They are:

1. The consumer must be authenticated
2. The merchant must be authenticated
3. The transaction must be authorized
4. Authentication data should not be shared outside of authenticator and authenticatee
5. The process must not rely solely on shared secrets
6. Authentication should be portable
7. The confidentiality and integrity of data and transactions must be maintained

OK, so none of these are a revelation, you knew this already. Well that’s why I am posting this here. I have since converted my Beautiful Security contribution into a wiki found here. My original writing is a high level design and we now want to take this to the next step. I am certainly not foolish enough to believe there are no flaws within it, nor is it detailed enough yet to implement. This is where the security and payments folks come in. This a call to action to read through the wiki, update it, and begin to flash out the details that could turn this into an actionable payment security system that could be implemented. There’s a quick summary of the goals on the wiki home page to address where we are heading. But hey, this is a wiki, so those can change too! If you have some expertise in online payments or information security (I know you do, that’s why you’re here), please take the time to help out and contribute.

Note: This post originally published on CSO Online.

Introducing SPSP

I was recently invited to participate on the advisory board for the Society of Payment Security Professionals which I happily accepted. The site explains the society best:

“The Society of Payment Security Professionals’ objective is to provide individuals and organizations involved in payment security with an online community to share information and access education and certification opportunities. Society members come from a variety of businesses including card brands, merchants, acquirers, issuers, ISOs, and more.  Though their organizations may vary, they all share one purpose:  to protect consumer data using the most current, viable technologies and processes.”

They also offer a certification, Certified Payment-Card Industry Security Manager (CPISM). Mike Dahn writes about the SPSP as well the certification on his blog here, here, and here.

We are now in the process of forming a working group on application security. If you have expertise on the topic and are interested in participating you can send me an email or leave a comment here. We’re open to any and all comers. It should be noted this is NOT about PCI but rather payment security in it’s entirety.

Looking forward to my new role on the AB as well as working with the Application Security Working Group.