Risk of 3rd party applications has always been a concern for security teams. The SolarWinds breach is an example of a 3rd party application inserting a vulnerability into an otherwise secure infrastructure. While the SolarWinds breach occurred in an on-premise environment, 3rd party apps can also create vulnerabilities in SaaS environments.
AppOmni’s data shows that, on average, there are more than 42 distinct third party applications connecting into live SaaS environments within an enterprise. Approximately half of these applications were connected directly by end-users, not installed by IT administrators. The typical enterprise has an average of 900 user-to-application connections. This represents hundreds of “authorized” third party connections to the data stored in the SaaS environment.
Of those 42 third party apps, an average of 22 have not been used in the last 6 months – yet retain the ability to access data via these connections. These inactive applications often represent a trial usage that was abandoned from a user’s perspective or applications where the business contract may have expired but the vendor access was not removed. These application connections remain authorized until that access has been revoked.
Due to the nature of these third party connections, they are frequently approved by individual users without any security oversight. While these applications may be quite useful, they are hidden pathways into an organization’s most sensitive data. These cloud-to-cloud connections exist outside the firewall and cannot be detected by traditional scanning and monitoring tools.
Not knowing which apps are or aren’t approved, what access the app has, and who could install an app are just some of the issues that may arise with third-party apps. A third-party app could have access to user groups, workspaces, or multiple areas in the corporate network. It could also have access to other SaaS applications.
In the event of an incident, it becomes even more complicated – the incident response team will have to investigate a compromise of the app, create timelines of when and where the app was installed, what it had access to, and other worst-case scenarios.
There are a variety of ways for 3rd party apps to connect to cloud services, but there are three in particular to focus on:
We’ve known this is a problem for quite some time. Looking back at the Apollo Breach, we saw the compromise of a 3rd party app as the stepping stone to dumping 200 million contacts from a major SaaS application. Just earlier this year, Facebook’s Twitter account was compromised. It wasn’t Facebook or Twitter’s security that was compromised. It was a third-party application that had access to the account.
When thinking of your overall attack surface, cloud applications are currently one of the biggest blind spots. This year we have seen a huge increase in cloud adoption driven by the pandemic and work from home. Existing investments in security technologies that focus on the network or the endpoint cannot help us with this challenge. It’s not that our on-premise tools have failed, the data has moved where they can’t see it. Getting visibility into what 3rd party applications are already connected to your cloud applications should be one of the top priorities for security teams. Successful organizations will have a process for continuously scanning and monitoring their cloud applications, and have a review and approval program for 3rd party connections.
CEO @ AppOmni