Not All Sandboxes Are for Children: How to Secure Your SaaS Sandbox

When creating a Sandbox, the mindset tends to be that the
Sandbox is considered a place to play around, test things, and
there will be no effect on the production or operational system.
Therefore, people don’t actively think they need to worry about its
security. This mindset is not only wrong, but extremely
dangerous.

When it comes to software developers, their version of sandbox
is similar to a child’s playground — a place to build and test
without breaking any flows in production. Meanwhile, in the world
of cybersecurity, the term ‘sandbox’ is used to describe a virtual
environment or machine used to run suspicious code and other
elements.

Many organizations use a Sandbox for their SaaS apps — to test
changes without disrupting the production SaaS app or even to
connect new apps (much like a software developer’s Sandbox). This
common practice often leads to a false sense of security and in
turn a lack of thought for its security implications. This article
will walk you through what is a SaaS sandbox, why it is vulnerable,
and how to secure it.

Learn how you can gain visibility and
control over your SaaS sandbox and app stack.^[1]

Cybersecurity & SaaS Sandbox Fundamentals

A cybersecurity sandbox allows separation of the
protected assets from the unknown code, while still allowing the
programmer and app owner to see what happens once the code is
executed. The same security concepts are used when creating a
SaaS Sandbox — it duplicates the main instance of SaaS
including its data. This allows playing around with the SaaS app,
without influencing or damaging the operational SaaS — in
production.

Developers can use the sandbox to test the API, install add-ons,
connect other applications, and more — without worrying about it
affecting the actual users of the organization. Admins can change
configurations, test SaaS features, change roles, and more. This
allows the user to better understand how the changes to the SaaS
will go before implementing it on an operational, and critical,
SaaS instance. This also allows time to create guidelines, train
staff, build workflows, and more.

All in all, using a Sandbox is a great concept for all software
and SaaS usage; but like all great things in the world of SaaS, the
problem is that there is a major security risk lurking within.

Sandbox Security Real-World Risks & Realities

A large private hospital inadvertently revealed data of 50,000 patients^[2] when they built a demo
site (i.e a Sandbox) to test a new appointment-setting system. They
used the real database of the medical center, leaving patients’
data exposed.

Often a Sandbox is created using real data, occasionally even a
complete clone of the production environment, with its
customizations. Other times, the Sandbox is directly connected to a
production database. If an attacker manages to penetrate the
Sandbox because of lax security, they will gain access to troves of
information. (This leakage of information can be problematic
especially if you are an EU company or processing EU data because
of GDPR. If you are processing medical information in the USA or
for a USA company, you can be in violation of HIPPA.)

Learn how an SSPM can help you automate
the security for your SaaS sandbox.^[3]

Even organizations that use synthetic data, which is recommended
for all companies, can still be at risk for an attack. An attacker
can use the Sandbox for reconnaissance to gain insight on how an
organization sets up its security features and its possible weak
spots. Since the Sandbox reflects to some degree how the
operational system is configured, an attacker can use this
knowledge to penetrate the production system.

How to Secure Your SaaS Sandbox

The solution for the problem of the non-secure Sandbox is rather
simple – secure the Sandbox step-by-step as if it was a production
system.

Step 1. Manage and control access to a Sandbox
and limit users’ access to the Sandbox. For example, not every user
that has access to production should also have access to the
Sandbox. Controlling which users can create and access a Sandbox is
the first step for keeping your SaaS environment secure.

Step 2. Implement the same security settings
that are configured within the operational system to the Sandbox
version; from requiring MFA to implementing SSO and IDP. Many SaaS
apps have additional security features that are tailor-made for
that specific SaaS app and should be mirrored in the Sandbox. For
example, Salesforce has unique security features such as: Content
Sniffing Protection, Default Data Sensitivity Levels,
Authentication Through Custom Domain, and so on.

Step 3. Remove production data and replace it
with synthetic (i.e., made up) data. Sandboxes are typically used
for testing changes in configurations, processes, flows (such as
APEX), and more. They don’t require real data for testing changes –
any data with the same format can be sufficient. Therefore, avoid
copying the production data and use Data Mask instead.

Step 4. Keep your Sandbox inline with security
improvements done in the production environment. Often a Sandbox is
neither refreshed or synced on a day-to-day basis, leaving it
vulnerable to threats that were minimized in the production. To
reduce risk and to make sure your Sandbox is serving its purpose, a
Sandbox should be synced every day.

Automate Your SaaS Security

Security teams can also implement and utilize SSPM (SaaS
Security Posture Management) solutions, to automate their SaaS
security processes and address the challenges detailed above, to
monitor and prevent threats from infiltrating the SaaS sandbox.

An SSPM, like Adaptive Shield, comes into play to enable
security teams to identify, analyze, and prioritize
misconfigurations in the Sandbox and across the whole SaaS app
stack, as well as provide visibility to 3rd party apps with access
to the core apps, Device-to-SaaS User posture management and
more.

Explore how to automate security for your
Sandbox and SaaS app stack.^[4]

Note: This article is written by Hananel Livneh,
Senior Product Analyst at Adaptive Shield.