Identifying SaaS App Risks

Originally published by Suridata.

Written by Haviv Ohayon.

SaaS vendors tend not to enforce strong security settings by default. Rather, they leave the details up to the client’s discretion. They do this mostly to reduce their responsibility for security. They also want to make their services less complex and easy to use, but nonetheless, the result is security risk exposure. Moreover, system administrators may inadvertently change and lower existing security settings, creating risk exposure in the process. If left untreated, inadequate security settings may allow external attackers, as well as malicious insiders, to access the SaaS. This could lead to the loss of data and other negative outcomes, such as system shutdowns, data breaches, denial of service attacks, increased expenses, and more. This article explores the issue, examining SaaS app risks and offering an approach to their mitigation.

A Growing Area of Risk Exposure

The scale of SaaS activity is one reason why risks can be such a challenge with SaaS apps. According to Vendr.com, the average organization uses 130 SaaS apps. Each app has hundreds of unique controls and settings that are subject to adjustment at will. Users have expectations for SaaS apps that may run counter to what security teams want. It can get tricky to balance security with functionality, a problem that can get more difficult to address as SaaS apps interact with one another.

The Impact of a Dynamic Environment

The dynamic nature of SaaS apps is a further factor complicating their security. SaaS apps seldom sit still. Their makers update them frequently—in some cases every day. This is one of the great things about SaaS. Users don’t have to wait for new versions. They appear automatically in the browser, usually as the result of Continuous Integration/Continuous Delivery (CI/CD) pipelines that push new code into production. The difficulty with this process is that new code often affects security settings.

Security teams may struggle to keep up, leading to a situation known as “configuration drift.” Additionally, because frequent updates to SaaS features usually result in a need to change security settings, security teams may let users change their own settings – granting excessive permissions to users so they can perform this task. The problem is that the security team may then fail to revoke those permissions at a later time. This creates risk exposure.

A Brief Note about Shared Responsibility for SaaS Security

SaaS apps work on a shared security model. This means that the vendor covers certain areas of security, such as the protection of the vendor’s physical infrastructure, networks, application security, and server operating systems. The customer is responsible for its own data security and user access controls, along with numerous security settings. This model makes sense, because the vendor cannot possibly know how to assign access privileges for the customer, to name but one example. However, the shared model can lead to confusion and omissions in security practices on the part of the customer.

Drivers of Common, but Serious SaaS App Risks

SaaS apps are exposed to risk through a variety of factors. Some of the most common include:

Misconfigurations — SaaS apps offer users and admins many configuration options, some of which can expose the user to risk. For example, Google Drive shares are available to anyone by default. This means that sensitive data could accidentally be exposed to virtually any malicious actor if this default configuration is not changed.

Deficient access management controls — Most SaaS apps allow access based on just a user name password pair. This is not secure, given the prevalence of credential stuffing attacks and comparable threats. A better practice is to implement multi-factor authentication (MFA). Risks can also arise out of misconfigured single sign on(SSO) solutions, which can accidentally allow unauthorized users to access SaaS once they have signed in elsewhere.

Third-party risks — Some SaaS apps can integrate with other, third-party SaaS apps, e.g., using a plugin to connect a SaaS to a SaaS-based storage app, and so forth. These plugins can create risk because they may be given access permissions that are not aligned with security policies.

In attention to regulatory compliance factors — The customer is responsible for many important aspects of regulatory compliance, e.g., protecting consumer data privacy, abiding by “data sovereignty” laws, and so forth. If SaaS owners do not pay adequate attention to compliance, they can increase risks of compliance penalties and costly remediations.

Data management oversights — The SaaS vendor is not responsible for data management. It is up to the customer to define and enforce the necessary data security policies, e.g., encryption, data retention and lifecycle, and privacy controls. Without such policies, storing data in a SaaS app creates data security risk.

Lack of strong password policies — Deficient password policies can lead to excessive risk of breach, e.g., if users can choose simple passwords, and are not required to change them periodically, it becomes easier for a malicious actor to gain entry to the system, especially if MFA is not in use. It’s worth noting that not all security professionals agree that strong passwords lead to better security. Ina great example of unintended consequences, a requirement to maintain strong (i.e., difficult-to-remember) passwords can cause users to employ the same password for multiple systems, which creates risk exposure.

In attention to account statuses — When users leave their jobs, or switch to departments where they will no longer need access to a SaaS app, it is essential to switch off their access. This does not always happen, which leads to the risk of unauthorized access. The web-based nature of SaaS makes this risk particularly acute, as a former employee can access the SaaS from home and access data to which he/she has no permission to access. These are sometimes called “zombie accounts.” Sharing of accounts is a related risk, one that exposes the organization using the SaaS app to risk of unauthorized access.

Detecting and Mitigating SaaS App Risks

What can be done to mitigate such SaaS app risks? The simple answer is that the SaaS client must constantly monitor and correct the SaaS security settings to properly protect it. However, considering the number of SaaS apps at the average business, it becomes obvious that any manual processes for monitoring and correction of security settings is going to be unfeasible. There are simply too many apps and too many variables to keep track of, especially in a dynamic environment. Undetected risk exposure is a virtual certainty.

The mitigation of SaaS app risks will require automated risk detection and remediation processes. Specialized solutions, now on the market, can continually scan SaaS apps and flag potential security risks. They can then automatically address risks caused by misconfigurations, zombie accounts, and so forth. These tools can be set to conform with an organization’s unique security policies.

Conclusion

SaaS app risk is, or should be, a main area of focus for cybersecurity teams and their partners in IT operations. The potential for data breaches and system outages looms if SaaS security weaknesses are not discovered and addressed. It can be a daunting subject, though, given the number of apps in question and the range of security configurations present in each app. Solutions are available, however. They leverage automation to overcome the administrative burden of detecting and mitigating SaaS app risks.