Tips for Secure SaaS Third Party Apps

Employees continue to clamor for access to third-party SaaS apps and solutions. Saying “no” will drive users outside of your controls, so say “yes,” but control their experience. This piece details the importance of keeping the list of approved SaaS applications short, configuring them correctly and training your users accordingly.

Managing Third Party SaaS Apps 

Successful management of third-party SaaS applications first requires an intentional reduction in the types of applications used. This process requires both approval and blocking processes, so that enterprise versions are allowed, personal versions are not. Speed is critical to success here, because the longer you wait to approve an application or to identify and approve an alternate application, the more likely it will be that workers will have already placed sensitive information in an unapproved environment.

Start with a small list of approved applications—one for each use case. Where technically possible and budget allows, license the software at a high-enough level to get security features and to invest in developing internal skills around configuring and monitoring the software.

Download: Third-Party Software Security Checklist

Training SaaS Users 

Once you have a list of authorized applications, identify which are secure enough to serve as specific data repositories and which might only be secure enough to use for metadata.

For example, you may decide that the security capabilities and internal skill set around one app are sufficient to allow sensitive data to be stored directly in it, while the same may not be true for others. 

This approach works well across many services. The difficult part is to avoid classifying vendors as “high” and “low” security. All vendors should be considered sufficiently secure to get on the approved list at all. The line must be drawn around what sort of data can be stored in each. Perhaps one app is approved for source code and another is approved for documents. This means that even though both are approved for use, it would be against the rules to place source code in one and to place documents in the other.

READ: Application Security Training & Resources

Simplify SaaS Service Rules 

By crafting specific rules around each service, it is possible to both align training to expectations and easily monitor and measure compliance with those rules. This approach may result in rules that are technically or logically nonsensical—especially as services change over time. For example, you might have a rule that says, "Support people can follow links from a certain tool, but only support managers can add links.” There is no technical or operational reason to do this, but from a training perspective, it is easier to route the linking through a small number of trained people than it is to try to train an entire organization to follow the right process. Simple, non-nuanced rules are easier to follow by the average person, which significantly reduces risk.

SaaS Platforms Options 

It is also important to recognize that Microsoft is developing Microsoft 365 to become a central platform on which all SaaS offerings can run. If you choose to fully embrace Microsoft 365 at a level that includes Azure Information Protection (AIP), for example, it becomes possible to wrap security directly into Microsoft Office file types, which integrate natively to Microsoft’s OneDrive and SharePoint systems. This approach provides a very clean technical implementation that allows users to work within tools and share documents in a way that prevents them from being viewed, copied or altered by unauthorized individuals at a very granular level.

There are advantages to this approach, there can also be drawbacks as well. While AIP is extremely powerful, it does require all applications to be Microsoft-approved options, and third-party application use is greatly limited. For example, the Microsoft approach would eliminate many tools. Few organizations are currently in a position to go all-in with respect to a Microsoft environment and trying to work with AIP at a partial level largely results in exercises of futility and frustration.

Tips for Secure SaaS Third-Party Apps 

When using third-party SaaS apps, try keeping the following three elements in mind:

• Only approve a small number of apps: Security rewards simplicity. Start small and grow from there.
• Configure that small number of apps securely: Secure defaults keep users in their lanes and data where it belongs.
• Train using simple rules: Technology and logical rules can allow for more nuance than humans can handle. Set up the system for the people using it, not for what is technically possible.

As you go through the process of saying yes to these requests (so users don’t try to work around you and your team), don’t be afraid to say “no, but” and deny requests for less-secure applications if you can guide those users to more-secure equivalents.

Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.