X-ray your SaaS apps to reveal hidden security vulnerabilities

As the founder and CTO of a public cloud hosted archiving service, I have unique insights into SaaS applications, how they are architected, and security evaluation frameworks CIOs should use to understand the security posture of their favorite SaaS applications.

My project began 11 years ago at the beginning of the public cloud era, and over the years evolved SaaS data and application security theory and implementation. As a whole, the technology providers in the cloud / SaaS ecosystem have matured quickly compared to PC and networking security eras. The cloud / SaaS vendors treated data and application security as a “first class” need to overcome IT buyer fears about replacing on-premises software with a SaaS alternative.  

This article is written for the technology leader interested to understand what is happening “under the hood” of cloud / SaaS.

Security evaluation frameworks

Every cloud / SaaS technology buyer should be acquainted with a few “trusted” security evaluation frameworks. These should be public domain, well vetted, and not influenced by the industry vendors.

FedRAMP and NIST-800-53 are two examples of known security evaluation frameworks that act as a “best practices” seal of approval for cloud and SaaS apps.

Technology vendors must clear a high-bar to achieve FedRAMP status. And what that means is the vendor’s collection of software, infrastructure, policies and procedures is evaluated against the NIST 800-53 assessment checklist of over 150 controls related to software architecture, security controls, encryption methods and policies ranging from change management, business continuity and security training. All criteria is then audited by a trusted third-party to ensure the vendor is actually operating true to their word.

The Enterprise Ready Framework (https://www.enterpriseready.io/) is another project allowing SaaS vendors to self-audit and report their status on areas such as single sign on, audit logs, role based access control, change management, product security and GDPR readiness. There is no independent auditing function, but rather a best practices checklist SaaS buyers can use to compare vendors or ask vendors not listed how they implement over 12 different best practices.   

Layers and responsibilities

Software as a Service (SaaS) can be delivered in two ways: Hosted from a dedicated environment or hosted from a public cloud. This article focuses on SaaS hosted on public cloud infrastructure (IaaS) since it’s the most interesting and challenging scenario from a security perspective.

SaaS buyers should think about security in the following ways:

1. How is my data stored in the system “at rest?” For many SaaS apps this means the information typed into browser screens, collected from APIs, or derived from routines acting on the inputting data. This data is typically stored in databases, cloud object and block files.
2. How is my data handled during processing? This means the various memory caches, processing queues and log files that make up today’s typical SaaS application.

Data at rest is where the bulk of your information lives. This information should be encrypted, and access controls locked down. None of this information should ever be exposed to the Internet in clear text. Most SaaS vendors do a good job to protect data at rest. Occasionally we hear about data breaches and a common post-mortem reason is the vendor didn’t lock down a database or cloud storage account from direct, un-encrypted access. These types of exploits are becoming fewer over time as the industry learns from each prior failure.

Data during processing is where the SaaS industry can do better. As data flows through a SaaS application stack, think of the information flowing “through the pipes”. SaaS customers should never see this data exposed and you want to ensure the SaaS vendor implements best practices not to expose customer data via “leaky plumbing”. This means no passwords in log files. No cloud secret access keys in vulnerable memory caches. All servers have the latest patches. No PII copied to a public gist.

At the beginning of the cloud era it was difficult to describe security for a SaaS application hosted on public cloud. The best practices security checklists of the time didn’t fathom a time when applications would be created by one vendor and hosted on infrastructure operated by a different vendor.  

A public cloud hosted SaaS application inherits the underlying security from the IaaS provider. Major cloud vendors such as Amazon, Azure and Google Cloud now publish their security assessment checklists so that the SaaS vendors hosting applications on the respective cloud can incorporate the security controls into their own policies and procedures, thus allowing the vendor to describe a complete system for auditors to understand the various layers and responsibilities.

The SaaS vendor should amplify (via their software) the security layers exposed at the IaaS layer, not weaken the inherited security.

X-ray your SaaS app from the browser

Two free browser-based tools can help the SaaS buyer understand how their SaaS applications work.

Whatruns.com is a Chrome or Firefox plug-in that reveals the technologies used in a web application. This is useful to learn about the application’s underlying services, which third-party vendors may be involved, and how the application is constructed.

StackShare is a crowd-sourced comprehensive database of technology and architectures for the many popular web services. Search for a vendor’s profile and learn about the components used to power the service. You will start see common trends across database, queuing, firewalls and security.

 Cloud and SaaS security is a pretty good now and getting better. The industry is learning and adapting quickly to ever changing threats and implementing best practices to ensure a strong security stance.

Third-party assessment frameworks provide best practices on how to secure sensitive customer data stored in cloud applications.

Customers have new tools and to help understand more about their SaaS apps and can keep vendors accountable to operating secure systems.