Identity - the missing Security Posture Management layer
Bridging the gap between CSPM and DSPM
“In my end is my beginning.” - T.S Eliot
Over the last five years, the rapid growth of CSPM and DSPM niches drove these capabilities to the top of companies’ Cloud Security agendas. Both CSPM and DSPM are must have capabilities for anyone operating in the cloud. But engineering design is about understanding and accounting for constraints. CSPM and DSPM are important tools, and both have limitations. As always, the most important question to ask is - and then what happens?
CSPM excels at finding structural misconfigurations from the outside-in. Beyond the vulnerabilities that CSPM identifies, the tools are not able to add much value for identifying issues once access has been granted. In other words, the end result of a transaction running through a CSPM system is - “access granted”, but what is the size and shape of the resulting blast radius? The downstream impact is a closed book.
DSPM takes the inverse approach - identifying data security issues from in the inside-out. Because DSPM starts from the data, there is the chance of a better view of the blast radius based on the policy, but again is the access set up properly in the first place? Neither CSPM and DSPM answer this today, there is a missing layer which is identity.
Identity is not a static thing, identity is from-to. One party asserts, and another recognizes. Put in tooling terms, the end of a CSPM transaction is an identity assertion, and the beginning of a DSPM protected systems is an identity recognition. But neither CSPM or DSPM delves deep into identity today.
There are lofty valuations in both CSPM and DSPM niches, and each are trying to grow their TAM to justify the high valuations.CSPM vendors are trying to claim some parts of DSPM and reinvigorate Appsec (Code, ASPM), which is a new variant of the much-tried one pane of glass approach. At the same time, DSPM vendors are looking to other niches like operations and DLP.
Both of these focuses miss the bridge layer that unites the ends and beginnings of their respective systems- identity. What the is efficacy and coherence of the session token, OAuth, SAML assertions that are whizzing through the CSPM/DSPM configs and what gaps are left? This can be thought of as a purple problem, where security zone A creates a Red policy and security zone B creates a blue policy. A determined attacker may find a Purple combination that elevates privilege in a way that is unforeseen by the limited views in the of the CSPM/DSPM combination. Until a SPM produces better recognition of the efficacy, health and wellness of identity systems there will be a gap in cloud system defenses that companies have to fulfill by other means.
CSPM and DSPM are designed and built in response to unique challenges with public cloud. IAM -- at large -- is the most complex, challenging and important security component for cloud. Many of the CSPM and DSPM vendors already offer a basic User to Endpoint mapping capability to illustrate what services can be reached, so I would argue that Identity piece is already in play. But when coupled with entitlements complexity, and the use of managed identities representing the machine/service, it's hard for mortals to understand the complexity of blast radius. We can reduce scope / complexity with micro-segmentation _on the data network_ but services APIs may have universal availability. I offer that IAM as a whole is the missing link for security posture.