LinkedIn presents an endless list of concerns and complaints about the ongoing evolution of cybersecurity acronyms. But, to be honest, new acronyms do little to highlight a solution’s function. Take XDR, its function is as clear as mud.

To shed some light on the alphabet soup of acronyms, I put together a list of solutions, their objectives, and their pros & cons.


SIEM: Security Information and Event Management

A SIEM performs multiple functions:

  • Collects information from other tools: Your antivirus, firewall, Active Directory, and other security tools generate logs (information). Without a SIEM, you need to look at each tool’s management interface to see what’s happening. With a SIEM, you can have a single place to look at everything.
  • Normalize the information: Once the SIEM receives the data, it’s usually still in its raw or original format. Simply put, every software you use creates logs, and the format (or structure) of those logs is often different. A SIEM will extract important parts from the original logs and save them to a database, giving it a standard structure. For example, the logs may contain information about the date, time, user, computer, and action performed.
    • For example, when a user enters their username and password on a Windows 10 computer, on a MacBook, or a website, all of these systems have software that can (and should) log the activity. However, there’s no universal standard that dictates the format. A SIEM will extract the date, time, username, computer name, IP address, and the resulting action, and whether it is a successful connection or not.
  • Storage: The SIEM saves the data for short, medium, and long-term requirements and makes it searchable. A SIEM will often have the data in two formats: raw logs (data in the original format it was sent), and the normalized data found in the database. The raw logs may be required in the case of forensic investigations.
  • Correlates the information: This is how the system links multiple events together in what is often called a “use case” or a scenario.
    • For example, by collecting the logs from a building’s physical security system with badge card readers, you could compare the list of people that are in the office to the computer accounts being used on systems also located in the office to find discrepancies. The SIEM also can add exceptions, such as for staff that can access their systems remotely.
  • Generates alerts: The alerts are based on the correlations and other SIEM configuration parameters. The alerts aggregate the relevant information from the events linked to the correlations (use cases) to help the security analyst confirm if the event is a security incident, a minor anomaly, or a corporate policy violation.
  • Produce reports and dashboards: Their use depends on your objectives and may include compliance reports, security trends, incident dashboards.


A SIEM can typically adapt to most types of logs generated by an information system. This means that if your system can create a log or record of an event, a SIEM has the capabilities to ingest that information and normalize the data to make it usable.

Another function of the SIEM is to enable search capabilities. Search results and speed depend on several factors, such as the amount of data ingested, the underlying architecture, and its ability to ingest, normalize, and index the data.

Data can be correlated into use cases or scenarios, where rules and other configuration parameters are configured to identify potential security incidents. For example, generate an alert if a user connects by VPN and is also active on a computer connected to the local network.

The creation of these scenarios is limited by the data generated by the devices, corporate security policies and procedures, and the SIEM’s underlying capacity to ingest the ever-increasing amounts of data.


A SIEM is only as valuable as the data it ingests, and as such, this presents a few challenges:

  • Data sources must be configured and maintained: If the firewall admin disables the transmission of logs to the SIEM, you lose your visibility. Configuration changes can also wreak havoc on a SIEM. For example, imagine collecting only specific Active Directory events for the required use cases, and that configuration is modified to send ALL Active Directory logs to the SIEM. Imagine receiving 10x-50x more logs and what that can do to the SIEM.
  • Use cases must be well defined: It’s easy for a SIEM vendor to say they have hundreds of malicious scenarios they can detect, but how many can be used in your environment? What logs are needed? Are the scenarios realistic?
  • False-positives: A SIEM will generate a large number of false positives. Every new rule or correlation requires careful tuning to try and minimize the volume of alerts generated. Go too far in the adjustments, and you may miss important events (false negatives).
  • Expertise required: To deploy and operate a SIEM successfully requires collaboration:
    • System administrators: Informed and responsible for device log configuration and maintenance.
    • Network administrators: In addition to managing network devices, they must also ensure the network can reliably transmit the data to the SIEM.
    • Governance & Risk: Will provide guidance about the high-value incidents the SIEM should monitor and priorities given to expanding the monitoring capabilities.
    • SIEM Admin: Building and maintaining the solution, create new rules, reviews the SIEM’s health.
    • Security Analysts: Monitor, triages, and investigates the alerts generated by the SIEM. Proposes adjustments to reduce false positives.
    • Incident response team: May be composed of resources above, as well as the helpdesk, depending on the nature of the incident.


UBA: User Behavior Analytics

These solutions build baselines to identify anomalies within user-based activities. While they also collect system event logs, as a SIEM does, they focus on events that will include a username, so anything that is purely system-based application-based would is excluded from its analytics.


Building user-based profiles makes sense in theory: Your staff should have well-defined job descriptions requiring access to specific applications and a given set of privileges to accomplish these activities and tasks. Ideally, this is defined through role-based access control, and stored in a repository such as Active Directory. Using these building blocks, the UBA solution will monitor each user’s activity, creating a user-specific profile. It will also compare users with the same roles and identify outliers or activities that stand out.


While the theory is promising, the limiting factor is how well-defined your roles are, the tools and activities performed by people assigned to the roles. Baselines and statistics are difficult for the system to manage when there isn’t enough data. In a small organization, you are likely in a situation where many people play many different roles. How is the system supposed to determine what is expected behavior? On the flip side, if you only have two employees assigning to the same role, the system might generate many alerts based on activities one person performed.

In summary, the challenge in reaping the benefits of a UBA solution are:

  • Data sources must be configured and maintained: Roles must be maintained in Active Directory (or other Identity and Access Management solution).
  • Use cases must be tuned: UBA solutions are provided with various scenarios to identify anomalies and risky behaviors. Careful tuning must be done to the configuration to reduce false positives. Going too far in the tuning can put the solution at risk of missing important events.
  • Expertise required: A UBA requires expertise in many areas and typically requires the collaboration of a team to be successful:
    • I&AM System administrators: Informed and responsible for developing and maintaining roles and groups used to access the various IT systems.
    • Governance & Risk: Will provide guidance around the high-value events the UBA should monitor.
    • UBA Admin: Building and maintaining the solution, tuning the configuration, reviews the UBA’s health.
    • Security Analysts: Monitor, triages, and investigates the alerts generated by the UBA. Proposes adjustments to reduce false positives.
    • Incident response team: May be composed of resources above, as well as the helpdesk, depending on the nature of the incident.


SOAR: Security Orchestration, Automation, and Response

Security Orchestration, Automation, and Response solutions enable customers to link tasks into a logical workflow. This can be fully automated or include human interactions, depending on the capability of the SOAR technology and the external tools that are being integrated. For example, imagine you receive a call from the helpdesk indicating that a few devices are misbehaving and suspect malware. However, they can’t confirm what it is. You could have a manual process, and some steps such as:

  1. Create a security ticket.
  2. Confirm the endpoints are running the latest version of the AV and it’s active.
    • If this is true, run a full scan of the devices using a different AV.
      • If the malware is detected and cleaned, identify why it wasn’t blocked by the AV and how it entered the environment.
      • If no malware is found, quarantine the devices, and perform additional investigative steps.
    • If false, force the AV update, and attempt to restart the AV service.
  3. Confirm the endpoints are up to date on software patches.
  4. Once the threat is removed, take devices out of quarantine.
  5. Inform the helpdesk, and close the ticket.


  • Enables the automation of repetitive tasks, saving time, and ensures consistency.
  • SOAR automations can be used by people outside of the cybersecurity team. For example, they can be initiated by tickets, emails, or some other trigger.
  • Flexible integrations with the use of various scripting languages used to interact with external solutions. For example, you can use PowerShell scripts on Windows devices and Python to query web interfaces.


  • Depending on the solution, they can be costly depending on the licensing model. For example, some solutions have a cost for the number of times automations can be executed per month, or charge for specific features or integrations. A good understanding of the pricing models and tests are recommended.
  • A SOAR’s strength is also its weakness: automating activities implies they are known, documented, and repeated often enough to warrant the effort.
  • Once the automations are in place, like everything else, they require maintenance:
    • The scripts must maintain compatibility with the scripting language’s updates.
    • The workflows and scripts typically need to be reviewed if a target system is updated, moved, or replaced.
    • Connections to external systems may rely on APIs, and their features, capabilities, or connection syntax may change over time.
  • As with the other technologies here, training and expertise in the external systems is required to get the most out of a SOAR.


