Despite IT procurement processes evolving to a Software as a Service (SaaS)-friendly — and often SaaS-first — stance, employees continue to take software matters into their own hands.

A recent Beezy workplace trends and insights report shows, unsurprisingly, that 32% of workers use unapproved communication and collaboration tools. And an HP Wolf Security Rebellions & Rejections report reveals that 91% of IT teams have felt pressure to compromise security for business continuity.

This scenario often plays out when a knowledge worker wants full control over how their work is done and the tools used to accomplish it and they subsequently skirt IT procurement and protocols to use their preferred apps.

This process of employees downloading, using or integrating applications into the tech stack without IT’s permission is commonly known as “shadow IT,” and the threat level posed by shadow IT apps can vary considerably.

Threat actors can compromise shadow IT to access enterprise data and systems

As an example, consider an employee in finance who has an unyielding preference for a specific charting tool. The IT-sanctioned charting application is, from the finance employee’s vantage point, not as effective. With a board meeting quickly approaching, the employee may sign up for a free plan or trial version of their preferred charting tool, put a full subscription on a corporate card that doesn’t flag transactions under a certain dollar threshold or even foot the bill personally to get the work done quickly.

The risk associated with a single employee using this type of application in a very limited scope is usually minimal. But the connected nature of today’s IT ecosystems, with easy integrations available by design, can quickly change the risk calculation.

Now imagine that finance employee connects the shadow IT charting tool to their Microsoft 365 account to import data directly from Excel instead of manually pasting it in. The employee also needs sales data from Salesforce and Clari and doesn’t think twice about adding those integrations. Once the charts are ready for review, they’re shared with the chief financial officer (CFO) via Slack. The CFO unwittingly clicks “Yes” to connect the charting app to Slack to enable easy previews and downloads.

In the course of an afternoon, the charting tool transformed from isolated use to being integrated with Microsoft 365, Salesforce, Clari and Slack. It shares the same permissions as a trusted finance employee on Salesforce and Clari and it has a higher executive-level permission in Slack due to the CFO’s connection acceptance. In the IT ecosystem, the tool is now a third-party app connected to all of these platforms.

As this example illustrates, third-party apps make work easier for employees at the cost of intensifying risk for breaches. If a third-party app is compromised, a savvy threat actor can often gain access to all the SaaS data and systems to which the app is connected. That hacker could, with the CFO-level permissions, make far-reaching changes that affect extremely sensitive data and processes, such as Sarbanes-Oxley compliance.

This charting-tool situation is hypothetical, but hackers are attempting to exploit this type of weakness every day. Gaining proactive visibility to applications that present the most risk is, of course, the desired end-state. But getting there comes with its own challenges.

Managing shadow IT risk in an increasingly complex ecosystem

A breach scenario similar to the one described above is also possible with a third-party app sanctioned by the IT team, assuming they have the resources to build and apply a third-party app policy along with the necessary onboarding process. While approved third-party apps are not impervious to attacks, the attack surface is considerably constricted. In such an event, IT understands the access privileges associated with the approved app, enabling the team to swiftly suspend the user’s access rights.

This response method becomes less effective if a tool originally approved for use with limited data sets morphs into expansive permissions and data access. If the charting tool had been approved for one user manipulating basic data, that approval wouldn’t extend to CFO-level permissions across critical systems. Yet this form of drift is, unfortunately, commonplace across sanctioned and rogue apps alike.

Without proper tools, inventorying and securing every third-party SaaS app would require Herculean effort. But that doesn’t mean IT teams can’t take practical steps to curb third-party app vulnerabilities.

Better educating employees, particularly those with highly privileged roles in vital SaaS systems, about the risks of third-party apps is certainly worth undertaking. Coupling this information with positive relationship-building between the IT team and end users may help employees think twice about installing a third-party app.

That finance employee may still have reservations about the approved charting application, but they may reconsider how a small learning curve on their part is preferable to a vulnerability that could impact a large swath of their teammates.

Even better, that employee could decide to follow the (hopefully) brief process for getting the preferred tool approved — and abide by third-party app integration policies.