Managing SaaS Security Risks: Beyond Compliance and Into Reality

Security is not a tax

In numerous Request For Proposals (RFP) and negotiations, I've grappled with selecting the ideal SaaS solution to meet our business needs. There is no escaping it, every company likely has hundreds of SaaS solutions to run its business. This simple fact astonishes many compliance and regulatory officers:

How do we manage the risk of transferring critical and sensitive data to external entities?

That’s a valid point, but many harbor concerns about the wrong facets of SaaS externalization. The prevalent fear is a data leak from a hacked SaaS provider, potentially threatening their business. In response, they seek various assurances like SOC 2 reports, ISO certifications, security questionnaires, and security assurance plans.

But, at the end of the day, the fact of the matter is that it’s impossible for an external company to really assess the security of a provider. Security questionnaires are a joke, no matter how thorough they are. Vendors will spin, lie, omit and probably sell their employees’ kidney to land that contract. ISO certification and SOC 2 are an exercise in futility and have no bearings on the flaws actually exploited by attackers (more on this here). Pentest reports presented by the SaaS company have been curated, tightly scoped and stripped down from their essence before sent to a prospective customer.

The only way to even hope for an albeit partial assessment of a vendor’s security is to perform yourself a regular full-scoped audit with an iron-clad contractual requirement to fix all critical vulnerabilities within a reasonable timeframe. This might be feasible for a handful of critical SaaS providers, but it's impractical for the vast number a typical company employs. Very few, except perhaps major corporations, can demand such intrusive audits. Imagine requesting full access to Salesforce's data centers for an audit.

So what can companies actually do?

The premise of this article suggests that the risk of a SaaS provider being hacked isn't the most probable threat. It’s much more likely that your own employees will get phished, use a weak password, have their computers hacked, go rogue and so on, and that the attacker will leverage this access to dump every data on every SaaS they get access to.

That’s your primary risk. Deal first with that one, before turning your attention to how Tableau, AWS, Snowflake, GitLab, or whatever SaaS you use will get hacked. A contractual clause holding SaaS providers accountable for damages resulting from a security breach might be the most pragmatic approach until unauthorized access issues are addressed.

Before you jump to my throat screaming in denial, please let me emphasize the nuances of my argument. For most companies, the risk of unauthorized access to a SaaS is likelier than the compromise of said SaaS company, and therefore deserves attention first. Especially since there is no easy way to objectively assess the security of said provider.

Yes, there are attacks that go after providers—LastPass, Sequoia and others come to mind—but, any of these companies would have and in fact did clear the security requirements of many strict corporations, and secondly, statistically, for many companies, the attacker first tries to go after the company itself, before taking the long detour of going through a SaaS provider that may only offer partial access to the data they’re after.

If this probabilistic equation holds for the company’s context, then it’s much more effective to focus your energy on the risk of unauthorized access, and shield the company from the risk of SaaS compromise through legal terms¹.

Now, what do we actually need to reduce the risk of contracting a SaaS provider? There are many essential security features on the top of anyone’s mind, but I would like to focus on two important ones that are often downplayed or overlooked²:

• Single Sign On integration

• Audit logs

Let’s dive into each one

Single Sign On integration

Every company should arguably invest in a Single Sign On solution³, a central authentication platform to manage their employees’ and contractors’ access. The benefits of a properly configured SSO portal far outweigh its risks—I explore this tradeoff in my book Blitzscaling Security if you’re interested.

The first thing one should expect from a SaaS provider is that they support the delegation of authentication to an SSO system. Users should not be bothered to create a new password for every new SaaS: upon arriving at the login screen of the SaaS, they should be automatically redirected to the company’s central authentication system (SSO) and be granted access following the completion of that step. This delegation of authentication typically involves the SAML or OpenID protocols.

It’s probably the most important security requirement of all when it comes to SaaS externalization. One that significantly boosts the company’s defenses.

See, not all SaaS enforce a strong password policy or implement a password reset after suspicion of compromise. An even lower fraction supports two-factor authentication. Do not even think about WebAuthn and physical security keys, anti-bruteforce, credential stuffing and so on. Authenticating users in a secure fashion that defeats phishing and credential stealing has more to it than meets the eye.

Similarly, all the account management duties will have to be performed manually: account creation, revoking access to offboarded employees and granting access depending on job function. Multiply these tasks by a hundred, and one inevitably ends up with old, forgotten accounts on a payment platform that can wire thousands of dollars.

By plugging the SaaS provider to a decently configured SSO, we defacto get all the features mentioned above and therefore neutralize entire classes of vulnerabilities and attack pathways: from credential phishing to generic accounts. It’s THE requirement that drastically reduces the risk of unauthorized access to your data. Imagine the attacker lucking out on an employee’s password, but not being able to use it on any tool that matters because the SSO, thanks to WebAuthn, requires a poof of proximity before allowing access (Touch ID, YubiKey, Passkey, etc.).