EDR: Endpoint (or Enterprise) Detection and Response

Endpoint Detection and Response solutions focus on devices such as laptops, workstations, servers, mobile devices. They concentrate on detecting potential threats that would have slipped through the other layers of detection and protection, whether at the network level or on the host itself, such as an antivirus.


  • Most solutions offer a cloud-based management console, which enables deployments to start quickly.
  • The endpoint agent software can be deployed using Remote Monitoring and Management (RMM) tools.
  • Alerts and events can be sent to a SIEM for additional analysis.


  • These solutions are often complex as they include many capabilities that are accessible from a single interface. The user must be very knowledgeable in cybersecurity, and about attacks against the endpoints they protect.
    • As with a SIEM, there may be a large number of false positives to investigate.
    • The capability to tune the solution means there’s a risk of creating blind spots and ignoring certain types of attacks.
  • Some solutions require physical or virtual log aggregation points to minimize the amount of data sent to the cloud.
  • Depending on the capabilities offered on the endpoints, the agent software can have a noticeable impact:
    • On system performance, as they analyze the data in real-time using the computer’s resources.
    • On user interactions required: Users may be asked to authorize or block an activity or program.
  • Assuming the tool does everything: As with any technology, people with the required expertise must maintain and operate it. The more complex the solution, the more expertise is required.


XDR: Extended Detection and Response

Extended Detection and Response solutions attempt to combine a SIEM with EDRs and sometimes a SOAR. However, the selling point here is that they all come from the same vendor. Contrary to the specialized solutions mentioned above, XDR’s main objective is to provide a more straightforward deployment path and optimized results. In addition, some will extend their capabilities further by including host IPS, anti-malware, and packet capture capabilities.


  • A single management console for all components.
  • One vendor relationship to manage.


  • The value comes from using all the tools. Unfortunately, this makes it more complex for customers to choose the solution as it is typically required to displace existing technologies to reap the benefits proposed by the vendor. If you don’t replace what you have, you’re back into a SIEM, with log collection for other sources, and the challenges that come with it.
  • All components may not be created equal: Considering the value comes from the consolidation, what happens if one or more modules don’t meet your requirements?
  • Will the XDR function with third-party solutions?


CYDEF: A Managed Detection and Response Solution Provider

At CYDEF, we had asked ourselves the same questions: should we consider ourselves an XDR and compete in that space? The reality is that we are focused on endpoints, detecting anomalous and malicious activities, and our capability to respond.

Contrary to traditional EDRs, we have an innovative approach to detecting attacks: We focus on outcomes and asking the question: Is this expected behavior in a corporate environment? This point of view has multiple advantages:

  • We don’t need to rely on knowledge about attack patterns, vulnerabilities, or misconfigurations.
  • We can not only detect malicious activity such as malware, ransomware, and other sophisticated attacks. We also detect anomalies, such as the use of crypto-miners, games, TOR browsers, and other activities that can be considered corporate security violations. In the end, they all add risk to your business.
  • We only need specific types of events, which means: lower RAM and bandwidth are required.
  • We don’t process the data on your endpoints, so we don’t impact its performance.

What you really care about are the outcomes:

  • Do you want a screen full of alerts you must review, investigate, validate and respond to, or do you prefer having a short list of confirmed incidents?

On top of this, we go a step further and provide our technology as a turnkey service:

  • We monitor your endpoints; no expertise is required on your part.
  • We monitor our agents; nothing works forever, and our team ensures we have visibility at all times.
  • We respond to malicious incidents by segregating the affected device.
  • We provide detailed information about anomalies and potential corporate policy violations. In addition, you can inform us about how your risk tolerance and we adapt to your needs.

If all of this seems daunting, don’t worry. You don’t need to be a cybersecurity expert to work with us. Contact us today to learn how our fully managed services can save you time, money, and headaches!

Elana Graham, COO, CYDEF
Elana Graham