Why Do We Do It?
-
Why Do We Do It?An interesting story about why we carry around so much sensitve data on laptops.
Is it laziness? Is it the pressures of work that force us to work at home? Is it just the hassles of working on your desktop at work?
It's probably all of the above in some cases. I know that having copies of data on a local machine gives you some advantages that you don't always have at work. Report writers don't want to deal with a slow VPN. Analysts want to work on the train/plane/whatever travel mechanism they use. Auditors need to work with their own set of tools and the easiest way to do it is by transferring files.
The solution isn't simple. It's asking people to change their human nature. Encryption is bypassed by pod-slurping or some other method of transfer. Obfuscation, while a good idea, soon becomes a hassle when you're trying to get out the door on a Friday afternoon. Friends do favors, like bypassing security regulations, so you can do your job easier.
It's like riding a motorcycle without a helmet. Everyone thinks that accidents happen to other people, so they are willing to take the risk. None of us thinks we'll get caught if we turn off encryption or copy some files to work on at home.
And most of us won't. Even changing the laws to penalize companies will end up with many of us required to work longer hours at the office so the data is safe.
But it won't be. We'll still copy it to the new 32GB chip in our cell phone or watch and continue to work at home.
Steve Jones
-
There is a simple way to resolve the problem. Eliminate hard drives out of corporate PCs. Boot software is loaded into memory and nothing can be saved to the local device.
What it will do is force people to work the way we worked in the 70, 80's.. when we didn't have laptops or portable devices.. do the work at work.. and leave it there!
Brett
-
I tend to think of this as a design issue. If the data is stored unencrypted on disk (ie in the table) during design then you are asking for it. When I design, I encrypt sensitive data in the database and store the key to the encryption somewhere besides the database. In SQL Server I'll often put it in a very small lightweight side database that isn't backed up to the main database. I'll back up the side database once and burn it to CDROM and give copies to at least two application owners to be kept in safes and the like. Then when you backup the main database or copy the database over to an analyst laptop, the data is still encrypted and the key isn't there. If they need access to the sensitive data, design it such that they have to go to the central source.
The key goal of getting data is financial information or info that can allow access to financial transactions. For the vast majority of sensitive data operations (credit card numbers, drivers license numbers, bank account numbers, SSN's, and some privacy strings) this is adequate security. If a bad guy gets his hands on your main database, he has nothing if he doesn't get the key.
-
Wow... Guess what, there is risk involved with having sensitive data on mobile computers. Duh, there is also risk with having sensitive data on a main frame computer. And... There is risk in having sensitive data written down on paper and stored in a file cabinet. And... There is risk in having sensitive data painted on the wall of your cave
Would you people get over it! Sensitive data is a risk no matter how you store it or transport it
Get used to risk... In other areas of risk you have more people dying in the USA in farm tractor accidents than with firearms, but you don't find any organizations that want to do away with eating to cut down on the need for growing crops and keeping farmers out of harms way do you? LOL
For me I say take the necessary risks in life, but do use some common sense and try to keep sensitive data from getting into the wrong hands.
Or to paraphrase, mobile computers don't steal sensitive data, people steal sensitive data...
-
One of the most egregious issues I've run across is when a developer or consultant is working on some aspect of a system that requires data structures and/or data, so they take a copy of the entire data set. They invariably want to maximize their productivity, so they don't encrypt, or sometimes even secure the information.
I recently gained a client's trust by doing what I always do.
They wanted a new interface to an existing data store, and I was hired to design it. I arrived to find they had the entire multi-GB database ready for me to take. I am apparently the only consultant they ever dealt with that told them I wasn't about to leave with their data in that form. I asked them to mount the database, ran some random scripts to obliterate identifying information with random data (all customer names and identifying numbers were rewritten, and all currency fields were randomly rewritten). I then deleted all but about 100 MB of records. The end result was that I could take the structures, and sample data, without risking their data itself. What shocked them were the dual factors that I was actually concerned about this security risk, and that I was willing to spend the time to obsfucate their data. What shocks me is that this isn't a more standard practice.
Obviously, a reporting solution needs to have good data, but even there I don't see the need to have real data in hand during most work. Analysis of data should always be done in the most secure environment because it represents the highest risk, and all other risks should be suppressed by standard practices that recognize the risk, manage it, and attempt to limit the impact of loss.
Then again...maybe the horrifyingly bad quality of most data is why some don't bother. Just yesterday I spent six hours looking at a design that engendered data that is more absent than present, and I might even be willing to print that out by the row and publish it worldwide just to see if it makes sense to anyone.
-
yeah, well...
Unfortunately, there's a big logical hole in your argument. A fundamental difference in your analogy to tractor accidents is the extent of the risk. A farmer is willing to drive the tractor because he is willing to take the risk of an accident. But he is not forcing every consumer of his crops to risk THEIR lives.
The issue with financial data being stolen is not that it could hurt the company from which the data was taken (although obviously that is a concern). The larger problem is that such data theft endangers the financial security of the customers whose data has been taken. They did not chose to be in that database, and they have no control over the level of security maintained by the company. In the case of banks, they don't even have the choice NOT to do business - everyone needs to be involved with bank accounts to a certain degree (unless you seriously wish to live in a cave).
Risking your own banking details (or your own life, for that matter) should be entirely up to you. But when your actions are starting to put other people's security at risk, it is certainly incumbent upon you to take extraordinary measures to protect those unwitting participants.
-----------------
C8H10N4O2
-
The solution is simple: Make everyone work through a terminal server, such as Citrix. Don't allow the user to copy to local drives, and you won't have to worry about copies out there...
-
This is a classic approach-approach conflict (hmmm maybe that worthless psych 101 course wasn't so worthless after all). Either we keep data secure (i.e. no uncontrolled access) or we make it easy for people to take their work with them whereever they go (is that an approach drive...maybe not).
Terminal servers are probably the best solution we have right now but what of the 'coasters high above flyover country? No broadband way up there--yet. Preventing data from physically leaving the premises wasn't so easy even in the 70's and 80's. Many a stack of greenbar went home overnight and none of it encrypted...although, come to think of it, given the state of primary education these days, English may be an effective encryption scheme...
-
I find it interesting how many replies have "simple" solutions that totally rely on technology (VPN, remove hard drives, terminal services, etc). All of these solutions will fail precisely for the reasons you describe in your editorial; people are lazy, busy, and impatient when they need to get their work done and they will use any technology at their disposal to make their jobs easier. Technology can have an affect, but companies are not willing to pay the expense of enforcing security rules that hinder productivity.
What we need is a change in everybody’s mindset about who actually owns this data. Currently it is firmly in the hands of the private companies that collect, process, and distribute this data. Yes they spend a lot of resources on this data, but we have to realize that this data is about us, and should properly belong to us.
When personal data is mishandled does it really affect the company? No not really, just a little bad PR which can be remedied with some warm and fuzzy ad campaigns or better yet, political donations.
But does this mishandling affect the people the data is about? Hell yes! People get screwed up and down when their personal data is let loose, years of cleaning up bad credit, pleading with creditors that their identity was stolen, and dealing with legal action.
Only when we change our attitudes about who actually owns this data (the data collection company AND the people whom the data describes) will we see any improvement.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply