Spoliation Risks of Legal Hold Methods

Digital data has presented new and unique problems for today’s litigants. Data is easy to create, and so is created in prodigious quantities, and easy to manipulate, requiring cautious protocols for management. The 3 primary risks a potential litigant must manage are:

  1. Finding and providing data to satisfy the court
  2. Preventing good actors from unintentionally damaging the data
  3. Protecting data from deliberate modification by bad actors

Finding and tracking relevant data is challenging because of the great volume of information, and so this is an excellent role for a software solution. Several developers have produced software that either include this function as part of broader information governance or a specific solution for Early Case Assessment (ECA).

Communication with personnel about what information is being held should be done early, clearly, and repeatedly. From regular backup deletion to technicians not knowing why that locker of computers hadn’t been wiped yet, companies have lost much data to unintended destruction. Be sure to give custodians clear responsibilities and reiterate them for as long as the hold stands.

Protecting data from bad actors is currently being done in several software-based ways. We highlight this risk as the weak link in current legal hold methods because of their software-only implementation. A software-only implementation cannot be protected from the administrators who manage and govern it.

The first method used, and apparently most common, is Access Control Lists (ACLs); the supposition that “even a database admin would not be able to alter the stored logs.” Unfortunately ACLs are active only when the software is running. For example: MySQL implements limits in what users can change in a database; however, it cannot protect its data files as they rest on the hard drive. Modifying these files directly is possible and of trivial security difficulty for a system administrator, though of potential technical difficulty. Alternatively, if the user can start MySQL on the host computer they can simply use the --skip-grant-tables option and have root access; a technique used to reset a lost password.

The next approach is encryption or digital signatures, themselves a form of encryption. When properly implemented, encryption is an extremely effective way to preserve secrets and protect data from modification. Because cryptography scrambles data into something incomprehensible, it is not possible to make specific modifications for nefarious ends. Unfortunately, this still does not work in a software-only implementation because the key needed to decrypt the data must be available to the software and is therefore necessarily accessible to the administrator.

Finally, we arrive at the best approach we found currently used in legal hold systems: cryptographic hash values for tamper-detection. These hash values allow even the slightest changes to be detected and require no keys to be kept secret. However, when used alone they too are ineffective. The hash values must be stored by the software system and are not themselves protected except by the aforementioned methods, so nothing prevents the administrator from simply recalculating the new hash value after modifying the document of interest. Some solutions use a trusted third-party to protect these hash values.

Businesses trust their system administrators to protect their interests. They must because of the incredible power they give them over the systems that allow them to do business. Should a business assume that a court, or opposing counsel, will trust their system administrators in the same measure? Or should they get auditable, third-party witnessed proof that their records have not been altered?