Beyond just monitoring IAM activity (e.g., successful or failed logins, account lockouts, etc.), many other IAM-related events and activities can be logged and monitored to help alert you to malicious activity. While identity threat detection and response
(ITDR) is a new category of solutions centered around this capability, anyone with an existing SIEM can add some additional alerts and monitoring to help identify these potential threats and actors.
This piece explains the importance of normalizing IAM data, suggests some key IAM events to log/monitor and recommends ways to ease the process.
What is ITDR?
ITDR is an emerging capability in the security monitoring and zero trust space. It is an extension of existing SIEM and security monitoring capabilities specifically focused on identity events and possible account compromise. While ITDR products can provide
a jumpstart toward monitoring and detecting IAM-based threats, organizations can also instrument their SIEM to provide similar capability; although, it requires staff with the right expertise and bandwidth.
How to Normalize IAM Data
The first major challenge when starting to look at ITDR and SIEM analysis of IAM logs and activity is normalizing logs and data across multiple disparate applications and infrastructure. For example, Windows logs may use the format of user@domain.com
for an authenticator, while web applications and infrastructure (e.g., firewalls) use just “user.” To get actionable data and analyze it across data sources, you must use a common format and identifier for IAM data. This can be provided
through lookups or other web services by the main identity warehouse, such as AD or your identity governance administration platform, etc., and should be referenced as part of the normal log aggregation and normalization process.
READ: When to Consider a New IAM Solution
Key IAM Events to Monitor
A wealth of contextual and event driven IAM data can be used to alert the security team about potential breach activity. Some key metrics and data to consider include:
- IAM contextual/open source intelligence (OSINT) info: Many public sites track malicious IP addresses and compromised hosts. If your IP addresses or website are listed, it can be an early indicator of an account breach. However, some new products
are starting to take that same OSINT data and add on identity and risk factors. For example, some products can analyze user registration data to see if it is common across data sources for the person in question and then compare it against known compromised
accounts in its OSINT database. Internally, you can also use this authentication and registration data, along with time windows, to identify potential account misuse (e.g., “impossible travel,” such as when a person logs into the same
site from two different locations, or if a source has a high-risk score).
- Account change identifiers: Watching your central governance and account changes can be a good way to detect possible account takeover or malicious activity. Some key things to watch for or correlate across data sources include:
- MFA factor changes/account activity: If email and SMS are used for MFA validation of users and are changed for an account followed by an immediate MFA attempt from a different-from-normal IP/location for the user, this could be a sign of compromise.
This can be monitored using contextual information for the user (see Bullet 1).
- Account changes with other transactional risk from a business perspective: If you notice an account login is updated/changed and then new external accounts/transfers are initiated, such actions should be flagged and may require step-up authentication
or notification to the user before they complete. For example, SIEM/IAM events can be integrated with business risk systems to monitor for financial fraud activity and help hold/stop suspicious transactions.
- Authentication token misuse: Where you use persistent tokens, application-to-application or service-to-service, consider applying stringent monitoring controls over where those tokens should be used or validated from. If something changes or a
token starts being used from a different location, this should trigger an alert. Additionally, for nonpersistent/user-based tokens and flows, monitor for reuse/replay of user tokens that have expired, constant token refresh or constant access to token
exchanges, etc. These can be signs of a token replay-type attack.
- Privileged use/changes: All privileged access changes should trigger an alert to the security team, the user’s manager, etc., to flag the change in activity. This should include administrator group additions, user management capabilities,
etc., and should be controlled through a standard request/approve certification process. However, this process should also trigger alerts when changes are done as part of a response/monitoring capability. You should also include monitoring of creation,
usage and assuming of service or nonhuman accounts and credentials. Some attackers may hide in service or nonhuman credentials so they don’t trigger other alerts. This should be part of monitoring these accounts for token account usage/misuse.
- Number of access requests for nonstandard or privileged access: When attackers compromise a user’s account, they sometimes start requesting additional access to privileged systems and data, hoping it gets approved. Watch for a large change
in access requests per user to see if there is anything that needs to be evaluated.
Integrate Business Data and Analytics
Financial institutions have great risk departments and capabilities that can be leveraged with IAM monitoring and response. As an integration point, check with your risk management and transactional security group to see what they monitor that might help
with your IAM monitoring. If the risk management group finds anomalous and/or risky transactions, this can provide alerts to the team of possible account misuse or account compromise.
IAM-Focused Threat Detection Best Practices
Monitoring for and alerting on anomalous IAM activities, beyond simple authentication-level events, can go a long way toward thwarting common identity-based attacks. To improve your chances of success:
- Consider using an ITDR tool: Many provide strong detections out of the box.
- Spend time normalizing your data: This will ensure you have full visibility, while reducing false positives.
- Work closely with the business side of the house: Financial services organizations, especially, have strong risk management teams. Take advantage of their work and integrate it with your ITDR or SIEM rules to ensure you get a strong head start
and cover all the bases.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in
connection with such information, opinions, or advice.