Data Security Posture Management vs Data Security Platform

Data Security Posture Management vs Data Security Platform

Data Security Posture Management vs Data Security Platform

Watch the Webinar

Get started for Free
Learn More

In a previous post, Jonathan Sander details the primary differences between a Data Security Posture Management (DSPM) solution and a Data Security Platform (DSP). He highlights that the most notable difference between a DSPM and a DSP is in the “policy definition and policy enforcement” aspects of a DSP. He explains that while some applications allow for simple API calls to manage access or security policies, such as removing a user’s group membership in Active Directory, implementing policy definition and enforcement at a deeper level for platforms like Snowflake becomes exceedingly challenging, if not impossible, for a DSPM.

Recent events have reignited my interest in understanding how ALTR distinguishes itself from a DSPM. The first event was the potential acquisition of Wiz by Google. Wiz, a cloud security posture management (CSPM) tool, is often confused with a DSPM. This has led customers to inquire about the differences between CSPM and DSPM and, subsequently, the distinctions between DSPM and DSP. Although the Wiz/Google deal fell through, it sparked an insightful discussion on Linkedin initiated by Pramod Gosavi from JupiterOne. I participated in this discussion, which delved into why Google should reconsider buying a tool like Wiz.

The other recent event that brings DSPM v DSP back into spotlight is the word ‘remediation’, which has been used by some DSPM providers lately. The word remediation in this context indicates a DSPMs ability to react to one of their findings. For example, a remediation might be removing a user’s access from a system or making a public-facing internet resource private. These types of remediations are simple and straightforward and should easily be achievable by a DSPM. But lately, some of the DSPM players have been making mention of remediations for platforms like Snowflake stating their platforms can do complex operations such as RBAC, data masking, and data security such as encryption or tokenization.  This is where the analogy "All squares are rectangles, but not all rectangles are squares" comes in handy. In this scenario, the DSPM is the square, and the DSP is the rectangle. A DSP can perform all the functions of a DSPM, but a DSPM cannot perform all the functions of a DSP. Let me explain.

The largest difference between a DSPM and a DSP is not the type or number of data stores supported, or the workflows within the platforms, but rather the biggest difference is the integration methods with the data stores. DSP’s live in the line of fire. We sit in the hardest place a vendor can sit, in the critical path of data. It’s the only way a DSP can provide capabilities like real-time database activity monitoring (DAM), data encryption or tokenization, data loss prevention, and others. Without this position in the stack, our ability to stop, or remediate, an out of policy data access request is minimized.

DSPM’s on the other hand do not live in the critical path of data access. They often exist outside the normal access patterns connecting to systems such as databases or file shares without fear of latency or uptime. A DSP has the unfortunate burden of having to essentially match the uptimes and availability of the platforms they control, often requiring significant investments in engineering and operations that DSPM do not have. It's these requirements of uptime, throughput, and strict performance metrics that make it nearly impossible for a DSPM to offer value over a DSP when it comes to complex operations in a platform like Snowflake. Since a DSP is already in line with the systems they are controlling and protecting, it is conceivable that a DSP could offer a wide overlap of the features of a DSPM, if it wanted to.

For customers, this means taking the time to understand the specific challenges you need to address for platforms like Snowflake, particularly regarding access controls and security. The multiple layers of roles and attributes assigned to users, the vast amount of data that moves and transforms inside the Snowflake platform daily, and the performance requirements of encryption on your downstream application is complex. These are hard problems for any business. And solving these challenge is what is going to fully unlock the value of your Snowflake instance.

Wrapping Up

Be cautious of any DSPM that claims to solve the complex governance and security challenges of Snowflake effortlessly. Always request detailed case studies to validate their claims. While it's not necessarily impossible, these claims often resemble a square trying to fit into a rectangle.

industry

Energy

PLATFORM

Snowflake

use case

Tokenization

Data Security Posture Management vs Data Security Platform

