8 SaaS security best practices for 2024

by Pelican Press
43 views 8 minutes read



8 SaaS security best practices for 2024

SaaS has become the normative path for many enterprises in how they consume business applications. Data from Productiv, which makes software to help businesses manage their application spending, showed that the average company used 342 SaaS applications in 2023.

In addition to the quantity, the ways that organizations use SaaS products complicate efforts to protect sensitive data and guard against data breaches. Organizations make choices based on their particular industry, requirements, goals, regulatory mandates and so forth. This all means that there’s no one-and-done, one-size-fits-all SaaS security checklist.

That said, certain SaaS security best practices and strategies can be applied to most situations. A few best practices to consider include the following.

1. Discover and inventory applications

One of the things that makes SaaS so compelling is how easily it can be put to work. This ease is both a blessing and a curse. New users can easily get started using a tool, creating situations where an application’s usage can go from a handful of users to significant usage practically overnight.

These adoption dynamics complicate SaaS management. A survey of IT professionals for BetterCloud’s “2023 State of SaaSOps” report found that up to 65% of SaaS application usage is unsanctioned, a strong indication that the shadow IT tradition remains alive and well.

To discover which SaaS applications are in use, a business might employ both automated and manual methods. Additionally, it is wise to have strategies in place for how to gather and validate usage data. You might, for example, combine improvement of your SaaS inventory with other data-gathering activities you have underway. You might choose business impact analysis — i.e., collecting information about applications’ usage and relative priorities for business continuity purposes — or evidence gathering for audit response as mechanisms to gather intelligence about SaaS applications in the environment. As you collect information, add the data to a running inventory or runbook associated with business use of these SaaS tools.

2. Implement single sign-on

Finding and recording information about usage is useful, but you also need strategies that self-enforce the secure outcomes you want. One particularly illustrative example of this is single sign-on (SSO).

From a user point of view, one of the biggest hassles with SaaS can be the proliferation of identities across the various business applications in use. A user might have dozens of username-password combinations; this is burdensome for them, plus it also creates management challenges and security risks, such as users sharing passwords across services or employees writing down their passwords.

Some SaaS providers offer the option of integrating with an external identity provider, such as Active Directory or Microsoft’s Entra ID. These are typically supported through federation mechanisms, including Security Assertion Markup Language (SAML) and OpenID Connect (OIDC). While these features are valuable on their own, they also help with discovery. Not needing to remember another username-password combination is directly beneficial to the end user — so much so, in fact, that users can help pressure for this functionality in cases where it is not in place.

This pressure to support SSO from the user community is a good thing because it identifies SaaS usage that the security team might not otherwise know about. It also ties together the authentication constraints — e.g., MFA and password complexity parameters — as well as extending access logging in to the SaaS realm.

3. Enable multifactor authentication

One of the main mechanisms to enable MFA is through federation of the user’s identity to the existing, internally used identity provider. However, this is not the only way. Some SaaS applications do not directly support SSO — e.g., via SAML or OIDC — but nevertheless do allow an option for MFA through one or more supported mechanisms, such as a time-based, one-time password or text. In situations where MFA is supported, making use of that feature and enforcing it across the user base can be valuable as well.

4. Vet and perform oversight

Just as you review and validate vendors from a supply chain perspective, it is important to evaluate SaaS providers and applications. You want to understand the usage of the application, as in who is using it and for what business purpose, as well as the security profile of the vendor. Identify the available security features. For example, are there optional data protection and privacy capabilities? Also, understand the core assumptions built into the product about which elements of protecting usage are on your side of the shared responsibility fence.

5. Employ data encryption

Most channels used for communication with SaaS applications employ TLS to protect data in transit. Many SaaS providers offer an encryption capability to protect data at rest, too. For some providers, this is a default feature; for others, it must be explicitly enabled by the customer. If given the option, it is a good idea to enable data encryption features. If your providers do not offer encryption, let them know this is a feature you want to see added.

6. Consider CASB

Depending on your security requirements, you might choose to evaluate tools and controls that help extend security requirements into the cloud. In a SaaS context, consider the cloud access security broker options. With a CASB tool, an organization can layer on additional controls not provided natively by the SaaS provider. For example, a CASB could provide better information about who is accessing the tool, better usage monitoring and better data protection. Pay attention to CASB deployment modes: TLS 1.3 has increased the complexity associated with some proxy-based models, while API-driven modes, in many cases, require support by the SaaS provider itself, which means your provider of choice might not support every product on the market.

7. Consider SSPM

Another option is SaaS security posture management. SSPM is similar in some ways to cloud security posture management. With CSPM, you more effectively ensure that you are enforcing a given security model across multiple cloud deployments. SSPM boosts efforts to ensure that security policy and enforcement are set universally across SaaS platforms. SSPM tool vendors have done the work of translating specific technical policy goals into the native configuration of different SaaS services; they then can query those services to ensure that your configuration is in the desired state. And they warn you if it is not.

8. Maintain situational awareness

As always, monitor SaaS use. Examine data from internal tools, including a CASB if you are using that, as well as any logs or other information provided by the service providers, to see where and how you are using SaaS.

It is important for IT and security leaders to understand that a SaaS offering is a powerful tool that requires the same degree of security as any other enterprise application. By adopting these SaaS security best practices in conjunction with systematic risk management measures and ongoing security assessments, organizations can ensure SaaS is employed safely by users and usage stays protected.

Editor’s note: This article has been updated and expanded to include changes in cloud security best practices since its original 2021 publication and to improve the reader experience.

Ed Moyle is a technical writer with more than 25 years of experience in information security. He is currently CISO at Drake Software.





Source link

#SaaS #security #practices

You may also like