Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×

How Do You Deal With Sensitive Data? 226

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?"
This discussion has been archived. No new comments can be posted.

How Do You Deal With Sensitive Data?

Comments Filter:
  • by Channard ( 693317 ) on Monday July 28, 2008 @06:38PM (#24376579) Journal
    .. 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.
  • by twolfe ( 235277 ) on Monday July 28, 2008 @06:48PM (#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.

  • by R3d Jack ( 1107235 ) on Monday July 28, 2008 @07:51PM (#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.
  • by Anonymous Coward on Monday July 28, 2008 @08:30PM (#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, i

  • by plover ( 150551 ) * on Monday July 28, 2008 @09:07PM (#24378405) Homepage Journal

    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 10.1.2.3.

    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:Policies (Score:3, Informative)

    by cool_arrow ( 881921 ) on Monday July 28, 2008 @09:27PM (#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.
  • by MrZaius ( 321037 ) on Monday July 28, 2008 @09:56PM (#24378901) Homepage

    This actually raises a valid point - Like every other reasonably competent government out there, the poster should do full disk encryption on every portable device and ban those incapable of it from the network (along with all employee owned devices). The poster should just do it a fair bit more quickly.

    Truecrypt's free. Lenovo's disk encryption is free and allows biometric use if you're using their laptops. The generic mainstream commercial options are less than a hundred dollars a head in many cases.

    There is absolutely no excuse not to use full disk encryption on modern laptops. Training matters, but noone should trust the user outside of company walls.

  • by trydk ( 930014 ) on Tuesday July 29, 2008 @03:19AM (#24381467)
    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.
  • by Rycross ( 836649 ) on Tuesday July 29, 2008 @11:07AM (#24385679)

    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.

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (5) All right, who's the wiseguy who stuck this trigraph stuff in here?

Working...