.png)
Along with Identity security, Data security are at the forefront of security. The idea of “data-centric security”, focusing on protecting the data, which then allows us to worry less about securing devices, networks, and associated infrastructure.
In practice, data-centric security has been disappointing, while having security policy and protection travel along with the data, as data spreads to every SaaS service we know about (and others we don’t know about - think jurisdiction & Data Governance!), is too much to be able to control. (e.g. The Digital Rights Management at scale concept has not been a great success).
Then we’ve scaled back expectations and started to rely on techniques such as tactical encryption, mostly using built-in capabilities (FDE for structured data, and embedded encryption for file systems). By doing so we’ve achieved compliance requirements, as well as getting the basic level of assurance that data was protected.
Other techniques, such as masking and tokenisation, also provided ways to protect the sensitive data. New tactics as test data generation tools also provide an option to ensure that developers don’t inadvertently expose production data. But even with all of these techniques, most organisations still struggle with protecting their data and SaaS does exacerbates the issue.
Protecting data continues to get more complicated especially with SaaS. As SaaS becoming more and more the front office, with the increase of the remote working trend, the focus now shifts.
Protecting data by encrypting/masking/tokenising it, or putting a heavy usage policy around it, can’t be the only solution (especially not at scale) for few reasons: The technology industry has rethought applications and the creation, usage, and storage of data. Thus, we need to rethink data security for the SaaS model. We must both rethink the expectations of what data security means, as well as the potential solutions.
We can use the Data Security Lifecycle to gain focus:
At the highest level, the Data Security Lifecycle lays out 6 phases from creation to destruction. We depict it as a linear progression, but data can move between phases without restriction, and need not pass through all stages (e.g. not all data is eventually destroyed).
With this lifecycle in mind, we can evaluate data and make decisions about appropriate locations and access. We need to understand where the data can reside, which controls apply to each possible location, and how to protect data as it moves. Then go through a similar exercise to specify rules for access, determining who can access the data and how. And where data security strategy depends on protecting all critical data, hence we need to run via this exercise for every important data type.
Then going another level down to understand which functions (e.g. Access, Process, Store) apply to each phase of the lifecycle, then determine which controls enable data usage for which functions.
It’s impractical to use this model at scale. That’s why we need to rethink data security.
We are building fewer applications and embracing SaaS. For the applications we still build, we leverage Cloud storage and other platform services, hence data security is not fully in our control (although we’re still accountable to protect the critical data).
In SaaS we cannot control data exploit (vulnerability or an exploit path to allow an attacker unapproved access to the data). We also probably don’t see the traffic going directly to a SaaS provider, unless we inefficiently (performance wise) force all traffic through an inspection point.
That leaves us to control the data and specifically to prevent access to sensitive data, and restrict usage to authorised parties. If we prevent unauthorised parties from accessing data, it’s tough for them to steal it. If we can ensure that only authorised parties can perform certain functions with data, it’s hard for them to misuse it.
data security in a SaaS world requires much more focus on access and application entitlements. We handle it by managing entitlements at scale. An entitlement ensures the right identity (user, process, or service) can perform the required function at an approved time.
With the traditional Data Security Lifecycle, the SaaS provider handles a lot of these functions – including creation, storage, archiving, and destruction.
The Role of Identity in Data Protection:
We may have heard the statement that “Identity is the new perimeter.” it’s basically true, and SaaS data security offers a good demonstration of it. Every data access policy associates with an identity. Authorisation policies within SaaS apps depend on identity as well.
SaaS data security strategy is based on identity management, such as most other things we do in the cloud. This dependency puts a premium on federation because managing hundreds of user lists and handling the provisioning/de-provisioning process individually for each application doesn’t scale. A much more workable plan is to implement an identity broker to interface with authoritative source and federate identities to each SaaS application. This becomes part of the critical path to provide data security.
Data Guardrails and Behavioural Analytics:
If managing data security for SaaS applications is effectively the ability to be able to set and enforce policies for each SaaS app, then this will require a clear understanding of each specific application, so we can set appropriate access and authorisation policies. But setting policies is only the first step. Environments change regularly, as new modules become operational and new users onboard. Policies change frequently, which creates an opportunity for mistakes and attacks. That all brings us to Data Guardrails and Behavioural Analytics.
The key difference is that data guardrails leverage this knowledge with models and processes to pre-define who can do what and stop everything else. Data behavioural analytics extends the analysis to include current and historical activity, using machine learning algorithms to identify unusual patterns that bypass other data security controls. It’s not an either/or choice; We begin by defining data guardrails, which provides the ability to establish allowed activities within each SaaS application for each user, group, and role (the Baseline). Then we add the observability aspect of it, with monitoring data usage for potentially malicious activities.
The Process:
The typical enterprise has hundreds and more of SaaS services. So what’s the best approach to secure those applications? We will need to think small, by setting policies to protect one application or service at a time (on an service prioritisation and categorisation basis).
The first SaaS app we run through the process should be an essential app with highly sensitive data. (e.g. O365, G Suite), CRM tool (e.g. Salesforce), file storage service (e.g. Dropbox), or ERP/HR package (e.g. SAP, Workday, Oracle).
Then we will need to maximise risk mitigation by starting with the app with the most extensive user base and get started by answering a few basic questions: What’s the data?, Who needs to see the data?, What do they need to do with the data?
Once we have the entitlement matrix documented, we write the policies. At that point, we load policies into the application. Then review, tweak and repeat for the other SaaS apps we need to protect.
Each SaaS app will have a different process to implement these policies, so there isn’t not too much of leverage to be gained in this effort. But we probably aren’t starting from scratch either. A lot of this work happens when deploying the applications initially.
Once the entitlements are defined (or revisited), and we’ve implemented acceptable policies in the application, we reach the operational stage. Many organisations fail here. New capabilities get rolled out weekly. So when they periodically check policies every quarter or year, they are surprised by how much changed and the resulting security issues.
So continuous monitoring becomes critical to maintain the integrity of data in SaaS apps. We need to watch for changes, with a mechanism to ensure they are authorised and legitimate. Security doesn’t need to have operational responsibilities for SaaS applications. But they need to assess the risk of access when building the entitlement matrix and to monitor the application to ensure changes don’t violate policies or add attack surface. All can be achieved either using in-house tools SIEM, ServiceNow, Jira and SaaS management tools.
It’s becoming clear that SaaS will replace much all of the back office applications and if anything will accelerate it now, is the fact that on-premise resources are mostly out of reach and working remotely (*to date), hence the current different approaches to data security must evolve accordingly.
**Sources:
- Cloud Security Alliance (CSA) Reference Architecture (Version 2.0)
- (ISC)² CCSP certification exam materials
- 'AWS Certified Security Speciality' certification exam materials
- 'Azure Security Technologies certification exam materials
- NCSC (National Cyber Security Centre); Cloud Security Principles
- Broad projects experience
- Online information
Comments