2007-12-23 Digital Darwinism
The New York Times article linked below discusses the problems and costs of maintaining digital works of art (cinema) over a long period of time. What this article helps expose is the fundamental problem facing all digital information generating entities: long term preservation and accessibility. What is subsumed within this question is how to ensure long term data provenance, or provably persistent data integrity.
This article actually sounds a clarion call for those who choose to archive anything digital. It also exposes issues not typically addressed by those selling recordable media or long-term storage or archive solutions.
First, "life-long storage" does not mean "long-life storage" --- the difference is crucial, and I believe generally ignored. Life-long storage of degrading media is really storage of media only, and not of the information contained therein. The "lifetime" of most media is described in terms providing no meaningful guidance (such as "mean time between failure" for hard drives). CD, DVD's do not typically advertise or disclose their stated "shelf-life." I remember purchasing some "gold" CD's that were hawked as "long life" only to see the glitter of gold dust exfoliated by these CD's with 5 years of their purchase. Others appeared intact, but became latter-day coasters. Newer storage media: I understand that "flash drives" just wear out over time. What that portends for the SD, Memory Sticks, thumb drives, and pc-memory storage components containing important information (oops, you store your key recovery data on that USB drive...") is not good. Nano-technology? No word yet as to longevity.
Ok, so that means that the 2007 Quadrennial 5-DVD Digitally Re-mastered Dolby 11.1 Enhanced Autographed, Numbered and Limited Edition Blue Ray/HDNA Directors' (and all other) Cut of "Blade Runner" for which I shell out 100 bucks may, or may not be playable five years after I take the DVD's out of the climate controlled, UV free dark room. I'll take my chances, but if they "decompose" I'll be sad. My sadness will be limited, however, only to the extent of my loss of a favorite flick (plus 100 bucks). Not so with enterprise or government information intended to last anywhere between a long time and in perpetuity.
What this means is that entities facing lengthy retention periods had better start considering developing and deploying methods for periodic and orderly migration to "fresher" media, or risk losing data. Including those redundant backups. This brings up the question of whether such entities are required to acknowledge and take steps now, or if these entities will be given a "pass" because they merely did what at the time appeared to provide compliance.
So, it appears that we may be leaving the survival of our most important information (digitally sourced) to "Digital Darwinism," in which information contained in only the "strongest" or most robustly maintained (and migrated) media, survive.
The other issue, in which I profess a biased interest, is how to ascertain and prove, through time, the integrity of such digital data that survives.
Maybe we should worry about that issue in 10 years. It looks as if we'll have a hard enough time proving provenance even for relatively short-lived data.
The link to the New York Time article entitled "The Afterlife Is Expensive for Digital Movies":
http://www.nytimes.com/2007/12/23/business/media/23steal.html?ref=business
Sunday, December 23, 2007
Tuesday, December 18, 2007
2007-12-18 Ohio Electronic Voting Machine Test Results - Not Good
The Register.com (why do we hear this type of information first from the UK?) reports that the Ohio Secretary of State has just released a federally funded report on electronic voting machines used in Ohio, and has found that they contain critical failures that could affect the integrity of state elections.
Excerpted from the Ohio Secretary of State's report (link below):
The voting systems uniformly “failed to adequately address important threats against election data and processes,” including a“failure to adequately defend an election from insiders, to prevent virally infected software . . . and to ensure cast votes are appropriately protected and accurately counted. (Id.)"
"• Security Technology: The voting systems allow the “pervasive mis-application of security technology,” including failure to follow “standard and well-known practices for the use of cryptography, key and password management, and security hardware.” (Id.)
• Auditing: The voting systems exhibit “a visible lack of trustworthy auditing capability,” resulting in difficulty discovering when a security attack occurs or how to isolate or recover from an attack when detected. (Id.)
• Software Maintenance: The voting systems’ software maintenance practices are 'deeply flawed,' leading to 'fragile software in which exploitable crashes,lockups, and failures are common in normal use. (Id.)'"
Register.com also reports an executive for eVoting solution vendor Premier Election Solutions as cautioning people not to read too much into the report. That executive was quoted in the article as stating:
"'It is important to note that there has not been a single documented case of a successful attack against an electronic voting system, in Ohio or anywhere in the United States," an executive for Premier said in response to the report. "Even as we continue to strengthen the security features of our voting systems, that reality should not be lost in the discussion." He went on to say the report failed to take into account security improvements made since the study began.'"
Here's the man behind the curtain (sections of the report) we're asked to ignore:
"Specific Results: Source Code Analysis and Red Team (Penetration) Testing
ES&S
Failure to Protect Election Data and Software Failure to Effectively Control Access to Election Operations
Failure to Correctly Implement Security Mechanisms
Failure to Follow Standard Software and Security Engineering Practices
Premier
Failure To Effectively Protect Vote Integrity and Privacy
Failure to Protect Elections From Malicious Insiders
Failure to Validate and Protect Software
Failure to Follow Standard Software and Security Engineering Practices
Failure to Provide Trustworthy Auditing
Hart
Failure To Effectively Protect Election Data Integrity
Failure To Eliminate Or Document Unsafe Functionality
Failure To Protect Election From “Malicious Insiders”
Failure To Provide Trustworthy Auditing
Lessee: Failure to protect against insiders. Failure to follow "standard and well known practices" for crypto, key management and security hardware. Failure to provide a trustworthy auditing capability, making it "difficult" to discover when an attack occurs. Deeply flawed software maintenance practices resulting in "fragile software."
Hmm. Let's build a house with twelve doors and eleven locks. Certify it as safe because there has been no 'documented" case of a successful attack?
Article link:
http://www.theregister.co.uk/2007/12/17/ohio_voting_machines_study/
Report Link:
http://www.sos.state.oh.us/sos/info/EVEREST/00-SecretarysEVERESTExecutiveReport.pdf
The Register.com (why do we hear this type of information first from the UK?) reports that the Ohio Secretary of State has just released a federally funded report on electronic voting machines used in Ohio, and has found that they contain critical failures that could affect the integrity of state elections.
Excerpted from the Ohio Secretary of State's report (link below):
The voting systems uniformly “failed to adequately address important threats against election data and processes,” including a“failure to adequately defend an election from insiders, to prevent virally infected software . . . and to ensure cast votes are appropriately protected and accurately counted. (Id.)"
"• Security Technology: The voting systems allow the “pervasive mis-application of security technology,” including failure to follow “standard and well-known practices for the use of cryptography, key and password management, and security hardware.” (Id.)
• Auditing: The voting systems exhibit “a visible lack of trustworthy auditing capability,” resulting in difficulty discovering when a security attack occurs or how to isolate or recover from an attack when detected. (Id.)
• Software Maintenance: The voting systems’ software maintenance practices are 'deeply flawed,' leading to 'fragile software in which exploitable crashes,lockups, and failures are common in normal use. (Id.)'"
Register.com also reports an executive for eVoting solution vendor Premier Election Solutions as cautioning people not to read too much into the report. That executive was quoted in the article as stating:
"'It is important to note that there has not been a single documented case of a successful attack against an electronic voting system, in Ohio or anywhere in the United States," an executive for Premier said in response to the report. "Even as we continue to strengthen the security features of our voting systems, that reality should not be lost in the discussion." He went on to say the report failed to take into account security improvements made since the study began.'"
Here's the man behind the curtain (sections of the report) we're asked to ignore:
"Specific Results: Source Code Analysis and Red Team (Penetration) Testing
ES&S
Failure to Protect Election Data and Software Failure to Effectively Control Access to Election Operations
Failure to Correctly Implement Security Mechanisms
Failure to Follow Standard Software and Security Engineering Practices
Premier
Failure To Effectively Protect Vote Integrity and Privacy
Failure to Protect Elections From Malicious Insiders
Failure to Validate and Protect Software
Failure to Follow Standard Software and Security Engineering Practices
Failure to Provide Trustworthy Auditing
Hart
Failure To Effectively Protect Election Data Integrity
Failure To Eliminate Or Document Unsafe Functionality
Failure To Protect Election From “Malicious Insiders”
Failure To Provide Trustworthy Auditing
Lessee: Failure to protect against insiders. Failure to follow "standard and well known practices" for crypto, key management and security hardware. Failure to provide a trustworthy auditing capability, making it "difficult" to discover when an attack occurs. Deeply flawed software maintenance practices resulting in "fragile software."
Hmm. Let's build a house with twelve doors and eleven locks. Certify it as safe because there has been no 'documented" case of a successful attack?
Article link:
http://www.theregister.co.uk/2007/12/17/ohio_voting_machines_study/
Report Link:
http://www.sos.state.oh.us/sos/info/EVEREST/00-SecretarysEVERESTExecutiveReport.pdf
Saturday, December 08, 2007
2007-12-08 Metadata Revisited - What's In That JPG? --- Relevant Evidence.
For those in the "most metadata is irrelevant" camp, I offer this argument in support of my position that metadata is critical to electronic evidence authentication: The metadata contained in most digital photographs can reveal camera ID, camera type, shutter speed, or aperture setting together with the more visible time and date notations. If someone accuses someone as having taken a certain photograph, it might be helpful to ascertain this information *(through discovery, of course) and then argue that the accused:
1. Owned or did not own the type of camera used to take the photo
2. The camera had or lacked the capability to take photos at the listed aperture, shutter or ISO setting
3. The camera had or lacked the capability to take photos at the claimed resolution.
The underlying metadata reliability argument quite readily exposes the gaping holes in the "most metadata is irrelevant" argument, as one might argue that the metadata showing these attributes (including the time and date source, and time and date notation) was unprotected, and subject to the same type of manipulation as is all other unprotected digital data, and is therefore unreliable. One might also present (and this is really the more difficult argument) that the metadata was generated and maintained in such a fashion as to be authentic and reliable. In other words, the metadata, like the photo itself, is what it purports to be at the time relevance attached to it.
For those in the "most metadata is irrelevant" camp, I offer this argument in support of my position that metadata is critical to electronic evidence authentication: The metadata contained in most digital photographs can reveal camera ID, camera type, shutter speed, or aperture setting together with the more visible time and date notations. If someone accuses someone as having taken a certain photograph, it might be helpful to ascertain this information *(through discovery, of course) and then argue that the accused:
1. Owned or did not own the type of camera used to take the photo
2. The camera had or lacked the capability to take photos at the listed aperture, shutter or ISO setting
3. The camera had or lacked the capability to take photos at the claimed resolution.
The underlying metadata reliability argument quite readily exposes the gaping holes in the "most metadata is irrelevant" argument, as one might argue that the metadata showing these attributes (including the time and date source, and time and date notation) was unprotected, and subject to the same type of manipulation as is all other unprotected digital data, and is therefore unreliable. One might also present (and this is really the more difficult argument) that the metadata was generated and maintained in such a fashion as to be authentic and reliable. In other words, the metadata, like the photo itself, is what it purports to be at the time relevance attached to it.
2007-12-08 eDiscovery Question - Do You Know the Way to ADS (Alternate Data Streams)?
Engineered into Windows since NT 3.1 (circa 1993) Alternate Data Streams was developed by Microsoft to allow for better compatibility with HFS (Mac) file systems. When creating any NTFS file or folder, a separate data stream (sometimes known as a "fork") can be also created for that file or folder. Data stored in an NTFS stream becomes invisible to Windows Explorer, text searches, and most other Windows' routine file apps. One may then store a 5Gb .zip file inside the streamed 20k text file. Windows Explorer and most other apps will then only detect the 20k text file, and not the 5GB streamed .zip file. So, one can use ADS to hide data within other data or folders.
Interestingly enough, ADS will be stripped from a file if the file is emailed as an attachment, or if it is copied to a FAT 32 drive (such as a thumb or flash drive), a CD/RW or other non-NTFS file, the ADS will be stripped from the copy.
There are numerous detection, and some removal tools available. ADS Spy is an exampled of a freeware detection and removal tool: http://www.bleepingcomputer.com/files/adsspy.php Good forensics tools such as enCase, SleuthKit, SMART, and others provide capability to detect ADS where a the forensically extracted copy is also an NTFS based filed.
Keep in mind:
1. Search for ADS.
2. ADS may contain discoverable information.
3. ADS may bear obscure non-relevant seeming names.
4. ADS may be encrypted.
5. ADS will be stripped when file is converted/copied to non-NTFS.
6. Ask for presence of and/or have examiner search for common ADS removal tools
7. Vista has a native ADS detection tool. From command prompt, type "dir /r"
Engineered into Windows since NT 3.1 (circa 1993) Alternate Data Streams was developed by Microsoft to allow for better compatibility with HFS (Mac) file systems. When creating any NTFS file or folder, a separate data stream (sometimes known as a "fork") can be also created for that file or folder. Data stored in an NTFS stream becomes invisible to Windows Explorer, text searches, and most other Windows' routine file apps. One may then store a 5Gb .zip file inside the streamed 20k text file. Windows Explorer and most other apps will then only detect the 20k text file, and not the 5GB streamed .zip file. So, one can use ADS to hide data within other data or folders.
Interestingly enough, ADS will be stripped from a file if the file is emailed as an attachment, or if it is copied to a FAT 32 drive (such as a thumb or flash drive), a CD/RW or other non-NTFS file, the ADS will be stripped from the copy.
There are numerous detection, and some removal tools available. ADS Spy is an exampled of a freeware detection and removal tool: http://www.bleepingcomputer.com/files/adsspy.php Good forensics tools such as enCase, SleuthKit, SMART, and others provide capability to detect ADS where a the forensically extracted copy is also an NTFS based filed.
Keep in mind:
1. Search for ADS.
2. ADS may contain discoverable information.
3. ADS may bear obscure non-relevant seeming names.
4. ADS may be encrypted.
5. ADS will be stripped when file is converted/copied to non-NTFS.
6. Ask for presence of and/or have examiner search for common ADS removal tools
7. Vista has a native ADS detection tool. From command prompt, type "dir /r"
Friday, December 07, 2007
2007-12-07 Printout of Metadata Held Sufficient for Discovery Purposes
The Sedona Principles' blanket approach to most metadata as "irrelevant" was adopted in Williams v. Sprint/United Management Co., 230 F.R.D. 640, 646 (D.Kan.2005). The Sprint court embraced the Sedona argument that "[I]n most cases and for most documents, metadata does not provide relevant information." Williams v. Sprint, 230 F.R.D. at 651. The Sprint court also noted that "[e]merging standards of electronic discovery appear to articulate a general presumption against the production of metadata[.]"
The recent decision in Michigan First Credit Union v. Cumis Ins. Society, Inc., Slip Copy, 2007 WL 4098213 (E.D.Mich. 2007) follows the Sprint approach and represents yet another example of how the Sedona Conference's blanket pronouncement is susceptible to misinterpretation. Here, the Court found that a printout of email metadata was sufficient and denied a motion to compel production of native, or source data. Curiously, even though the data and time information contained in the metadata was considered relevant, the "unique identifier" data was not, and since all was "printed out" in a pdf, the Court ruled that no further relevant information could be gleaned from the native, or source data:
"This includes the date and time of the creation of the message file, as well as a long string of characters that serves as a unique identifier for each message." She further states that she has reviewed the screen-shots of the email message produced for Plaintiff, and that "[a]ll metadata pertaining to the individual messages, except for the unique identifier referred to in the above paragraph is visible on these printouts." Hence, except for an "identifier" that would have no evidentiary value, the relevant metadata (such as date and time of creation) appears in the PDF copy. Were this not the case, there would be value in producing the metadata. However, since the PDF copies contain all the relevant information that Plaintiff would otherwise glean from the metadata, I agree with Defendant that producing the metadata for the emails would be unduly burdensome." Ibid, at *2.
Of course, no challenge to the metadata itself was apparently made. Imo, this is a clarion call not only to have the Sedona Principles properly reflect digital litigation reality, but also for counsel to bring themselves up to speed, and understand what it is they must challenge, or defend. Knowing what to ask for, and why, is a good start. The flip side is that being uninformed or misinformed as to the importance of metadata will at this time be more likely to result in this type of "gotcha."
The Sedona Principles' blanket approach to most metadata as "irrelevant" was adopted in Williams v. Sprint/United Management Co., 230 F.R.D. 640, 646 (D.Kan.2005). The Sprint court embraced the Sedona argument that "[I]n most cases and for most documents, metadata does not provide relevant information." Williams v. Sprint, 230 F.R.D. at 651. The Sprint court also noted that "[e]merging standards of electronic discovery appear to articulate a general presumption against the production of metadata[.]"
The recent decision in Michigan First Credit Union v. Cumis Ins. Society, Inc., Slip Copy, 2007 WL 4098213 (E.D.Mich. 2007) follows the Sprint approach and represents yet another example of how the Sedona Conference's blanket pronouncement is susceptible to misinterpretation. Here, the Court found that a printout of email metadata was sufficient and denied a motion to compel production of native, or source data. Curiously, even though the data and time information contained in the metadata was considered relevant, the "unique identifier" data was not, and since all was "printed out" in a pdf, the Court ruled that no further relevant information could be gleaned from the native, or source data:
"This includes the date and time of the creation of the message file, as well as a long string of characters that serves as a unique identifier for each message." She further states that she has reviewed the screen-shots of the email message produced for Plaintiff, and that "[a]ll metadata pertaining to the individual messages, except for the unique identifier referred to in the above paragraph is visible on these printouts." Hence, except for an "identifier" that would have no evidentiary value, the relevant metadata (such as date and time of creation) appears in the PDF copy. Were this not the case, there would be value in producing the metadata. However, since the PDF copies contain all the relevant information that Plaintiff would otherwise glean from the metadata, I agree with Defendant that producing the metadata for the emails would be unduly burdensome." Ibid, at *2.
Of course, no challenge to the metadata itself was apparently made. Imo, this is a clarion call not only to have the Sedona Principles properly reflect digital litigation reality, but also for counsel to bring themselves up to speed, and understand what it is they must challenge, or defend. Knowing what to ask for, and why, is a good start. The flip side is that being uninformed or misinformed as to the importance of metadata will at this time be more likely to result in this type of "gotcha."
2007-12-07 Options Backdating Update - Former United Health CEO Returns 418 Million
The New York Time and the Wall Street Journal report today that William W. McGuire has settled with the SEC and agreed to return an estimated 400 million dollars in connection with the options backdating civil action pending against him. According to one account, the total returned by McGuire will exceed 600 million dollars. Options backdating involves altering the date of an option grant, typically to increase it's value at the date of granting. The option grant's strike price is typically (and some argue should only) be the date on which the grant is made. This grant date also typically coincides with the commencement of a new position, or a bonus.
The grant date maneuverability necessarily involves some time based computer data manipulation, as I highly doubt that any of these time-shifted options grants were accomplished by the efforts Aunt Tillie typing on her Selectric, bottle of White-Out by her side, in the typing pool.
The malleability of computer data (and the difficulties involved in challenging and detecting same) are well set forth in In re Texlon Corporation Securities Litigation 2004 WL 3192729 (WD Ohio 2004). The Texlon court roundly excoriated the defendant's auditor PriceWaterhouseCoopers for violating its duty of preservation. The court noted that auditing documents were altered "well after the close of the [relevant auditing period] and that [PWC should have been on notice to preserve these documents..." The Texlon court further noted that expert testimony discovered that the metadata of certain documents had been altered or deleted, specifically that data had been time-and-date shifted.
What is perhaps most important is that the Texlon court also implicitly recognizes the issue of time based data manipulation, as it also took notice of expert testimony that "it is possible to alter any document in the database, and if the date on the computer used to alter the document is reset, the incorrect date will be incorporated in the metadata fields as the date of modification." Texlon, 2004 WL 319729 at *19. It should be noted that the matter ended prior to the judge's action on the reports and recommendations of the magistrate.
Perhaps in the future the time and date malleability of computer generated information will become the focus of more intense scrutiny by counsel as well as the Courts.
The New York Time and the Wall Street Journal report today that William W. McGuire has settled with the SEC and agreed to return an estimated 400 million dollars in connection with the options backdating civil action pending against him. According to one account, the total returned by McGuire will exceed 600 million dollars. Options backdating involves altering the date of an option grant, typically to increase it's value at the date of granting. The option grant's strike price is typically (and some argue should only) be the date on which the grant is made. This grant date also typically coincides with the commencement of a new position, or a bonus.
The grant date maneuverability necessarily involves some time based computer data manipulation, as I highly doubt that any of these time-shifted options grants were accomplished by the efforts Aunt Tillie typing on her Selectric, bottle of White-Out by her side, in the typing pool.
The malleability of computer data (and the difficulties involved in challenging and detecting same) are well set forth in In re Texlon Corporation Securities Litigation 2004 WL 3192729 (WD Ohio 2004). The Texlon court roundly excoriated the defendant's auditor PriceWaterhouseCoopers for violating its duty of preservation. The court noted that auditing documents were altered "well after the close of the [relevant auditing period] and that [PWC should have been on notice to preserve these documents..." The Texlon court further noted that expert testimony discovered that the metadata of certain documents had been altered or deleted, specifically that data had been time-and-date shifted.
What is perhaps most important is that the Texlon court also implicitly recognizes the issue of time based data manipulation, as it also took notice of expert testimony that "it is possible to alter any document in the database, and if the date on the computer used to alter the document is reset, the incorrect date will be incorporated in the metadata fields as the date of modification." Texlon, 2004 WL 319729 at *19. It should be noted that the matter ended prior to the judge's action on the reports and recommendations of the magistrate.
Perhaps in the future the time and date malleability of computer generated information will become the focus of more intense scrutiny by counsel as well as the Courts.
Subscribe to:
Posts (Atom)