Save time with unbiased, independent feedback on vendor solutions.
Watch weekly bite-sized webinars hosted by IANS Faculty.
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.
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
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
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
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
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.
When using third-party SaaS apps, try keeping the following three elements in mind:
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
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.
September 19, 2023
By IANS Faculty
Discover the diversity of IANS Faculty's real-world expertise. Learn how our faculty members can help you solve your most challenging security issues.
September 14, 2023
Learn how to use a three-step approach to defending and managing public and private APIs while avoiding common mistakes.
September 12, 2023
Understand the main differences between first- and second-gen SAST tools and learn how to determine which will work best for your environment.