How secure is that cloud application service?

Try to imagine life without software as a service (SaaS). It’s really hard to do, given how much all of us –businesses, organizations and individuals ­– rely upon these cloud applications services nearly every day.

The more dependent we have become upon SaaS apps, the more important it is to be aware of their liabilities. That was the point of this previous article. One of the areas I mentioned there — security, governance and compliance — deserves a closer look. Life without SaaS may be farfetched, but it’s easy to picture at least one, in a landscape of many apps, being compromised or running afoul of rules and regulations.

We are all CISOs now

Most users of Office 365 or SalesForce or Slack, or any other SaaS app, engage via the software to get their work done. But they also generally have control – and lot of control in some cases ­– over settings. Something that would have been previously handled by an IT Admin. They also might have influenced, or have even made, the decision to sign up for an app in the first place.

In other words, in addition to using SaaS apps, end users have also assumed roles in assessing and administering them. This shows how the “democratization of IT” has not only put technology into more hands, but it has also expanded responsibilities. In many ways, we all need to be virtual CIOs now, if not virtual CISOs.

In the remainder of this article, I will raise some basic questions about the security of SaaS apps. In particular, authentication, encryption and administration. In a follow-up article, I will discuss the security profile of SaaS companies and more about their own infrastructure.

Authentication options

The SaaS security topic closest to end users is passwords and authentication, but the challenges are numerous. Users not only continue to be careless; they have reason to be confused. For example, it turns out the original rules around creating a secure password no longer apply. The man behind that standard now “regrets wasting your time.”

Password managers can be a good way to create and manage long passwords, which are now recommended, although it does not inspire confidence to know that at least one leading provider of this service has been hacked. In any case, no one contends that passwords alone suffice.

Two-factor authentication (2FA) uses a second step, commonly sending a validation code to a separate device. But there is some debate about how best to implement this approach. The U.S. Government, for instance, discourages the use of SMS for authentication.

Then there are additional factors, such as biometrics (see Windows Hello in Windows 10) or geographical markers, which can reinforce authentication and trigger alerts for anomalous log-in activity. Strong authentication is also associated with encrypted channels, hashed passwords, event monitoring and other advanced techniques.

So what kind of authentication does your SaaS provider use? Two or more factors? Do they enhance password security in other ways? How do they facilitate single-sign on (SSO), or federated authentication, to multiple applications?

Encrypting and protecting data

Another area of concern is what happens once you – and your data ­– are engaged with an app. So how does your SaaS provider handle data in-transit, in-use and at-rest?

Traditionally web companies have used secure socket layer (SSL) for communications. Actually, the IETF deprecated SSL in 2015, with Transport Layer Security (TLS) 1.0 supplanting SSL 3.1, but the ‘SSL’ tag has stuck, often representing both standards. A website that has implemented these cryptographic protocols is marked Secure HTTPS (HTTP within SSL/TLS), which should be table stakes for any SaaS app.

If your SaaS provider is like many cloud-based companies, they could be using a multi-tenancy architecture, meaning that your data will most likely end up adjacent to someone else’s data. What types of encryption are used and how granular are the controls? And then, whatever the architecture, how do they back up, replicate, store and restore your data? 

Another set of issues concerns the type of data. The data breaches that receive most attention involve the release of Personally Identifiable Information (PII), a category that is increasingly subject to government regulation and receiving lots of attention with EU’s General Data Protection Regulation (GDPR). So, in addition to encryption, how else is your SaaS provider preventing the loss of PII and sensitive data?

Admin, policies and governance

The topic of data loss prevention (DLP) overlaps with the issue of user controls, because data can be exposed inadvertently through incorrect settings. End users can get started on most SaaS apps with minimal (or no) training, but given the potential for damage, that’s quite possibly not a good practice.

Even if end users had to acquire the equivalent of a driver’s license, it’s always good to limit the potential for human error. Smarter apps – or management overlays – can be helpful in tagging and locking down PII.

Administrative roles are another issue with security and compliance implications. Limiting privileged access is a good general practice, but it’s a special focus for GDPR. A well-architected app should also facilitate the adding and deleting of accounts. In that regard, you might see if your SaaS provider has leveraged the System for Cross-domain Identity Management (SCIM), an open standard that automates the exchange of User IDs.

A few final policy-related questions for your SaaS provider: Can they limit login to designated IP ranges aligning with your corporate network or VPN? Do they allow you to manage the app’s availability on mobile devices? Are there adjustments for session timeout thresholds?

Not just for cybersecurity ninjas

While some of the questions above may seem basic, you never know. See this "Taming the SaaS security wilderness" by security manager “Mattias Thurman” (a pseudonym), who describes the “nightmare” of discovering the risky use of a highly insecure collaborative SaaS tool, a free app that had been introduced to the corporate network by one of his company’s engineers, no less.

You might think that only cybersecurity ninjas can grasp what’s key, but that’s not true. One goal here should be demystifying the topic. It’s in the interest of everyone ­– app makers, end users and third-party providers ­– to see that ownership in cloud application security is a holistic and ubiquitous responsibility.