Why IAM must be part of your data security conversations

The short answer is because it is the key zero trust pillar. Yes, data, applications, devices, networks, infrastructure, and reporting and analytics solutions are also extremely important, however, you can’t exclude authentication and authorization, even if you are not the main responsible for that. I’m not suggesting that the rest of the pillars are optional or merely nice to have.

I find data protection an extremely interesting topic, and more when I see that they are a mix of technical and non-technical. For example, we could discuss specific solutions, features and capabilities that should be implemented, how they work, etc., together with industry regulations, certifications, requirements, consequences of data breaches, reputation, fines, and more.

From an identity perspective, it is my job to offer solutions that aim to protect everything related to the different topics that are around the authorization and authentication mainly, like the basics of identity and access management (IAM, again), identity governance and administration (IGA), privileged access management (PAM), provisioning, separation/segregation of duties (SoD), access reviews, lifecycle workflows, integration with HR solutions, passwords and policies management, and reporting/analytics.

As an identity specialist, some of the most common data security scenarios that I discuss include:

• Policies to apply during the authentication in combination with sensitivity labels.
• Policies to apply in combination to applications that provide access to sensitive information.
• Policies to apply in combination to specific user attributes.
• Policies to allow or restrict access based on the status of devices (such as managed or unmanaged), or even based on device attributes.
• Policies that are triggered based on contexts (i.e: I access to a site and try to perform a specific action or try to access a specific section of the site that requires additional security).
• Govern of assignments (direct, indirect) and accesses. Lifecycle of identities (employees and externals). For example, through my IGA solution I could be giving access to an application, site, or assigning users to groups and through these I could have potential access to sensitive information. Assignment of sponsors.
• Identity protection. In combination to the policies mentioned above, I can integrate additional capabilities related to offline and real-time detections.
• Delegation of administration over a specific subset of identities that consume sensitive information. Could be for example to a data owner, among others.
• Lifecycle workflows related to joiners, movers and leavers. Onboarding and offboarding. Automation of all these as much as possible.
• Self-service solutions for the end users.
• Education of end users. Finding internal sponsors and making them part of this from the beginning.
• And last but not least important, full or partial automation of everything related to attestation, access reviews, approvals, etc.

If you notice, many of the scenarios described above relate to accessing sensitive or non-sensitive information as well as others that are more related to what’s happening after a user is authenticated and authorized.

For customers and companies that take security as a priority, I hope you find this article useful.

If you are a cybersecurity seller don’t sell by following a siloed approach (i.e: I do identity; don’t talk to me about data). If you are involved in a conversation that goes beyond your area of expertise involve someone else. This is a triple win: you; the other seller; and the customer.

If you still think that identity is not important because “it just works” after reading this or even if you think that identity is a commodity sooner or later what could go wrong will go wrong.

Thanks for reading,

Marcelo.