Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

How Do You Deal With Sensitive Data?

ScuttleMonkey posted more than 5 years ago | from the just-turn-off-db-access-for-everyone dept.


imus writes "Just wondering how most IT shops secure sensitive data (customer records). Most centrally managed databases seem to be monitored and maintained very well and IT workers know when they are tampered with or when unauthorized access occurs. But what about employees who do legitimate selects from these databases and then load CSV files and other text files onto their laptops and PDAs? How are companies dealing with situations where the database is relatively secure, but end-use devices contain bits and pieces of sensitive business data, and sometimes whole segments? Does anyone use sensitive data discovery software such as Find_SSNs or Senf or other tools? Once found, how do you deal with it? Do you force encryption, delete it or prevent extracts?"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


Sensitive Data (5, Funny)

cheebie (459397) | more than 5 years ago | (#24376489)

I try not to talk loudly around it, and make sure it's emotional needs are met.

Steve Jobs has the big-C (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#24376767)

Yup, Steven Jobs has Crabs.

Re:Sensitive Data (2, Funny)

Spy der Mann (805235) | more than 5 years ago | (#24376961)

I try not to talk loudly around it, and make sure it's emotional needs are met.

No wonder sensitive data is lost so easily in Microsoft Windows... it's still scared of the chairs.

Re:Sensitive Data (1)

value_added (719364) | more than 5 years ago | (#24377067)

I try not to talk loudly around it, and make sure it's emotional needs are met.

But what about YOUR needs?

Seems to me that if you're willing to go that far, then it should be happy to go with you everywhere you go. Hallway conversations and performance reviews would be a good start.

Easy (3, Insightful)

pak9rabid (1011935) | more than 5 years ago | (#24376499)

Pay your employees enough to make protecting your company's data on their computers/PDAs worthwhile.

Unless of course, you're.. (5, Informative)

Channard (693317) | more than 5 years ago | (#24376579)

.. The UK Government [scotsman.com] . 600 lost laptops over the last ten years! Including two from the MOD with very sensitive data on them. And that's just electronic data. Despite the public being told how important shredding documents is, some commercial enterprises seem to be just chucking sensitive data out in the bin, unshredded.

Re:Easy (4, Insightful)

QuantumRiff (120817) | more than 5 years ago | (#24376723)

Try having well written, very clear policies that that kind of action is forbiden. Of course, a piece of paper means crap to most employees, but the first time you fire someone for violating that policy, the grapevine and water cooler will provide more training than a dozen hour long meetings could convey..

Re:Easy (5, Insightful)

techno-vampire (666512) | more than 5 years ago | (#24377419)

Try having well written, very clear policies that that kind of action is forbiden.

It's all well and good having policies like that, but if your employees either don't know about them or can plausibly claim they don't know, they won't do any good. Every employee who has, or even might have access to sensitive data should be required to sign a copy of that policy and it should be part of their records. That way, if anything happens, they won't be able to pretend they didn't know they were violating company policy. Depending on local laws, this might help you avoid (or defend) a suit for wrongful termination.

Start at the top (5, Interesting)

Anonymous Coward | more than 5 years ago | (#24377607)

The main problem usually happens at the top - or the legal department.

I worked at a place with a clear and documented policy against transmitting sensitive information over insecure networks - including the old text pagers from RIM (prior to the GSM blackberry). It was routine for me to receive sensitive/proprietary information on my pager from legal counsel. When I pointed out their failure to secure that data, they simply said I was paranoid - not that I'd misinterpreted the policy. They were too busy to worry about that. I documented every instance and handed 1 copy to the CIO, another to the secretary of the Chief Counsel and the final with the CEO's secretary since I couldn't get in to see either of them. I did this on my last day working there - left for a better job.

Turns out the new job wasn't any better with important data - they wanted me to recover data from a desktop where they escorted the contractor out of the building. I don't know why. Seems he didn't really use the machine and remoted into his home server and a colo server for almost everything. The contract didn't ensure he placed all the code into the corporate SCS weekly or that he would document it or write manuals. 6 months of hourly cash paid and basically nothing to show for it. I did find a password protected ZIP file full of stuff - took 3 days to brute force it, but it was over 3 weeks old and the code didn't run.

The company didn't even have a $20 background check performed before giving him access to the network. I would have liked a clean drug test too.

Also, being tight at the start of a company is easier than after the barn doors are already open. Most of us start ups don't have the willpower to do this - or the technical expertise.

Re:Start at the top (1)

plover (150551) | more than 5 years ago | (#24378165)

The cure has to come from the tip-top, as well. Your company needs a Chief Information Security Officer, meaning an executive with a seat on the board. The CISO needs the support from the board to write these policies, the authority to punish violators (including the UberSalesGuy in marketing,) and the balls to do so when necessary. He also needs to be qualified for the position, and to have a qualified and competent staff working for him.

The best way for that to work is for the CEO to introduce him and sell him to the rest of your shop: "Here's Mr. Smith, he's our new CISO, and he'll be responsible for *anything* relating to information security. That means *everyone* will follow our policies regarding information security, including me. Our company would be sued out of existence if we had a breach like this one (point to random news article about the most recent data breach) and we simply can't afford it.

"He's going to write up some policies that we all must follow, and then he'll be creating Tiger Teams to help you get your laptops cleaned up of sensitive data. Don't worry, we'll fully help and support you in following the policies; but if you bypass them, it will be your job."

And Mr. Smith better be competent. He needs to produce those clear policies quickly, and he needs to get programs in place to begin securing all your info system assets. There's a lot to the job.

Re:Start at the top (0)

Anonymous Coward | more than 5 years ago | (#24378257)

Don't get me started on legal council. We have an SSL encrypted nfuse gateway that acts as a tunnel into our internally encrypted Citrix servers which allow access to our encrypted Lotus Notes servers, and what does our freaking senior legal council do, forward highly confidential emails to their home account! Her freaking excuse was that she couldn't open it on her Blackberry and figuring out the Citrix solution was too hard. We have near minimum wage data entry folks that have ZERO problem with it after being shown once and this ostensibly intelligent woman can't figure it out!?!? It's one freaking URL, and as long as you either have the MS JVM, a Sun compatible JVM, or our standard client load it just works!

Re:Easy (0)

Anonymous Coward | more than 5 years ago | (#24377661)

Our company uses full disk encryption and has very clear policies on how to handles sensitive information.

Re:Easy (4, Insightful)

syousef (465911) | more than 5 years ago | (#24377737)

but the first time you fire someone for violating that policy

Another one that thinks the solution is to fire employees, and gets modded insightful. You know what I get the impression that most slashdotters would make piss poor bosses. Firing employees randomly when they violate a policy to set an example isn't exactly smart.

Do you know what it costs to hire an employee, and get them up to speed doing their job well? Never mind the fact that the next person you hire to fill the roll might be a dud, or that the job market may mean the position goes unfilled for quite some time. Do you know what it does to morale? That gossip around the water cooler gets people updating resumes and looking for work elsewhere before they're fired for some other petty reason to set an example. Then there's the legal aspect - if you're wanting to avoid unfair dismissal claims providing clear guidelines is just one step - you have to show that the on the spot firing was justified. Then there's the human aspect - unless you're a soul-less piece of shit that cares not a jot about destroying a family's livelihood you may want to look for actions that don't leave people jobless.

Re:Easy (0, Redundant)

jeiler (1106393) | more than 5 years ago | (#24378369)

Firing employees randomly when they violate a policy to set an example isn't exactly smart.

Firing an employee for violating a clearly written, explicitly trained policy is hardly "random."

Re:Easy (1, Insightful)

myowntrueself (607117) | more than 5 years ago | (#24378375)

Firing employees randomly when they violate a policy to set an example isn't exactly smart

I'm sorry but I'm having trouble making sense of your sentence.

How, exactly, is firing someone for violating a very clear, written and signed policy in the least bit 'random'?

Maybe you have a different idea of 'random' to the rest of us... just checking.

Re:Easy (1, Funny)

SEWilco (27983) | more than 5 years ago | (#24378571)

the next person you hire to fill the roll

Fortunately it doesn't tend to take much training to replace a bakery worker. Whether you're filling the rolls by hand or by machine, whoever fills the role should get up to speed quickly.

Policies (3, Interesting)

larien (5608) | more than 5 years ago | (#24376545)

Partly, you need policies to discourage end users copying data anywhere it's not needed. And I really, really mean discourage, up to and including possible sacking.

At a technical level, every laptop/portable data storage device should have its hard drive encrypted. Disable USB ports if you can get away with it, or at least put software on which forces encryption of files sent to USB keys. That will cover most of your issues.

Users will legitimately require access to sensitive data as part of their job; the IT department should have the power to ensure they don't do it in a way that exposes the company to the embarassment of losing a laptop with SSNs in the subway...

Re:Policies (4, Insightful)

aztracker1 (702135) | more than 5 years ago | (#24376841)

Personally, I can't see *ANY* instance where a full set of SSNs for more than a handful of people should *EVER* be needed on a laptop... I mean, if you are entering data, sure... but WTF should anyone be carrying around some of the information that gets leaked.

I think *IF* such information is needed for lookups, then a 1-way hash is a necessity. If you aren't responsible for dispatching to customer locations on a weekend, then you shouldn't need street addresses. I can see needing some information for customers, but SSNs, or CC data should *NEVER* be on anything outside of the office, or a backup storage facility.

It's that simple. No SSNs leave the office... No CC information leaves the office... no street addresses leave the office, unless absolutely necessary.

I've seen smaller companies that have the entire database in the "on call" laptop, that gets copied from the server friday, and to the server monday.. I shudder every time I think about it...

Re:Policies (1)

bucky0 (229117) | more than 5 years ago | (#24377253)

Not to pick nits, but a 1-way hash of SSNs don't do you much good. Though it's a hash, you get limited to the keyspace of the SSN which is trivially reversible. (instead of 2^80 possibilities, you get 10^9)

Ideas for making SSNs more secure (Re:Policies) (1)

TheScienceKid (611371) | more than 5 years ago | (#24377993)

Um, why not treat the SSNs the same way you do passwords, and add a salt? store something like "$salt$H(SSN + salt)" ?

Obviously, what length of salt, and the actual hash algorithm you use, along with the way you construct the cleartext to hash, will vary. But adding some kind of salting to the hashing of SSNs should make brute forcing harder. (admittedly, if you only want 1 person's SSN, you only need the 10^9 hashes for that given salt.)

Consider something like PBKDF2 (a Password-Based Key Derivation Function) that makes going from password to key sloooooow (eg, 5 seconds).

Sure, you can parallelise this, but if you're trying to make this hard.

On the other hand - if all you need is to have a function of the form getEmployeeBySSN(s : SSN) : EmployeeObject then why not keep the SSNs serverside, and just use a synthetic (sequence-generated) primary key on remote copies (missing out the SSNs entirely).

Hope that wasn't too much of a ramble.

Re:Ideas for making SSNs more secure (Re:Policies) (1)

bucky0 (229117) | more than 5 years ago | (#24378327)

Oh, you should definately salt it, but if someone is dumb enough to pass a SSN around, what would keep them from sending the salt with it?

Re:Ideas for making SSNs more secure (Re:Policies) (1)

smellotron (1039250) | more than 5 years ago | (#24378497)

You're supposed to send the salt around with the encrypted result. The point of the salt is not to be secret, but to add new sources of variance to the hash, making it harder to reverse-engineer (and impossible to trivially detect duplicate SSNs/passwords).

You also need a different salt added to every SSN. If you're adding the same salt everywhere, you are worse off because the consistency makes it easier to reverse the hashing algorithm. This is essentially what caused WEP to be broken so easily.

Unless your process is driven by marketing (4, Interesting)

Moraelin (679338) | more than 5 years ago | (#24377517)

And you might have gotten away with it too, if it weren't for those pesky kids... from marketing and sales.

Honestly, I don't know about government, but it most other places it seems to invariably be some sales or marketing guy who's lost a hard drive full of SSN's and contract data and whatnot. I guess it's simply a tale of greed. The prospect of selling an extra copy/insurance/account/contract is tempting enough to override all other concerns. So when you try saying that Mr Marketing GOD can't take all that data with him, guess who wins? Remember also that he's the guy who knows how to sell stuff to people, including his side of the story, while you're probably the security nerd that doesn't even speak management.

To go on a roundabout tangent towards how _I_ would fix it: the funny thing is that the market can work in funny ways too. In a "bad money drives good money off the market" way. It applies to more than that. E.g.,

- if some people can get away with tax evasion or corruption, they undercut and drive off the market the honest merchants. (See most of the ex-Communist Bloc.)

- if some people can get away with monopolistic behaviour, they drive off the market those who don't. (See MS.)

- and if some people can make a few extra bucks or save some costs by wiping their ass with your privacy, they gain an avantage over those who don't, and may eventually even drive them off the market one way or another.


The thing is, the free market is just an optimization algorithm. It takes a given set of constraints, and eventually moves the economy towards a more optimal state. Optimal for those constraints. But like any optimization algorithm, you must make sure you set the constraints you need, or the solution may be something else than you expected. Bad behaviours can (and usually are) more "optimal" than good behaviours, if left unregulated. And eventually those who weren't destructive, either get the clue when the others are eating their lunch, or get to get bankrupt/bought/whatever.

So basically what I'm saying is that nothing will really get fixed as long as there _is_ an economic advantage in ignoring privacy and security, and just giving the salesmen anything they want. The only way to fix it is if there was some kind of a negative feedback in the loop. When they'll stand to lose more money by losing your data, than anything they could gain by mis-using it, _then_ they'll start taking it seriously. Until then, nope.

And it's not just a matter of personal principles and doing the right thing, regardless of what everyone else is doing. You're not isolated from the rest of the economy. If anyone wanted to be the "good" guy there, will find that the "bad" guys have an advantage over him. If he doesn't care, maybe his boss does, or maybe the shareholders just get rid of those shares and reward the bad guys instead.

Re:Policies (3, Informative)

cool_arrow (881921) | more than 5 years ago | (#24378631)

It's a good idea to limit who gets your ssn. I'm having surgery done on my knee in a couple of days which has entailed seeing 4 docs at 4 diff offices (MRI etc). They all want your SSN when filling out their paperwork - I simply didn't put mine down on any of them. Two of them brought it to my attention and my response was "I don't give it out". Didn't have a problem. I could see if I wanted credit or was borrowing money from a bank. Otherwise don't be too eager to give it out.

Re:Policies (1)

sexconker (1179573) | more than 5 years ago | (#24377371)


All sensitive data is constrained to certain machines.

These machines (desktops only!!) are physically locked down in the office.

No remote access.
No physical access to the ports/case.

You can go further and prevent people from taking cellphones, cameras, pens, etc.

In fact, let's just lock them in the box with the data.

Our hospital records are strongly protected (5, Funny)

Anonymous Coward | more than 5 years ago | (#24376573)

we use a robots.txt file and a strongly worded "keep out - private data" header on all important records

Re:Our hospital records are strongly protected (1, Funny)

Anonymous Coward | more than 5 years ago | (#24376817)

Our hospital uses stronger means: besides robots.txt our headers say "Keep out - only private data of our celebrity customers (including Ms Portman)".

We are actually still doing financially fine, though our legal fees are unusually large.

I just wish (1)

Kamokazi (1080091) | more than 5 years ago | (#24376587)

I just wish the people where I work were actually smart enough to export customer data and manipulate it so I wouldn't have to for them.

Re:I just wish (1)

Tablizer (95088) | more than 5 years ago | (#24376667)

I just wish the people where I work were actually smart enough to export customer data and manipulate it so I wouldn't have to for them.

I had this issue before. If I gave or built them better data manipulation tools, I'd be out of a job. Ultimately I left because I'd rather automate it because it grew tedious after a while. Some were also reluctant to automate such for various reasons anyhow. I figured I wasn't a good fit: they wanted a half-programmer-half-clerk.

Automate it and rent it! (1)

Mateo_LeFou (859634) | more than 5 years ago | (#24376771)

So many people don't see the payoff of spending 2-3 hours learning the gist of an extraction/reporting tool (or two or three). They're happy to pay $50/mo. for this to be taken off their hands. Makes me laugh. In three months they've easily paid for the time it would've taken to grok a man page.

Re:I just wish (2, Funny)

Zerth (26112) | more than 5 years ago | (#24378101)

The trick is to make the tool and not tell them about it.

Even better, develop a form that you make everyone fill out when requesting data which is really just the arguments for your script. I had a coworker who was constantly praised on his responsiveness to requests because his mail->sql->excel->mail script always responded in (int(rand()*10)+5) minutes.

Well, until he forgot to turn it off when he had the flu and somebody noticed "he" kept working. He literally replaced himself with a (not so) small shell script.

in plain sight (0)

Anonymous Coward | more than 5 years ago | (#24376627)

I encode all my sensitive data as recipes, and keep them in the Central City's First Branch Library in plain view...

Once found, here's what you do (5, Interesting)

bugnuts (94678) | more than 5 years ago | (#24376703)

Once found, how do you deal with it? Do you force encryption, delete it or prevent extracts?

First off you need to have a policy on who is allowed to extract it, and how they should handle the data (be it encryption, keeping the data on-site, etc).

But here's the trick: If you find data kept in violation of the policy, you send EVERYONE to training. I'm talking mandatory training where they lose computer access (and thus, don't get paid) until they do the training. All new hires have to do it, too. Make it really boring, and administered after normal work hours.

After the first time everyone is sent to training for some poor schmuck being careless, I guarantee nobody will ever violate policy again.

Re:Once found, here's what you do (1)

Anonymous Coward | more than 5 years ago | (#24376865)

Causing several unproductive hours for the majority of the work staff doesn't sound like a good idea to me.

Re:Once found, here's what you do (4, Interesting)

bugnuts (94678) | more than 5 years ago | (#24377027)

Causing several unproductive hours for the majority of the work staff doesn't sound like a good idea to me.

Actually, I was being mostly facetious....

Except that it is how several companies do it, due to government contracts, insurance, and (gasp) congressional decree.

I honestly had to take several training courses (yearly) because someone screwed up. And when that happens, the peer pressure is really increased to not screw up.

One time, a person randomly tripped in the hallway, and the potential workman's comp issue was terrifying. I joked that we would have to go to training to learn how to walk. And guess what... "paying attention while walking" was added to an existing mandatory training course!

Ah, government work.

Re:Once found, here's what you do (0, Troll)

drinkypoo (153816) | more than 5 years ago | (#24377583)

The real reason you train everyone is so that there are no excuses. Everyone knows. However, you legally can't make it after work hours in many if not most states...

Re:Once found, here's what you do (0)

Anonymous Coward | more than 5 years ago | (#24377483)

If it saves losing sensitive data that could destroy the entire company, and possibly land you in jail or a civil suit then I'd say it sounds like a very good idea.

If you're talking about losing the boss's dirty picture collection, probably not a good idea... ...unless your boss is the President, or the Pope.

Or how about some banking records that contain complete sets of name, credit card number, security code, and ATM PIN? I'd say spending a few hours on employee 'training' is worth not losing a pile of data like that...

Re:Once found, here's what you do (1)

settrans (902777) | more than 5 years ago | (#24377381)

Sounds like a great plan if you want morale to plummet! I'm not kidding, this was tried at a former workplace and there was turnover in the aftermath.

Re:Once found, here's what you do (1)

syousef (465911) | more than 5 years ago | (#24377531)

I'm talking mandatory training where they lose computer access (and thus, don't get paid) until they do the training. ...and...
After the first time everyone is sent to training for some poor schmuck being careless, I guarantee nobody will ever violate policy again

Boy am I glad you're not my boss. You may also wish to check what the laws are like where you are. What you're proposing is bound to be illegal in at least some (sane) places.

Re:Once found, here's what you do (0)

Anonymous Coward | more than 5 years ago | (#24377923)

Except this could backfire if one's peers instead all try to make sure that management never finds out about such policy violations by collectively covering it up.

Encryption & data loss protection (2, Informative)

twolfe (235277) | more than 5 years ago | (#24376717)

We use forced whole disk encryption on all laptops. Additionally, you can look at data loss solutions like you've suggested but I'd recommend something a bit more holistic, like Cisco's Security Agent, which provides a centrally managed firewall, IPS, anti-virus and data loss protection function all from a single installed agent.

12345 (5, Insightful)

lazycam (1007621) | more than 5 years ago | (#24376725)

The strength of your encryption means nothing in the face of a user who insists on using their birthday as a password or keep a post-it on their computer monitor. Unless you are able to force individuals to use strong or randomly generated passwords you are at a loss. In the end, human behavior will circumvent our best security.

Re:12345 (1)

bugnuts (94678) | more than 5 years ago | (#24377219)

"What a coincidence... that's the same password on my luggage!"

Forcing users to use strong or randomly-generated passwords tends to lead to keeping it on a post-it note on the monitor!

But post-it notes with a difficult password are not inherently bad. Just store the note in a safe on-site where the data are stored. If someone has access to the safe, they also have access to the disk drives.

For laptops going off-site, encrypt it with the user's public key. Make that encryption part of the extract (which would also guarantee that the data couldn't be carried off by someone masquerading). Yes, each user has to remember a single strong password that protects his private key. But that should be part of the responsibility of having the data. If people are so unwilling to have a strong password to protect the data, they probably shouldn't have access to it anyway.

Re:12345 (0)

Anonymous Coward | more than 5 years ago | (#24377459)

The strength of your encryption means nothing in the face of a user who insists on using their birthday as a password...

Ahh, but I was born on Febtober the eleventy-second. No one ever tries that.

Re:12345 (3, Interesting)

Anonymous Coward | more than 5 years ago | (#24378129)

I have 16 personal passwords at work, and 10 shared passwords.
All change, some daily, some weekly, some monthly. Oh, and did I mention they retain our passwords for 3 years to prevent re-use, and run them against dictionaries so anything not random rejects.

Keeping track of these things is a huge pain, you never know what password you used, and most of the systems have a 3 tries and you're locked policy.
They even have the password databases tied together so if you use one password on one system, it can't be used on a different one.

The end result is every one of the 500+ employees with desks covered in post-its with passwords written on them.

We asked if we could just use one password on all systems, they said it was possible for about 90% of them, but that it would mean one lost password would compromise the whole system.
I mentioned it would be more secure than everyone writing down the passwords on their desks.
They said to lock our drawers with the pw's in them at night.
I said we don't have any keys.
They didn't say anything else.

The next day we got to work and all our passwords were gone, taken from the desks. Management had write-ups for each of us for failing to adhere to our security policy.

So now most of us use a password utility that can be put on a usb stick, and we take them home so they don't get taken. Some people still write them down on paper, but also take them home.

The moral being, due to an over-aggresive security policy, we now have passwords to all our sensitive systems floating around on paper, usb sticks, etc. some people have even taken to just emailing their own password list to themselves, and just remembering the email password.

I work at a large banking/investement support firm. Scary, isn't it?

Re:12345 (2, Interesting)

Bios_Hakr (68586) | more than 5 years ago | (#24378195)

When it comes to employees, especially non-technical ones, the best bet is to generate a password for them. Have the password printed on a laminated card along with 15 other random passwords. Give this to employee and tell them to (very good) keep it in their wallet or (less good) even post it on a monitor.

Only they know which of 15 passwords it is. If they lose their wallet tell them to call you right after they call the DMV and their CC company.

Check the logs for bad password attempts and then call the user to see if they actually did that. If they didn't, then someone else is trying with their passwords.

Or, move into the 21st century and start using SmartCard logins. They need a card and a PIN in most cases, so just losing the card is no biggie.

Re:12345 (1)

smellotron (1039250) | more than 5 years ago | (#24378625)

The strength of your encryption means nothing in the face of a user who insists on ... keep[ing] a post-it on their computer monitor.

What's so bad about that? There is a certain level of privacy expected in the workplace. If the company has an issue with a snooping ronin employee, audit trails should reveal it pretty quickly, and result in a swift termination. It is a fact of life that not everyone will remember every password they are bombarded with, so it's stupid to fight it. Just find the least damaging alternative... like having them write their password on a $50 bill (since people are pretty good at keeping money safe, when compared to post-it-notes). It turns "something you know" into "something you have".

Send letters (3, Insightful)

chinakow (83588) | more than 5 years ago | (#24376729)

From what I can see, most companies wait until the sensitive data is lost or stolen then they send every customer a letter telling them it is gone and offering to pay someone to keep an eye on their credit. Other than that, I think the policy must be, "ignorance is bliss." That is just my two cents.

No, they don't unless in CA. (0)

Anonymous Coward | more than 5 years ago | (#24377091)

... then they send every customer a letter telling them it is gone and offering to pay someone to keep an eye on their credit. Other than that, I think the policy must be, "ignorance is bliss." That is just my two cents.

They only send a letter if they do business in California where it's mandatory that they do it.

There was a woman I talked to who, when logging on to her account, saw a different web page than usual asking for SSN and all this personal information. She called the bank in question to report it thinking it was a phishing site. The bank replied that, No, they were asking that information from her to make sure it was her because there was a data breach.

I can't remember exactly which bank it was - maybe Capital One.

Doesn't matter. All those fuckers, as you said, will do the absolute minimum and the customers can go fuck themselves.

Enforce Strict Naming Conventions (5, Funny)

jaguth (1067484) | more than 5 years ago | (#24376743)

I name all of my sensitive files, databases, tables, and fields with names that nobody would want to touch, such as "Smashing Pumpkins Discography DB", "tblPeeWeeHerman", "Oprah.txt", ect.

And for storage, I burn them all to DVD and put them inside empty "Aerosmith" jewel cases. Keeps them nice and safe from prying eyes.

Re:Enforce Strict Naming Conventions (1)

Tablizer (95088) | more than 5 years ago | (#24377425)

You don't by chance work for a San Francisco municipality, do you?

Re:Enforce Strict Naming Conventions (1, Funny)

Anonymous Coward | more than 5 years ago | (#24378253)

I code-named one project PMS. Urinary Tract Infection does wonders too.

We lock it via user-restricted accounts (2, Insightful)

WillAffleckUW (858324) | more than 5 years ago | (#24376749)

We use specific user names and strong passwords (not user selected) behind a strong firewall and web encryption.

But the reality is that anyone could stick the query results to file on a flash drive ...

Re:We lock it via user-restricted accounts (1)

aztracker1 (702135) | more than 5 years ago | (#24376959)

Sticky note on my monitor with pre-generated passwords... check!

Generally I find that a 3/4 rule for a 10+ character password works... Upper, Lower, Number, Non-AlphaNumeric. Suggest that users do short phrases like... "c is for cookie" even "c 1s 4 c00k13" works... this is generally pretty strong, far easier to remember, and less likely to be written down/stolen.

Point out the concept of the above to people, and they are far more likely to use a secure password, that they can live with... Using a common username-password system via LDAP/AD or another system also helps. Having to keep 8 passwords for various company systems with different rules, or inability to change your passwords only leads to having passwords printed out in clear text.

Re:We lock it via user-restricted accounts (1)

WillAffleckUW (858324) | more than 5 years ago | (#24377169)

Actually, we keep a password book that looks like all the other lab notebooks on the shelf, except it has passwords like AMI$6*mani - but you still need to know the account name and since it's linux it's case-sensitive.

Then the database fetch page uses an internal fetch password that we don't tell the users which meets the same restrictions.

Why do they need access? (4, Funny)

bockelboy (824282) | more than 5 years ago | (#24376761)

Ask yourself why the employees need the SSN access in the first place!

Tell your DBA to create a view which replaces the SSN with some other random number for every possible person with DB access. That way, folks doing data mining or data quality will be happy.

If your devs need SSN access to develop your application, ask them why the hell they need to work on the production DB!

There's eventually going to be folks who need access to the real data. Hire a large football player, dress him in a suit, and have a "come to jesus" moment with any employee to make sure they understand how serious this is.

Re:Why do they need access? (2, Interesting)

aztracker1 (702135) | more than 5 years ago | (#24377029)

totally agreed.. I'd say have a special lookup table for SSNs, and have a 1-way hashed version in the main table/views... no select queries for the SSN, only an sproc where you enter the key, and get the value, for use in a program where you need to see it... for those that need to "lookup" a record based on SSN, then you can hash it, and search based on the hash. Unless you need it for filling out medical, tax, or other government records, there is *NO* need for any person to have access to a raw table with SSNs, let alone have it on a portable device. I'd say the same for CC information, and Street Addresses... 99.9% of the time, there's no need to even be able to view said info.. let alone for it to be anything but a lookup/hash value.

Re:Why do they need access? (1)

wizzat (964250) | more than 5 years ago | (#24377387)

In most cases, you can use a view of a hidden table and security definer functions (for postgres) to bypass this issue entirely.

Consider (mocked up):

psql=>create table users_real (user_no integer, name text, password text, sensitive_information text);
psql=>create view users as select user_no, name from users_real;
psql=>-- revoke all on users_real to all;
psql=>-- grant all on users to all;
psql=>select check_password('user', 'password'); -- security definer function 'suid' looks at users: proposed user, proposed_password
psql=>select set_password('user', 'password'); -- security definer function 'suid' looks at users: proposed user, proposed_password

Josh Burkus gave an excellent talk at OSCON about protecting sensitive data in a database.

Re:Why do they need access? (2, Informative)

plover (150551) | more than 5 years ago | (#24378405)

Beware. Hashing SSNs is dirt-easy to crack with a dictionary attack. There are only 10^9 possible SSNs. Let's say you hashed them all with SHA-1, which I have personally benchmarked on my crappy 4-year-old desktop machine at 50,000 hashes per second. That means I could test every possible hash of an SSN in 20,000 seconds, or about 5-1/2 hours.

And I have, to prove the point to one of our teams that was proposing this exact same system.

It is "sort-of" possible to do it securely, but your protocols and access to such a system have to be guarded as closely as if you were dealing with the secret encryption key to the real SSN database. You need logged and restricted access to the queries, and you need an intrusion detection system watching for anomalous activity, such as a large number of sequential requests for hashing coming from IP address

No matter what, it's not easy and it's barely secure, even though it sounds great to management: "Hey, boss, I protected all our SSNs using SHA-1 which has 160 bit hashes which Bruce Schneier says are almost unbreakable!"

A much better approach is to ask yourself why you are storing customer SSNs in the first place? Customer SSNs should be treated as transitory data, used for the initial credit application (or whatever) and then discarded. Something else should be used as the long-term "customer number."

Re:Why do they need access? (0)

Anonymous Coward | more than 5 years ago | (#24378351)

Hire a large football player, dress him in a suit, and have a "come to jesus" moment with any employee to make sure they understand how serious this is.

Terry Tate, office linebacker?

"You kill the joe, you make some mo'"

Legitimate selects? (4, Insightful)

MartinG (52587) | more than 5 years ago | (#24376803)

What about employees who do legitimate selects from these databases and then load CSV files and other text files onto their laptops and PDAs?

What kind of employee? General users shouldn't be doing selects directly anyway, but should be using software that limits what they can query to the minimum information they need, preferably not in a general purpose form like csv. On the other hand the developers of that software need to do all and any kinds of selects for a whole range of reasons. They however, should not be let anywhere near the actual production databases.

This is how we do it anyway.

Re:Legitimate selects? (2, Insightful)

Tablizer (95088) | more than 5 years ago | (#24377355)

General users shouldn't be doing selects directly anyway, but should be using software that limits what they can query to the minimum information they need, preferably not in a general purpose form like csv. On the other hand the developers of that software need to do all and any kinds of selects for a whole range of reasons. They however, should not be let anywhere near the actual production databases.

Users always want to manipulate info on spreadsheets to adjust it to their needs or pretty it up. Thus, being able to export the data is almost a must at a typical corporation.

The alternative is to have a dedicated pool of re-formatting gurus who prepare the stuff for each user or department; but most companies don't want to do it this way because its difficult to reign in excess requests. Letting each group do their own filters out dumb or excessive requests because they have to allocate the reformatting labor from their own staff. Plus, a central pool can create bottlenecks and delays as low-priority requests are treated the same as high-priority ones (unless you implement a complex and costly tracking system).

It's possible to limit the amount of data per CSV or spreadsheet download or request, but if they really need it, then they'll do one slice at a time until they have all they need. For example, do one month at a time in order to collect a full year. Thus, limiting the download does not prevent misuse of the data, it only makes more work for those determined to get the data for whatever project they're working on.

"Proper" and thorough security is often not cheap. The cost of inflexible data has to be weighed against breach costs/risks. Managers and employees want flexible information systems to make better decisions. If you red-tape the process, it slows or prevents the flow of info, hurting the bottom line.

I publish it (0)

Anonymous Coward | more than 5 years ago | (#24376847)

I give the data to the New York Times, and they publish it. Isn't that how sensitive data is supposed to be handled?

Don't let PHB run the show and don't buy from golf (2, Interesting)

Joe The Dragon (967727) | more than 5 years ago | (#24376903)

Don't let PHB's run the show and don't buy based on golf course meetings.

Extreme Prejudice (0)

Anonymous Coward | more than 5 years ago | (#24376993)

I erase it.


Laptops: Yes PDAs: No (2, Interesting)

Bandman (86149) | more than 5 years ago | (#24377023)

I can't imagine a need for an employee to have any bit of our client's data on their PDA. There's really no excuse for that at all.

As for laptops, sure, we issue our employees laptops, with which they are able to work from home via VPN. There are occasions where the employee will have to save and modify excel spreadsheets, or CSV files, as you mentioned.

Ideally, whole drive encryption would be utilized, but it's not (yet) in our case. I've been behind the times implementing that.

Remotely Delete Files (1)

Nicademous (857607) | more than 5 years ago | (#24377167)

Another thing you can do to protect data is to install laptop anti-theft software to ensure that important data doesn't fall into the wrong hands. I have experience with this software because I did some work for the company that developed a product called Laptop Cop.

Laptop Cop allows you to remotely delete or retrieve files over the Internet in the event that a laptop gets stolen. You can also monitor and control everything the thief does by logging into the web-based UI.

Lots of companies are using it to protect their data and also understand why the laptop was stolen in the first place (to play video games? to conduct coporate espionage?) Because it lets you see all computer activity from the stolen laptop, you can know if the thief is trying to access confidential information or simply using it for their own personal reasons.

It also gives you a confirmation of the deletion of data so that you know it was destroyed. And it deletes it to a U.S. Dept. of Defense standard that makes it unrecoverable regardless of the techniques used.

I tested the product myself and it did what they claim. As long as the stolen pc gets an Internet connection, all is well which according to the FBI's crime statistics happens in 93% of the time.

You can learn more if you're interested here:

http://www.laptopcopsoftware.com/ [laptopcopsoftware.com]

Re:Remotely Delete Files (1)

sexconker (1179573) | more than 5 years ago | (#24377513)

As long as it's not behind a firewall (external, obviously), and as long as they aren't after your data, these things work.

Anyone who is after sensitive data knows about these systems. Don't connect it to the net. Copy the hard drive and work on the encryption/blackmail from somewhere else.

If you want to sell/use the laptop itself, hack away (via flashing) at the anti-theft system, physically attack the chip.

Out of band systems are nice, but they're not perfect, and they never will be. Physical access is king.

This is how we do it... (3, Interesting)

bogaboga (793279) | more than 5 years ago | (#24377197)

Well, in our environment, (an insurance company), the system will allow those authorized to copy data onto their notebooks, but what happens is that what actually gets written or copied are not the actual data. From what I know it goes something like this:

Say the actual Name is John Doe and SSN is 123-456-789 and DoB is 1976-12-08, what gets copied is something like Name: XvfC Gzd, SSN: 908-954-213, DoB: 2788-98-98.

So you work with the dummy data instead of the actual thing. Once done with whatever you wanted to do, the data get processed to reflect the needed changes before being written to disk.

Even after getting written, committing only happens after rigorous checks.

Re:This is how we do it... (1)

sexconker (1179573) | more than 5 years ago | (#24377691)

That's masking / reversible encryption though.

Someone can figure out the scheme by having access to just a few pieces of known data and a compromised laptop. For example, if they knew a few people's information and knew they were your customers, they'd have a huge head start.

The dummy data itself is irrelevant. You could just as well have all dummy data set to null, and tie dummy entries to their corresponding entries in the original database at a single point.

Storing the changes (as it sounds like you're doing) to the dummy data and then feeding them back to the original database to be applied isn't very safe. Someone could trawl through them and look for patterns (since people often do monotonous, repetitive tasks with data).

The changes themselves should be encrypted (and not masked!) with a unique key for each entry. You can set up a public/private key system where the database holds both keys and the encryption key is sent to the laptop.

This still doesn't resolve the issue of someone accessing the laptop and using it to poison your database.

Re:This is how we do it... (1)

Tablizer (95088) | more than 5 years ago | (#24377715)

Name: XvfC Gzd, ... So you work with the dummy data instead of the actual thing.

My real name really is Xvfc Gzd, you insensitive clod! My family is from Czechoslovakia. -Xvfc

Usenet (0)

Anonymous Coward | more than 5 years ago | (#24377307)

Upload it to usenet.

Its not a problem really. (0)

Anonymous Coward | more than 5 years ago | (#24377333)

I just sell it to the highest bidder.

At The Biggest Bank in America (1)

netsavior (627338) | more than 5 years ago | (#24377337)

I work for a big bank (hint). One that had a major customer data scare a few years back. All SSN/Name data is encrypted in the database and in all files. When it needs to be displayed it is decrypted then sent through our https presentation layer, or shown in a fat client of some kind. Ad-hoc reporting (such as pulling files for CSV extracts or whatever) is not allowed, at all on CSI (customer sensitive information) tables. As far as SQL permissions, only the applications that are cetrtified presentation mechanisms are allowed to do selects of those tables (which contain encrypted data).

If they do somehow manage to get some sensitive data on to a laptop, our laptops are all lojacked, and FDE'd (Full disk encryption). Burining dvd R/CD-R drives are disabled, usb drives are auto-mounted as read only, email is monitored... Sure there are still ways around, but you would have to be a bit smarter than your average PHB to screw over the customer's privacy.

I start by keeping as little of it as possible (2, Insightful)

CFD339 (795926) | more than 5 years ago | (#24377347)

Any project I manage, and most I am influential all, I make it a point to constantly ask "Why are we collecting this? How long do we need to keep it? When can we delete this data?"

If you don't have it, you can't lose track of it and it can't be stolen from you.

If you have to store sensitive data -- and in some cases we all do -- you try to isolate the sensitive parts of it from the identifying parts of it. Use hashed values for keys instead of actual names or account numbers, that kind of thing.

There's the obvious of course -- data on laptops should be encrypted, and the key for that encryption shouldn't be taped to the inside of the battery door.

Pretty much a solved problem... (2, Insightful)

rbunker (1003580) | more than 5 years ago | (#24377375)

This is pretty much a solved problem. * only grant execute access to stored procedures, no ad hoc or dynamic sql at all * encrypt sensitive information so that backup tapes do not become a vulnerability * don't store anything you don't actually need...there are credit card authorization firms that will give you a token to store, so you never store the credit card number at all, even for recurring payments * segment particularly sensitive data entirely...the HR database should be a different instance on a different server etc. * don't give IT folks access they don't actually need....this protects them from suspicion, too * if you have especially sensitive stuff, use a data access intelligence product like rippletech to intercept database calls and stop suspect ones * don't allow the data to float around in clear text before it hits the database....clear text credit cards in the apache logs obviate the benefit of strong encryption in the database, and if it moves over the network in the clear any employee that can download snort owns it * use different vlans for sensitive information, or for inter-application communications that might be particularly rich with valuable information * use strong authentication for access to sensitive servers...several layers worth for connecting from home etc. etc. etc. all the normal security stuff.

bah I wish people knew what was going on (1)

bobbycool (826758) | more than 5 years ago | (#24377479)

Some organizations have no idea what the heck is happening after an application is deployed. I think it's quite a bit of wishful thinking that most IT staff actually know what's happening to the data. I know that some high profiled places don't use any sort of encryption for email, usb keys, cd's or laptops. They bank on the "goodness" of the people using their equipment. I guess that is to be expected in organizations that do not even have a data classification scheme. Anyway I hope that what I am speaking of is really not the norm.

Depends on the data (1)

Heembo (916647) | more than 5 years ago | (#24377485)

If any of your general (even technical) employees can execute a select statement and get credit card information, you are screwed. For small company, flush your credit card numbers as soon as you are done processing the transaction. (do not log them or persist them in any way)

If you are a big company and really need to store credit cards beyond the transaction time, you are under the umbrella of PCI. PCI says you need to encrypt and isolate credit card data in a secure repository - where only a few trusted (and heavily background checked) employees have access.

"Cryptography in the database" by symantec press is a good software-code-centric book on the topic.
If you org cannot afford to build a solution to isolate and encrypt data in this regard, then you should not be storing it.

Social Security, health, financial transaction records - they should all be dealt with in this form. The days of storing sensitive information plain text in a database are over.

The fact of the matter... (2, Informative)

R3d Jack (1107235) | more than 5 years ago | (#24377585)

is that this is not an IT issue. IT can help implement the solution, but someone at the "C" level has to consider this serious enough to create and enforce policies. We kill ourselves politically by even bringing up these sorts of issues (controlling what Sales, etc., can do with information), and that just makes the problem worse. We also make our lives miserable when the PHB's afflict us for our presumption. The best thing for you to do is implement sound security within the limits of your position, and then let it go. Unless you are the CIO, there is nothing you can do about this. Looking back from the tail end of a career, I should have joined an OSS project or found something else worthwhile for personal satisfaction.

Prevent downloads and screen scrapes (1)

postbigbang (761081) | more than 5 years ago | (#24377595)

Increasingly, applications are living in isolated boundaries, whether cloud, SaaS, or other ways that prevent a direct to user download. It's more difficult to use web apps and disable screen scraping, but others have found techniques that help prevent taking screen fulls of info that in turn, become text/formatted documents that walk out the door. Policy and trust are big helps, including machine lock-downs. But people increasingly reject lock-downs.

DRM is currently perceived to be unweidly especially in database applications. That's why many apps now conceal most parts of an SSN or other saleable or interesting data. Having an appliance do the watching is nice, but it's also expensive and not necessarily rife with holes, either. Read 2600 if you have any doubts about this.

In the end, a few heavy prosecutions could serve as a deterrant, but today, huge amounts of data walks out the door without anyone even knowing. Data thefts aren't even reported consistently when they're found.

Data Security (1)

halhub (1334647) | more than 5 years ago | (#24377695)

We use a 3 prong approach. 1. end point sercurity 2. IronKey Enterpise USB keys with MokaFive 3. RAS encription If you have any question please contact me

gf (1)

pak9rabid (1011935) | more than 5 years ago | (#24377835)

Same way I deal with a whiney girlfriend...with large amounts of apathy, followed by a small amount of back-peddling.

Wrong Approach (1)

nonsequitor (893813) | more than 5 years ago | (#24377911)

I would never let end users directly access that data, instead they would get anonymized unique identifiers for working with the data as an end user. That way if their computer is compromised none of the sensitive data would be. That limits the exposure and centralizes the security. Then who cares if the laptop gets stolen, hacked, dunked in liquid nitrogen, etc... There's nothing there to steal even if its the employee trying to steal it.

How about $10,000 per SSN? (3, Insightful)

rueger (210566) | more than 5 years ago | (#24377915)

It seems like most of these stories involve some boob carrying data away on a laptop or USB key then losing it or having it stolen. Sure you want to acknowledge and deal with boobishness, but you also really need to address why the boob found it necessary to carry data away from the workplace in the first place, and why management encouraged and/or endorsed that action.

If employees can complete work during a regular work day then there is no reason to take it home with them.

If management insists that data security matters, it is possible to set up systems so that it's not possible for employees to copy of chunks of data and remove them.

The solution likely is to nail these companies to the wall, and make it more expensive to let data out of the workplace that it is to hire more or better employees and develop secure internal systems to protect data.

As it stands now a company can usually get by with firing one employee and saying "Oh my God! We promise this will never ever happen again!"

For a start, how about a penalty of $10,000 for every SSN or credit card number released to the wild, no matter what the reason or excuse? Suddenly losing a laptop with 100,000 customer files will become a VERY big deal.

One word...OBFUSCATE (0)

Anonymous Coward | more than 5 years ago | (#24377951)

In order to protect the personal information in our database anytime it's outside of the production environment we obfuscate the data. Any and all SSN/EIN/Banking/Account Numbers/Routing Transit data is overwritten with random values, Employer information is randomly swapped with other employers, as is all membership information. The only thing that remains the same is the number of members associated with a particular employer. Beyond that the data is changed. The result is if this database was compromised, there would be nothing to worry about.

I know what my company would do... (1, Informative)

Anonymous Coward | more than 5 years ago | (#24378017)

Fire me.

The company I work for owns a handful of other companies - three of which have sensitive data.

I have access to database of consumer data - 1.7 trillion records annually of detailed transactions of consumer purchases (date/time, street address, cash register number, products purchased, usually some personally identifiable piece of data) It accounts for about 65% of that market's retail data. They audit my access to individual customers, every year they come around asking about all my accumulated permissions from that year... if I don't have a good reason to have permission to that part of the database anymore, they yank it.

Another database... this one happens to contain HIPAA data. Again, annual audits, they yank access, I have to go to hours of sessions each year to review that years detailed HIPAA guidelines, with lawyers, and sign contracts saying I'll uphold them.

A third company... same HIPAA compliance rules.

All three are voluntarily SOX compliant as well... meaning, in our case, no unauthorized updates to production.

So... how do we solve it?

a) they closely monitor for unauthorized access at the client level, not the application level. Many times, even when working on the system, I don't need even temporary production access; we have a cleaned development database (either client data that's signed waviers or that's been scrubbed by data specialists) Production access is limited to a key few, and even their actions have to be approved ahead of time by an audit review board. Emergency approvals are possible by key individuals, but those are reviewed after the fact. They can and will drag you out on the carpet if you've been slipping anything in.

b) You mention that they seem pretty good about finding out when people have accessed things they haven't. The real trick to that is limiting access to a very few individuals. I'm not talking about every DBA in the building; I'm talking about a few production DBAs with production system passwords, and most of the rest may learn a password for a project; but then it gets changed and they might not need it anymore... then you audit everything - audit the accounts annually or more often. Audit application accesses - every time the app touches anything, you should be able to tell what the change was (before and after values), who did the change and when from the audit log. Log read access to individual clients at least, maybe more granular if your security requires it. By making sure that 95% of the people that make changes do so through the application and not direct DBA access (yes, even the technical people), you limit your exposure greatly.

c) We make clear policies about what is and isn't allowed with the data. You are not allowed to save the data off; we have cleaned versions for development and sales to isolate access to those that strictly do need it. If you do a file transfer, say between servers, you use backed up high speed redundant storage for all of that - in the server room. Physical access to servers is logged (if you're VISA CISP compliant, you're supposed to have been doing that for years now). People can and still do occasionally use laptops to transfer data or save reports with sensitive information (most of our employees never see sensitive information, only information that's been scrubbed or in aggreggate form)

d) fire people that break policies. We don't do it on the first offense generally - but we monitor for policy violations before they become a problem. First time we find sensitive data where it shouldn't be (we have scanners on network backed up folders as well as the typical corporate spyware - details confidential sorry to say), they get a polite warning. Second offense, laptop is locked to desk with a different lock for the night. Third offense, you find your laptop has been replaced with a desktop. I would assume any serious and/or malicious breach would skip straight to fourth offense, what I call "management chain of risk and liability" You know, if it's not TOO serious, you get a verbal warning from your boss. Step two or step one for more serious offenses, it's a written from HR. Step three (or for malicious offenses), it's straight out the door.

I've only seen it get to step three once. Noone else wants to risk their laptops. I of course, wouldn't actually know about anything higher up on that chain - it's all speculation, haven't been through it myself... but every management consultant at every training seminar seems to be on the exact same page with how that procedure should work...

You deal with a sensative Data by.... (1)

jflo (1151079) | more than 5 years ago | (#24378097)

You deal with a sensative Data by turning his emotion chip off... DUH!

Deidentification Software (1)

adougher9 (1092141) | more than 5 years ago | (#24378651)

This query is related to deidentification software. This is software that identifies all personal data in files. I am using this for example to make certain projects that have sensitive information in them available as open source projects. Unfortunately, I have not been able to find one that meets my needs and so I have written my own, called "classify". Google "frdcsa classify" to read more. Anyways, that will only turn up old pages on classify - to find out more subscribe to the mailinglist or email me: andrewdo@frdcsa.org
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account