September 23, 2008 at 9:22 pm
Comments posted to this topic are about the item DLP Technology
September 24, 2008 at 5:36 am
I'm not quite sure how you could assign a 'per row' cost, unless you were ignoring litigation costs associated with data loss (http://www.sqlservercentral.com/articles/Editorial/64241/). In the healthcare industry, we'd also have to consider potential government fines related to non-compliance surrounding data loss. In that case, it would almost be a 'per column' cost also, since some data is PHI (Protected Health Information) and some is not.
Interesting concept.
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
September 24, 2008 at 7:24 am
Unfortunately (or as you pointed out, fortunately for all of us DBA's), the day is drawing very near, when we will be required to track every piece of information that is viewed from our database(s). I have been given those precise requirements. The auditors want to be able to know at what time did what person view what information, and how it was viewed, ie printed, internal application, Query Analyzer.....
Now, I understand why they would want this info, to help track down or rule out potential suspects in Data theft (a very broad definition) incidents. But, in order to store these requests in a useable form, I will have to have a completely separate database, preferably a separate machine, to compile and store this info. The audit database will be a factor of times larger than the actual database being monitored, that factor will depend upon how many selects are run against the database. Depending upon how the code was written and how the data is used, this could be monolithic!! You have to log the info as it is at the time of the viewing, so no pointers to make this smaller.
If you want to follow this way of thinking, then who is monitoring the views of Audit tables, albiet these views would be much smaller, but important none the less as it is still SPII data. Or how can I track if a user gets the SPII data on his screen via an audited software, but then gets a screen print? Where does this madness end?
Stephen
September 24, 2008 at 8:07 am
Darn! I was hoping this was going to be a discussion about HDTV.
I think it would be of benefit to companies having financial and healthcare data. I see where it could cut down on the lag time of finding data breaches and companies could secure the breach, initiate the investigation and notify customers. The TJ Maxx data breach went on for over a year and a half before company officials discovered the breach.
September 24, 2008 at 8:22 am
I think this is a good reason why we should have "certified" applications for SQL Server. Some way to limit access to the server to both a user and an application.
I have no idea how to prevent Excel/Word/etc. from getting access to your data and tracking that.
Or how you handle screen prints.
What about DBA tracking? never thought of that, but should every QA/SSMS sessions be audited somehow?
September 24, 2008 at 8:31 am
When you really start considering all the possibilities, it starts spiralling quickly.
What will really need to occur, is a shift in the way the applications are written. They will need to use as little SPII data as possible to pull result sets, and then users should have varying levels or rights, limiting the exposure to the SPII data and minimizing the Audit footprint. But that would be a HUGE shift in the coding of applications.
SPII - Sensitive Personally Identifiable Information
September 24, 2008 at 8:34 am
This is especially true for outsourcing. Imagine you're a health care company. You have SS numbers, parents maden names, ect all stored in you're medical DB's. Then you decide you're going to offshore you're server migration team to India. That means you have Indian Techs going into the US performing Server migrations for hospitals. What's to stop the DBA doing the migration to add a few extra steps to the migration and query out all the customer data to a FTP site. That's why I quit a previous job, no accoutability if a external disgruntled contractor steals customer data and sells it.
(I should name the company but that would be vindictive and unproffessional)
Now with multinational borders and outsourcing who can you really trust with customer sensative information?
My solution: encrypting sensative data through the application connecting to the database (we had a simple client server model for the software). Key fields like name, address, and SS would be good canidates. Often passwords are encrypted why not do the same to secure customer data. This isn't a 100% but at least if it's done right you have a extra layer of protection. (This is an example that would have saved TJ MAX. Ironically I worked down the street from them when I was in Natick in my first DBA job working for EDS.)
Does anyone know how fast 128bit SSL algorithms run? I'm not a programmer but it seems logical in theory. In practice is a another matter for programmers.
September 24, 2008 at 8:37 am
Disclaimer:
EDS wasn't the company I was working for that got outsourced to India. That was a different company. EDS actually came in to the client I worked for and secured they're network and locked it down really well. The other company, company X didn't have such policies or found them to be important.
September 24, 2008 at 9:59 am
The question "who guards the guards" has the potential, like any recursive algorithm, of becoming an infinite loop.
Let's say you run a full-on trace on every database, in order to do security audits. You, of course, have to safeguard the files from the trace, or they become a means of breaking security. But how do you audit access to those files? Do you set up an audit on the hard drives to see who access what files? Where does that audit data go? How is it secured? Who has access to that? And so on.
Eventually, it always comes back to a person or group of people, who have to keep security under personal control. And those people have to be trusted (they may or may not be worthy of trust, but you reach a point where you have no choice but to trust someone, or do everything yourself - and then who's trusting you?).
And, always, security reduces usability, just by its very nature. The whole point of security is to make access more difficult.
I don't know enough about DLP products to make any real assertions, but I'm sure, in the end, security will still come down to personal responsibility for a small number of people who you just plain have to trust.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
September 24, 2008 at 10:31 am
Stephen Dyckes (9/24/2008)
When you really start considering all the possibilities, it starts spiralling quickly.What will really need to occur, is a shift in the way the applications are written. They will need to use as little SPII data as possible to pull result sets, and then users should have varying levels or rights, limiting the exposure to the SPII data and minimizing the Audit footprint. But that would be a HUGE shift in the coding of applications.
SPII - Sensitive Personally Identifiable Information
I have experienced a number of companies that are stripping direct access to the DB from the application layer, by implementing other layers. Most DBAs and Devs are familiar with 3 layer systems: Database, Business & Data Access, and Application. However, I am seeing a trend now towards 4, 5, and 6 layers, aided significantly by the .NET framework(s). Layers like: Database, Data access, Business Rules, Security/Firewalls, Interfaces, Presentation, and Application. In this latter paradigm, the Application never touches direct access to the data. Data is ported from system to system like a virtual multi-appendage mobile such as those that babies play with, often in XML, JSON, or proprietary format, and encrypted.
However, at the end of the day, we all quietly know that such things:
- bog down the major change process... significantly.
- only serve to help keep the honest, honest.
- and most importantly, still do not prevent the inside man, nor the end user from using data inapropriately.
At the end of the day, you still have to trust people that must use the data.
But still, multiple layer design also allows greater flexibility in cross-system (and GUI) portability, and also allows separate development teams to tackle upgrades to significant portions of the system without affecting the others, as long as the standing "contracts" of interchange are not broken. In essence allowing far greater possibilities. But it requires much more forethought in design.
Personally, I feel logging is still deep in the Network Admin's realm, and is really only useful at the database level to track precendence and change flow in OLTP systems, and keeping the honest in good working order.
That's my take...
September 24, 2008 at 1:04 pm
Maybe in the case of TJX it wasn't so much a mater of the fact that you can't trust you're people, you have to secure you're network. From what I understand TJX had and still has poor password schemas that are easy to crack. Once cracked the data is open.
http://hardware.slashdot.org/article.pl?sid=07/05/05/1812254&from=rss
http://it.slashdot.org/article.pl?sid=07/08/16/207215&from=rss
You have to properly secure you're network and have proper updates to malware detection and antivirus. Also having proper security policies is essential. I do admit I like the idea of smart cards but it's by no means perfect.
Ultimately DLP is a great idea I think for encryption of sensitive key objects ect. but every company is bound my social beings and proper background checks and peer reviews are important to gauge and health of employees who may be having "personal problems" that interfere with they're work life. (IE emotional stress form divorce, death, financial, or mental health issues.) I think you're peer's are a good indication of how you interact and work with you're peers. Ultimately everyone says "He was such a nice boy" when they find out they're living next to a serial killer. You never know who's going to "loose it", you just have to do the best job you can to make sure you're high security employee's (DBA's ect.) are stable and happy. DLP can't fix a disgruntled employee who feel's he or she is underpaid and overworked.
Don't let DLP become a band-aid for poor security practices, and bad security policies.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply