Skip to content

Maximize Your SIEM with Precise Active Directory Security Details

Filling the AD Security Gaps in Your SIEM

Lateral movement and privilege escalations through Active Directory are the root cause of all breaches. SIEM solutions are not new, and most organizations rely on them to measure the overall security of the network and devices that the SIEM is monitoring. SIEMs can gather log information from computers, firewalls, network devices, printers, and more. With each device having a different logging format, as well as different levels of events, the SIEM must be configured for each and every device to ensure proper analysis and event gathering. Just looking at Active Directory and domain controllers alone, you’ll find thousands of generated events.

What SIEMs do
very well

Most organizations rely on their SIEM to gather logs from all devices and keep the security team abreast of glaring issues. This is done by gathering the security logs from each device, then designing the SIEM to look for specific event IDs and/or message content. Considering the volume of data that a SIEM processes constantly, it does a good job of spotting events and content that it is actively looking for.

With the sheer number of devices on even the smallest networks, the number of events per device is usually limited, though it is still an overwhelming amount of data. The SIEM vendors realized that they could charge by the amount of data being analyzed and have built a cash cow out of it. Imagine how much functionally useless data costs to analyze.

This also means that organizations have backed off from collecting all events from security logs, instead looking at only a handful to ensure that the SIEM does not miss anything, while saving on costs to boot.

Log-based data

The traditional SIEM is logged-based, meaning it only looks at the events that are stored in the log. This has benefits and disadvantages. First, with the only source being a security log, the formatting can be dead simple and consistent. Nearly all vendors have conformed to standards allowing nearly any SIEM to consume and analyze the data.

On the other hand, having a standard does not mean the events or content of the event is standardized. This is where the first negative comes in. Almost every device must be manually configured in the SIEM (some do come preconfigured in the SIEM for a handful of events). This manual configuration, combined with the data cost, usually means the SIEM is looking at a very stripped-down view of the security log.

The other downside of relying solely on events from the security log (or any other log that falls within the standards), is that information not stored in security logs can be missed. If the device stores security information and/or events in a different file or format, the SIEM will be unable to consume that data. Often the attackers know about this limitation, so they tailor their attacks to bypass what the SIEM can see.

Minimal event gathering

Many organizations choose not to gather all events from the logs due to the cost and manual labor required to customize each event. Attackers know it too. If you look at the default events that SIEMs gather and focus on per device, they represent small percentages of the overall security events that could be gathered and analyzed.

For example, one mainstream SIEM gathers less than 20 events from a domain controller running Active Directory. Even though the security log on a domain controller has over 1000 events, the SIEM is only looking at five percent. Digging deeper into the events obtained, most are related to logon/authentication events: failure, success, password reset, password change, etc.

Although this level of security is important for many audits and compliance regulations, deeper security within AD needs to be analyzed in real time—something the SIEM simply can’t do.

Agent or privileges
often required

In some cases, the SIEM will offer an add-on that includes an agent-based component. This enhances the capability of the SIEM but comes at a cost.

First, the amount of information gathered from an agent can significantly increase the overall data flowing into the SIEM. Of course, if the SIEM is licensed by volume of data, this will spike the overall cost.

Second, if the volume of data increases yet the number of SOC/security analysts does not, the chance of the new data being analyzed manually (and efficiently) is slim. The analysts will need to create custom alerts and correlations to help them “see” the security issues coming from the acquisition of the agent.

Third, using an agent to gather information from a domain controller usually indicates that all changes will be monitored and stored in the SIEM database. Without detailed scripts to analyze the data or a human to dissect the data, it will be difficult to distinguish a security issue from normal behavior.

Finally, if an agent is being used to gather data from a domain controller, the agent’s service account will most likely need privileges. A security product should never require privileges, as they can be leveraged to compromise AD and the domain controllers. It would be a sad day to have your own security solution used to attack what it is meant to protect.

Customizing the SIEM

There are very few SIEMs that come with an exhaustive set of rules and alerts. The reason is the number of devices that a SIEM can handle, which all have different events and details . To gather more events and to know how to analyze them, the SIEM must be customized.

Customization is time-consuming

Customizing a SIEM takes time, knowledge, and patience. Consider that each device has a different set of events, event IDs, and details within the event. For each customization, the tech will need to develop the code, then test it. This means that each entry will need to be triggered on the device to ensure that the code works correctly. It would be a shame to spend hours creating a special event detection for a device, only to have a misspelled word or missing comma.

The maintenance of this customization is a full-time job. As devices are updated with new software, existing events will change slightly, and new events will be introduced. The existing code will need to be updated and again tested to ensure it is functioning correctly.

With new attacks and behavior being routinely introduced, the SIEM configuration and correlation rules must also be updated. This has proven to be a monthly process as of late, so there should be a team of SIEM developers ready to update the SIEM for both the updated AD-related attacks and all device attacks. This requires a broad, deep knowledge of how AD works and how an attacker could leverage even one missed attack pathway.

