Skip to main content

SaaS Deployments: Security Checklist for Cloud Services

Author Security Compass

Cloud security in SaaS

The benefits of Software as a Service (SaaS) to vendors and customers are clear. Buyers have fewer applications and infrastructure to manage and can easily scale licenses up or down. For vendors, deployments are simplified, and keeping all users on a common version makes support easier.

Just as there are different security considerations when choosing a SaaS application, building these also warrant different considerations.

Compared to an on-premise deployment, SaaS applications can be more easily reached by hackers.

SaaS applications often call for a DevOps or Continuous Integration/Continuous Deployment (CI/CD) development approach to support more frequent updates. Further, while you alone will be responsible for the security of the application you build, based on the Cloud Service Provider (CSP) and deployment model you choose, you may not be managing all the hardware configurations in your SaaS deployment, including operating system patches. 

SaaS deployments bring new risks

Moving applications from on-premise to SaaS deployment brings a different set of risks to all organizations.

First among those is the fact that a user’s sensitive data will be stored in the SaaS provider’s data center — often in multiple geographic locations to enable high availability. Access to these data stores should be tightly controlled, but with estimates that 6 percent of Google Cloud buckets are misconfigured and vulnerable to unauthorized access, SaaS vendors should be prepared to provide evidence of compliance with good security practices.

Regulatory requirements for SaaS vendors

For organizations building SaaS applications, it is important to remember that using a cloud service does not relieve one from regulatory compliance.

Just as a cyber insurance policy requires organizations to ensure its vendors maintain minimum required security practices, regulatory obligations cannot be transferred to a cloud provider.

This means understanding all external requirements (and internal security policies) covering an application when selecting a cloud provider with whom you will share responsibility for managing and securing the cloud infrastructure.  

Inject security into development from the start

Security testing tools like static and dynamic analysis are helpful for finding coding errors that result in exploitable vulnerabilities. However, building secure applications for the cloud isn’t just about testing. It requires starting with a secure design, ensuring that DevOps and security teams know exactly what tasks are expected of them.

secure coding for developers

Because security roles are shared with the cloud provider, it is critical to identify requirements and threats before starting development. This includes understanding the information managed by the application, including any regulatory standards or internal policies covering the application. Only after these are defined is it possible to evaluate the cloud providers’ capabilities and controls.

DevOps and security teams must next understand the technology stack of the application and enumerate the threats inherent to the application’s programming language, frameworks, and deployment environment. This exercise allows security and development to identify the controls required to mitigate risk from these threats.

Once controls are detailed, tests to validate the proper implementation of those controls must be defined and assigned to development, QA, and security. Keep in mind that some controls like WAF rules may be assigned to operational security teams.

Considerations to ensure cloud security for SaaS applications

While a cloud provider can provide assurances on certifications for their facilities, SaaS vendors must be prepared to answer questions from customers regarding security controls for applications. These include:

  • Identity management and authentication: Users will not always access a SaaS application from an organization’s network. Provisioning and de-provisioning users can be time-consuming and prone to error. DevOps and security need to decide whether to use single sign-on and federated solutions in addition to password strength requirements, timeouts on login failures, and password reset protocols.
  • Encryption and key management: Software customers will naturally expect data to be encrypted in transit. SaaS customers will also expect encryption of sensitive data at rest. Since the data is stored at facilities not controlled by the customer, teams should also consider offering customers the ability to control their keys so that vendor and data center personnel cannot access sensitive data.
  • Logging: Security and DevOps will want to maintain detailed logs on all interactions with the software. This helps ensure performance SLAs, of course, but also can provide evidence in the event of a malicious insider. 
  • Ensuring isolation: Most SaaS applications are multitenant, eliminating the need to spin up a new instance of the application for each customer. Multitenant users worry that an error or attack on one customer or the application could also expose their data. Software architects, security, and operations need to agree on an isolation model that works best for their capabilities.

Balance speed with security

By identifying threats and controls in advance, development is accelerated. When secure coding standards and regulatory controls for each application are defined for development, QA, and security, vulnerabilities are avoided and remediation costs are reduced.

Want to learn more? Read our whitepaper on taking a security-first approach to cloud applications.