By Venkat Rangan, CTO at Clari
A lot has been written about cloud applications and what an organization needs to do to protect their information assets when moving their applications to the cloud. The Cloud Security Alliance in their The Notorious Nine Cloud Computing Threats summarizes the threats to an organization when they sign up for a SaaS application or engage with a SaaS provider, but very little has been written about the steps a SaaS application provider needs to take to ensure that they meet the security needs of all their customers. In this blog, I examine a few considerations.
The SaaS Architecture Motivations
SaaS application providers have many options for architecting their services. Fundamentally, SaaS providers try and build their infrastructure so their costs for both initial provisioning of customers as well as on-going support are optimized. One way to achieve these goals is to implement a multi-tenancy model—where all the compute, storage and network infrastructure costs are shared across all their customers. Having a single image of software on a single pool of system and network resources means both initial infrastructure costs as well as software deployment costs, infrastructure scaling, and upgrade costs are shared across all customers. Also, having a single latest software version deployed for all your customers reduces support costs substantially, and makes it possible to reduce the “time to value” of the SaaS provider’s product investments. These benefits have been the primary driver for growth of the SaaS model of application delivery, which per Centaur Partners report, has grown by 29 percent in 2015. However, this rapid adoption of cloud technologies for software delivery comes with new and emergent security risks.
The following are some of the steps a SaaS provider can take to improve their security posture.
Industry Certifications
As a SaaS provider, consider getting your company and service certified through either the Service Organization Control (SOC 2) or ISO27001 organizations. These certifications ensure that your team follows well-established policies and procedures for ensuring that you are operating a secure environment. Following a checklist for a successful audit process will ensure that the right policies and procedures are in place. Also, establish a process for continuous improvement where security risks are identified and documented, and a remediation plan is put in place to address any security gaps. In addition to certifications, be prepared to share the results of audit reports.
If you engage a sub-processor or utilize another cloud service in providing your services, ensure that they are certified as well.
Customer Data Exposure
Take steps to minimize exposure of your customer data among your employees. This requires compartmentalizing the work of your employees into distinct responsibilities, so that each work area is dealing with only parts of the customer data, or in some cases, only data that is encrypted. As an example, the DevOps team dealing with backup, disaster recovery, and resource management should only be exposed to encrypted data, so it is technically not possible for this group of employees to access the data in the clear.
If there are individuals that need to diagnose business logic and customer data in the clear as needed, implement a “Grant Access” mechanism so your customers can explicitly permit your team to access the data. Any such mechanism should include a time range when such access is permitted, and every grant action should be properly tracked and logged.
Hardening Your Systems
Systems running your services should follow hardening principles. For Linux systems, ensure steps listed in Linux Hardening are followed. If services are based on Windows OS, follow procedures outlined in Windows Server Hardening. For virtualized environment, guidelines listed in Virtualization Hardening will be helpful. Also, establishing auto-updates of critical patches or, if controlled updates are in place, a quick automated way to update all systems with a patch-list is critical. Designing your service and system architecture to be resilient to partial updates, with some services leading the update cycle while others are catching up would make such rolling updates less painful.
Vulnerability and Threat Assessment
It is critical to set up vulnerability scanning at the network and application level to automate this process. Scanning tools, along with static code analysis, can alert your DevOps team to potential gaps in security posture that are waiting to be exploited. Some scanning solutions may need to be integrated into your Software Development Life Cycle (SDLC) process, so that any changes to your application environment are identified promptly. Also, be prepared to share these reports with your customers as proof of a secure information security environment.
Encryption Technologies
Where possible, enable encryption at all stages in your data pipeline—Data at rest, Data in flight and Data in use. Encryption at each level with strong key management practices helps reduce specific data security threats. Data at rest encryption helps in cases where entire data repositories fall in the wrong hands. Data in flight encryption prevents exposure of data via man-in-the-middle attacks. Data in use encryption mitigates risks of application delivery staff—both developers as well as DevOps teams—from accessing customer data.
Encryption at all levels comes with challenges in key management. As a SaaS provider, you need to be prepared to provide options for key management that satisfies your customer’s needs. Specifically, keys must be managed through an approved key management system with customer owning the keys. Manage per-customer keys, with you providing only the compute instance encryption engines, and your application securely retrieves keys from your customers. Once keys are retrieved, they are used only within the context of the application and are disposed of when usage is completed. This also provides added benefits to your customers such as granting access only to authorized users in their organization. Also, this allows them to revoke the keys when they no longer need the services, and for deprovisioning the application without having to worry about their data getting in the possession of adversaries. Of course, this approach can offer technical guarantees that you as a service provider can make to your clients—that you have no way to decrypt the data.
Client-side encryption is a way for your customer to first encrypting the data before it is sent to your SaaS application. While client-side encryption is attractive, it may not be practical—in many cases, only token-level encryption is possible on the client side. If your application delivers business logic and is unable to deliver value when data is not in the clear, you may not be able to offer client-side encryption. A good alternative is client-owned keys which will be only be used by an encryption engine in your application.
Multi-tenancy Considerations
Cloud technology benefits are best realized when your SaaS infrastructure and application components manage multiple customers using a single instance of the infrastructure. Having a single set of servers running the same version of software greatly simplifies application upgrades and application delivery. Having a database instance with a common schema across all customers makes it easier to deliver key software innovations and features—without great investment in managing multiple schema and database versions. Also, having a single instance means you can add and provision new customers without much friction. However, the multi-tenancy model introduces new challenges for both maintaining security as well as proving to customers that data does not leak from one customer to another. Co-mingling of customer data in a single environment would have been unthinkable a decade ago, but is now fairly common.
In a multi-tenancy model, consider adding security features that would prevent accidental data leakage from one customer to another. Also add features that would prevent one customer either accidentally or with intent attempt to access another customer’s data. One common technique is to offer per-customer encryption keys, and ensuring that data at rest, owned by one customer, is never exposed to another customer. For preventing data in use (which is often based on decrypted data), consider using strong session-to-customer mapping where the customer is identified by an organization or tenant identifier, which is closely tied to user session. Any request-response pattern using sessions will need to implement strong software-based matching of sessions to their tenant identifier and reject any mismatched access. Another frequently used option is to use a separate virtual instance or virtual container for each customer. Container technologies allow the cloud provider to deploy a container for each customer at low cost. In this model, every data access and usage by data encryption engine as well as all business logic is limited to only the customer assigned for that specific container.
For co-mingled data in a database instance, consider architecting database hardening at the SQL-driver level that can introduce tenant identifier as a mandatory query filter criteria. Data hardening also includes avoiding any possibility of SQL injection where any legitimate user is prevented from injecting another tenant’s identifier in their queries.
Provability of effectiveness of security features that prevent data leakage in a multi-tenancy model is an important consideration. Per-customer encryption keys, managed by the customer, along with per-customer containers are much more provable than other architectural approaches. Unalterable logging of data-access activity is yet another way for SaaS provider to establish provability.
SLA Agreements
Another aspect of SaaS applications that need consideration in conjunction with security is service level agreements. In addition to the standard availability guarantees, consider including SLA components for any compliance related activity. As a SaaS provider, minimize the need to implement compliance-related SLA provisions. As an example, avoid the need to have to electronic-discovery related compliance by getting them to be out of scope from your SLA agreement with your customer.
Cloud Infrastructure
Leverage a proven public cloud provider. Use their security infrastructure such as network firewalls (security groups) and intrusion detection systems. The network layer can provide significant protection from man-in-the-middle attacks using its public-private key infrastructure, port scanning and secure endpoints. Even more useful are built-in monitoring systems that can alert to an in-progress security threat such as repeated login attempts, cycling through large user credentials, or denial of service attacks (which often manifest as performance degradation). In conjunction with other cloud-based log analysis products, you may be able to identify a developing attack before it becomes damaging.