Integration of IAM and SIEM to improve event and anomaly detection


Sending information from your identity and access management (IAM) system to your security information and event management (SIEM) system can help you find events and anomalies that you might not find otherwise. This allows you to recognize that an attacker has penetrated your systems. Your SIEM system may already be collecting a lot of data. So you might be wondering why you should send data out of the IAM system? Can’t you get this data directly from the IAM system?

Since the answer to this question is not trivial, we need to dig a little deeper. Let’s focus on identity management first.

It makes sense to send data from your IAM system to your SIEM. Several events occur in your IAM system that should be checked by your SIEM. These could be failed logins, denial of service attacks, session hijacking detection, or stolen application access tokens. On the other hand, your IAM can help find actions and anomalies that aren’t always malicious events.

Possibilities of SIEM integration

Let’s take a closer look at the event of a newly created account. This can be a local operating system account, an app account, a software-as-a-service account, or a domain account. When the SIEM system registers the event of an account being created in a connected system, it is not clear whether it is a desired or malicious event.

However, if your SIEM system can correlate this “add account” with a corresponding action from the IAM system, it’s easy to distinguish between approved and malicious account creation. Remember that creating a new account is often part of the “persistence” attack phase. Therefore, this improves your SIEM skills.

For some examples of attacks related to new account creation, see the MITER ATT&CK framework ‘Create Account’ and sub-techniques.

Other examples are restoring or adding an account to an access group. Both can be normal or malicious actions when seen by SIEM in a connected system. And both can be actions of an attacker in the persistence or privilege escalation phase of an attack.

Disabling unused default accounts is a best practice in IAM. If an attacker is able to recover and use such an account, without IAM it will be difficult to detect. This should be an event that the IAM system sends to the SIEM system.

Monitoring the memberships of an access group is also a typical feature of an IAM system. It corrects incorrect memberships by itself. But such cases should be reported to the SIEM system by default. They are at least suspicious and could be malicious.

Possible challenges

You may face some challenges integrating IAM and SIEM systems in the real world to cover use cases like these. The biggest challenge is the scope of the systems. This integration works best when the scope of both systems is the same. This sounds obvious, but could pose a problem in the early stages or during a risk-based adoption approach. False positive results or uncorrelated events may occur.

Having reached the same scale, you should also be aware that an IT environment is alive and changing. The integration should be able to adequately handle the lifecycle of connected and controlled systems for both security systems.

Ensure that your SIEM system is always monitoring the IAM system. After all, it is a highly sensitive system, especially in terms of confidentiality and integrity.

When done right, integrating the IAM and SIEM systems can become a best practice for mature IT security environments.


Comments are closed.