An SSO in front of all the critical SaaS acts as a wonderful first protection layer against many attacks. Again—I cannot stress this enough—provided the SSO is well configured: 2FA WebAuthn-only, HR integration to receive employee attributes, automatic access based on job function, granular permissions to admins, and so on.

The rub, however, is that providers, in a sheer feat of madness, double or triple the license fee to offer an SSO integration—a phenomenon accurately captured by the SSO wall of shame. Such a lose-lose strategy. One would think that vendors would push their clients to use the most secure configuration. After all, when a data leak happens, it’s both the vendor’s and the customer’s names that share the headline—AWS learned this the hard way after one too many S3 bucket leaks… Yet, we have vendors that give the core and complex features for free and force companies to pay for a SAML integration that can be developed in 1 week.

Audit logs

If you have good negotiation skills and are willing to spend a little money, you can get pretty far in the SSO coverage. Most companies can reasonably aim for a 75% coverage of all their important SaaS tools. Audit logs however, are another beast altogether, which is quite puzzling given how simple the requirement is:

Programmatically export activity logs to an external storage: who did what from where

Yet so few can provide it.

A company, any company, should monitor what is going on their information system. The first step in the NIST framework is called “Identify” for a reason: the company must have full visibility on who does what to be able to qualify what is “normal”. Only then can they hope to detect abnormal or suspicious behavior, often indicative of a breach. The attacker will try to blend in the regular traffic, but there will always be subtle clues they leave behind:

• they’re enumerating more objects than regular users

• they’re exporting more data than usual

• they’re using different request attributes (user agent, IP address, etc.)

• they’re using a python/ruby script instead of the tool commonly used by admins

• they’re getting more errors than usual

• etc.

Audit logs should contain detailed information about user’s activity to allow companies to identify normal traffic characteristics and build proper detection rules that weed out any unusual traffic and alert on it.

The sad reality, however, is that the crushing majority of SaaS providers make it difficult, neigh impossible to export these logs automatically (e.g., through an API, or by streaming them to AWS S3). The very few that have any kind of logging impose several constraints: Notion⁴ does maintain an audit log history, but it’s only visible through their own UI, making it useless as a detection mechanism. Others don’t include all the request attributes (e.g, user agent, IP address, email address, etc.), crippling any clever detection rule the company wants to implement.

Look at this sad example: Tableau allows exporting logs if you pay them enough, but this is what you get:

 {
    "actorExternalId": "bca23fd7-7e76-4580-a23e-eaa573f91b31",
    "actorUserId": 687978,
    "eventTime": "2023-08-10 20:23:11.987Z",
    "impersonatedUserId": "10a53de7-8886-4a27-8b63-6dd7067a8500",
    "siteLuid":"b862610b-a49f-4bab-a5e5-9dd1f83c5a84",
    "eventType": "hist_login"
 }

What the hell exactly is this? A bunch of obscure IDs that barely describe what happened, let alone allow decent for detection measures. How can any company make sense of this data, to, for instance, alert when a hacker impersonated an employee?

In this sea of depression, there are however some good players who are worth mentioning, if not only for inspiration and guidance as to what constitutes a good audit log: Launchdarkly, AWS Cloudtrail, Salesforce and 1Password to name a few.

Hopefully, more and more customers requesting an export of audit logs will push vendors to develop or hone this feature, but in the meantime, fight like hell during contract negotiation to ensure you get access to logs or get a release commitment.

Closing thoughts

There are additional security features one should expect from a decent SaaS provider: granular permissions, admin notifications, approval scheme, IP whitelisting for service accounts, and so on, but I wanted to specifically focus on two features that I deem to be basic, yet personally frustrate me in any SaaS negotiation.

If one can achieve a WebAuthn-only SaaS approach, one effectively kills the most prevalent attack scenarios, namely credential phishing. If one has decent detection, then as soon as the attacker starts their reconnaissance phase or exploring more data than usual, they get busted and booed out of the tool.

These features empower companies to secure their environments and should be included by default in every paid licensing tier. Hopefully, one day we will get there.

1. Should you do both? Send security questionnaires, ask for security certifications, and address the risk of unauthorized access. Yes, of course you can. But if you spend 20h a week going through security questionnaires while employees connect to your SaaS with a 6 character password, then you’re misallocating your resources.

2. You’ll notice that I am specifically talking about SaaS providers only. Not providers that establish a direct connection to the infrastructure: a VPN connecting two services, etc.

3. A quick explanation of how SSO works is available here https://www.onelogin.com/learn/how-single-sign-on-works

4. I do hear that Notion is currently toying with a feature to stream logs to a SIEM