In my previous blog, I outlined the enormous benefits of the rapidly growing SaaS and cloud services model for software, and also touched on the inherent security risks of misconfigurations and how they’re going largely unaddressed. These risks are substantial, so let’s go into a bit more depth describing them.
Let’s start with the authentication settings that define how a cloud service recognizes a trusted identity. Applications establish identities and accept sessions with them based on settings such as password policies, single-sign-on (SSO), multi-factor authentication (MFA) and IP address allowlisting. If SSO and MFA are driven by an external identity provider like Microsoft Azure AD, both the identity provider and the application must be configured correctly. Frequently, password-based authentication is not shut off even when SSO is enabled. This setup can create a risky backdoor that bypasses the MFA control.
Once an application accepts a session, authorization settings like roles, groups, and access control policies kick in to grant identities permissions. These permissions are managed manually by administrators of the cloud service or in part, provisioned through directory groups by the administrator of an external identity service.
Permission setup is complicated because it requires a strong understanding of the cloud service and some context about a user’s job responsibilities. Some services have dozens or hundreds of granular entitlements and a complex set of abstractions that are involved in an authorization decision. Chained abstractions such as group memberships that map to custom roles, or federated identities that map to resource policies through roles, are particularly difficult to set up and maintain. Also, since employees tend to accumulate permissions as they change jobs within a company, maintaining appropriate permission assignments over time is challenging.
The widespread use of APIs by cloud services and the emerging API economy have added a new dimension to the problem of excessive permissions.
Take OAuth, an open standard for granting APIs access based on permission scopes. If I’m using an API to read information from Salesforce, but the API’s OAuth scope includes write access, my API-based integration is potentially capable of wiping out mission-critical data in the company’s Salesforce tables. This could be malicious or perhaps just an error in a release update to the integration.
New APIs and their scopes are usually defined as an application evolves over time and the need for API access to specific resources arises. API scopes, therefore, don’t always align with the original permissions model designed by developers and can become unwieldy. Even worse, depending on who’s allowed to enable integrations — yet another setting — unsafe API integrations are frequently onboarded in error. The result in most organizations is a mesh of ungoverned integrations with overly broad scopes.
Tracking user and API permissions is clearly important. Periodic user access reviews have always been a key control for regulatory compliance. The complexity and diversity of cloud services makes reviews critical for both compliance and “least privilege” security. Reviewing all onboarded API integrations is a new requirement that’s rising in importance.
Many cloud services and applications also support settings that implement other data security controls such as data encryption, key management, or auditing. For example, Box administrators can enable unencrypted file uploads while Zoom offers an end-to-end meeting encryption option, and Office 365 supports a setting for unified audit logging enablement. Complex services like Salesforce and AWS even come with their own built-in security modules that need to be enabled and configured. Of course, tracking all of the security controls in a cloud service that’s in use, understanding best practices, and enforcing them is no easy task.
Cloud security misconfiguration is a thorny problem, in large part because the sheer scale of applications, infrastructure services, identities, permissions, and settings involved, is soul-crushingly large. How can organizations possibly address them all?
Automation is the answer. But that’s our topic for the next blog.
