Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Identity management with SIEM: A better breach defense

Chas Clawson Cloud SIEM Engineer, Sumo Logic

Two information silos once diverged in enterprise IT—one containing IAM (identity and access management) and another security information and event management (SIEM). Both technologies have advanced in sophistication over the last decade; where IAM is the domain of IT Ops, next-gen SIEMs continue to focus on security. 

Now organizations are integrating them bi-directionally. For security analysts, this brings better context to their events of interest. In their world, context is everything for effective triage. 

The primary role of IAM is to provision accounts and provide identity assurance— meaning users are who they claim to be—and then grant or rescind privileges to business resources based on each user’s role. 

For IT Ops, this integration brings the possibility for efficiencies gained through automated response, often caused by analysts who request that accounts be temporarily suspended or have their privileges removed. For the CISO, this means fewer business disruptions caused by security breaches, quicker remediation, and an improved security posture.

Integrating IAM feeds with your SIEM analytics is another identity and governance best practice that can make a big difference. Here's how to get started.

Move toward a zero-trust architecture

Traditional security models assumed that anything inside the perimeter could be trusted, so security budgets should be spent on strengthening the perimeter. A more modern security approach—one adopted by an increasing a number of companies—is to assume a breach and create a "zero-trust" (ZT) architecture.  

According to Forrester Research, a ZT architecture "abolishes the idea of a trusted network inside a defined corporate perimeter. ZT mandates that enterprises create micro-perimeters of control around their sensitive data assets to gain visibility into how they use data across their ecosystem to win, serve, and retain customers." 

Combining real-time analysis and visibility with contextual information—to identify threats, address vulnerabilities, and uncover incidents in progress—requires real-time analysis and visibility across networks, devices, apps, users, and data, the report added. You also need contextual information about the user, transaction risk, and the overall security state, such as traffic flows, device state, user identity and biometrics, behavior, app state, app classification, data classification, location, and time.

SIEM and IAM play important roles in this new way of thinking. Principles such as "never trust, always verify" and "least-privileged access" can stop—or at least slow—attackers' lateral movements before damage occurs. 

[ Special Coverage: RSA Conference 2019 ]

Integration brings context and correlation

Although the functional lines between tools are constantly blurring, it's good to understand the key differences between IAM and SIEM. While the primary role of IAM is to provide identity assurance, a SIEM collects authorization events and also ingests logs from endpoints, firewalls, applications, and servers to determine what actors are actually doing within an enterprise.

At times, a SIEM may simply know that someone (maybe just a dynamically assigned IP address) is taking actions that trigger an alert, but not who that user is or what role he has within a company. 

In fact, a common first step an analyst takes when investigating alerts is to attribute an IP to a user, and then determine whether or not the user involved has an account with elevated privileges. This often involves pivoting to an IAM or centralized directory.

In many cases, this information can be brought into a single tool. At this point, you can apply more advanced correlation rules, which can dynamically adjust the risk/priority of alerts based on information known about the user. This is what a good SIEM tool is designed to do. 

