IAM

Identity and Access Management (IAM) governs who can access which systems and data. It covers accounts, roles, permissions, and the processes for joiners, movers, and leavers.

How it works

Each person and every technical account receives an identity. This identity is linked to roles defining accessible applications and data. When an employee joins, accounts are created automatically from the HR system. Permissions are adjusted for job changes and revoked upon departure. Regular recertification reviews check if assigned permissions are still required.

An example from practice: An employee moves from the accounting department to the sales team. Without proper IAM, they keep old permissions and gain new ones. After a few years, their account can access financial, customer, and HR data. If this account is compromised, the attacker has extensive access.

What to look out for

• Automate joiner, mover, and leaver processes via the HR system.
• Regularly review permissions, at least for critical applications.
• Do not forget technical and service accounts. They often have extensive permissions.
• Keep roles simple. Too many special roles complicate the system.
• Use multi-factor authentication for all accounts, especially for admins.

Switzerland and regulation

The revFADP (revised Federal Act on Data Protection) demands suitable technical measures to protect personal data, including the proper management of access rights. FINMA Circular 2023/1 requires banks and securities firms to effectively manage access rights, especially for privileged accounts.

Relevance for the SOC

Identities are now the most common target for attackers. A SOC therefore needs logs from the IAM and identity provider. Only these logs allow it to detect account takeovers. It can also spot new admin rights and suspicious logins.

How we implement it

In the SOC, we monitor identities and block compromised accounts within our mandate. We are happy to discuss architecture questions as part of our Security Consulting.