In the first article of our series, we discussed securing a private cloud via micro segmentation in detail. This time we’ll be talking about Software as a Service (SaaS) and compared to SaaS, securing the private cloud is child’s play.
For a private cloud you could say that you have everything in your own hands. The opposite is true for SaaS. Compare it to baking a pizza. In the first case, you prepare the pizza from scratch. You make the dough and you bake the pizza in your own oven. You therefore know exactly what goes in the pizza and you’re the only one who can reach it.
In the other case, you take a carton of pizza flour to the pizzeria and ask them to bake the pizza for you. Ofcourse they’ll do so, but you can’t stay with the pizza when they’re working on it. Do you still know what exactly goes in it? Who all have access to it, add ingredients, or take ingredients away? That’s how it works with a SaaS application. You hand over everything. The network, control, software, and your data. But you remain responsible for that data, whilst you depend on your supplier for its security. Not a pleasant idea when you consider what the consequences of inadequate security are:
- Misuse or theft of data
- Breach of confidentiality of data
- Malware spread
- Compliance risks
In short: no or limited control, but responsibility and dealing with adverse consequences remains with you. Therefore, you can’t just trust the security measures of a SaaS supplier. So, what should you do?
SaaS-security: how do you go about that?
1. Ensure insight
We’ve said it many times before, but insight is the first step to good security. You can only check and security something when you know what’s happening. The SaaS Risk Assessment Report offers a solution. This report shows, amongst other things, which SaaS applications are being used and by who, and how much data is sent to those applications.
2. Determine what is and isn’t allowed
If you know which applications are being used, you can distinguish between applications that are and are not allowed. A commonly used format is:
Unsanctioned apps
Unsanctioned apps are the riskiest. These often arise from shadow-IT. Business use of these applications is highly undesirable. Firewall policies can exclude these apps from use.
Tolerated apps
Tolerated apps are apps you’d rather not use, but are often so embedded in the organization that prohibiting them is no longer an option.
Sanctioned apps
You have the most control over this category. As an organization, you choose an application for a specific purpose and set conditions for it.
3. Classify your data
Determine what is and isn’t allowed within the sanctioned application. Amongst other ways, this can be done by classifying data. For example, specify in your policy that a legal document can be shared via OneDrive business, but not via OneDrive personal.
If the application doesn’t provide this functionality, Palo Alto Networks’ Aperture offers a solution. Aperture classifies data automatically based on the content (English and German are available as well). In addition, it blocks the files, even when already shared, or sends them to WildFire (sandbox) in case of an unknown threat.
What else do you have to take into account
Good preparation can prevent a lot of problems. When choosing a SaaS supplier, it is therefore important to pay attention to the following points:
Policy before cloud
As we’ve already said, you remain responsible for your data. Reduce the risks and the impact of cyberthreats to the bare minimum. How? By basing everything on Zero Trust. In our previous article we explained how you can limit risk and impact via segmentation. Segmentation ensures that not all connections just remain open (limit risk). And, if something unexpectedly does go wrong, the damage will be limited to that one segment (limiting impact).
A SaaS application is also (part of) such a segment. And each segment has a specific policy. Based on this policy you can determine which functionalities are required and use this to test whether or not your cloud provider offers these functionalities.
Avoid unpleasant consequences
Anyone who chooses a supplier without first checking the functionalities, can run into difficult situations afterwards. What if the policy can’t be executed, then what?
- The policy gets adjusted. In this case, policy becomes subordinate to functionality and you make concessions to security. And if the policy flows from a legal requirement, you can seriously question whether or not a policy change is even an option in the first place;
- Discuss and determine functionality with the supplier to ensure it is in line with the policy (this likely doesn’t fall under the heading ‘service’);
- Cancel the contract with the supplier and find a new supplier. This is not an attractive nor a cheap option
The price tag
For many organizations, the price tag is one of the most important reasons for using SaaS applications. Which is perfectly understandable, as low purchase costs are easier to justify than high ones. Except we’re not just talking about purchase costs. SaaS providers derive their income from subscription costs. And those can turn out higher than expected. A lot of organizations are lured in with low starting costs, and after the first subscription period, the costs are significantly increased.
Everything in one place: is dat safe?
A SaaS application means that you’ll be storing everything in one place. Sounds nice and organized and it is, but there’s an added risk. When something goes wrong, everything goes wrong; after all, everything is hosted by the same provider. In the case of downtime, the entire application is down and data cannot be reached. It’s therefore not such a bad idea to, for example, divide data amongst multiple providers. If you work with data with a high BIV-rating, keep this data in separate places (preferably on premise as well) and make sure that you maintain control. It’s a good idea to think about a multi-cloud strategy, but this also comes with extra risks. When data is located in two places, there are also two places that can be attacked.
Have an exit-strategy in place
“Leave our cloud provider. Why would we want that?”
It might sound like an unlikely scenario, but there may come a time where you want to part with your cloud provider. When?
- The cloud provider adjusts the conditions, so your policy is no longer in line with the functionality;
- After an initial period with an attractive starting rate, the cloud provider increases the monthly costs significantly;
- A change in law obligates you to sharpen the security policy and the cloud provider cannot comply with this.
In short, plenty of plausible reasons to have a plan B ready to go.
Can you safely use SaaS-applications?
Think before you leap, that’s what it boils down to. SaaS applications offer numerous advantages, but don’t lose track of the downside. After all, you ultimately remain responsible for your data.
- Establish policy before choosing your cloud provider;
- Take redundancy and back-up (especially in case of sensitive data) into account;
- Make sure you have an exit strategy.