Unfortunately, many organizations stop developing their SIEM use cases once the compliance checkbox is checked. But compliance is a byproduct of well-executed security policies and is only a minimum standard, not the end goal.

    What you need to know about integrating identity data feeds with your SIEM

    As you go about integrating IAM and SIEM tools, here are a few questions to ask before you get too far down the path:

    • Do your analysts frequently have to pivot to other tools to gather contextual information?
    • Is there an information gap between your IT Ops and SecOps teams that integration can bridge?
    • Are there ways you can automate "lookups" at ingest time that will enrich your base log events, or is a pivot at the time of search sufficient?
    • Does your IAM platform provide high-fidelity security events such as anomalous behaviors observed that should be fed into the SIEM and used as a data point for alerts?

    Two scenarios might help underscore the benefits of integration.

    Scenario 1

    User A triggers a SIEM alert when logging into a system from an unusual foreign country. An analyst must then find out if this user is on travel or if this is his normal workstation, and investigate contextual events showing he is likely that user. 

    Pivoting over to IAM, the analyst might see that the user was strongly authenticated (via two-factor, for instance) and is using his company-issued workstation. 

    This greatly reduces likelihood of it being nefarious activity. The analyst then also confirms that the account used was not an admin, reducing the risk and need to wake someone up in the middle of the night. 

    A good IAM tool could also provide a “risk score” associated with identities to a SIEM. This can help identify user types other than administrators (executives, auditors) that have access to sensitive data or systems. Having all of this context in the same tool would have helped reduce the investigation time.

      Scenario 2

      A normal-looking login event is recorded within the IAM tool. But the SIEM, which has additional logs and visibility that may not be available within IAM, triggers an "impossible travel" alert. The alert is based on a different application login event that occurred because the two IPs associated with that user were from distant geographic locations. 

      Looking back in the IAM tool, it becomes clear that that one of the authentications used "emergency access" or password recovery techniques. And the IAM system noted that this same user has both standard- and admin-level accounts. 

      Given this context, the situation warrants a call to the user or manager to determine which of the activities was legitimate. Taken a step further, when actions are determined to be nefarious, the IAM solution can initiate emergency disablement actions for all of the accounts associated with the compromised user.

      Events you may find of interest that can originate from your IAM solution include:

      • New privileged account observed
      • Unusual number of failed logins
      • Logins occurring on unusual systems or unusual number of systems
      • Logins occurring at unusual times
      • Logins occurring from unusual places or “Impossible travel” alerts
      • Misuse of service account audits
      • Inappropriate requests for access

      Authentication is one thing, behavior another

      Taken a step further, many of these considerations can be calculated automatically within the SIEM to dynamically raise or lower the threat score of the event so that only the truly actionable events make their way to the analyst-triage stage.

      Authentication is one thing; behavior is another. These homegrown use cases are similar to those that have since been incorporated into dedicated user and entity behavior analytics (UEBA) tools, and are great for organizations that haven't matured yet. 

      Beyond improvements to response and investigations, there are other benefits to be gained as well. It is likely that the SIEM platform has better visualizations and dashboards, automated reporting, and the ability to create historical trends. A weekly report of observed admin activity, account lockouts, and emergency access can be automated and can, at times, identify areas of concern.

      As any SEIM engineer can tell you, it takes a lot of time to onboard all the systems/applications you'll need. But some of this valuable identification data can be achieved early on by collecting IAM event logs.

      Going deeper with contextualization

      Anything that can be done to make more efficient playbooks can help avoid analyst burnout and swivel-chair syndrome. For junior analysts, more advanced detection rules and content can help train them about the latest indicators of compromise (IoCs). Some of this information is commonly collected by SIEM solutions, while others are commonly seen within IAM systems. 

      So what do these events actually look like? Below are events of interest common to Windows systems; you should locate them and confirm they're making their way to the rules engine and analytic tools that are easily searchable by analysts. 

      Keep in mind that they will likely be delivered to the SIEM in the native schema of your IAM solution—in JSON arrays or CEF Syslog events—and may or may not retain the original event IDs and categorization as the base events.

      Successful login events (check for event ID 4624 and 4648)

      Confirm that your SIEM tool and analysts have visibility into who is logging on, where they are logging in from, and what type of authentication was used. This information will be high in volume, but will be invaluable for conducting incident response investigations. 

      In addition, most users only use one or two systems locally. If you can identify accounts used across multiple endpoints, that may indicate lateral movement.

      Knowing your login types is also useful. Type 2 indicates users physically logging in (interactive), or "run-as" user actions. Also, you need to be able to track authentication events of Type 4 or 5. Highly privileged accounts will at times need to perform tasks on a remote system. 

      This is sometimes done as scheduled task logons or service logons which is great for sysadmins. But when logging into workstations they leave credentials in memory, and on disk in the LSA secrets, which an attacker can use to pivot from one local administrator account into a domain-wide compromise. 

      Unsuccessful login events (event ID 4625)

      These logs might be less useful, since more sophisticated actors use tools such as Mimikatz to steal and reuse valid credentials and use pass-the-hash and pass-the-ticket attacks. But old-school, brute-force attempts can still happen. 

      Even when unsuccessful, malware that attempts to brute-force passwords can cause serious business disruptions because built-in account lockout protections kick in and start disabling accounts at high rates. By monitoring unsuccessful logins you'll be alerted you to this before it becomes a serious problem. 

      Poorly configured accounts

      Weak Kerberos configurations in accounts, for example, are useful to attackers, since they can be used to get offline password hashes to crack with powerful tools such as hashcat. This is especially dangerous when combined with a weak/short password or a no-password-required setting.

      Forgotten service accounts that have elevated privileges can be a great way for attackers to move under the radar, so periodically auditing this activity and confirming it with system owners is a good best practice.

      New users created (check security event log 4720)

      Living off the land means attackers use the same tools as your system administrators. Creating a new user as a means of persistence, for instance, is not uncommon. This account can be used for future Remote Desktop Protocol sessions or to log into cloud applications. If the creation of this account is missed, the use of it will probably be missed in the future.

      An automated report sent to system administrators can prove helpful in finding anomalous behavior. Sysadmins and the security team aren't always sitting in the same space, so finding ways to automate some of the checks and balances can be a big help.

      Misuse of service accounts or new services created (system event log 7045 or 4697)

      Creating new services is one of the easiest ways to achieve persistence. These services can point to remote access tools (RATs), and use PowerShell as a first stage before downloading additional malicious code from somewhere on the Internet. 

      Validating new services and who created them, and baselining services against other machines can help identify outliers and give analysts something to "hunt" for in between event triage duties.

      Creation and execution of scheduled tasks (operational log 106/200)

      As with services, scheduled tasks are a common way to get a permanent foothold into a system. When analyzing these events, keep in mind that tasks can be scheduled on remote systems as well, if the attacker has already compromised user accounts.

      Clearing of logs (security event 1102)

      Once a system is compromised, much of the forensic data on that system is no longer trustworthy. This is why having events stored centrally within IAM or SIEM tools is affective. 

      Still, attackers try to cover their tracks. Forcing attackers to choose between leaving logs or creating a signal by removing them makes their life more difficult, and could give network defenders a chance to find them earlier in the kill chain.

      Build an intelligent SOC

      By bridging the gap between identity and security you can provide a real-time, holistic view of the enterprise and its compliance posture. There is real power in cross-validating identity, access and policy information in real time, and helping security operations (SecOps) teams know who is accessing what, when they are doing it—and whether they are authorized.

      In turn, if situations arise that are out of the norm, the platform takes appropriate action in real time, including sending simple notifications, initiating full remediation (e.g., revoking user access), or both. The actual remedy for the violation is determined by the policy of the organization and how it wants to manage a given situation.

      Don't fall victim to the self-fulfilling prophecy that building a mature SIEM isn't feasible and requires too much effort. While some work is required up front for more of these powerful integrations, the end result is efficiency gains that will more than pay for themselves.

      In the world of security events, context is king. It helps security analysts understand alerts and streamline incident response processes instead of having to chase down every false positive, only to be further backlogged in incident triaging.

      The bottom line is this: Lowering meantime to detection (MTD) and meantime to remediation (MTR) delivers significant benefits in cost, reputation, and overall security posture.

      Keep learning

      Read more articles about: SecurityInformation Security