PCI and Logging

In my experience, one of the most challenging areas of PCI DSS compliance is logging. Anyone who is familiar with PCI or with Verizon's 2010 Data Breach Investigations Report knows that daily inspection of your logs is not only required, it is good security.

The problem, of course, is that logging is complicated (see Barbie's "Math class is tough!"...if you dare). Therefore, I suggest that anyone involved in, responsible for, or just interested in logging and PCI, head over to good friend and logging guru Anton Chuvakin's blog (click here) for his analysis of PCI DSS log review procedures.

Many of you will remember Anton from his memorable presentation at last year's PCI Workshop. This time he is in process of putting together a string of blog posts which he describes as:

It was written to be a complete and self-contained guidance document that can be provided to people NOT yet skilled in the sublime art of logging and log analysis (a key requirement for this project – guidance was to be useful to such people) in order to enable them to do the job and then grow their skills. It is focused on PCI DSS, but based on generally useful log review practices that can be utilized by everybody and with any regulation (or without any compliance flavor – of course!)

If you are involved in PCI compliance or just the logging part, I suggest you bookmark Anton's blog (if you haven't already!) and follow along. It promises to be valuable, interesting, and if I know Anton, occasionally hilarious.

New SAQs Released and Revised for PCI 2.0

The PCI Council has posted the SAQs for PCI v2.0 on its website (click here to download them).

I'm still looking at them, and I'll have more to say later. It is interesting that there are now two versions of SAQ C. There is plain, old SAQ C (still checking revisions) and a new SAQ C-VT for virtual terminal users.

The same restriction that made this SAQ so difficult to use in practice is in place for both versions, i.e., the terminal can't be connected to any other locations or systems in your environment. Nevertheless, it may be worth a look.

One BIG change in SAQ C-VT is that there is no vulnerability scanning requirement. That's right -- there is no Requirement 11 at all.

I'll be writing more when I have a chance to look at all the SAQs more carefully, but you may want to take a look yourself in the meantime.

Why PCI 2.0 Says You Need to Search For Sensitive Data

On of the big changes to PCI 2.0 is that you now need to document how you determined your PCI scope. That is, you need to demonstrate that you have located all your cardholder data.

But how are you going to do that?

One way is to go around and ask everybody: "Do you have any payment card data?" Don't forget you also need to specify that includes paper and electronic, and that "electronic" includes databases, flash drives, CDs and DVDs, spreadsheets, etc. Good luck with that approach. Can you really ask every staff and faculty member? Can you rely on the answers?

Alternatively you could use an automated tool that seeks out and finds sensitive numbers like payment cards (and SSNs, too). To my way of thinking, this is the only realistic way to determine if you have found all your cardholder data. The reason is that data have a way of leaking out into all sorts of unexpected places. If you don't believe me, consider the recent unfortunate case at the University of Hawai'i which just announced they lost personal information on 40,000 alumni. This is one of the largest Higher Ed security breaches in recent memory.

Based on the press reports, the personal data "was stored on an unsecured UH computer server by a now-retired UH West Oahu Campus professor researching the achievements of UH students after graduation." Furthermore, the data breach could have been prevented if the university had taken “some fairly simple” data protection measures."

One part that the story got right is when they said “This could have been prevented if the university had a policy of scanning its IT system for records containing personal information like social security numbers,” adding that software programs and information technology experts are available to perform such searches.

The part the story -- or at least the expert quoted therein -- gets wrong is where they say that data discovery programs “are not cheap" and add " that the university has struggled in recent years with severe budget cuts and spending restraints." WRONG! Excellent open source (read: "free") data discovery tools are abundant. Two examples are Cornell Spider or SENF from the University of Texas. All it takes is the good sense to use them. Now at least, PCI DSS v2.0 is making it abundantly clear that you really need to do this.

The data compromise didn't include payment cards, as far as I can tell. Nevertheless it is an example of the type of compromise that you could face when payment cards are kept on a workstation or database in accounting or development or the medical center or athletics or the bookstore or the parking garage or...you pick the department.

The moral of this story: PCI once again has your back. The requirements may seem difficult, but the almost unnatural ability of intelligent and well-meaning people to mishandle sensitive data is a risk you cannot take. Next time, it may not be a professor at a distant institution. It may be someone right on your campus who with the best of intentions abandoned all common sense and put your school in the headlines.

Speaking of the professor, the article notes how "maintaining information security in a university setting is a challenging task – departments and professors are fiercely protective of their independence and their research." It continues, “To the average professor, those pesky IT security people just get in the way.” Sigh. That is the astonishing naive arrogance (a fool's mixture) we all need to deal with on occasion.

So what are you to do? The only realistic lesson to take from this is to get moving and find all your sensitive data, at least (from this QSA's perspective) your payment card data. And the only way to do that (per PCI, IMHO) is to get an automated data discovery tool. Barring that, I guess we all will be "pesky security people" asking questions and getting dismissive answers.