What IAM security risks should you be aware of?

In modern complex application environments, principle of least privilege is surprisingly difficult to follow and implement. Sometimes the approach you take replicates the benefits of the principle without truly implementing it.

This is the hard problem of IAM (once you are done with identity itself). Very had to do manually. The only out is automation. If you have not automated, consider it open (not protected). Automation is how we can solve for misconfig and human errors - ie by removing the human in the loop!

Ao lidar com Identity and Access Management (IAM), esteja ciente dos riscos como concess?es excessivas de privilégios, autentica??o fraca, falhas na gest?o de credenciais, acesso n?o autorizado a dados sensíveis, falhas na auditoria de atividades e amea?as internas. Manter-se atento a esses riscos é essencial para fortalecer a seguran?a do IAM, requerendo práticas rigorosas de controle de acesso e monitoramento contínuo.

Third-Party and Vendor Risks: Outsourcing IAM functions to third-party vendors or relying on external services introduces additional security risks. Businesses should carefully vet third-party providers, assess their security practices, and establish clear contractual agreements to ensure the protection of sensitive data and compliance with security standards. Data Loss and Leakage: Inadequate controls over user access and permissions may result in data loss or leakage. Unauthorized access to sensitive data or misconfigured permissions can lead to accidental exposure of confidential information, compliance violations, and reputational damage.

In today's era of digital transformation, IT faces significant challenges in implementing the least privilege using traditional IAM stacks. The roles and responsibilities of users are changing more frequently than ever before, increasing in partner and cross-company collaborations, and the adoption of flexible work-from-anywhere policies. Moreover, the methods of accessing business resources have diversified, including Zero Trust Network Access or VPNs, privileged access to private applications via privileged or shared accounts, and SaaS access through similar means. As a result, misconfigured IAM policies have become increasingly common with the traditional stacks. It appears we require a new method.

Oftentimes, credential theft arises from hardcoded credentials publicly exposed through GitHub repositories. Attackers can merely scan repositories and identify authentication keys in the code. Instead of hardcoding sensitive credentials, consider using a secret manager and ensure only authorized personnel can access the secrets.

Credential theft is when threat actors steal credentials to gain access, bypass an organization’s security measures, and steal sensitive data. Once access is gained to an internal account, they can launch more widespread and malicious attacks across an organization’s network. Phishing is the most common form of entry because it is inexpensive and efficient.

Credentials theft refers to the act of stealing or misusing the credentials of users, roles, or services to gain unauthorized access to resources or data. To protect against credentials theft the following is considered the best practices: - enable MFA - enforce credentials rotation - encrypt data at rest and in transit - implement the principle of least privilege - enforce strong/complex passwords

Relying solely on usernames and passwords without MFA increases the risk of unauthorized access if credentials are compromised. Insufficient password policies can lead to the use of easily guessable passwords, making accounts vulnerable to brute force and dictionary attacks.

Relying on weak, static passwords without multi-factor authentication (MFA) can make it easier for attackers to gain unauthorized access. Implementing MFA and strong password policies can help mitigate this risk.

Privilege escalation is when a threat actor gains elevated access and administrative rights to a system by exploiting security vulnerabilities. By modifying identity permissions to grant themselves increased rights and admin capabilities, attackers can conduct malicious activities, potentially resulting in significant damages.

This involves exploiting flaws in the IAM system to gain elevated access to resources that are normally protected from an attacker or a user. This can lead to unauthorized access to sensitive information or systems.

The largest risk most organizations face in IAM is the persistence of obsolete user IDs and inappropriate permissions. De-provisioning is a crucial function and often overlooked. The Nick Leeson scandal that brought down Barings Bank was caused by overprovisioning - as he moved through various roles, he kept all the access rights he'd been granted. During my tenure as CTO of Waveset, an IDM startup, we had one large financial client who had 17,000 employees - according to HR - but 34,000 employees according to IT. Some IDs belonged to individuals who had left the company years earlier. Microsoft's recent breach resulted from brute force attacks against stale userIDs.

Based on my experience, visibility is the biggest challenge in IAM. Knowing the how many users have the administrative access in the environment is extremely important. Another big challenge is of the password, currently world is moving towards the passwordless authentication. For solving these challenge, i think Just-in-time access will help because in this organization provides access for limited interval of time for performing a task.

Well you don't have to look much further than the recent CISA beach and the importance of removing all access when employees depart. The breach happened due to credentials belonging to a former employee that were compromised by a separate data beach allowing internal access. This highlights the importance of maintaining accurate records and revoking access immediately after it's no longer necessary.

Organisations need to consider Segregation of Duties (SOD) risk as part of IAM. The risk that an employee may have access to an application or resource that they are not authorised to have as part of their job increases the likelihood of fraud, error or plain nefarious behaviour. For example, employees who can modify or grant access permissions in an IT department should not normally have similar access to financial systems. Or employees who are developers should not have access to promote the code they have developed into the live environment. Or teams who raise change requests should not approve them. SOD acts as a safeguard against errors and unintentional mistakes and helps maintain a secure and compliant environment.

When you hear IAM, do you only think about users? Most people aren’t yet aware that they need IAM for workloads. Workloads /applications typically access other workloads with highly privileged long lived credentials, yet validation of identity and access via policy is rare for workloads today. This lack of workload IAM led to Cloudflare’s sensitive wiki and bug system being breached this past month.

As above and to summarise, two key aspects: - ensuring access to each application or resource is appropriate and authorised, the minimum access appropriate is granted. - then also looking at access in aggregate for each user to ensure Segregation of duties is enforced and toxic combinations are eliminated. - it may also be appropriate to look at access across multiple related users to ensure opportunities for coercion or working together is minimised. All access must be reviewed regularly, more often e.g. monthly, for joiners/movers/leavers and an overall thorough review for all users on say an annual basis.

When considering IAM (Identity and Access Management) security, be aware of risks such as inadequate user authentication methods, which can lead to unauthorized access. Poorly managed user privileges and access rights can result in privilege escalation and abuse. Also, the risk of orphaned accounts, which are not properly deactivated after a user's role change or departure, can become a significant security vulnerability.

- Policy Weaknesses eg - poor lifecycle management, not removing accounts - Insufficient Data Controls: Lack of granular access control for sensitive data