3 R&D Security Practices to Adopt When Moving to SaaS

Are you planning to move your product from an on-premises offering to a SaaS model? If so, you should familiarize yourself with the new attack surface and readjustments required in your current practices before transitioning.

Based on my experience as head of R&D product security, I wanted to share some key security practices that I found significant to follow.

What has changed?

In the on-premises development architecture, the main R&D security focus is delivering the software with no vulnerabilities. From the moment the product is released, it is the customer’s responsibility to deploy it securely, and protect their perimeter.

The R&D developer’s focus is on the application security aspects, including training and following OWASP (The Open Web Application Security Project) best practices, awareness of the OWASP Top 10 threats (and how to prevent them), NIST Crypto standards, secure coding, threat modeling, adopting automated security tools in the CI/CD, etc.

In the SaaS world, your responsibility is much wider, and the focus does not start and end with creating the product. Rather you, as a service provider, are responsible for protecting the customer’s data in your environment and the deployment protection elements and ensuring you set the right infrastructure for various new threats, such as multi-tenancy potential leakage, public URLs, DoS and more.

In addition, your developers now probably are deploying applications to multiple cloud accounts as part of their dev environment, which, without the right awareness and protections, will significantly increase the attack surface of your environment.

If the emerging threat is clearer now, which practices are worth adopting?

Awareness first

Start by knowing what the new attack surface and threats are.

Your training programs for both R&D newcomers and your security staff should be adjusted accordingly. In addition to training around OWASP, cryptography, secure coding, etc., you need to cover additional topics like these:

• Make sure you have a clear policy for cloud development for the developers to follow, and the controls in place to monitor and enforce it (e.g., by eliminating public S3/security groups that may expose your resources, data or source code).
• If developing over modern architectures, such as serverless, you now need to know what the OWASP Serverless Top 10 mitigations are.
• Be aware of multi-tenancy potential leakage and how to plan your architecture accordingly (such: Different DB scheme, row based protection on the DB level, or any other approach that will help making sure engineers don’t make mistakes when working on a different tenant scope).
• Consider deployment threats (e.g., opening your application web interface to the internet and exposing you to various attack attempts), and enlist a WAF to protect it.
• Most importantly, you should adopt a cloud security framework, such as CSA CCM (Cloud Controls Matrix) for cloud security and privacy, to make sure you have the right security controls over your SaaS application.

Tighten your pipeline security

The SaaS transition also requires adjustments to the pipeline. Consider these practices:

Automated tools in the pipeline

In standard pipelines, you probably have security tools, such as SAST (Static Code Analysis), SCA (Software Composition Analysis for open source scanning) and DAST (Dynamic Scanning) integrated into your CI/CD.

Moving to a modern SaaS application will require re-adjustments of those tools, as well. One classic example is how the software is built. A SAST tool is based on a clear starting/ending point of the code to create a flow of “source” and “target” (sink) of a user input. That way, it raises a potential vulnerability as a result of the lack of user input sanitization.

In the SaaS modern architecture, you may have many serverless functions, and the flow is not as serial as before. This means you need to verify that your SAST tool still provides accurate findings, despite the architecture shaping.

Moreover, in a SaaS world, your releases to production are much more frequent. This requires that your automated security tools work in the DevSecOps spirit: earlier feedback to the developer of potential vulnerabilities in the IDE and pull request level before the upcoming check-in to the prod. If your current automated tools do not fit “developer first” experience or don’t have a high rate of real findings because you’re running over serverless architecture, you may need to look for alternatives.

Potential secret leakage

Transitioning to SaaS code management and version control tools, such as GitHub, GitLab, etc., to ship your code quickly and better collaborate on projects leads to an increase in the accidental publication of sensitive information like passwords, API keys, tokens and more. Consider combining automated tools that can detect secrets in your repos before checking in to the pipeline (e.g., GitLeaks). That will cause the pull request to fail if it finds a secret prior to the commit.

Monitoring and Reaction

Since your environment is probably extended over various cloud accounts, the attack surface of your environment and pipeline has expanded. So, it now requires a more careful definition of sensitive actions over the pipeline (e.g., trying to change sensitive security configuration on Jenkins) and adding alerts when it happens, along with a clear playbook to react to them.

Protect your deployment

This aspect must start during your developers’ work, and you shouldn’t assume that this is the sole responsibility of operations.

In SaaS applications, deployment is usually based on Infrastructure as Code (IaC), in which your deployment is based on automation code that may also contain security vulnerabilities.

Your developers and DevOps engineers also need to follow secure coding practices on programming languages. Some known secure coding platforms teach it in a gamification way. Make sure the one you choose includes IaC secure practices (for example Secure Code Warrior or SecureFlag).

Cooperation between the developer and the Operation team

Let’s take an even closer look at the importance of such cooperation. The following example will show you how, due to the developer’s work and mindset, you can catch an attacker red-handed in a replay attack scenario (when an attacker tries to intercept data and then retransmits it as part of a spoofing attack).

1. Your developers just added a protection against a replay attack in the code. They also know that if there is a replay attack attempt, then the application layer will write an error code “999”
2. An attacker attempts to carry out a replay attack; it fails, and the applicative log is populated with a new error code entry “999”
3. Applying a playbook for automatically responding to the replay attack event to the SRE/Operations team is another change the developer will make
4. The SRE/Operations team will trigger it by adding a blocking rule to the WAF for the source IP address from which the attack was initiated. In addition, this will trigger an event to the SOC team that there was an attempted replay attack

This applicative operation E2E mindset is a key practice in every feature you work on.

Fig.1 Red Handed attack due to developer’s awareness and early cooperation with SRE

Wrapping up

Moving your software from on-premises to a SaaS world requires a thorough R&D security practice adjustment. You should look at this as a holistic security view (a linked chain of aspects), starting from the application security layer, the cloud accounts your dev teams use, your pipeline security and the service security of your deployment.

It all starts with awareness and requires ongoing practice adjustments to the new reality.