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

Since the answer to this question isn’t trivial, we need to dig a little bit deeper. First, let’s focus on identity management.

Sending data from your IAM system to your SIEM makes sense. There are several events that happen to your IAM system that should be checked out by your SIEM. These may be failed logins, denial of service attacks, detection of session hijacking or stolen application access tokens. On the other hand, your IAM can help with finding actions and anomalies that are not always malicious events.

SIEM integration opportunities

Let’s look deeper into the event of a newly created account. This might be a local operating system account, an app account, a software-as-a-service account or a domain account. If the SIEM system registers the event of a created account in a connected system, it won’t be clear if this is a desired or malicious event.

But if your SIEM system is able to correlate this ‘account add’ with a related action from the IAM system, it’s easy to distinguish between an approved or malicious account creation. Remember, new account creation is often part of the ‘persistence’ attack phase. Therefore, this enhances your SIEM capabilities.

Some examples of attacks involving new account creation can be found in the MITRE ATT&CK Framework ‘Create Account’ and sub-techniques.

Other examples are the restoration or addition of an account to an access group. Both might be normal or malicious actions if seen by the SIEM in a connected system. And both might be actions of an attacker in the persistence or privilege escalation phases of an attack.

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

Monitoring memberships of an access group is a typical feature of an IAM system, too. It will correct wrong 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 might face some challenges when integrating IAM and SIEM systems in the real world to cover use cases like these. The main challenge is the scope of the systems. This integration works best if the scope of both systems is equal. This sounds obvious, but it might be an issue during the initial phases or during a risk-based adoption approach. It might produce false positives or non-correlating events.

After you’ve achieved equal scope, also be aware that an IT environment is living and changing. The integration should be able to handle the lifecycle of connected and controlled systems properly for both security systems.

Make sure your SIEM system always monitors the IAM system. After all, it is a highly sensitive system, especially regarding confidentiality and integrity.

When done right, integration of the IAM and SIEM systems can evolve into a best practice for mature IT security environments.