In today’s rapidly evolving SaaS environment, the focus is on human users. This is one of the most compromised areas in SaaS security management and requires rigorous governance of user roles and permissions, monitoring of privileged users, their activity level (dormant, active, hyperactive), their type (internal/ external), whether they are incoming, moving or outgoing and more.
Not surprisingly, security efforts have been primarily human-centric. Configuration options include tools like MFA and SSO for human authentication. Role-based access control (RBAC) limits the level of access; Password complexity guidelines prevent unauthorized users from accessing the application.
However, in the SaaS world, there is no shortage of access granted to non-human actors or, in other words, third-party connected apps.
Service accounts, OAuth permissions, and API keys are just a few of the non-human identities that require SaaS access. When viewed through the lens of the application, non-human accounts are similar to human accounts. They must be authenticated, granted a series of permissions and monitored. However, because they are not human, much less attention is paid to ensuring safety.
Examples of non-human access
Integrations are probably the easiest way to understand non-human access to a SaaS app. Calendly is an app that eliminates back-and-forth emails to schedule appointments by viewing a user’s availability. It integrates with a user’s calendar, reads the calendar to determine availability, and automatically adds appointments. When it integrates with Google Workspace via an OAuth permission, it requires scopes that allow it to view, edit, share, and delete Google Calendar, among other scopes. The integration is initiated by a human, but Calendly is not human.
 |
| Figure 1: Permission scopes required by Calendly |
Other non-human accounts involve sharing data between two or more applications. SwiftPOS is a point of sale (POS) application and device for bars, restaurants and retail outlets. The data captured by the POS is transferred to a business intelligence platform, such as Microsoft Power BI, where it is processed and analyzed. Data is transferred from SwiftPOS to Power BI via a non-human account.
The challenge of protecting non-human accounts
Managing and protecting non-human accounts is not as simple as it seems. For starters, each app has its own approach to managing these types of user accounts. For example, some applications disconnect an OAuth integration when the user who authorized it is deprovisioned from the app, while others maintain the connection.
SaaS applications also take different approaches to managing these accounts. Some include non-human accounts in their user inventory, while others store and display the data in a different section of the application, making it easy to overlook.
Human accounts can be authenticated via MFA or SSO. Non-human accounts, in contrast, are authenticated once and forgotten unless there is a problem with the integration. Humans also have typical behavior patterns, such as accessing applications during working hours. Non-human accounts often access apps during off-peak hours to reduce traffic and network pressure. When a human logs into your SaaS at 3 a.m., that could trigger an investigation; when a nonhuman connects to the network at 3 a.m., it’s business as usual.
In an effort to simplify management of non-human accounts, many organizations use the same API key for all integrations. To facilitate this, they grant broad sets of API key permissions to cover all potential needs of the organization. Other times, a developer will use their own API key with elevated permissions to grant access to the non-human account, allowing it to access anything within the application. These API keys act as full access passes used by multiple integrations, making them incredibly difficult to control.
 |
| Figure 2: A malicious OAuth application detected via Adaptive Shield SSPM |
Sign up for THN’s next webinar: Reality Check: Identity Security for Human and Non-Human Identities
The risks of non-human accounts add to the SaaS stack
Non-human accounts are largely unmonitored and have wide-ranging scopes of permission. This makes them an attractive target for threat actors. By compromising any of these accounts, threat actors can access the application undetected, resulting in breaches, unauthorized modifications, or service disruptions.
Take steps to protect non-human accounts
By using a SaaS Security Posture Management (SSPM) platform along with Identity Threat Detection & Response (ITDR) solutions, organizations can effectively manage their non-human accounts and detect when they are behaving erratically.
Non-human accounts require the same visibility as human accounts from security teams and should be managed in the same user inventory as their human counterparts. By unifying identity management, it’s much easier to view access and permissions and update accounts regardless of who owns them. It also provides a unified approach to account management. Organizational policies, such as bans on account sharing, should be enforced at all levels. Non-human accounts should be restricted to specific IP addresses pre-approved in an allow list and should not be granted access via standard login screens (UI login). Additionally, permissions should be customized to meet their specific needs as apps and not be broad in scope or match their human counterparts.
ITDR also plays an important role. Non-human accounts can access SaaS apps at all hours of the night, but are usually fairly consistent in their interactions. ITDR can detect anomalies in behavior, whether it be changes in the schedule, the type of data added to the application, or the activities performed by the non-human account.
The visibility provided by SSPM into accounts and ITDR into non-human identity behavior is essential to managing risk and identifying threats. This is an essential task for keeping SaaS applications secure.
Learn more about protecting against non-human identities