There’s a dangerous assumption that can be made to justify a migration from on-premise information technology (IT) to hyperscale cloud: “The cloud provider’s massive investments in security will keep us safe from evildoers.” Nothing could be further from the truth! To quote the great management theorist Mark Twain, “It’s not what you don’t know that gets you killed; it’s what you know that just ain’t so.”
It’s obvious that an infrastructure-as-a-service (IaaS) deal, where you license server, storage, and network capacity from a cloud vendor and use this infrastructure to craft your own solutions, leaves your internal IT and security on the hook for cybersecurity (while the vendor handles physical security within their facilities).
It’s perhaps less obvious that licensing software tools from your cloud vendor in addition to infrastructure (called PaaS or platform-as-a-service) still leaves your CIO and CISO on the hook. Having your infrastructure vendor also provide and maintain products like databases and other utilities has benefits to be sure: The tools are compatible with the cloud infrastructure, and they’re maintained for you by the cloud vendor. While that improves time to value and reduces technical debt, it does nothing to help with your security. To quote an actual computer scientist, Grady Booch, “A fool with a tool is still a fool.”
So, what about the top level of the cloud abstraction pyramid, software-as-a-service (SaaS)?
The Elements of Proper SaaS Security
In the SaaS model, you license applications, or even suites of applications, from the cloud vendor without any responsibility for overseeing where the applications actually run. SaaS apps are typically licensed by the seat (or named user), by the transaction, or by the device — in other words, SaaS is less focused on inputs (i.e., speeds and feeds) and more focused on business value. Does that makes SaaS a cybersecurity paradise where the vendor just “makes it so”? Hardly!
But the good news is that a well-designed SaaS application should provide a careful CIO and CISO with the tools necessary to create an adequately secured application stack. However, the two earlier quotes still apply!
So, let’s consider the elements of proper SaaS security.
Element #1: A Secure Foundation
I have a T-shirt that reads, “There is no cloud; it’s just someone else’s computers.” It’s funny, but true. The SaaS applications you license are run atop a complex web of interacting components, from the discrete central processing units (CPUs) and solid state drives (SSDs) and network switches, to the physical data centers that house the components, to the processes by which the data centers are operated, to the people recruited and trained and overseen to maintain and operate the datacenters. A hyperscale cloud environment is an amazingly complex assembly of hardware, software, and process components: millions of servers spread across dozens of data centers worldwide.
Since you, as a client, can’t vet the interconnected whole, start by identifying independent certifications relevant to your industry, geographic footprint, regulators, clients, and investors (and increasingly to your insurance underwriters). I can’t list every standard that might apply to you, but here are a few standard certs: Service Organization Control (SOC) 1/2/3; Statement on Standards for Attestation Engagements (SSAE) 18; International Organization for Standardization (ISO) 27001; Health Insurance Portability and Accountability Act (HIPAA); Payment Card Industry Data Security Standard (PCI DSS), National Institute of Standards and Technology Cybersecurity Framework (NIST CSF) and other NIST standards, and on and on.
Conclusion #1: Picking the relevant standards isn’t the SaaS vendor’s job: That’s on you. Be sure you include all relevant stakeholders and obtain their buy-in.
Element #2: Zero Trust
SaaS application suites like enterprise resource planning (ERPs) and electronic health records (EHRs) operate on the organization’s most valuable commodity: data. Accidental or unauthorized addition, deletion, alteration, or disclosure of information can be anything from annoying to embarrassing to expensive to ruinous. So, security design must make it easy for appropriate/approved operations while making it difficult/expensive for anything else to be done. That’s the essence of “zero trust”: If something isn’t explicitly permitted, it just can’t happen.
When designing your SaaS structure, it’s vital to define two concepts and their interactions:
- Roles: Defining operations allowed by each class of users (subsets of employee, partner, customer, even device and — someday soon — artificial intelligence) when doing a particular function (inputting a new customer, loading a truck, paying an invoice, etc.)
- Data elements and data sets: Classifying every kind of data in terms of sensitivity (access level) and allowed operations (e.g., can we delete the collection of data that defines an employee vs. changing an employee’s status)
In traditional security models, a named user (“Wayne”) might have access to specified data (“payroll”). That allows lots of room for mischief and mistakes because a) every employee is defined individually and b) their access to data is far too broad.
Example: Wayne may do several tasks. As a “timekeeper,” Wayne can input hours for existing employees. As a “project manager,” Wayne can create and modify project steps but not delete existing steps. Using zero trust allows us to define roles and assign them to people (or things), where a role has just enough access to data to accomplish the specified task.
Conclusion #2: A SaaS product should be built to implement zero-trust concepts. More importantly, your organization must do the work (and it’s serious work!) to implement and maintain your specified zero-trust rules.
Final Thoughts
A well-designed SaaS product running on a secure foundation allows the CIO and CISO — along with the rest of your risk-identification and mitigation experts — to design and operate a secure yet productive application. Leave out either step and you put the organization at risk!
