Security

Root out data breach dangers by first implementing common sense


As security breaches of personally identifiable information (PII) make the news, (http://www.privacyrights.org/ar/ChronDataBreaches.htm) an analysis of the breaches may lead you to the conclusion that it is not hackers or malicious employees that are to be feared but just plain stupidity. While you will find data breaches that can be blamed on those things, the vast majority can be lumped under the category of carelessness. Whether it is information inadvertently e-mailed to someone, theft of hardware, loss of a laptop, or paper in the dumpster, the real culprit is a lack of neurons firing and not following procedures.

The usual reaction to these breaches often centers on tighter security, encryption, policies and procedures, encryption, rules and regulations, encryption....I think you get the picture -- encryption is often looked at as a panacea for preventing data loss. However, this belief will end up giving you a false sense of security and stick you with a next-to-impossible task. If you look at the data breaches that I lump under carelessness, you will find that in most cases, the sensitive information, like SSNs, should not have been there in the first place!

Data encryption as a silver bullet to this problem misses the mark by a long shot. While it should be part of a security plan that mitigates losing laptops, there are too many places that PII is being stored for you to encrypt every instance of it. The sad fact of the matter is that many organizations cannot give you an accurate accounting of every place that it collects and stores PII. Those who can either have undergone an intensive self assessment of PII collection and storage, or they are ignorant and are knowingly or unknowingly lying to you.

So the real answer to reducing data breaches is in asking why PII is collected and stored in the first place and then eliminating it, if possible. You might be astounded to find that PII, SSN in particular, is collected and stored primarily to insure that a person can be uniquely identified in a database. Since, SSN is the closest thing we have to a national ID, people's knee-jerk reaction is to collect it because it's the only thing we have to uniquely identify a person. However, unless it is absolutely imperative that an individual can be matched across organizational domains, there is no need to capture it when a unique number can be assigned to a person instead. Again, if you surveyed your organization, I am willing to bet that you can find numerous instances where PII is collected unnecessarily.

Then there are instances when there is a legitimate need to collect PII, but it is inappropriately distributed within the organization. This is especially the case when I see that information has been lost on a laptop. For what purpose does someone need to carry around a database that has thousands of SSNs in it? If that info has to travel, the SSN could easily be translated into another number that is unique and can later be re-translated back into an SSN if necessary.

If you do a risk assessment of your organization, you will find that the needless collection and unnecessary dissemination of PII accounts for probably 70 to 80 percent of your risk. So, if you eliminate these two problem areas, you'll have it licked, right? Well not completely, but you will have gone light years towards fixing the problem.

I know that you are thinking that this is easier said than done -- but it is possible -- I have seen it happen. And it all starts with an intensive risk assessment. In fact, if you were deciding whether to spend money on an assessment or new technology, such as encryption of mobile devices, you'd get better ROI spending the dollars on an assessment. Without it, encryption is just a finger in the dike that will inevitably spring another leak.

Now, does this mean that technology is not part of the solution? Of course not, and encryption and other security measures will play a large part in it. However, it's the surgical employment of technology tools to a limited universe of potential problems that wins the day, not the blanket adoption of technology in the hopes that you can eliminate your risk. Be mindful that both methods can be expensive -- because finding and eliminating the two worst abuses of PII is not going to be cheap. But if given the choice, I prefer to get to the root of the problem, not just cover it with a Band-Aid.

8 comments
gphoto45
gphoto45

Reminds me of friend that only drove old cars, incase it got stolen. It is NOT stupid people running the machines. It is stupid people breaking into them. When the courts do catch the crackers, they let them off with a slap on the wrist. One year prison time for each byte of data stolen, and the crackers would think a lot more about what they are doin.

rodb
rodb

What's an SSN

techrepublic
techrepublic

Anywhere a "man-number" can be used in place of a SSAN, it should be. Relationships between tables concerning personnel can be made with such just as easily as with a SSAN. There are situations where the SSAN must be used, but that data can be segregated and kept in offline databases. No system is perfect and there are times when Privacy Act type data must be stored and used, but there are WAY too many times it is used when unnecessary. The stupidity begins with the programming of storage solutions that take the easy way out and don't find other ways to uniquely identify personnel records...

gsell
gsell

The problem in the cyber internet world is that development of techoniogly is being used to infiltrate personal and buisness information for profit. It is a money scam. A sure way to end this is to protect the source code. Administrative rights are certanly used as a front to access material by using the position or authority of the position.

jmgarvin
jmgarvin

SSN => Social Security Number. It's something used as an identifier in the US.

fore_thought
fore_thought

10 digits. I can remember your SSN and if I can remember your SSN then you aren't safe. It applies to the issue of user rights assignments/password protection/online protection/yada yada... SSNs were invented in the foredays before computing. Uniquely you data would be...DNA. So...given an OS that can identify you by your DNA and then conduct transactions between two seperate people and then encrypt the transaction with the DNA sequance...if you want my private data, you can ask me for it. I'll acknowledge it on my end so that you have a copy. You take the copy and do whatever you want with it which is where the flaw is. It's all human...no matter how you look at it.

Neon Samurai
Neon Samurai

"A sure way to end this is to protect the source code" No, no, no; in general, open the source code for all to see then develop a rock solid system; more eyes equals faster code hardening. Be it encryption or whatever other security software. Hiding the code for a limited number of eyes to see and develop only serves to insure that bugs remain unfound longer, development progresses slower and give end users a false sense of security. The belief that somehow things are more secure because they are obscure is part of the reason for the current state of afairs; "sure this shouldn't *be* on my notebok but no one knows it's there and I burried it in a really *obscure* folder on the drive so it'll be ok." I also wouldn't go with Administrative rights. Admin/Root rights should be to admin the machine; create a secure user account specifically for the sensative data if you must. But for the love of Baud, don't keep thinking that hidding source code or sensative information is going to provide even the faintest bit of security hardening. I'll leave your misuse of the term "cyber" alone for now. There is nothing cybernetic about the topic of discussion though in the general public's misunderstanding of the term, "cyber internet" is humerously redundant. But, this isn't meant as an attacking reply so a discussion of cybernetics should be left for another time.

techrepublic
techrepublic

Sure, but how many SSANs can you remember? The issue when speaking of protecting information in electronic records is eliminating risk wherever possible. If my credit card company transfers information by any means - over wires, or on a disk in a UPS truck - it doesn't have to contain my SSAN or address or anything else of value to identity theives. It can contain transaction information with a unique identifier for me that was generated when the company issued me an account. They will obviously still need to have my SSAN stored somewhere, but it doesn't have to be included in such records. I can easily see a system where an offline data store contained PII info and is protected as you suggest with appropriate Policies. The two tables marry up in the offline environment only, and only when necessary.

Editor's Picks