In a previous post, Jonathan Sander details the primary differences between a Data Security Posture Management (DSPM) solution and a Data Security Platform (DSP). He highlights that the most notable difference between a DSPM and a DSP is in the “policy definition and policy enforcement” aspects of a DSP. He explains that while some applications allow for simple API calls to manage access or security policies, such as removing a user’s group membership in Active Directory, implementing policy definition and enforcement at a deeper level for platforms like Snowflake becomes exceedingly challenging, if not impossible, for a DSPM.

Recent events have reignited my interest in understanding how ALTR distinguishes itself from a DSPM. The first event was the potential acquisition of Wiz by Google. Wiz, a cloud security posture management (CSPM) tool, is often confused with a DSPM. This has led customers to inquire about the differences between CSPM and DSPM and, subsequently, the distinctions between DSPM and DSP. Although the Wiz/Google deal fell through, it sparked an insightful discussion on Linkedin initiated by Pramod Gosavi from JupiterOne. I participated in this discussion, which delved into why Google should reconsider buying a tool like Wiz.

The other recent event that brings DSPM v DSP back into spotlight is the word ‘remediation’, which has been used by some DSPM providers lately. The word remediation in this context indicates a DSPMs ability to react to one of their findings. For example, a remediation might be removing a user’s access from a system or making a public-facing internet resource private. These types of remediations are simple and straightforward and should easily be achievable by a DSPM. But lately, some of the DSPM players have been making mention of remediations for platforms like Snowflake stating their platforms can do complex operations such as RBAC, data masking, and data security such as encryption or tokenization.  This is where the analogy "All squares are rectangles, but not all rectangles are squares" comes in handy. In this scenario, the DSPM is the square, and the DSP is the rectangle. A DSP can perform all the functions of a DSPM, but a DSPM cannot perform all the functions of a DSP. Let me explain.

The largest difference between a DSPM and a DSP is not the type or number of data stores supported, or the workflows within the platforms, but rather the biggest difference is the integration methods with the data stores. DSP’s live in the line of fire. We sit in the hardest place a vendor can sit, in the critical path of data. It’s the only way a DSP can provide capabilities like real-time database activity monitoring (DAM), data encryption or tokenization, data loss prevention, and others. Without this position in the stack, our ability to stop, or remediate, an out of policy data access request is minimized.

DSPM’s on the other hand do not live in the critical path of data access. They often exist outside the normal access patterns connecting to systems such as databases or file shares without fear of latency or uptime. A DSP has the unfortunate burden of having to essentially match the uptimes and availability of the platforms they control, often requiring significant investments in engineering and operations that DSPM do not have. It's these requirements of uptime, throughput, and strict performance metrics that make it nearly impossible for a DSPM to offer value over a DSP when it comes to complex operations in a platform like Snowflake. Since a DSP is already in line with the systems they are controlling and protecting, it is conceivable that a DSP could offer a wide overlap of the features of a DSPM, if it wanted to.

For customers, this means taking the time to understand the specific challenges you need to address for platforms like Snowflake, particularly regarding access controls and security. The multiple layers of roles and attributes assigned to users, the vast amount of data that moves and transforms inside the Snowflake platform daily, and the performance requirements of encryption on your downstream application is complex. These are hard problems for any business. And solving these challenge is what is going to fully unlock the value of your Snowflake instance.

Wrapping Up

Be cautious of any DSPM that claims to solve the complex governance and security challenges of Snowflake effortlessly. Always request detailed case studies to validate their claims. While it's not necessarily impossible, these claims often resemble a square trying to fit into a rectangle.

Heading 1

Heading 2

Heading 3

Heading 4

Heading 5
Heading 6

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.

Block quote

Ordered list

  1. Item 1
  2. Item 2
  3. Item 3

Unordered list

  • Item A
  • Item B
  • Item C

Text link

Bold text

Emphasis

Superscript

Subscript

CASE STUDIES

Providing real solutions

Ready to get started?
We’re here to help. Our team can show you how to use ALTR and make recommendations based on your company’s needs.
Get Product Tour

