I got to attend my first SOURCE event last week, thanks to a lucky confluence of events which freed up my time. Mainly, I didn’t have to go to the PCI Council’s Community Meeting and was able to take advantage of SOURCE Seattle instead. I know many of the people involved in SOURCE and I’d been wanting to go for a long time. This was the 10th SOURCE event, and I walked away very happy I’d finally been able to attend.
The Seattle conference is very different than any other event I’ve been a part of; with under 100 people in attendance, it’s small and personal. I had the opportunity to talk to almost every person there, which is something you rarely get to say at any event these days. During lunch on both days the team running the event led interesting discussions and helped encourage people to talk to other security professionals they’d never met before.
My favorite talk was by Tony Rucci, giving a detailed account of what it was like to be part of the White House staff on 9/11/2001. It was interesting to hear the first hand account of someone who’d been on the ground at the time. I liked getting to go to talks by friends like Adam Shostack and Zach Lanier, even if Zach did lose me about 15 minutes into his talk (I’m not an Android debugger by trade, so shoot me). Robert M. Lee’s talk on the maturity of security was good to hear, but I feel he may be a bit optimistic. The Base Rate Fallacy talk by Florer & Lowder made my brain hurt; my wife is currently taking a statistics class, maybe I should ask her for help.
I haven’t been to the larger SOURCE Boston, but if you’re in the Seattle area, look at coming to the con when it happens next year. Hopefully it stays small and intimate for a few more years. And hopefully it can stay in the Maritime Museum for a few more years as well.
One of the biggest challenges for a QSA is deciding the exact limits of an assessment. Deciding which systems store, process or transmit credit cards and all systems connected to them sounds like a straight forward and easy to follow, but in practice, the QSA’s two favorite words, “It depends” come into effect all to often. Drawing the lines around the systems that store or process card data is fairly easy, but when you get to the ‘transmit and all systems connect to them’ it get’s a lot fuzzier. Not only is it hard for a QSA to make those judgements, it can also be hard to argue with the customer about the specifics of scoping. And it can cause some very, very heated arguments.
So when i heard that the PCI Council had a Special Interest Group formed specifically to create a Scoping Toolkit, I was excited and filled with trepidation at the same time. I knew or had worked with many of the people who were involved with and leading the effort. This gave me hope that the PCI Council would be releasing something that would give QSA’s a good platform to base their scoping decisions. But from the first time I talked to the people who were working on the scoping document, I discovered that the Scoping Toolkit would probably never see the light of day; apparently this group put the ‘Special Interests’ in SIG. What one member of the group thought was absolutely necessary was anathema to another member at almost every turn. The entire effort was doomed from the start, with rabbit holes of edge cases and ‘what ifs’.
The Scoping Toolkit never did get released by the PCI Council, but the Open PCI Scoping Toolkit has been released. While it’s not an official document from the Council or even one that’s being publicly acknowledged by them, it’s an important piece of reading for any QSA to dig into, especially on the plane flight to his or her next on-site assessment. As Walter Conway says, it addresses the three fundamental scoping questions, gives the QSA a better understanding of how other QSA’s might scope the client, and gives the QSA more ground to stand on when explaining their decisions. And anything that helps take the variation between QSAs out of the assessment process is a good thing.
I’m glad this document finally got released into the wild. I know a lot of hard work and sweat went into hammering out these guidelines and they can help stabilize some of the ongoing concerns about PCI and the variation in scoping between QSAs. It’s too bad that the PCI Council couldn’t step up and endorse the document directly, but I’m glad they’re not standing in the way of it getting published either. Which gets them the best of both worlds; the Scoping Toolkit gets published and they don’t have to stand behind it as an official document. All the upside, none of the liability. We wouldn’t want them to actually make a stand and improve the overall security of the merchant community, now would we?