Correlation can miss info

A powerful aspect of any SIEM is the ability to create correlation rules to uncover actions and steps that might uncover an attack. The rules can span multiple devices, depicting the behavior that an attacker would take to move laterally and gain privileges throughout the environment. The creation of each rule requires expertise on how attackers move in a network, as well as the various routes they might take.

Correlation rules can generate false positives, however, as the steps listed may be what a normal user follows to install a service, access a database, etc. One of the major issues with correlation rules is that they must establish the steps exactly as the attacker behaves. For example, if the rule starts with “there are at least three failed logon attempts”, but the attacker is able to access the network with only two failed attempts, the rule will never trigger.

False positives

A major flaw with SIEM solutions is the fact that they generate false positives. A false positive is when an event is flagged, but the event is from desired activity. A good example would be if a new member is added to the Domain Admins group. Many SIEMs will flag this event, as having a new member of the Domain Admins group is a key aspect of domain security. However, it would require further action to determine if the new member is desired or not. This could be a call to the administrative team or a check into the change management system to see if there is an entry for a new member.

False positives can cause significant overhead for security analysts. Considering there are millions of events coming through a typical SIEM, having to manually determine if an alert is from a malicious, errant, or desired action takes time. In some cases, the SIEM can be configured to automatically remediate actions that are known to be rare and undesired, but even then it is hard to change a configuration which might have been desired and essential. No one wants to be responsible for breaking communication thanks to an automated task.

No context

SIEMs are efficient at gathering and analyzing voluminous data. They are also very good at parsing the content of events to pull out the details required by the analyst. However, what SIEMs are not so good at, and in most cases do not even provide, is giving relevant information regarding the alert or event. This requires knowledge of the system and surrounding devices and configurations.

The lack of context around SIEM alerts dramatically impacts the efficiency of the security analyst. The security analyst must take the event information provided by the SIEM and then analyze the content as stand-alone info within the context of other changes, as well as the existing infrastructure. This analysis is time-consuming and requires a deep understanding of the system/device from which the event came, as well as the other systems/devices with which the event might have some relationship.

Not real-time
(gathering, analysis, etc.)

The concept of real-time is becoming more and more important within the security world. With ransomware sitting and waiting for (mis)configurations, security professionals are on the clock to react. Any lag in the issue being sent to the administrative or security staff could prove costly. Also, it is essential that the information provided to the IT staff be detailed, so that no analysis is required before action is taken.

Unfortunately, SIEMs do not work with such immediacy. Often there is a lag from the moment the event is posted to the log, to when the SIEM receives it. There can also be a lag until the SIEM triggers the alert. Finally, most SIEMs fail to give the correct level of detail for the change or attack, so analysts are forced to triage the more important alerts. This could cause a mission-critical delay, allowing the attacker plenty of time to move through the network, create persistence, and even spread ransomware that encrypts the network data.

Filling the gap left by SIEMs

Clearly the SIEM is a useful and needed component of the overall security solution within an organization. Even smaller organizations benefit from a SIEM, as they still have a multitude of devices and mountain of security information requiring monitoring and analysis.

The gap is in failing to provide relevant information with real-time alerts to both administrators and security analysts. The solution should have the following characteristics:

  • Real-time
  • 24x7x365
  • Ability to find existing misconfigurations and attack pathways
  • Proactive alerting around misconfigurations and attack pathways
  • Reactive alerting around attacks as they occur
  • Contextdriven information and guidance
  • Seamless integration of existing SIEM and/or SOAR infrastructure and SOC team workflows
  • Agentless
  • No privileges
  • DC replication-based data gathering
  • Ability to communicate discovered issues to the SOC (SIEM/SOAR)

With a solution capable of providing these capabilities, the SIEM now has a security partner that can help with both existing and future issues as they appear. This will give the organization a full 360-degree view of the following aspects of AD security:

  • Uncover existing misconfigurations and attack pathways so they can be fixed ASAP
  • Real-time monitoring of any AD change that can then be analyzed
  • Constant analysis of any AD change to ensure a new attack pathway has not been opened
  • Instant alerts if an attack is launched against AD
  • Knowledge that the security solution cannot be used as an attack vector

Comments are closed.

Download pdf

Summary

SIEMs are an essential component when developing a complete security solution to protect AD and the rest of the network and devices. SIEMs give insights, provide centralized storage of security information, and can help with reporting and forensics. However, there are many aspects of a SIEM which leave the AD environment and the organization at large exposed to attack. Such an attack may never be brought to the attention of the IT staff, or the alert’s lag could allow the attack to proceed too far without remediation.

To fill these SIEM gaps and the others mentioned throughout this guide, a solution is required for every network running AD—one that provides insights directly into the SOC (via SIEM and SOAR solutions) regarding the existing AD security, ongoing AD changes, and alerting of attacks as they occur. It is only when the SIEM’s gaps are closed that the AD environment will achieve true security and the IT team can gain full awareness of all potential security issues within Active Directory.

Contact us