Data Security Posture Management vs Data Security Platform

PUBLISHED: Jul 30, 2024

While a DSP can perform all DSPM functions, a DSPM cannot perform all DSP functions.

James Beecham
Founder & CEO

In a previous post, Jonathan Sander details the primary differences between a Data Security Posture Management (DSPM) solution and a Data Security Platform (DSP). He highlights that the most notable difference between a DSPM and a DSP is in the “policy definition and policy enforcement” aspects of a DSP. He explains that while some applications allow for simple API calls to manage access or security policies, such as removing a user’s group membership in Active Directory, implementing policy definition and enforcement at a deeper level for platforms like Snowflake becomes exceedingly challenging, if not impossible, for a DSPM.

Recent events have reignited my interest in understanding how ALTR distinguishes itself from a DSPM. The first event was the potential acquisition of Wiz by Google. Wiz, a cloud security posture management (CSPM) tool, is often confused with a DSPM. This has led customers to inquire about the differences between CSPM and DSPM and, subsequently, the distinctions between DSPM and DSP. Although the Wiz/Google deal fell through, it sparked an insightful discussion on Linkedin initiated by Pramod Gosavi from JupiterOne. I participated in this discussion, which delved into why Google should reconsider buying a tool like Wiz.

The other recent event that brings DSPM v DSP back into spotlight is the word ‘remediation’, which has been used by some DSPM providers lately. The word remediation in this context indicates a DSPMs ability to react to one of their findings. For example, a remediation might be removing a user’s access from a system or making a public-facing internet resource private. These types of remediations are simple and straightforward and should easily be achievable by a DSPM. But lately, some of the DSPM players have been making mention of remediations for platforms like Snowflake stating their platforms can do complex operations such as RBAC, data masking, and data security such as encryption or tokenization.  This is where the analogy "All squares are rectangles, but not all rectangles are squares" comes in handy. In this scenario, the DSPM is the square, and the DSP is the rectangle. A DSP can perform all the functions of a DSPM, but a DSPM cannot perform all the functions of a DSP. Let me explain.

The largest difference between a DSPM and a DSP is not the type or number of data stores supported, or the workflows within the platforms, but rather the biggest difference is the integration methods with the data stores. DSP’s live in the line of fire. We sit in the hardest place a vendor can sit, in the critical path of data. It’s the only way a DSP can provide capabilities like real-time database activity monitoring (DAM), data encryption or tokenization, data loss prevention, and others. Without this position in the stack, our ability to stop, or remediate, an out of policy data access request is minimized.

DSPM’s on the other hand do not live in the critical path of data access. They often exist outside the normal access patterns connecting to systems such as databases or file shares without fear of latency or uptime. A DSP has the unfortunate burden of having to essentially match the uptimes and availability of the platforms they control, often requiring significant investments in engineering and operations that DSPM do not have. It's these requirements of uptime, throughput, and strict performance metrics that make it nearly impossible for a DSPM to offer value over a DSP when it comes to complex operations in a platform like Snowflake. Since a DSP is already in line with the systems they are controlling and protecting, it is conceivable that a DSP could offer a wide overlap of the features of a DSPM, if it wanted to.

For customers, this means taking the time to understand the specific challenges you need to address for platforms like Snowflake, particularly regarding access controls and security. The multiple layers of roles and attributes assigned to users, the vast amount of data that moves and transforms inside the Snowflake platform daily, and the performance requirements of encryption on your downstream application is complex. These are hard problems for any business. And solving these challenge is what is going to fully unlock the value of your Snowflake instance.

Wrapping Up

Be cautious of any DSPM that claims to solve the complex governance and security challenges of Snowflake effortlessly. Always request detailed case studies to validate their claims. While it's not necessarily impossible, these claims often resemble a square trying to fit into a rectangle.

Ready to get started?
We’re here to help. Our team can show you how to use ALTR and make recommendations based on your company’s needs.
Get Product Tour
ALTR Blog