Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

News

5/21/2008
05:10 PM
George Crump
George Crump
Commentary
50%
50%

An Inconvenient Data Retention Policy

I recently met with a client that had a 45-day retention policy for ALL data. I've heard of this kind of policy for e-mail, but I don't recall ever hearing of it for all the data in the enterprise. Is this realistic and can you get away with that short of a data retention policy? Not really, and here's why.

I recently met with a client that had a 45-day retention policy for ALL data. I've heard of this kind of policy for e-mail, but I don't recall ever hearing of it for all the data in the enterprise. Is this realistic and can you get away with that short of a data retention policy? Not really, and here's why.What the client really meant by this 45-day retention policy is that it only kept backup copies of data for 45 days. This client had been sued a few times in recent years and this policy was in response to requests for legal discovery information. The problem is, I'm not sure how this actually protects them from anything, and in fact may be more dangerous because it provides a false sense of security. It's not deleting all data (or any data, for that matter) after 45 days, just recycling backup data sets, essentially tapes. All the data, years worth, is still on its servers, desktops, and laptops. As part of a discovery request, you can ask for information off any of these. I've seen cases where laptops have even been confiscated. If you were a data recovery specialist, wouldn't you rather start with the file system data anyway? Isn't that easier to get to that data on tape? Certainly the customer wasn't going to crash a server and lose all the data on a server's hard drive in the event of a lawsuit. If I were asked to find data and all the company sent me were tapes, I would most likely be able to get to all the data. Why? The old data is on the file servers and isn't being deleted from the file servers every 30 days. As a result, this old data is backed up every weekend when full backups are done.

While the company may only keep the tape for 30 days, the fact is that the actual data being backed up each week is well over 30 days old. The only instance where it is protected is if a user deletes something, and then 31 days or more later after the deletion a legal request is made, then the data wouldn't be accessible. Reality is that the users will likely not delete that data as part of normal housekeeping. I know very few users that every 30 days clean up all their files in accordance with corporate guidelines. So, in reality, all the data needed is still on the backup tapes. To make matters worse at this organization, there was no formal policy in place to delete old projects, so the project data stays on the servers indefinitely. The only time project data would be deleted would be in the instance of a RAID failure on a server, but even then it would likely be recovered through the restoration process. There was no policy in place to not recover old data -- everything comes back on a server recovery.

To take this a step further, if a user or system administrator knowingly deletes data that may have bearing on a future legal action, that is obstruction of justice. Note the precedence has changed -- it is not only when you are currently under a legal action, but even if you think the data might be of value in a FUTURE legal action. This isn't a scare tactic on my part, it is legal precedence: "Silvestri v. General Motors Corp., (2001) "spoliation" is destruction or material alteration of evidence or failure to preserve property for another's use as evidence in pending or reasonably foreseeable litigation." The e-mail policy was similar; all e-mail was deleted from the primary mail server after 45 days. Ironically, though, users were encouraged to save any mail they wanted to keep beyond this 45-day window to PST files. Those PST files were stored on a specific file server on the network and were backed up as part of the normal backup rotation. The last time they were sued was over an inappropriate e-mail being sent from one employee to another (I'll let you fill in the blanks as to what the e-mail contained). This policy was to prevent that evidence from being available. The problem was that the offended employee sent it to their personal e-mail account and had it for the case. The company looked rather silly and a bit conspicuous by not being able to produce anything relevant to the case. As is typically the case, the retention and litigation focus of this organization was on the wrong end of the problem -- data being stored at rest, not active data. The policy was basically to try to get rid of potentially liable data after the offense.

What can be done? The best solution is training users to understand that someone may eventually see what they put in a document or e-mail that they did not intend to see it. I tell users to write everything (documents or e-mail) as if it was going to be e-mailed to everyone in the organization. Obviously, in the case of employee issues that involve Human Resources, this needs to be done more discretely. Training policies should focus on the active data, not the passive data. Software solutions should be used to log, search, and monitor active documents so that if a legal action occurs, that data can be found quickly and, once found, having an accurate log of who created, modified, and potentially deleted that data can be invaluable. At the end of the day, you have to keep data. We can debate about how long that might be; 3 years, 7 years, forever, but I can assure you it is significantly longer than 45 days or even one year. If you find a piece of data stored on a server that might cause damage to your organization, the last thing you should do is delete it. Someone else has probably seen it, or at least you should assume they have. The best thing you can do is isolate the document or e-mail and be prepared to address it, preferably prior to any legal action.

George Crump is founder of Storage Switzerland, an analyst firm focused on the virtualization and storage marketplaces. It provides strategic consulting and analysis to storage users, suppliers, and integrators. An industry veteran of more than 25 years, Crump has held engineering and sales positions at various IT industry manufacturers and integrators. Prior to Storage Switzerland, he was CTO at one of the nation's largest integrators.

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/3/2020
Pen Testers Who Got Arrested Doing Their Jobs Tell All
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/5/2020
Exploiting Google Cloud Platform With Ease
Dark Reading Staff 8/6/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-16219
PUBLISHED: 2020-08-07
Delta Electronics TPEditor Versions 1.97 and prior. An out-of-bounds read may be exploited by processing specially crafted project files. Successful exploitation of this vulnerability may allow an attacker to read/modify information, execute arbitrary code, and/or crash the application.
CVE-2020-16221
PUBLISHED: 2020-08-07
Delta Electronics TPEditor Versions 1.97 and prior. A stack-based buffer overflow may be exploited by processing a specially crafted project file. Successful exploitation of this vulnerability may allow an attacker to read/modify information, execute arbitrary code, and/or crash the application.
CVE-2020-16223
PUBLISHED: 2020-08-07
Delta Electronics TPEditor Versions 1.97 and prior. A heap-based buffer overflow may be exploited by processing a specially crafted project file. Successful exploitation of this vulnerability may allow an attacker to read/modify information, execute arbitrary code, and/or crash the application.
CVE-2020-16225
PUBLISHED: 2020-08-07
Delta Electronics TPEditor Versions 1.97 and prior. A write-what-where condition may be exploited by processing a specially crafted project file. Successful exploitation of this vulnerability may allow an attacker to read/modify information, execute arbitrary code, and/or crash the application.
CVE-2020-16227
PUBLISHED: 2020-08-07
Delta Electronics TPEditor Versions 1.97 and prior. An improper input validation may be exploited by processing a specially crafted project file not validated when the data is entered by a user. Successful exploitation of this vulnerability may allow an attacker to read/modify information, execute a...