July 15, 2021

Three Security Risks Lurking in Your eDiscovery Environment

Jordan McQuown

George Jon

+ Follow Contact

Facebook

Twitter

Send

Embed

George Jon

Over the course of my fifteen-year career as a technology consultant, I’ve audited hundreds of eDiscovery environments. I’ve been privileged to work with thousands of bright and capable eDiscovery specialists in all major industries and on almost every continent. These people amaze me. They are diligent, focused and committed to their careers and companies. Yet, even with all of this dedication, I’ve continually encountered something that troubles me. Nearly every eDiscovery environment I’ve audited contains security holes. These holes exist despite the very best efforts to secure client data.

The Panama Papers, a motion picture based on the real-world experiences of the law firm Mossack Fonseca, foregrounded the fall-out of security leaks. We all know how damaging it is to be in those public crosshairs. I really don’t want to see this happen to you, your company, or your clients. So, in this thought piece, I want to outline the three most common security holes I see in nearly every eDiscovery environment I’ve audited. These security holes might very well be in your environment. I also want to offer you practical and ready-to-implement steps you can take right away to plug these holes.

Who This Counsel Is For

I recognize that I’ve made a strong claim above. Nearly every eDiscovery environment I’ve audited does indeed contain security holes. But even if your organization does not have the security holes I’m about to describe, that doesn’t mean you won’t benefit from considering my counsel. Security is as fluid as a river, subject to new threats and continual disruptions. The people who want to steal your data and hold it for ransom are clever and nimble, never ceasing in their efforts and tactics. This means vigilance never goes out of style.

One of the biggest mistakes I see organizations make is believing that security is something you do one time, then you’ve got it licked. That is not a healthy way to think about security. So, from the very start, my first piece of counsel is this. Change your mindset about security. Don’t view it as something you do once in a while. Don’t think that passing an annual security audit means you are not at-risk of a breach. Think of security like electricity: always flowing, necessary for getting work done and, if wrongly used, it will burn down your business.

Here is who I see being at-risk of eDiscovery security breaches. This includes any organization that:

Takes possession of another entity’s data for the purpose of reviewing matters. This might include litigants in a dispute, audits to satisfy regulators or even internal investigations.
Migrates data from clients’ internal IT systems to external systems where the review will take place.
By virtue of taking possession of the data, therefore bears responsibility to protect the integrity of the data from accidental or intentional exposure.

If your organization engages in this activity, my advice here could be crucial for protecting your brand and giving clients real peace-of-mind. Here are three steps you can take right now to plug those security holes:

Uncouple your eDiscovery environment from your general IT environment.
Eliminate shared logins.
Adopt identity management tools.

Let’s take a closer look at each of these ideas.

KEY TAKE AWAY

“Please don’t view security as something you do once in a while, as if passing an annual security audit means you are not at-risk of a breach.”

Uncouple Your eDiscovery Environment From Your General IT Environment

The first security hole I usually encounter comes from “coupling.” In the technology world, systems are “coupled” when they are somehow integrated together, connected if you will. Many organizations make this unnecessary mistake. I have yet to encounter a scenario where general IT systems and eDiscovery systems have to coexist in the same environment and be connected. These systems can be separated with little to no impact on users and performance.

Most organizations involved with eDiscovery recognize the need to protect client data. However, they are often nominally aware of the threat of coupling. Here’s the risk as I see it. The IT environment, for most organizations is where malware, ransomware and viruses tend to penetrate—not the eDiscovery environment. This is well-documented these days. High profile cases often show that malicious code was embedded in the IT systems of hacked organizations for months or even years.

If your IT environment is not separated from your eDiscovery environment, you’ve potentially given hackers a bridge to your clients’ data. Of the eDiscovery audits we’ve conducted with organizations who’ve been hacked, the general IT environment is often the breach point. We’ve seen some companies attempt to address this with firewalls, password managers and the like. Usually, these efforts are not enough to truly sever the bridge. To fix this, you need hard barriers.

The solution I recommend is actually pretty straight-forward. The way to federate your eDiscovery and IT environments is by taking these steps.

Segregate your authentication systems (how users login) at the domain level. This means users are logging into a completely separate set of systems to do their eDiscovery work.
Leverage identity management tools to authenticate your users. This usually means they are accessing your eDiscovery environment through a browser that is passing authentication to an application, not a traditional login. This degree of separation provides a hard barrier between IT and eDiscovery systems. Users literally cannot introduce viruses and ransomware into the eDiscovery environment.

This approach substantially limits the risk of your IT environment unintentionally poisoning your eDiscovery environment.

Eliminate Shared Logins

The second security risk I often encounter comes from shared accounts. Here’s how this usually works and why organizations engage in this behavior. Many eDiscovery reviews involve the ingestion of client data into the service provider’s environment. The EDRM describes this as “Processing” ESI (electronically stored information). The ingestion process is crucial to a successful review. Unfortunately, these processes usually do not run themselves. They can run into roadblocks that only administrators can solve due to their technical skills and elevated privileges.

Depending on how much data is being ingested, Processing could be a simple and quick task, requiring just a few hours. Or it could take days to complete—especially if terabytes of data are involved. These types of matters are the big dollar engagements that most eDiscovery organizations really want. If it takes days, multiple administrators will need to oversee this process to ensure it goes well. After all, they need to sleep too. This is where shared identities come in.

If Processing lasts for several days, multiple administrators will be involved. But they do not want to log in and log out as individual users because that could interrupt the ingestion process in most mainstream eDiscovery applications today. This is an inherent limitation in how most of these applications work. To overcome this, many administrators “take over” the login credentials of other administrators. This is a problem for three primary reasons:

The audit log will not reflect the actual behavior (logins, logouts, system changes, etc.) of a real administrator.
The accountability for “who did what and when” gets completely lost. To the system, it can appear as if one user did everything even though multiple people were involved.
Access governance is a nightmare because it is almost impossible to discern if users are authorized employees or rogue individuals.

But these problems are compounded by two additional factors. Most administrators have elevated privileges, which they need to do their jobs. This means they sometimes have admin-level access to the entire eDiscovery environment, which makes their credentials particularly powerful and dangerous. If hackers get access to their credentials, it’s game over. But because of the application limitations, administrators have to share credentials with other administrators. Every time they share, they put their login credentials at-risk.

Here’s how I encourage you to think about this. The big-ticket eDiscovery engagements that you probably really want also put you at the greatest risk of compromised access and credential sharing. It’s a real conundrum.

I have two recommendations to address this issue. First, have you heard of credential vaulting? These types of tools, from companies like CyberArk or Thycotic, can fix this problem. Here’s how:

Organizations deploy a credential vaulting solution and apply it to individual users. This means users are logging directly into the credential vault, not the eDiscovery application.
The credential vaulting tool provides access to the eDiscovery environment for authorized users. In some instances, the user may not even know the login details for the eDiscovery application.
At any given time, users on the system can be verified as authorized or identified as potentially rogue. This allows for real-time control of access to eDiscovery resources.
The credential vault creates an audit log, which reinstitutes true accountability at the individual level.

The second solution I recommend leverages workflow automation like Rampiva. Here’s how they work:

Organizations deploy the tool and create user accounts for administrators.
Users login to the tool and access the eDiscovery environment indirectly, by way of a browser.
This allows administrators to launch Processing jobs and monitor progress.
In many instances, this is all that is required to complete processing. Only if a job encounters issues does an administrator then need to login to the eDiscovery environment. Even if this occurs, administrators do not need to share credentials.

This approach reinstitutes true accountability at the user level. It also dramatically reduces the need to share valuable credentials.

Adopt Identity Management Tools

The third security risk I frequently encounter has to do with identity management. Organizations often encounter the challenges I’m about to describe when they adopt some of my recommendations above but do not pair those with identity management tools. For example:

Some organizations don’t federate IT and eDiscovery environments, requiring users to login to different systems.
Some organizations adopt credential vaulting and workflow automation tools. These also come with separate login requirements.

After a while, the proliferation of user credentials can become a real problem. How users store and manage passwords can also put their accounts at-risk of breaches. But there’s an even bigger problem. Not all systems require the same type of process for logging in, particularly two-factor authentication, usually by way of a mobile phone. In other words, if a user logs in to five different systems over the course of their workday, two of these might require two-factor authentication but the other three do not. This is not a best practice.

To address this issue, I often recommend a single-sign-on identity management tool. Companies like Okta create these solutions. They’re usually very affordable and they fix a lot of problems. Here’s how they work:

An organization deploys a single-sign-on solution for their users. They establish user accounts and make sure to enable two-factor authentication (this is available in most of these types of tools although it’s often an optional setting).
A user starts their day by logging in to the single-sign-on environment. When they do, they are taken to a portal that provides them with access to all of the applications and resources they need to do their job. Over the course of their workday, they usually don’t need to login to anything else.

This type of solution has a lot going for it:

It’s far more secure because it requires two-factor authentication.
It simplifies the user experience and makes it easy for them to login one time—not five or more times.
It does not require users to manage, store or recall passwords for individual applications.
It creates an audit log to maintain governance and accountability.

Final Thoughts

Most of the eDiscovery environments I’ve been privileged to audit do indeed have security holes that put their organizations at unnecessary risk. In this thought piece, I’ve presented three potential solutions that can make a real difference.

Federate your general IT environment from your eDiscovery environment.
Eliminate shared identities, usually due to application limitations.
Adopt identity management tools.

These three solutions can significantly enhance your security stance. Even so, I also recommend that you think of security as something that requires ongoing vigilance. Security is never one-and-done because the value of client data is simply too enticing for cybercriminals. If you have questions about any of the points I’ve raised in this thought piece, please know my door is open.