Software as a service (SaaS) has made collaborating between geographically dispersed teams easier and more efficient. It’s replaced classic on-premises solutions across virtually every business function with cloud versions for everything from messaging, storing and sharing files to collaborating across documents, coordinating projects and more.
But while SaaS has undoubtedly enhanced the way we work and collaborate, it has also brought about a host of new security challenges that place your cloud access controls and business-critical data at risk.
Managing Disparate Apps
Corporate security teams today are tasked with managing a growing stack of SaaS apps. Because SaaS applications have their own specific access and security controls, with different logic and terminology and with distinct kinds of permissions and privileges that can be assigned, security teams need to allot time to familiarize themselves with the nuances of each app. And while many companies use centralized IDaaS solutions to manage hundreds of users and groups, many other factors and identities—not centrally managed such as third-party apps, or users that belong to external vendors or partners, and local IAM users—affect the security team’s ability to properly manage each application. As a result, companies expose themselves to data corruptions, data leaks and breaches.
Additionally, suspicious activities may go unnoticed and unaddressed in SaaS apps. Most of the time, a malicious actor can leak sensitive data without ever being noticed by overworked security personnel or existing security products.
The fact is, the more apps a company adopts, the more admins they have to manage and secure—and learning the security logic while actively managing a multitude of SaaS solutions is simply unrealistic.
This problem is compounded if admin users and other privileged identities are compromised or go rogue. This can lead to configuration errors—or, worse, the corruption or theft of an organization’s most sensitive business data. Take Salesforce for instance: An admin may grant a user the customize applications privilege to grant them permission to create custom fields or a workflow. However, they may not realize that said privilege often also grants the user the ability to elevate its own privileges, potentially leading to a complete takeover of the service.
Securing a SaaS Application
Managing SaaS apps differs greatly from the old days of managing on-prem solutions. With SaaS apps, security teams must set up and manage different identities and roles for each user as well as different kinds of permissions for each service, not just a single identity, role, and permission set. Also, users can access SaaS apps from anywhere, outside of perimeter security controls; access to on-prem apps, however, often requires access through a VPN and users are subject to network security protocols once inside. These factors make securing SaaS apps a herculean task.
Beyond the Traditional Admin
Non-administrative SaaS app users often perform privileged actions, such as adding users to security groups, granting edit permissions to external vendors, installing third-party apps that integrate with the system and so on. The extent of non-administrative users’ power varies between SaaS apps and is usually configurable to some degree. For example, in G Suite the admin can restrict users’ sharing capabilities. Yet, those users still retain a high degree of power and control over the application. This is a problem, as they are not trained security personnel and typically don’t hold security concerns top of mind when making changes.
Oversharing Is Too Easy
Governing data exposure in SaaS is more complicated than in an on-prem environment. There are a lot of different access types, controls and means of granting permissions to resources. For example, if someone shares a business-critical file in Box with the entire organization via a link, keeping track of who has access to it is no longer possible. This is not due to a bug or a bad feature; in fact, most environments support this kind of file sharing. Admins must be aware of such behaviors in the SaaS services they choose to deploy and their impact on data governance. They should be able to keep track of which resources are shared and with whom, and be able to revoke unnecessary access to sensitive resources.
Security Responsibility is Shared – Sort of
SaaS vendors adhere to a shared responsibility model for security: They ensure the security of the platform, but the customer is responsible for securing usage. Unfortunately for customers, many applications have some over-permissive privileges, faults in their access-controls or other security problems that make securing usage difficult. In many applications, some privileges and permissions are bundled in such a way that makes separation of duties (SoD) or least-privilege extraordinarily difficult to achieve. In Box, for example, if one wishes to retrieve metadata about the links to files and their configuration, write permission would be required. Ultimately, there are no perfect solutions. Every SaaS application today has its faults, and it’s important for security teams on the customer end to understand the limitations and issues of each.
From Infrastructure to Identities
Even non-privileged cloud users can now manage files, tasks, code and customers remotely from anywhere in the world using a variety of devices. This administrate-from-anywhere capability is convenient, but also creates easy entry points for hackers. Instead of pursuing hard targets such as infrastructure, hackers now hone in on users instead. This includes those who may have unintentionally created easy-to-guess passwords or accidentally leaked credentials and tokens or by phishing and social engineering campaigns, especially if MFA is not enforced.
What To Do?
Bottom line: You should secure your SaaS stack just as much as you do your own-prem network and IaaS environment. Adopt a cloud security solution that lists the different identities and how they interact and may interact with the cloud environments. Such a product will enable the security team to keep track of what’s going on across your entire SaaS stack. This includes the different entities at play, their impact potential and a detailed representation of their permissions, what they can do and what they can access, and the exposure status of the organization’s resources. It’s important to use these services consistently and keep track of what’s going on in the SaaS environment, and what permissions are in use.
It’s also encouraged to let external experts assess your cloud identity impact. Experts can help find misconfigurations and risky privileges, improve the overall security of your ecosystem and help you implement an SoD and Least-Privilege permissions model in your organization—or at least warn you about the weak points of the ecosystem and how to remediate or monitor them.
And, of course, it’s important to educate the users in the organization. Users should understand who they share files with and who they add to a group. They should understand the dangers of installing a third-party app, even if it’s a popular SaaS application. Password practices and the usage of multi-factor authentication should be taught and enforced. Eventually, both users and admins should be aware of security necessities and how to avoid risky situations. The security of the organization’s data is everyone’s responsibility.