Can Encryption Help?
-
I think that having encryption built into the database platform is important to having a more secure data platform. In fact I think that having it build into Windows, having drives encrypted, backup tapes encrypted, network channels, etc., all help make things more secure. At least for the lost or stolen drive/tape/whatever media you use. But does it help prevent data theft?
This is an interesting post about a situation where a DBA allegedly stole customer data from a subsidiary of Fidelity National Information Systems and sold it to third parties. That's an editorial for another day, but what struck me in this post was the talk about using encryption to protect the data.
Let's suppose that the DBA/developer/analyst/whoever, had accessed encrypted data. The system should have verified their ability to access the data and then...
... returned them unencrypted data. I'm not sure how encryption would have prevented a user that was trusted with the data from getting it and using it for profit. Even with auditing set up, how would that help? An analyst or DBA could easily claim a "forgotten where clause", even in a third party tool. Maybe there would be a deterrent if someone came by your desk every time you accessed the data, but after 3 or 4 false positives, would they continue to monitor you? Or would they assume you were an idiot?
For some companies the solution might be to limit the size of result sets, so you couldn't select all customer data back at once. Or if you did, raise a huge red flag right away. Encrypting some fields, like SSNs or credit card numbers, and not letting anyone have the keys can help. However the problems that come with applications are that at some point the data needs to be decrypted and returned to someone.
I've never worked in a company where I thought that you could prevent me (the DBA) from accessing data and still doing my job. Troubleshooting queries just required too often that I run the actual stored procedure or that I check the query being used against data, or something like that. It might make sense in places, but I know every job I've had would have required access to the data.
This is a hard problem to solve and I readily admit that I'm not sure exactly how I would even want to solve it, let alone the details of implementing a solution. However it is a problem that we need to do a better job of solving. And be sure that the people in charge of securing data read about this situation.
Just be sure to remind them of one thing: this was an Oracle DBA 😉
-
Securing data of any type requires making some assumptions - beginning with the integrity of the people who have access to that data.
Encryption can provide a layer of security, but keeping information where it should be is a people process. When I was part of the PC support organization at a large telecom, the region Vice President's secretary would call me when there was a problem with the VP's email. You can probably guess that there were times (such as email about personnel matters or company plans) when I was told "You didn't see that." And as far as the rest of the company knew, I didn't see it...
John
-
Hi Steven,
I'm not sure I agree, (or understood correctly) with your statements in that it seems that you feel you should be able to have access to a production database data to be able to debug queries.
First, and foremost, (and as I am sure you are aware) debugging queries or stored procedures should never be done on a production database, even if its just a select query.
I'm personally against made-up 'test' databases as they rarely reflect a real life situation - as I constantly explain to my boss, testing one record of ten is very different to testing one of millions, and that is why the testing dept. rarely discover bugs, and why his estimates, test cases and needs analysis are often wrong, but thats another story...
However, testing /debugging a query is against a 'staging' database, where the 'sensitive data' in that database has been randomly scrambled should be proof enough that the query is correct, without returning sensitive data. This is especially important as packet sniffer could make your innocent test a data leak.
I guess it depends on what environments you work in as to whether or not the company is geared towards data protection or not. I know that the company I work for allows us free access to every client database and the internet (we use SA credentials), but doesn't let us read the code we're supposed to fix without permission or use USB devices or media drives...
Nick
-
As a DBA, system administrator..., you unavoidably have access to sensitive information. I have never seen an arrangement where you can effectively carry out such a job if your access to the system and the data is severely restricted. Basically, companies will have to rely on social control and trust in their DBA and sysadmin teams.
May I point out the fact that the really important frauds do not come from administrators, but from people in the business?
Using all my system privileges, I COULD get and sell some sensitive information for a few bucks. But any executive secretary has access to far more delicate info.
I could not even deviate some dollarcents to my own bank account without it showing up on various cross-reference reports. But a trader or an branch manager can manipulate millions without them being questioned.
A chief officer can use its knowledge of strategic company plans to sell or buy shares or stock options and make a large profit on it.
Security is a necessity, but the assumption that fraud issues can solved by putting the squeeze on the little guys in the datacenter is a big mistake.
-
The weakest piece of any security technology is the human component. Effective security requires people with integrity who take pride in their work.
Integrity and pride are learned behaviors. Let's teach more of that, and a lot of our security issues will disappear.
-
I just wish that XP had a 'secure mode' and a 'fast mode'. Encryption slows things down. If I'm working in microsoft word or playing the latest game then I don't care if the file is encrypted locally or not. I know when I'm playing my game that there are tons of things going on in the background that could be turned off to give me more resources.
Live to Throw
Throw to Live
Will Summers -
As some people have pointed out, this type of security is primarily a human problem. This is not new, throughout history some trusted people were always necessary, whether bankers, keepers of the king's treasury, military planners, etc. Occasionally those situations break down, but we have thousands of years of experience in human behavior. It is a mistake to recast this as an encryption/technology question.
...
-- FORTRAN manual for Xerox Computers --
-
The interesting issue would be not the technology but the vetting of the individual whom breached the trust of Fidelity. I guess that at a certain juncture technical solutions are after thought. What were the warning signs ignored in the evaluation of suitability for employment at this level of access to data?
Was there a divorce, relationship failure, or child custody battle?
Was there a recent loss of a family member?
Was there a change in job responsibility or position of employemnt?
(these are the top three indicators of review)
Was there a substance abuse issue?
Was there credit over-exstension?
(these two are often related and associeated with the primary causes)
I'm willing to bet that these questions asked of critical infrastructire personnel whom meet the criterion: 'when good clearances go bad' are in actuality not a technical challenge but instead are a human resources challenge.
And the knee-jerk reaction of management and individuals whom want to perform damage control and perception management is to pretend that technoplogy (more of it) can alleviate breach's of trust, well if that was true.. then a cumulative security patch would have fixed IE long ago. LOL
While encryption limits the loss of data to outside breachs, it however will not suffice to protect data from employees whom have emotional or financial issues that are not perceived to be met and whom see the organization that they work for as an opportunity to meet those needs: warranted. rational, or ethical arguments of HR performing due dilligence as to the holistic health of an employee and monitoring their key areas on the pyramid of needs could have in all high probability avoided this breach of trust.
While a corporation or institution is not responsible for the holistic needs of an individual, it is REQUIRED to as part of a SOX (Sarbanes Oxley) plan for DR404 and security controls peform due-dilligence in this area.
I would love to see their (Fidelity) controls upon security and ask the simple question: Do you think the IE patch approach is appropriate without HR monitoring key employees at this level of access?
As a member of that group, I'm damned tempted to create a class-action suit on the part of the individuals whom data was compromised and inquire why this key element of security was ignored and what controls were in place?
This is not a technical issue where preventing technicians from accessing need to know data is the issue.
This was in all high probability a failure of HR to effectively monitor a key employee in the areas above listed.
-
Very interesting comments, and it's a tough problem. I'd disagree with the first response that you don't need sensitive information to debug a query. Most of the time you don't, but when the CxO (or any management) complains about some report and says you're missing data, you often need to look at the real data with them to determine if something is missing or not. Or if the query is returning what they expect or want. Scrambled data might work for me, but for business users it might not be acceptable.
-
When I did my time as an Internal Auditor for a Fortune 500 conglomerate, part of which was a Defense Contractor, I developed a formula to express to plant management why I was there: A last-chance level of protection to help ensure that our employees, who are assumed to be honest, were NOT working in an environment where they would be tempted or invited to become corrupted. No manager could argue with that approach. Of course, when you are busy arguing about the strength of passwords, or the wide open access to the crown jewels - engineering computers, it's hard to remember this was the objective. But the bottom line is that we have to assume that our employees are honest. If they weren't honest, hardworking folk, why in the world were they hired, and why are they still working with us?
-
Crime happens. You do what you can to prevent and contain the crime. Then you rely on the law to help you punish those involved and recoup your losses. As mentioned by others, this is a "human" problem. Encryption is just another tool in your utilty belt to help in the prevention department.
James Stover, McDBA -
Encryption can help in mitigating risk. There is a question as to what type of breech database encryption (table, column, or entire DB) will prevent. If the back-up tapes are encrypted and/or password protected, the risk is mitigated until the tape password is found on a post-it on the outside of the case. If a hacker gain privileges on the DB server and can export a query of all the tables, encryption won't help at all.
Its a Cost-Benefit Analysis of each piece of the pie to determine what will be most beneficial in providing multiple layers of protection to keep the data accessible and available to (only) those who need it.
Jay Bowers
CP-SP (Certifiably Paranoid Security Professional)
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply