What Is Shadow IT? You Can't Solve It by Blocking It

When something is “forbidden,” it’s in our nature to seek it out—just ask Eve how that apple worked out. Unintended consequences aside, organizations have a responsibility to keep their and their customers’ data secure, which usually means stopping employees from using certain devices, apps, and software that they believe will more efficiently accomplish their work tasks.

However, when those restrictions are put in place, employees are willing to bend the rules to use the tools they want—which is how organizations end up with a big problem called Shadow IT.

For employees, efficiency is the name of the game; and if your business’ arbitrary restrictions impede the ability to get work done, a workaround will be found—leading to a host of issues that you may be already familiar with in the world of Shadow IT.

Before we unpack the phenomenon and share some ways to mitigate its risks, let’s dive into examples of Shadow IT that may actively be used across your organization.

Two Examples of Shadow IT in Your Company

It’s hard to imagine how I could know anything about your company, but for most folks reading this, the following scenarios will likely hit close to home:

Grammarly

We recently wrote about Grammarly. It is an incredible tool that allows folks who may not be comfortable writing grammatically correct English to produce fluid, cogent, and concise writing. The rub? Grammarly sends any text it checks to their cloud. For a business with strict confidentiality agreements, a single employee unknowingly transmitting privileged data to a third party could have severe legal consequences.

Grammarly is a canonical example of Shadow IT in action. The business provides indirect incentives for people to want to write better; a company emerges to fill that need, employees use it unaware of the greater risks to the business.

Dropbox

Another typical example is third-party cloud services like Dropbox. End-users may be concerned about losing their data, syncing personal preferences, or wanting to access useful files they didn’t produce on their company laptop. While these all are reasonable use-cases on their surface, dig deeper and major concerns emerge.

Imagine a developer that decides to synchronize their entire home folder but, in the process, inadvertently syncs their .ssh/ folder, which includes keys that allow them to access production services. These files could now be synchronized to any other of the employee’s personal laptops, some of which may not even have full disk encryption. It’s a major security incident waiting to happen.

In both situations, employees are reaching for tools they know and trust but don’t have the full context of how they could be dangerous for the organization. Shadow IT problems stem from this fundamental constant, a lack of awareness of the real risk to the business.

The Risks of Shadow IT

While the risks of each instance of Shadow IT are specific to the software’s capabilities, overtime, we can extrapolate many commonly seen risks.

Lack of visibility

The undeniable truth of Shadow IT is once you discover it, you also have a second problem, a big visibility gap. Whether it’s devices on a network you cannot account for or an inability to answer basic questions like, “What Chrome extensions are installed that only appear on a single device?” a lack of sight is what creates the opportunity for Shadow IT to emerge unchecked. If you don’t know what devices your employees are logging into your systems with and can’t see what they’re doing, what else are you missing?

One major way Shadow IT creeps into an organization is through employees accessing work credentials using personal, unmanaged devices. (In this context, unmanaged means not enrolled in a company’s MDM.) IT has very limited visibility into those devices, and virtually no way to control them. This is a pervasive issue; According to our recent Shadow IT report, 47% of companies surveyed allow employees to access their resources on unmanaged devices, and those devices can be full of totally invisible Shadow IT.

Inconsistency and inefficiencies

Much of Shadow-IT comes from employee ignorance that other solutions are available. Instead of leveraging economies of scale and getting a great deal on two screen-sharing platforms, your company has twenty (that you know of). Many of these products rely on network effects to provide their value; everyone needs to be using the solution for it to be valuable. An excellent example of this is Slack. These software silos eventually lead to data silos, as each service looking to be “sticky” foists proprietary formats and lacks interoperability. The result is employees cannot share information with their colleagues, while the lack of consistent processes and integrated workflows can impact data governance and operational cost-efficiency.

These costs feel small at first but can add up, especially when a company starts to grow quickly (and acquire other businesses).

Increased attack surface

More “stuff” (software, services, device) means more stuff to attack. The Attacker’s Advantage and the Defender’s Dilemma tells us that it takes just one poor decision to create an opportunity for an attacker to subvert millions of dollars of intentional defense. It’s an unfair playing field, and Shadow IT tilts the tables even further in the direction of the bad guys.

When IT and Security review vulnerability announcements without a complete understanding of the software/services landscape, they cannot react to critical warnings from vendors. They can’t even enumerate the vendors!

Sensitive data leaks

Having Shadow IT nearly guarantees sensitive, proprietary, or otherwise valuable data leaves your company devices and production services and ends up in places it shouldn’t. Many of the most valuable services generate money not through direct payment but by indiscriminately vacuuming up metadata in the hopes it can be packaged up and sold to others. Other times it’s more direct; for example, when employees upload production data to a cloud storage service and back to their personal devices, malicious actors could intercept the files in transit. If the personal device is shared, stolen, or breached, the information may fall into the wrong hands.

Increased chance of password reuse attacks

When employees sign up for SaaS services on their own, they cannot integrate the company’s centralized SSO. Instead, that could mean they are using traditional email addresses and passwords to access a service that could eventually be the host to essential production data. If they use the same password for multiple accounts, all it takes is one breach to unlock a treasure trove of access for potential attackers.

Inability to revoke access

If you don’t know what accounts employees have created to handle company data and business processes, you can’t revoke their access when they leave the company. This lack of visibility can become a vulnerability when Shadow IT undermines effective employee off-boarding. How can you be sure that your sensitive data isn’t lurking somewhere on the internet, waiting to be stolen?

Poor regulatory compliance

Unsanctioned integrations to facilitate data sharing are often against security compliance guidelines, while custom configurations can undermine existing security settings. Not to mention, if you can’t track and monitor where your data is and how it’s used, you can’t provide the documentation required to stay compliant with data protection regulations (e.g., GDPR, SOC 2, HIPAA, CCPA, and more.)

Blocking Shadow IT Is Only Part of The Solution

Shadow IT left to rot is a big problem, so it’s easy to see why IT teams reach for big preventative hammers like depriving users of administrative rights or blocking the installation of all unknown programs. These types of actions can make matters much worse.

To be clear, it’s perfectly valid to block dangerous apps and unknown devices, but it must be done while respecting user needs and agency. Otherwise, you’ll likely make your users miserable, and drive them further into the shadows.

As I wrote about in the Honest Security guide, when you create roadblocks that impede employees’ ability to do their job, they will often reach for the path of least resistance. In a world dominated by remote work, opening an IT ticket to request new software is no longer necessary. Instead, users can reach for their personal devices and use the tools and services they are used to. While horrifying for IT, it’s surprisingly common and perhaps one of the worst outcomes possible.

The first problem here is that users don’t fully understand the risks of their behavior, because preventative blocking deprives users of the opportunity to understand why a program may be harmful. The second problem is that IT lacks the ability to enforce their own block as long as users are able access work resources on personal devices. A viable solution to Shadow IT needs to provide both meaningful user education, and an effective blocking mechanism, that can’t be easily sidestepped by unmanaged devices.

How to Mitigate Shadow IT Risks

The most effective strategies for Shadow IT preserve end-users autonomy while giving IT and security teams effective automated ways to educate end-users about risks and make them participants in the process. By definition, then, the solution must be reactive. We must wait for an employee to make an error in judgment and quickly correct it. Instead of just shutting it down, we can take the opportunity to see how you can improve processes, technology, or user experience to prevent it from happening again in other parts of the organization. When we approach Shadow IT from this perspective, both sides learn something.

How to stop Shadow IT

From here on out, we’re going to use our own solution as an example, since one of Kolide’s primary functions is to prevent Shadow IT. That being said, you don’t have to have Kolide to practice these principles; they all fall under the general idea of device trust. However, before we highlight the principles that got us to where we are today, it’s important to note that it all falls under the umbrella of device trust.

Device trust is the idea that a user’s device must be secure before accessing an organization’s sensitive resources (such as networks, cloud apps, and data). You can learn more about it here. Now, let’s dive into what you can do to protect yourself and your organization.

Step 1. Get visibility (honestly)

The key to scoping your Shadow IT problem is to invest heavily into the visibility into endpoints while being mindful not to create a surveillance state that drives people to use personal devices. I talk about this at length in the Honest Security Guide, and there are tools like Osquery that can get you started down this path. You can use these tools to identify apps and programs today that are likely causing issues.

All of these must be done while respecting employees’ privacy. For example, they should know what device you’re monitoring and who has access to their data. That’s why we created the privacy center, so end users can understand what data Kolide collects and who can see it. After all, if you aren’t transparent with your employees, you can’t expect them to be honest with you.

Step 2. Identify opportunities to educate

Once you have visibility into the situation, the next step is to find ways to contact users when you’ve found a potential issue. At Kolide, our Device Trust solution ensures devices are in a compliant state before they authenticate to your company’s cloud apps. If they are not, Kolide blocks users from authenticating and provides them with self-remediation instructions to fix the problem, as well as context on why this issue is important. The key in any automated messaging is you explain not just the “what” but also the “why.” Remember, the key here is to educate so people aren’t tempted to find ways around your policy.

A well-crafted message may also suggest IT-approved alternatives. It can encourage users to share red flags they might have encountered when using the unsanctioned software (e.g., data synced to personal devices) so IT can address potential risks proactively.

Step 3. Follow-up that education with conversations and consequences

Part of the benefit of educating end-users is creating conversations for them to push back with reasonable use-cases you may not have thought about. This is important visibility and feedback for the IT team, so this feedback must be captured and actioned in a way that is visible to end-users.

On the other side of the coin, you may have users who refuse (or are afraid) to engage. Now that you have communicated with them, it’s okay for the gloves to come off a bit and give the end-user a call, or if that fails, start taking defensive measures to keep the company safe. One such defensive measure is to have an effective blocking mechanism, such as our device trust solution. By not allowing a device to access your company’s sensitive apps unless the Kolide agent is present, you ensure they won’t simply carry on using the tool you’ve blocked on their personal device. The key here is that we didn’t assume punitive actions were necessary from the get-go, but now, it’s the only tool left.

Too little too late?

You might wonder if a reactive process is “too little too late.” In my view, it is not. In the vast majority of cases, the actual risks of Shadow IT are only realized much later than the initial installation of the offending app. Also, unless a compromise occurs, a willing employee can reverse much of the damage. For example, an employee that accidentally synced their work code folder to Dropbox can be admonished and asked to remove it.

Human-based prevention

If you don’t want just to be reactive, there are preventative measures you can take, but they aren’t technical. Instead of treating prevention like a technology problem, it should be treated as an employee education problem.

It’s vital to proactively get a pulse of what people’s needs are and procure, define, or promote official sanctioned solutions for those needs. In many cases, people are happy to use the official tools, but usually, there isn’t a great way to discover what they are or how to acquire them.

Starting with a central wiki with this information can be paired nicely with the reactive approach mentioned above, not just to tell users that they can’t do something, but to also direct them to the valuable alternatives (and the location of where they can find information like this next time.)

If you liked this blog, we have more security content where that came from—subscribe to our wonderful bi-weekly newsletter!