Software as a service (SaaS) is amazing, but it has created an entirely new set of challenges for security professionals. Although security leaders generally do deep diligence on vendors before putting sensitive data such as trade secrets and PII into a cloud-based application such as Salesforce, employees may be subverting these policies unintentionally. Employees subvert policies and security unintentionally by taking advantage of the interconnected APIs of SaaS applications.
Take for example Jim, an account executive at a fictitious company in the financial sector. Jim’s CIO provided him with access to their secure, vetted, cloud-based CRM, configured single sign-on (SSO) to ensure that only Jim can log in to his account and put IP restrictions in place on the SSO vendor and the CRM vendor to ensure that Jim can only log in from the company network.
This fictitious company did its best to ensure that the CRM had all of the necessary capabilities, but after spending time in the application, Jim decided that he’d like to implement a better forecasting tool. The forecasting tool Jim wants is $99 per month and has a built-in integration with the company’s CRM. In just five minutes with his corporate credit card, Jim has signed up for an account and in just one click Jim connected this forecasting tool to his CRM account.
Although the company in this story is fictitious, the security concern is real, and this very scenario plays out thousands of times per day at even the most secure company. This unvetted third-party tool now has access via API to Jim’s account, and those API calls are not governed by the SSO policies of the company. The result? All of the CRM data that Jim has access to is now accessible by the unvetted third party. The traffic between the third-party servers and the CRM APIs aren’t managed, or even visible, by the corporate firewall. The IP restrictions aren’t enforced, and if this third party suffered a security breach, the attackers would now have access to the company’s trade secrets and customer data.
To add insult to injury, with the increasing scrutiny on PII storage by third parties, if any of that data in the CRM contains PII, Jim’s company may now be in violation of GDPR and consequently subject to a penalty up to 4 percent of its annual global gross revenue. In just one single, innocent click, Jim put the entire company at risk.
Firewalls, CASBs, PC-based agents and company policies don’t prevent or solve the problem of employee-purchased SaaS. Further, because of the growth of BYOD and the fact that more than 80 percent of employees admit to accessing work applications from their home computer, even the most rigorous browser-based monitoring won’t catch these new applications.
In addition to the risk of employee self-provisioning, employees often retain access to company SaaS, even after they have long since left the company. According to the Intermedia Rogue Access study:
- 89 percent of former employees surveyed retained access to Salesforce, PayPal, email, SharePoint or other sensitive corporate apps.
- 45 percent retained access to ‘confidential’ or ‘highly confidential’ data.
- 49 percent actually logged into ex-employer accounts after leaving the company.
Although SSO provides a front-end solution to the problem of retained access, the vast majority of SaaS vendors permit SSO and native vendor accounts to coexist side by side. Native accounts allow a user to log in to the application with only a username and password, never being prompted for SSO verification.
Why do native accounts persist as a problem? SSO was supposed to solve this problem! Many native accounts are provisioned prior to implementation of SSO but an even larger percentage are provisioned after SSO implementation. This happens for one of two reasons: time and time.
At most companies, not every application is guarded by SSO because SSO implementation is time-consuming, which means there are always SaaS apps that have to be carefully managed by hand. Even when SSO is implemented on an application, however, a product administrator may need to grant access to a fellow employee or contractor but doesn’t have the time or patience to wait for IT to provision those credentials. Time and time again, time is the primary reason that employees bypass policy.
So, what’s the solution? Fear not, because wherever there’s a question, technology finds an answer! In the last two years, a new category of products have sprung up to address these, and other problems, as it relates to SaaS management.
Instead of sniffing network traffic, these tools connect via API to ERPs and expense report providers to ingest credit card transactions. By looking at credit card transactions, these tools are able to identify SaaS that has been purchased by employees and alert IT administrators who can then remediate by vetting the application and bringing it under management. These tools provide near-real-time insight into new SaaS applications that employees may be self-provisioning, outside of permitted IT policy.
Identification of native accounts require direct integrations between your SaaS management vendor and the SaaS application itself. By connecting to the API of the SaaS application, retrieving a list of users who have access, and then comparing that list against the list of users in your Active Directory or SSO system, a SaaS management platform can alert you to the existence of native accounts and activity in those accounts.
Although training and company policies play an important role in securing the enterprise, modern IT security requires teams to adopt to the way that employees behave. Between the increase in work-from-home, BYOD and self-provisioned software, IT security professionals have a new threat to manage in SaaS. Thankfully the category of SaaS management has emerged to address it.