Slashdot Mirror
How Do You Deal With Sensitive Data?
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?"
I try not to talk loudly around it, and make sure it's emotional needs are met.
Pay your employees enough to make protecting your company's data on their computers/PDAs worthwhile.
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...
we use a robots.txt file and a strongly worded "keep out - private data" header on all important records
.. The UK Government. 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.
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.
As our way of thanking you for your positive contributions to Slashdot, you are eligible to disable Slashdot 2.0.
I encode all my sensitive data as recipes, and keep them in the Central City's First Branch Library in plain view...
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.
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.
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.
my mom posts on slashdot.
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.
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.
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 ...
-- Tigger warning: This post may contain tiggers! --
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.
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.
My turnips listen for the soft cry of your love
Isn't the point of GP that when you pay the proper amount, you can often count on -- gasp -- *competent people coming to work.
My turnips listen for the soft cry of your love
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.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
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's run the show and don't buy based on golf course meetings.
I erase it.
Completely.
I erase it. Completely.
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.
Check out my sysadmin blog!
... 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.
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/
The first rule of Sensitive Data is you don't talk about Sensitive Data.
-fb Everything not expressly forbidden is now mandatory.
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.
Upload it to usenet.
I just sell it to the highest bidder.
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.
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.
The problem with quotes on the internet, is that nobody bothers to check their veracity. -- Abraham Lincoln
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.
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.
Tech Alpha Computer Forums
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.
Horns are really just a broken halo.
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.
Etc.
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.
A polar bear is a cartesian bear after a coordinate transform.
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.
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.
---- Teach Peace. It's Cheaper Than War.
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.
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
DonÂt create any sensitive information
Same way I deal with a whiney girlfriend...with large amounts of apathy, followed by a small amount of back-peddling.
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.
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.
Three Squirrels
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.
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.
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, i
You deal with a sensative Data by turning his emotion chip off... DUH!
WWPD - What Would Picard Do?
"Peekaboo". Would you have guessed it?
Hail Eris, full of mischief...
E pluribus sanguinem
this might sound stupid: but i just don't keep really sensitive data ...
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
Policies might tell staff to shred customer documents, but are shredders made available? Probably not. Instead the docs are put in boxes for shredding and recycling and get lost during transit to the bulk shredding service across town.
Policies on passwords and data locking? Yup they are there, but are they effectively implemented? Are staff trained? Are there automated procedures to force frequent password changes?
Engineering is the art of compromise.
Start by searching hard drives for JPG, MPG, and MP3 files. Copy the good stuff to a USB drive; you can compile quite a collection this way...
when u think u can't deal with something technologically.....
try to fallback what human intelligence did so many yrs way before computers
Another one I've found to be quite effective is to use the first letter of each word in a sentence, then change some of those letters to similar numbers and some to uppercase, then some of those numbers to the character on that same key (1=!, 2=@, etc)
1) bears love to eat lots of yummy berries
2) blteloyb
3) b12EL0yb
4) b!2EL)yb
You now have an incredibly hard to guess password, but as long as the person remembers that bears love berries, they can usually remember which are numbers/capital/symbols.
I don't understand you people. Why do you ask serious questions on slashdot when you know damn well > 70% of the replies are gonna be modded funny..
Encryption and C4!
---- Liquid was a patriot ----
You can only do so much to keep things locked down. At some point employees need access to this data, and then you need to ensure they do not take it outside the organization. There is an industry of products that are targeted at this type of security issue.
Wikipedia has a poor article here: http://en.wikipedia.org/wiki/Data_Loss_Prevention
Products in this market tend to be able to detect and prevent security issues like:
- Network traffic containing sensitive information leaving the organization (email, ftp, http/s) ...
- Users copying files to removable storage, printing, faxing,
- Shared repositories containing sensitive data without proper constraints
One such product is Vontu DLP (www.vontu.com)
I wish more people would do it. the vast majority of the times now these different places want your ssn and they have zero legit need for it, but they intimidate people into giving it to them,. Where it then goes on to be "lost on a laptop". Whenever some feather merchant or anyone says they "need" it I demand to see their written loss guarantee compensation plan. they stare. I go "OK, if you lose my data due to incompetence or theft, how much will I be compensated?" "Oh., nothing? You ain't getting it then" Shuts em up. I got id theft way back early 90s and man it just sucked clearing that mess up, ever since them, the only people get my ssn are employers, full stop. Not even utilities, I refuse, I'll show them a drivers license for ID, but they don't get that ssn number. Sometimes there is a hassle and I (politely) demand to see management and their lawyer, once it goes that far they cave.
Anyway, good for you, hope your surgery goes well, funny, went to the vets the other day to take some pets in for shots, they wanted SSN, I wrote "no way" on the lines on the forms I filled out.
It drives our users nuts because it does hog some resources and it takes time to decrypt on the fly, but when they won't listen, you have to force them to be safe with the data. We also use a system that allows us to use our domain password rules and force complex passwords of a minimum length. Some really hate that, but tough, its for the good of the company.
No personal thumbs drives, no personal laptops on the network, CD burning only for certain people, no floppy drives, etc.
We work with some very sensitive data so even all of that is barely keeping up with government auditors.
And that is just for the little files they may take with them.
SENF is cool, but I leveraged Cornell's Spider to get my SSN|CC scan on. Even thought I work at utexas.edu (home of SENF), perl > java kthx. :)
It is not a case of "Firing employees randomly" when there is a clear, written policy, but I understand what you're getting at -- authoritarian mgmt isn't the best sol'n in the long run.
A better path is a 1-2-3 style -- verbal, written, termination -- with probationary periods between. The key difference is the objective -- education vs simple weeding. By educating the offender you have the opportunity to bring the goofer-upper to an understanding of the why behind the policy. You can nurture a basic, but through, understanding and practice of info security.
hmmm... what am I thinking? This is the modern world -- thinking long term isn't just out, it's wrong... ah, eph'it, I'll still do things this way.
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?
Maybe someone should teach them how to implement views in their DB so that it cuts down on just how many people can do 'selects' to query the DB for sensitive information.
this nation, under God, shall have a new birth of freedom. -- Lincoln, Gettysburg Address
I have an application where images of thousands of checks travel, by laptop, to the bank twice a week. A number of the people whose routing/account numbers we have are rather well off. The people in possession of the laptops are very non-technical.
I have used EFS, PGPDisk, and PrivateDisk. PGP and PrivateDisk with a hardware token. None of them worked worth a darn. PGP was especially annoying. I used to be a PGP fanboy; I really wanted it to work.
I have started using FDE hard drives (Seagate and Fujitsu have them, maybe others.) So far they are stable, but I will be happier when Bruce Schneier or someone comments on them. It is darn hard to find solid information on these things.
Dan
Use technology use remoting(citrix or whatever) to the computers as techology and disallow any copy paste to local machine. Make email's internal only.Disable USBs. So the only thing that can happen is reading the screen and writing down the stuff... but that would be planned crime/violation
Explain WHY the data is sensitive, in measured, even terms, and how it can be abused. If you rely on unbelievable, larger-than-life stories of data loss and the horror and gnashing of teeth that resulted, people who know just enough to be dangerous will call BS and promptly ignore your warnings. Also, please don't pretend that all data is equally sensitive. Everyone (including you) knows it is not. Claiming otherwise will force users to decide for themselves what is "really" sensitive and what is not... and you probably don't want that.
Knowledge is valuable. Ignorance is dangerous. Censorship is unacceptable. http://slashdot.org/comments.pl?sid=10
Ok, not exactly fruit loops, but there's a program called Toucan. Whenever I need to swap files from one device to another I drop them through the handy encryption functionality first. Haven't needed it often, but kept a credit card number from floating away from me that way once already ... not that I would have stored that un-encrypted in the first place.
For any device of dubious origins/destinations, I use Eraser to delete the files off.
The nice thing about what I've linked is that they're the portable versions of the app ... meant to float on your thumb drive in your pocket so you can use them most anywhere.
Overlooked and misunderstood, Rotate by Thirteen Places, for years has been ridiculed by so called security "experts" and academics, who miss the subtle complexity of this ancient encryption tool. The simplicity is its genius.
I work as a contractor for a number of companies and need to take sensitive data home (like their customer contracts, proposals, etc.) on my laptop.
To make sure I do my best to keep their data away from others (especially since I travel a lot), I encrypt twice. First I encrypt the hard drive (before booting the OS) and then I encrypt the individual customer's files in separate "containers".
Truecrypt has a nice feature for its encryption of containers (I use files with uninformative names like turbo.dat, haiku.wav, just for the fun of it) that it will automatically unmount the containers when the computer is put into sleep mode or hibernation, which means that no customer data is accessible when I am travelling.
And regarding common sense: I do not keep any unecessary data on my laptop. I do not copy unneeded data to it and I remove all unneeded data immediately. I keep the different customer's data in separate cointainers and do not open different customer's containers at the same time to reduce the exposure, should somebody steal the laptop from my hands. I keep it locked to a big object whenever I work at a fixed place for some time and always before I leave it out of sight. I lock the screen every time I leave it.
And guess what? It doesn't take too much time either.
You know, in this day of the internet, where you can easily get outside access without too much cost and trouble, VPNs and alike, I'm always amazed that some organisations still think that the way to get outside access to data, or to get data from A to B for access, is to burn it to a CD, download it on to a USB drive or download the entire database into a CSV or even a whole Excel file. I'm also flabbergasted that any non-developer would really need to do this. These files inevitably get left scattered around, and despite what anyone might tell you there is absolutely no way of dealing with this whatsoever. You've made it an unmanaged mess, and it will stay one.
You'd think that VPNs, Terminal Services, remote X and stuff like NX Server just didn't exist. If you want to give outside access to something, and you want somebody to work on something while they're off-site, let them log in via Terminal Services or a remote X session and let them actually do their work physically on-site. If that's not quite possible, let them access the services they need through a secure VPN so critical data is never taken off site and you never open the can of worms where you are bullied into relaxing access to solve the off-site access problem. If someone leaves you just cut their login access and they can't get to any critical data any more.
Seriously, this is what the internet and your bandwidth should be *used* for. While in a small minority of cases there will be some people who will need local access to some data, or there might be bandwidth problems, these will be few and far between and should never be solved by arbitrarily letting any idiot with a laptop download a massive CSV dump of a database.
Is it me?
First have policies in place to let people know what they can and cant do with data. Allow no personal devices, laptops,cd,cellphones,usb devices to be connected to pc's at work.
Any computer leaving the company must have encryption enabled or disk less virtual desktop laptops. that way data never leaves the company.
okstate has started providing SSN scanning software for departments to use. I also know the Navy is starting to get serious about similar initiatives.
Wish I had seen this earlier, but you describe almost exactly the use case for data loss prevention software. Specifically the endpoint protection vector. There are several companies that sell software to protect data at the endpoint, Vontu (now part of Symantec), Vericept, Websense, RSA and Orchestria to name a few.
There are three vectors generally protected by data loss prevention software suites: data in motion - at the network border over email or web traffic; data at rest - stored data in repositories such as file shares and databases; and data in use - data stored on endpoint laptops and workstations. They are content aware applications that will monitor and alter the allowed usage of sensitive data.
One of the things you might be able to do is to create fake records (don't forget which ones are fake!). Some should never appear on the internet, and some might appear, but you have special contact addresses, email, phone for the,
Then if the fake records ever show up on Google, or on one of those databases for sale or if someone/something ever tries to contact _your_ Mr Alan Adams (whether via phone, email or snail mail), you know you've got a problem.
You could have modified records - e.g. have a real person (you for instance) but special contact addresses instead. Or your contact addresses but different name or surname.
Of course, some applications/bosses might not like fake records or even slightly altered ones.
Check out Varonis. It's easy to see who is creating and accessing data-- sensitive or otherwise. It will also display file system permissions from both a data and a user/group perspective (bi-directional), as well as where permissions may be excessive. It helps put context around data classification technologies (anyone use this data, anyway?), and helps data leakage projects by showing you how to secure the data further upstream.
I work in retail and part of being PCI compliant is not storing track data on computers, but how do you prevent people from doing it. Part of our system is using tools from PCI vendors to monitor the data on computers at our retail locations. We use Trustkeeper from a company called Trustwave. Their agent scours drives to look for information that people shouldn't be storing. It works well for us
Add some random salt to the SSN before, and it automagically becomes as secure as any 160-bit hash.
Bu why would you need to hash them? Just make sure with your usual database permission structure that in most of your applications can access only a view of the table that does not have the SSN column at all.
My employer is currently going through a change of policies after an incident where someone stole laptops which had SSN's on them. They were actually locked up at the time but with flimsy cables. The cables were found cut and the laptops gone. At first the users of the machines said that there had been no sensitive data on them but then, once backups were analyzed, it became apparent that there was a lot of sensitive data present. That's lesson number one. End users often don't even realize the sensitivity of what they're working with.
We are in the process of changing policies and procedures. It seems that the main measure taken will be to change workflows and setups to locate data on file shares rather than on local hard drives or other disks. We are, in fact, using Find_SSNs but only for Mac users. The recommended software for Windows is Identity Finder because it's much more user friendly. Senf is more user friendly than Find_SSNs but I think the reason we chose against it was that, in testing, it had a higher rate of false positives and false negatives.
We're very picky in the first place about who we allow to access customer data. We have a separate deployment team and production support team who are authorized to see the customer data. The QA team can get copies of customer data to cover certain test cases. This data can be partially scrubbed. The development team only gets thoroughly scrubbed or generated data. We handle data on a need-to-know basis, basically.
But your question is more geared at legitimate data on laptops. Well, our corporate policy is that all laptops have hard-drive level encryption, no exceptions. If you lose that laptop, you have to report it to our incident team. Your laptop has to be secured at all times in the office, and if you lose track of it at any time in, say, an airport, thats an incident that needs to be reported. You can't let other people use or borrow your laptop if you have sensitive data on it.
Thumb drives are forbidden unless they are an officially sanctioned encrypted thumb drive. Those thumb drives cannot be used with non-corporate machines. If you violate these rules you can be penalized anywhere from sanctions to termination.
Additionally, our internet is proxied, firewalled, and heavily monitored. Doing tricks with tunneling to get around the web censor software or firewall rules can get you pink slipped.
Obviously this is a high level overview. The best thing to do is try to give that data to as few people as possible and make them accountable. If someone has access to that data they can leak it, despite any technological measures you take. The best course of action is to make sure as few people have the data as possible, that they understand how to protect it properly, and that they are properly punished if they don't practice due-diligence in protecting the data.
Part of my day job involves security of data and compliance with government regulations to that effect...
I can state very simply that the vast majority (90%+) of companies which I've seen have done absolutely nothing to secure their data in any way.
I should state that I'm certain that's not reflective of the real world... as organizations that have their sh*t together aren't nearly as likely to employ our services. However, I'd be willing to bet, given that most companies aren't large and can't afford a security staff, that it may be as high as 75%.
You could use products like Authentica to manage sensitive information.
Shred. Shred. Shred.
Deny. Deny. Deny.
You're stating the other side i didn't cover.... Thanks... It IS a sad state of affairs, isn't it?
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
I hate every time something happens and people say.... "The goverment should tax them more or fine them". This really only gives the government more of a reason to find money. Once that is done, NOTHING is done to fix the problem, they don't want to shoot the cash cow, right? So here is what I would like to see happen.
Every time a compnay looses data they have to pay the people who had their data lost.
Say a credit card company looses 10,000 names, card numbers, SSN, and DOB's. Well, they have to pay every person in that list $12,000. The government does need a cut, otherwise thay have no reason to spend money to make sure they pay.
This is the only way to give them a reason to care about security.
--
My parents went to Slashdot and all I got was this lousy sig.
I think that double rot13 would achieve a faster HIPAA complaint rate. EDIT: I read the subject again and realized it said compliant, not complaint...
They use Data Loss Prevention software. I founded one of them, so go ahead and call me biased, but the "F1000" crowd have this problem big time.
DLP systems will tell you where the secondary and tertiary copies of this data are (inappropriately) stored. They'll tell you how that data is being used, where it's being sent, and which employees are using and/or abusing it. The good ones will be able to block the egress or exposure of the data before it leaves the perimeter.
Do you have a bank account at a national retail bank? Are you insured by a "top 10" firm? If so, it's highly likely your data is already being protected by these systems.
Most of the risk of exposure is driven by well-meaning insiders who think they are just doing their job, but make a mistake or cut a corner and end up losing or exposing data. DLP software frequently catches the corrupt and/or malicious crowd as well. Most perps are pretty sloppy operators, and DLP software finds their tracks easily.
There is always somebody that may be disgruntled enough in spite of being properly compensated.
Here the old saying that money does not buy happiness is ominously true.
Trusting human nature is all warm, new agey and fuzzy, but will not save your ass if somebody that felt wronged decides to take advantage of your trust.
Confidential data is far more important than a relationship of trust with your employees in regards to that data.
You can trust your employees to do the right thing in most situations, but you can't take such a gamble with data that is sensitive. To be so trusty is a dereliction of duty.
IANAL but write like a drunk one.
We are talking about somebody that violated a policy which stated he would be fired for doing so.
Such an employee may be immensely more expensive than the meagre expense of replacing him (go on, don't tell me you already forgot about the dude that almost brought down the major French bank a few months ago)....
IANAL but write like a drunk one.
There are several solutions that use tokens (SecurID, Safeword) or even SMS messages to ensure people use one time passwords.
All this printing card with passwords nonsense is confusing, difficult to maintain and fails to acknowledge the existence of cheap good technology that makes this much easier.
IANAL but write like a drunk one.
Such an action would be most likely unfair dismissal in the UK.
If that is not the case in the US or other localities, please do receive my pity.
IANAL but write like a drunk one.
The data should stay in the company's intranet and be accessed remotely via a VPN and using remote desktop software of some kind.
IANAL but write like a drunk one.
I'd have thought there would be best practices. Note I've never worked in such an environment but these are some things I'd think would be no-brainers.
1. No one gets direct access to the database
All data is segregated by purpose and accessible only via a credential-enforcing interface. Identifying characteristics are suppressed and replaced with keys used only for internal purposes.
2. No one gets to connect their laptop or PDA to a sensitive system, period.
This goes back to the people I hear ask, "How do I play game XYZ on my system with SELinux?" You don't. Really. If you want to play games on your system then you don't need to run SELinux on it. If you need SELinux that system should not be used to play games.
3. No paper.
The paperless office is essential for data security. No external electronics, no paper, and limited network access. No installing crap. No, no, no.
If the data is sensitive, it should be protected. If you can make the data non-sensitive enough (via data segregation/scrubbing/separation of duties) for your lawyers and customers and auditors to be comfortable with it being published in 72pt in the NYT Sunday edition then you can take that out (via limited, secure network access) to a non-sensitive area and listen to your mp3 player or yammer on your phone or fristpsot on /. while you work. Otherwise, sensitive means sensitive and you should be paid well enough to forgo such luxuries.
I'm sure I could think of more rules given time, but seriously it should be pretty straightforward. If the data is sensitive treat it like codes for nukes and don't be loose with it. If it's not really sensitive but due to government or other rules/laws you must treat it as such then you still treat it as nukes. If it really isn't sensitive then stop pretending it is.
-HobophobE
Nothing laughs forever.