Your SaaS environment is unique. Your security approach should be too.
When Obsidian first debuted our SaaS security posture management platform, we felt it was important to provide preconfigured rules based on our team’s expertise, security research, best practices, and industry-recognized standards. These out-of-the-box recommendations were—and continue to be—instrumental in enabling our users to deliver immediate security improvements to their complex SaaS environments. In the process of working with our customers, however, we learned that this was only a starting point.
“You are the experts in SaaS Security. We are the experts in our company. What we really need is a partnership with both of our expertise to solve the problem.” – Security & GRC Leader, Large Technology Company
SaaS applications are inherently complex. As these applications have evolved, the flexible configuration options they provide have also increased, making it possible for users to define policies and safe usage boundaries that fit their specific needs. At the same time, this immense, open-ended flexibility can easily overwhelm security teams, especially when you consider the dozens of applications and thousands of individual settings they have to make sense of.
With the launch of our next-gen SaaS Security Posture Management solution, we’re making it possible to customize policies across your SaaS environment in a way that is both approachable and scalable. Our out-of-the-box recommendations aren’t going anywhere, to be sure; for organizations with unique security and compliance needs, this update opens an entirely new depth of flexibility in the Obsidian platform.
The explosion in the number of SaaS settings
A SaaS setting is a discrete value within an application, most commonly a boolean/numerical value that can be customized to tailor application usage to fit preferences or security requirements. Some applications also allow users to create profiles overriding these defaults to manage access in a more granular fashion.
Global settings and local overrides can be misconfigured in a number of ways, including:
- An unaware system administrator trying to achieve a productivity outcome
- A new default can be set by the SaaS provider intending to enable a new capability by default
- An attacker hoping to execute a malicious outcome
Without a single standardized, and consolidated place to visualize and contextualize your SaaS settings—and changes that have been made to them over time—security teams can become extremely overwhelmed. After all, a complex platform like Salesforce has over 800 individual settings that can be set in the console or via the API, and Microsoft has several thousand!
“I’m really concerned that settings will either be changed by the IT team or by a software update by the SaaS provider. Recently, a critical setting was reverted back to an insecure state by a system administrator, publicly exposing data, we only found this out a lot later. I don’t want to have a member of the team having to watch consoles all day.” – Security & GRC Leader, Large Financial Services Company
What makes a SaaS setting security-related—and why does this matter?
Beyond the sheer number of SaaS settings that exist, there is a further distinction between settings that are and are not relevant to security posture. Making this distinction—and I’m speaking from the experience of our teams conducting this review themselves—is painstaking and mandraulic work. This problem is further exacerbated by continuous SaaS platform updates which seem to introduce settings at a breakneck rate.
In Salesforce, for example, there are settings that determine “which month does the financial year start” and “the default language of the system.” There are also more nuanced situations where settings that might not be strictly security-related may tangentially impact security posture. In Microsoft, there are non-security settings that impact data sharing and consequently may be “security relevant” to organizations with strict regulatory requirements around data privacy.
To help teams better understand their SaaS security posture and focus their attention on the settings that are most critical, Obsidian clearly distinguishes between security-relevant and non-security settings across applications. We also analyze the severity of each setting’s impact to help teams prioritize remediation efforts on areas with the most potential positive impact.
Customize your SaaS security approach with Obsidian
With the addition of customization as part of our next-gen posture release, organizations will have an unprecedented granularity and depth of control over their SaaS security posture. This is especially important for those businesses with strict internal policies and regulatory obligations as they extend those security requirements to SaaS.
Here’s just one example—in Salesforce, there is a setting to “enforce login IP ranges on every request” which forces users to remain at the IP address from which they originally authenticate. Our team’s guidance would typically be to set this as “true” as a powerful combatting measure against man-in-the-middle attacks. However, this setting can interfere with the mobile Salesforce application, and consequently, organizations that require this capability can elect to customize this value to “must be false.”
Again, the Obsidian recommendations informed by our extensive research and industry benchmarks aren’t going anywhere. Our customers have been incredibly clear about what a valuable foundation these insights provide from day one.
Still, the reality is that no two SaaS environments are the same, and your security approach should reflect that. So go ahead, customize settings in Obsidian to fit the unique needs of your team, your organization, and your industry. No matter what values you decide on, Obsidian will still assess them across every one of your tenants and monitor to ensure that they don’t drift over time. It’s just another way we’re empowering security, GRC, and application teams to make SaaS a safer experience.