Blog

Archive for July, 2009

I promise not to use the data…

Tuesday, July 28th, 2009

Apparently an employee of the Johnson County payroll department in Kansas accidentally emailed a file containing 8,600 names and social security numbers to 49 other Johnson County employees.  They discovered the error in less than an hour and asked everyone to delete the attachment they should never have gotten.  And then they apparently met with each of the 49 recipients and confirmed with them that none of the information had been copied.

I don’t know about you, but I’d rather not trust the security of my social security data on someone else’s promise not to use the data or share it with someone else.   At the very least, I would have expected the country to do some analysis of their network and email traffic to make sure that the recipients didn’t do anything with  the data.  But it is possible the county either lacked the technical know-how or didn’t want to commit the resources to do this analysis.  If that’s the case, then the county would be well advised to implement software like Zgate which would have prevented the file from being distributed in the first place, or assuming the employee had the authority to send out social security numbers, it would have given the county an easy log to see what the other employees did with the email once they received it.

Protecting Cardholder Data: PCI Data Security Requirements

Wednesday, July 22nd, 2009

If you’ve been looking into what you need to do to pass a PCI audit, you know that one of the prime requirements for PCI Data Security is “Protect stored cardholder data”. Protection takes several forms. There are requirements specifying what data is allowed to be stored, and covering the need to establish policies limiting how long it is held on to and how it is disposed of, and of course requirements covering encrypting the data using strong cryptographic keys.

The requirements regarding the cryptographic keys are pretty specific. For instance, limiting access to the keys to the fewest people possible, using strong keys, keeping the keys in a secure location and splitting the keys so that at least two people are required to enter the key.

All of these requirements are encapsulated in Zecurion’s Zserver suite of products, and even expanded upon. For instance, the encryption is based on 256 bit AES, and the keys are built using a concept of a key quorum. The quorum allows the administrator to split the key into multiple parts (ie. 5), but only require a subset of those parts (as few as 2) to come together to rebuild the key on the server for decryption. That means that you are no longer at risk of having to keep multiple copies of each key part in case someone loses the smart card holding their piece of the key. The quorum also protects you from a single individual being able to lock out authorized users from the system.

So if you are serious about passing a PCI audit, you should be looking into tools like these to help you maintain compliance with their requirements.

Maybe they should have been encrypting?

Monday, July 13th, 2009

I don’t know if you caught the news report about Northrop Grumman back in late June.   Basically, journalists for Frontline were doing a story about how all of our electronic waste ends up in dumps in the 3rd world.  They stumbled upon a completely different story when one of the hard drives they bought at a market in Ghana contained hundreds of documents about government contracts that Northrop Grumman was engaged in.   According to the news reports, the documents contained information about recruiting airport screeners and implementing data security.    The drive itself was apparently given to an outside vendor who was supposed to have safely disposed of the computer.    According to a statement released by the company, they believe the hard drive may have been stolen from their asset-disposal vendor.    But what I found really interesting in their statement was that they felt that “despite sophisticated safeguards, no company can inoculate itself completely against crime” and that “the fact that this information is outside our control is disconcerting.”

But the truth is that if they were really serious about data security and keeping sensitive information confidential, they could have easily enforced a policy of encrypting the data on the hard drive. Then the “loss” of the hard drive wouldn’t have been an issue, and they would have always had complete control of their information. Hopefully somebody in the company’s information security department is thinking the same thing to themselves right now so that we don’t have to hear about them in the news next year. And maybe somebody in your company’s information security department is thinking about this issue too. If not, maybe they should be?

Goldman data theft – Do you know where your code is?

Monday, July 6th, 2009

By now, you have all heard about the ex-Goldman VP of Equity Strategy, Sergey Aleynikov, who was arrested over the weekend for allegedly stealing the code for one of their quant trading desks. If not, you can read a good summary here ( Bloomberg )

Since a number of people have covered the facts of the theft and have been posting more details as they’ve become available, I’m going to focus on the implications of the theft. First, there are already people saying that Goldman should have done a better job of protecting their code from theft. But the fact is that this guy was one of a select group of programmers responsible for maintaining the code, so he needed regular access to it or Goldman would have been wasting the $400,000 a year they were allegedly paying him.

So given that they had to give Sergey access to the code, Goldman should have been able to prevent him from encrypting the data and sending it out of the company, or failing that, of discovering the loss as soon as it happened instead of what looks like weeks later.

The ideal situation would have been if they had blocked Sergey from being able to send the data out of the company or flagged it for followup when it happened. According to the details so far, he downloaded the data from the Goldman servers, encrypted and compressed it on his desktop and then sent it to a server in Germany. If Goldman had proper monitoring in place, it might have picked up the attempt to send encrypted, compressed data out of the network and blocked it as it was happening. Just the fact that it was encrypted would have been a red flag to pay more attention to what was happening.

Early detection or prevention is important in this case, because Sergey sent the data to a server in Germany, which means that Goldman and the FBI have to go through an extra round of hoops to find out what happened to the code once it got to the destination server, and even to prevent it from being spread right now. The data has already been exposed for a month, and while that is probably too little time for it to have been actively used against Goldman, it is plenty of time for it to have been spread to competitor firms who will eventually be able to use Goldman’s algorithms that it spent millions developing to give it an edge in the marketplace.

At this very moment, Goldman is probably going through a security review with senior management asking IT what could have been done to reduce the odds of this theft.  Your company should be going through that same type of review, because every company has some sensitive data that would either level the competitive playing field if someone else got a hold of it, or would just cause embarassment if it was publicly lost.  If your senior management comes to you and asks that question, what are you going to tell them?