Evan Schuman tries to take a cheap shot at the PCI council on StorefontBacktalk. It’s a strange article called PCI Council And Passwords: Do As We Say, Not As We Do

First, to be fair, what’s being protected is not especially sensitive. Specifically, the password is not intended to keep out prying eyes. Rather, its sole purpose seems to be to keep meddling fingers away.

That caveat is extremely important. You really do not need to read any further since the rest of the article is misleading. I’ll try to explain here why it is also wrong.

Companies that must adhere to PCI should take a risk-based approach. This guidance is supported by the PCI Council. This means, in brief, that the most critical assets should be protected while the non-assets or non-critical ones should get less attention and effort. Payment card data is the focus of the Council and that is why you see a great deal of money, time and talent focused on keeping payment card information safe. You should not see, and usually do not, security efforts focused on things that can be easily replaced, are not vulnerable, and have a low likelihood of attack. This can be expressed with the formula: Risk = (Asset Value x Vulnerability x Threat) / Countermeasures

Mr. Schuman again raises this obvious point:

As mentioned earlier, these documents don’t include credit card numbers or other sensitive information. But if the decision is made to lock them down, there’s presumably a reason. If the concern is that QSAs or merchants can change the document, then the Council needs to choose a password that will indeed create the desired protection

Perhaps they put the password on the document as a test to see who would be foolish enough to complain about it.

The article should not have continued past the point that there is no payment card information in the Word document. I would wager they have already succeeded in creating the desired protection. What would the author suggest as a replacement, given that there is clearly no sensitivity, it’s trivial to crack a Word password and it has to function as a shared secret?

The article, contrary to Mr. Schuman’s claims, raises neither irony nor interesting points.

It reads is like someone standing outside a bank complaining that the flowers next to the sidewalk can be stepped on, therefore the bank is not following appropriate precautions to protect its money. Smart auditors know where to draw the line on scope. The author of this article does not show an ability to draw any lines; he awards himself the honor of appearing like a really bad auditor.

Companies that handle payment card information do not need this kind of noise and nonsense from an auditor. They need to hear opinions that reflect the reality of today’s threats and vulnerabilities, and to work with someone who understands how information assets are valued before issuing edicts for every pebble they stumble upon.

The topic of centralized workstation logs came up recently again in a discussion about PCI compliance. I soon realized not many people are aware of the new Windows remote management options. Any Vista or Windows Server 2008 can provide the centralized log daemon. The latest versions of Windows including XP and Server 2003 can forward events.

Here’s the update for XP and 2003:

http://support.microsoft.com/kb/936059

And here are the steps to take with a command prompt to enable centralized logs from a workstation

1) Setup remote management
> winrm qc

2) Setup the event collector service
> wecutil qc /q

The event viewer on the workstation will now show “Microsoft-Windows-Forwarding/Operational”

Now just configure the “subscriptions” on your centralized daemon and you can collect all the workstation logs you want. Here’s an example:

http://support.microsoft.com/kb/950257

I also have to point out that workstations have an incredible amount of spare space on the drive these days. An argument easily could be made for requiring logs to be configured and maintained for a year locally instead of centralized. Either way, workstation logs are more in scope for compliance than ever before.

CIO magazine has posted the latest Deloitte paper “Cyber crime: a clear and present danger”.

They look at the latest trends and recommend three security practices:

1. Recognize that the threat from cyber crime to data is real
2. Use a risk based approach to get the most benefit/return from security spending
3. Use centralized management to get a high-level view

Clearly this is not rocket science. Could there ever be a survey that does not produce these three recommendations? What has changed with “cyber crime” versus any other attack name/vector/title? They are sound practices, but do not seem linked to any specific trend or development that is distinct from past threats. In fact, they also conclude with “We do not suggest that cyber security professionals consider a change in focus and additional duties lightly.” Sound advice and I really do not see much change here.

I will be presenting next Tuesday at the RSA conference on the Top Ten Breaches. I will give a high-level view, analysis of trends and then specific steps to mitigate the current threats. The objective is to give information that is not just general advice but actionable and targeted.

Hope to see you there.

The old attack vector was just to block GPS signals, but the BBC News says Sat-nav systems are under increasing threat from more sophisticated attacks.

“You can now buy a low-cost simulator and link it to Google Earth, put on a route and it will simulate that route to the timing that you specify,” said Professor Last.

“A GPS receiver overcome by it will behave as if you’re travelling along that route.”

We have relied for too long on open communication. This is yet another case for authentication between devices.

Of course I must say that even with 100% assurance my GPS device is connected to an authentic signal I would still be concerned about bogus directions. Just the other day Google maps tried to send me to a city center when I asked for an airport, and my GPS suggested I turn left in the middle of a bridge. Aside from all that, however, authentication definitely needs to be factored into the future of navigation systems.