Data protection solutions, and in particular, Data Security Posture Management (DSPM) platforms, should be built to effectively map, monitor, and protect your organization’s most valuable asset — your data.
But not all cloud data security and compliance tools offer the same advantages, and not all will be suitable for your business’s unique data requirements.
Here are five questions you should ask when evaluating DSMP platforms to ensure you choose the right solution for your organization.
1. What is the coverage of data services?
To stay relevant and agile in today's fast-paced digital world, organizations need to be prepared for continuous change. This means embracing new technologies, just as cloud vendors create novel ways for organizations to build new, exciting things.
.png)
When evaluating cloud data security and compliance solutions, ask yourself, is this DSPM solution relevant for the services your development teams are using?
Will it allow you, as a cloud security architect, to retain control of your data by visualizing all of your data stores (the managed ones you know of, and the unmanaged ones you don't)?
Ask what services the vendor supports, make sure they are relevant for your use cases, and verify that the requested permissions are for these services only. Overly permissive policies might be relevant for future support, but are they advantageous for you today?
2. Where is the data analyzed?
Most DSPM solutions classify the customer’s sensitive data. To do so, they need access to all data assets within your cloud environment.
It’s a relatively common practice for vendors that want to provide a fully managed SaaS solution to take data "back home" for analysis purposes. Therefore, relying on third-party vendors to keep your sensitive data secure and compliant, might expose your organization to significant risk.
A preferable and more secure option is to have an analyzing service in your cloud account to perform the analysis work without sending sensitive data back to the vendor.
While this means that some of the cost of this service will be part of your cloud account bill, this can also be managed and monitored.
3. What permissions should you avoid?
While in most cases, Get, List, and Describe are low-risk permissions you would expect, sometimes more permissions are required, like Create or Delete.
Typically, you should avoid granting these permissions to any vendor, unless the system depends on it.
Before committing to a DSPM vendor, ask what permissions they need and why, so you can avoid enabling permissions that are too general.
Here is an example where the Action is ‘Create’’, which basically says that according to this policy, one can use any KMS create action on any KMS resource on the account. Having this level of permissions might be required, but can also be abused by bad actors that gain access to this policy.
In the following sample, you can see how this policy could have been made more strict for a specific action, on a specific KMS resource, reducing the attack surface and making sure anyone using this policy is limited only to what it was created for.
Another example that is specific for AWS IAM permissions is the “iam:passrole” permission. This permission grants a user/service permission to pass any role in the AWS account to any service in the AWS account, which can lead to Privilege Escalation. This is where it becomes vital to ensure this permission is limited to specific secured roles and only allowed by the services you need them for.
4. Is the permission scope bound to the required areas?
In the case of a permission that is on the "riskier" side, the safest approach is to limit it to a specific boundary of resources, or a scope.
Not all DSPM vendors use this method, which can potentially be used to perform actions on areas they shouldn't, by mistake.
When evaluating DSPM platforms check that any permission that should not be granular is made specific and bound to a certain area, resource, or cloud tag by using conditions or similar methods.
