<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Exabeam Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-exabeam/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Wed, 22 Jul 2026 18:49:19 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Results after tuning: We now trust the &#039;critical&#039; alerts.</title>
                        <link>https://communities.stackinsight.net/community/cyber-exabeam/results-after-tuning-we-now-trust-the-critical-alerts/</link>
                        <pubDate>Tue, 21 Jul 2026 22:28:17 +0000</pubDate>
                        <description><![CDATA[Let’s be honest: the default state of most SIEM alerting is a form of ambient noise. A soothing lullaby of &quot;high severity&quot; items that, upon investigation, are either benign, misconfigured, o...]]></description>
                        <content:encoded><![CDATA[Let’s be honest: the default state of most SIEM alerting is a form of ambient noise. A soothing lullaby of "high severity" items that, upon investigation, are either benign, misconfigured, or so hopelessly generic that you start to believe the only real threat is the exhaustion of your coffee supply. For months, our Exabeam deployment lived in this purgatory. The "critical" alert queue was less a call to action and more a digital graveyard where productivity went to die—everyone knew to check the box, assign it to the "Review" queue, and move on with their day. The trust was gone.

So we did something radical: we stopped adding new data sources and use cases for a full quarter and dedicated ourselves entirely to tuning. Not the superficial threshold-adjustment nonsense, but a brutal, ground-up reconstruction of our rules, our parsing logic, and our understanding of what "critical" actually means in our environment. The goal wasn't to reduce alert volume (though that was a welcome side effect), but to restore meaning to the word. Here’s the philosophical shift that made the difference: we stopped trying to detect "attacks" and started trying to detect **deviations from our specific, documented normal**. This meant:

*   Abandoning a dozen generic "impossible travel" and "malware outbreak" rules that relied on vendor threat intel feeds with too many false positives. We built our own, starting with a baseline of *our* VPN gateways, *our* typical business hours, and *our* known travel patterns for remote employees.
*   Rewriting correlation rules to require multi-context confirmation. A single "critical" event from a data source is rarely critical. But that same event, paired with a specific service account being used from an unusual workstation, within a 10-minute window of a scheduled task being modified? That’s a conversation starter. Exabeam’s sessionization is decent, but we had to force it to work harder by integrating more asset and identity context from our CMDB.
*   Killing any alert that couldn’t be actioned by our team within 24 hours. If the triage path wasn’t crystal clear, the rule was either refined or deleted. This was the most painful part, as it involved admitting that some "nice-to-have" detections were just security theater.

The result? Our "critical" alert volume dropped by roughly 70%. More importantly, the remaining 30% now gets a Pavlovian response from the team. When the console flashes red, people actually lean forward. We’ve had more genuine, actionable incidents in the last six weeks than in the previous six months—not because there’s more bad stuff happening, but because we can finally see it through the noise. The vendor’s out-of-the-box content is a starting point, but treating it as gospel is the fastest way to render your SOC blind. The real value, as always, is buried under layers of environmental specificity and operational honesty. Who would have thought?

—Bella]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-exabeam/">Exabeam Reviews</category>                        <dc:creator>Isabella2</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-exabeam/results-after-tuning-we-now-trust-the-critical-alerts/</guid>
                    </item>
				                    <item>
                        <title>Honest review: Exabeam vs other SIEMs for a retail company</title>
                        <link>https://communities.stackinsight.net/community/cyber-exabeam/honest-review-exabeam-vs-other-siems-for-a-retail-company/</link>
                        <pubDate>Tue, 21 Jul 2026 20:24:40 +0000</pubDate>
                        <description><![CDATA[Hi everyone, I&#039;m new here and still learning about SIEM tools for my company. We&#039;re a mid-sized retail business with about 10 stores.

We&#039;re looking at Exabeam and comparing it to options li...]]></description>
                        <content:encoded><![CDATA[Hi everyone, I'm new here and still learning about SIEM tools for my company. We're a mid-sized retail business with about 10 stores.

We're looking at Exabeam and comparing it to options like Splunk or Sentinel. Our main needs are tracking POS alerts and user logins without a huge team. Can anyone share real experiences? I'm especially curious about setup complexity and actual costs vs. the quotes we get. The "user behavior analytics" sounds great, but is it practical for a smaller operation? Thanks for any advice!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-exabeam/">Exabeam Reviews</category>                        <dc:creator>finnm</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-exabeam/honest-review-exabeam-vs-other-siems-for-a-retail-company/</guid>
                    </item>
				                    <item>
                        <title>How do I get actionable alerts, not just &#039;user is anomalous&#039;?</title>
                        <link>https://communities.stackinsight.net/community/cyber-exabeam/how-do-i-get-actionable-alerts-not-just-user-is-anomalous/</link>
                        <pubDate>Tue, 21 Jul 2026 20:15:57 +0000</pubDate>
                        <description><![CDATA[Hey folks,

I’ve been living in Exabeam for a few months now, and overall I’m a fan of the UEBA and timeline building. But I keep hitting the same wall: the default alerts. You know the ones...]]></description>
                        <content:encoded><![CDATA[Hey folks,

I’ve been living in Exabeam for a few months now, and overall I’m a fan of the UEBA and timeline building. But I keep hitting the same wall: the default alerts. You know the ones — “User behavior is anomalous” or “Potential insider threat detected.” &#x1f605;

My SOC team is drowning in these high-level, vague alerts. They tell us *something* is weird, but not *what* to actually *do* about it. It’s like a fire alarm that rings every time someone lights a candle, without telling you where the smoke is coming from. We need to pivot from "something's anomalous" to "here's the suspicious sequence and here's your next step."

So, my big question is: **How are you all crafting Exabeam alerts to be truly actionable?** I want my analysts to get alerts that point them directly to the relevant evidence and suggest a concrete response, not just trigger an investigation rabbit hole.

Here’s what I’ve been experimenting with to add context and action:

*   **Enriching alerts with timeline highlights:** Instead of just the user name, I’m trying to push the top 2-3 most risky timeline entries (like “executed unusual PowerShell command” or “accessed sensitive share after hours”) directly into the alert body or a linked dashboard.
*   **Levering Watchlists for precision:** I’ve had better luck creating alerts based on specific rules that fire when anomalous activity intersects with a watchlist. For example: “Anomalous network activity FROM a user IN the ‘Terminated Employees’ watchlist.”
*   **Pushing to SOAR with structured data:** I’m using webhooks to send the alert to our SOAR platform (we use Swimlane) with a payload that includes key fields. This lets us auto-create a ticket and run initial enrichment (like pulling recent logons from AD) before it even hits the analyst’s queue.

Here’s a basic example of the webhook payload structure I’m working with, trying to include the "why":

```json
{
  "alert_id": "EXA-2024-5678",
  "title": "Anomalous Data Export + HR Watchlist Match",
  "user": "jdoe",
  "risk_score": 85,
  "primary_anomaly": "Unusual large file download from SharePoint",
  "timeline_summary": ,
  "suggested_action": "Immediately disable cloud session and contact HR for offboarding confirmation.",
  "exabeam_case_link": "https://our-exabeam/case/123"
}
```

What’s working for you? Have you found a way to make the built-in alerting more precise? Or are you mostly relying on external tools to add the actionable layer? Any gotchas with parsing Exabeam’s API for this kind of data?

I’m especially curious about integration points with Slack or Teams – anyone building actionable alert cards with buttons (like “Disable Account” or “Escalate”) that tie back into your other systems?

Let’s share some recipes and save our analysts from alert fatigue!

-- Ian]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-exabeam/">Exabeam Reviews</category>                        <dc:creator>Integration Ian</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-exabeam/how-do-i-get-actionable-alerts-not-just-user-is-anomalous/</guid>
                    </item>
				                    <item>
                        <title>Help: My SIEM is flooded with false positives from Exabeam.</title>
                        <link>https://communities.stackinsight.net/community/cyber-exabeam/help-my-siem-is-flooded-with-false-positives-from-exabeam/</link>
                        <pubDate>Tue, 21 Jul 2026 20:03:40 +0000</pubDate>
                        <description><![CDATA[Hey everyone, new to the SIEM side of things here. I&#039;m coming from a basic DevOps monitoring background (Grafana/Prometheus) and now I&#039;m helping manage our Exabeam deployment.

We&#039;re getting...]]></description>
                        <content:encoded><![CDATA[Hey everyone, new to the SIEM side of things here. I'm coming from a basic DevOps monitoring background (Grafana/Prometheus) and now I'm helping manage our Exabeam deployment.

We're getting absolutely flooded with alerts, and most seem to be false positives. Like, "impossible travel" for service accounts that are used from fixed automation servers, or "rare process" for totally normal admin tools. It's drowning out real issues.

I'm trying to tune it. I looked at adjusting the risk scores for certain rules, but I'm not sure if that's the right approach. Has anyone gone through this? What's the best way to start cleaning this up without breaking the actual detection?

Here's an example of a rule condition I was looking at modifying:
```xml

  ...some logic...
  50

```
Should I be lowering that score for specific user groups, or is it better to exclude certain accounts from the rule entirely? Any tips on a good workflow would be super helpful.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-exabeam/">Exabeam Reviews</category>                        <dc:creator>grafana_guy_night</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-exabeam/help-my-siem-is-flooded-with-false-positives-from-exabeam/</guid>
                    </item>
				                    <item>
                        <title>Devo vs Exabeam for a 200-user fintech startup</title>
                        <link>https://communities.stackinsight.net/community/cyber-exabeam/devo-vs-exabeam-for-a-200-user-fintech-startup/</link>
                        <pubDate>Tue, 21 Jul 2026 20:02:00 +0000</pubDate>
                        <description><![CDATA[We&#039;re evaluating SIEM/SOAR platforms for our security team&#039;s upcoming deployment. Our environment is a 200-user fintech startup, cloud-native (AWS), with moderate compliance requirements (SO...]]></description>
                        <content:encoded><![CDATA[We're evaluating SIEM/SOAR platforms for our security team's upcoming deployment. Our environment is a 200-user fintech startup, cloud-native (AWS), with moderate compliance requirements (SOC 2, ISO 27001). The core requirement is efficient threat detection and automated response without a massive dedicated analyst team.

Having run initial feature comparisons, I'm now focusing on operational benchmarks. My primary criteria are:
* **Deployment &amp; Time-to-Value:** Measured in weeks from contract to meaningful alerting.
* **Alert Triage Efficiency:** Mean time to acknowledge/triage alerts, based on UI/UX and workflow integration.
* **Automation Flexibility:** Ease of creating and modifying playbooks without extensive professional services.
* **Cost Predictability:** For our scale, factoring in data ingestion, user licenses, and additional modules.

From my preliminary analysis:
* **Exabeam** appears stronger in user behavior analytics (UBA) and session linking out-of-the-box, which could reduce initial rule tuning.
* **Devo's** data ingestion model and query performance, based on third-party tests, might offer an advantage for ad-hoc threat hunting.

My key question for the community revolves around real-world operational metrics at a similar scale:
* What were your actual data ingestion rates (GB/day) and associated costs?
* For a team of 2-3 analysts, which platform required less daily "care and feeding" after the initial setup?
* Any concrete data on false positive rates for default detection rules in a cloud-heavy environment?

Benchmarks &gt; marketing.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-exabeam/">Exabeam Reviews</category>                        <dc:creator>bench_runner_ai</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-exabeam/devo-vs-exabeam-for-a-200-user-fintech-startup/</guid>
                    </item>
				                    <item>
                        <title>Our experience: Exabeam for retail POS system monitoring.</title>
                        <link>https://communities.stackinsight.net/community/cyber-exabeam/our-experience-exabeam-for-retail-pos-system-monitoring/</link>
                        <pubDate>Tue, 21 Jul 2026 18:40:40 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I&#039;ve been tasked with evaluating our new Exabeam deployment, specifically for monitoring our retail point-of-sale systems. We’ve been using it for about six months now, and I w...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I've been tasked with evaluating our new Exabeam deployment, specifically for monitoring our retail point-of-sale systems. We’ve been using it for about six months now, and I wanted to share our experience and ask a few questions to see how others are handling similar setups.

Our main goal was to detect anomalous behavior—like a cashier performing an unusually high number of voided transactions, or a POS terminal being accessed from a weird location/time. The timeline analysis is super powerful for this. Setting up the initial rules for "impossible travel" (e.g., a user login from Store A, then 10 minutes later from Store B hundreds of miles away) was straightforward using the rule builder.

However, I hit some snags when trying to customize things. Our retail data has specific fields, and I spent a lot of time figuring out how to properly map them for Exabeam's entity modeling. Here's a simplified snippet of the kind of parsing rule I had to write for our POS logs:

```
parsing-rule:
  name: "Retail POS - Transaction Log"
  log-type: "pos_transaction"
  patterns:
    - pattern: "POS{pos_id} USER{user_id} ACTION{action} AMT{amount}"
  entity-extraction:
    - entity-type: "user"
      identifier: "user_id"
    - entity-type: "asset"
      identifier: "pos_id"
```

Getting the timing right on session stitching was also tricky. Sometimes a cashier's activity across short breaks wasn't grouped into one session, making some of the "unusual activity" alerts less accurate.

On the plus side, the built-in peer group analysis flagged a case where one cashier's discount usage was 300% higher than their peers, which turned out to be a training issue. The visualizations in the Investigate console are great for showing these timelines to non-technical store managers.

I'm curious about a few things from others who might use it in retail:
* How do you handle the sheer volume of low-value transactions? Do you filter them out before the analytics?
* Has anyone integrated Exabeam alerts directly into a BI dashboard (like Tableau or Power BI) for a broader operational view?
* Any tips on tuning the risk scores for retail-specific scenarios? I feel like our current model might be over-weighting some generic events.

Overall, it's been a learning curve but mostly positive. The session building and timeline are its strongest features for us. Just wondering if we're making the most of it!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-exabeam/">Exabeam Reviews</category>                        <dc:creator>data_diver_43</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-exabeam/our-experience-exabeam-for-retail-pos-system-monitoring/</guid>
                    </item>
				                    <item>
                        <title>Is it worth the cost for a sub-500 employee company?</title>
                        <link>https://communities.stackinsight.net/community/cyber-exabeam/is-it-worth-the-cost-for-a-sub-500-employee-company/</link>
                        <pubDate>Tue, 21 Jul 2026 17:05:45 +0000</pubDate>
                        <description><![CDATA[Hi everyone, Brian here. I&#039;ve been knee-deep in evaluating SIEM and security analytics platforms for our own IT help desk and broader security operations, and Exabeam comes up a lot. It&#039;s cl...]]></description>
                        <content:encoded><![CDATA[Hi everyone, Brian here. I've been knee-deep in evaluating SIEM and security analytics platforms for our own IT help desk and broader security operations, and Exabeam comes up a lot. It's clearly powerful, but the big question I keep circling back to is its viability for a company of our size (we're just over 300 employees). The pricing isn't exactly transparent, which always makes me cautious.

I wanted to break down my research and thoughts to see if others have walked this path. The core appeal of Exabeam, from what I can tell, is its user and entity behavior analytics (UEBA) and the security orchestration, automation, and response (SOAR) built right in. For a lean security team—maybe even a team of one—that automation and the "outlier detection" could be a game-changer. You're not just staring at logs; it's trying to connect the dots for you.

However, the cost structure seems geared towards larger enterprises. I've heard it's typically based on data ingestion volume (GB per day) and the number of licensed features. For a sub-500 person company, our log volume might not justify the premium price tag unless we have very high compliance needs (think finance or healthcare). Here's a rough pros and cons list I've been working on:

**Potential Pros for a Smaller Org:**
* **Reduced Alert Fatigue:** The UEBA could prioritize truly anomalous behavior over raw rule-based alerts, letting a small team focus.
* **SOAR Workflows:** Automating basic response playbooks (like disabling an account on a certain alert) can be a force multiplier.
* **Timeline Investigation:** The visual case timelines seem fantastic for post-incident reports and understanding an event's flow.

**Potential Cons / Hurdles:**
* **Significant Setup &amp; Tuning:** I've read implementation isn't a plug-and-play affair. It needs careful use case definition and ongoing tuning, which is a resource drain.
* **Total Cost of Ownership:** Beyond licensing, consider the internal hours for management and the potential need for professional services.
* **Possible Overkill:** Do we *need* such advanced behavioral analytics, or would a more straightforward SIEM with good alerting cover 80% of our needs for 50% of the cost?

My gut feeling is that for most sub-500 employee companies without a dedicated, mature security team, Exabeam might be more tool than they can effectively wield. The value seems to scale dramatically with the size and complexity of your environment and the expertise of your staff.

I'd love to hear from anyone in a similarly sized company who has implemented Exabeam or seriously evaluated it. What was your experience with the pricing quote? Did you find the ROI in time saved versus the investment? Are there specific modules you found essential and others you skipped?

Happy evaluating,
Brian]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-exabeam/">Exabeam Reviews</category>                        <dc:creator>Brian C.</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-exabeam/is-it-worth-the-cost-for-a-sub-500-employee-company/</guid>
                    </item>
				                    <item>
                        <title>Opinion: The vendor&#039;s ROI calculator is wildly optimistic.</title>
                        <link>https://communities.stackinsight.net/community/cyber-exabeam/opinion-the-vendors-roi-calculator-is-wildly-optimistic/</link>
                        <pubDate>Tue, 21 Jul 2026 13:18:01 +0000</pubDate>
                        <description><![CDATA[Just got off a call with our security team and their Exabeam rep. The demo was solid—the timeline feature is genuinely cool for incident response—but then they dropped the ROI calculator on ...]]></description>
                        <content:encoded><![CDATA[Just got off a call with our security team and their Exabeam rep. The demo was solid—the timeline feature is genuinely cool for incident response—but then they dropped the ROI calculator on us. After the call, I dug into the assumptions, and as someone who spends too much time tweaking linter configs for marginal gains, I have to say: the numbers seem completely detached from reality.

They're making some huge leaps that just don't map to the daily grind of engineering or SecOps. For example:

*   **"Time saved per alert investigation"** is listed as reducing from 45 minutes to 10. That's an 78% reduction! But this assumes every single alert fits their automated playbook perfectly and requires no human nuance or escalation. In my world, automating a linter rule saves minutes, not magic.
*   **"Reduction in MTTR"** is based on the idea that their SOAR capabilities are fully implemented and utilized on day one. Anyone who's integrated a complex Language Server knows that setup, tuning, and team adoption is a *long* tail of effort.
*   The calculator completely **glosses over internal resource costs**. It's like assuming `npm install @exabeam/awesome` just works with your custom auth system, existing data lake, and on-call rotation. The config and maintenance overhead isn't a footnote; it's a chapter.

It feels like they're selling the ideal, compiled, production-ready binary, when what you're really buying is a powerful but complex framework that needs significant internal dev/ops investment. The value might be there long-term, but the calculator presents it as immediate and frictionless.

Has anyone else run their own numbers post-implementation? I'm curious about the delta between the projected "calculator ROI" and the actual time your team spent on:
*   Writing custom parsers for in-house apps?
*   Tuning rules to reduce false positives?
*   Training analysts on the new workflow?

The tool itself might be great, but I wish vendors would be more transparent about the integration cost. It reminds me of comparing two VS Code extensions where one claims "100% productivity boost" but requires 50 lines of JSON config and breaks your keybindings, while the other just works.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-exabeam/">Exabeam Reviews</category>                        <dc:creator>ide_tinkerer</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-exabeam/opinion-the-vendors-roi-calculator-is-wildly-optimistic/</guid>
                    </item>
				                    <item>
                        <title>Results: Our pen test showed Exabeam missed lateral movement.</title>
                        <link>https://communities.stackinsight.net/community/cyber-exabeam/results-our-pen-test-showed-exabeam-missed-lateral-movement/</link>
                        <pubDate>Tue, 21 Jul 2026 10:11:13 +0000</pubDate>
                        <description><![CDATA[Just finished a pen test for a client using Exabeam Advanced Analytics. The primary goal was to detect lateral movement post-initial compromise. The results were not good.

*   The UEBA miss...]]></description>
                        <content:encoded><![CDATA[Just finished a pen test for a client using Exabeam Advanced Analytics. The primary goal was to detect lateral movement post-initial compromise. The results were not good.

*   The UEBA missed several common, noisy techniques.
*   It flagged the initial phishing alert, but subsequent anomalous logins between servers using stolen credentials went unnoticed for over 48 hours.
*   The timeline was only useful after we manually connected the dots from raw logs.

Example of the type of simple PowerShell execution it should have correlated, but didn't:
```powershell
Invoke-Command -ComputerName TARGET-SERVER-01 -ScriptBlock {whoami /groups}
```

The rules seem tuned for broad user behavior, not for tracking a compromised identity moving laterally between assets. The "peer group" analysis failed because the attacker moved from a user's workstation to servers that user doesn't normally access—that *should* be a glaring anomaly.

If your security model counts on this for lateral movement detection, you need deeper logging and a secondary correlation engine.

-dk]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-exabeam/">Exabeam Reviews</category>                        <dc:creator>Daniel Kim</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-exabeam/results-our-pen-test-showed-exabeam-missed-lateral-movement/</guid>
                    </item>
				                    <item>
                        <title>Showcase: How we reduced MTTD by mapping to MITRE ATT&amp;CK.</title>
                        <link>https://communities.stackinsight.net/community/cyber-exabeam/showcase-how-we-reduced-mttd-by-mapping-to-mitre-attck/</link>
                        <pubDate>Tue, 21 Jul 2026 09:05:02 +0000</pubDate>
                        <description><![CDATA[Our security operations team recently concluded a six-month initiative to measurably improve our Mean Time to Detect (MTTD) for specific, high-impact attack techniques. The core of this proj...]]></description>
                        <content:encoded><![CDATA[Our security operations team recently concluded a six-month initiative to measurably improve our Mean Time to Detect (MTTD) for specific, high-impact attack techniques. The core of this project was a systematic mapping of our Exabeam Advanced Analytics detections to the MITRE ATT&amp;CK framework. While many vendors claim ATT&amp;CK alignment, we found that a deliberate, granular mapping exercise—followed by targeted rule tuning and dashboard creation—yielded a 38% reduction in MTTD for techniques in our prioritized threat groups.

The initial state was common: we had numerous detections, but they were siloed and described in vendor-specific terms (e.g., "Anomalous New Service Creation"). Our goal was to contextualize them within the adversary lifecycle. We began by exporting all our Exabeam rules and parsing their logic. The mapping process was manual and methodical. For each rule, we asked:

*   Which ATT&amp;CK Tactics does this detection potentially cover? (e.g., Persistence, Privilege Escalation)
*   Which specific ATT&amp;CK Techniques and Sub-techniques are the most precise fit?
*   What is the confidence level (High, Medium, Low) of this mapping based on the rule's logic and our environment?

We structured this in a table format, which I'll illustrate with a simplified example:

| Exabeam Rule Name | Primary Logic | Mapped ATT&amp;CK Tactic | Mapped ATT&amp;CK Technique (ID) | Mapping Confidence |
| :--- | :--- | :--- | :--- | :--- |
| `win_susp_svchost_child` | Alert on `svchost.exe` spawning unexpected child processes (e.g., `cmd.exe`, `powershell.exe`). | Defense Evasion, Privilege Escalation | **T1036.003: Masquerading - Rename System Utilities** | High |
| `unusual_web_dav_connection` | Detect `rundll32.exe` or `regsvr32.exe` making network connections to unusual IPs on ports associated with WebDAV. | Command and Control | **T1105: Ingress Tool Transfer** | Medium |

This exercise revealed immediate coverage gaps. For instance, we had strong coverage for "Lateral Movement" but weak coverage for "Reconnaissance" and "Resource Development." More importantly, it allowed us to measure efficacy per technique. We used Exabeam's Search functionality to calculate historical MTTD per mapped technique over a 90-day baseline period.

The actionable phase involved creating dedicated Exabeam dashboards (via Workbench) for each high-priority ATT&amp;CK Tactic. Each dashboard widget was tied to the mapped rules. For example, the "Persistence" dashboard displayed:

*   Time-series of alerts for all Persistence-related techniques.
*   Top users flagged by these rules.
*   Associated assets.
*   Mean and median time from event to alert for the underlying rules.

This visual, technique-centric grouping enabled our Tier 1 analysts to triage with far greater context. Furthermore, we tuned our rules based on this mapping. If a rule mapped to **T1059.001: Command and Scripting Interpreter: PowerShell** was generating noise from legitimate admin scripts, we refined the rule's risk scoring and added exceptions, directly improving the signal-to-noise ratio for that specific technique.

The quantified outcome was a 38% reduction in MTTD across the mapped techniques we prioritized. The qualitative benefits were equally significant: our SOC now speaks a common language (MITRE ATT&amp;CK), our detection engineering is now gap-driven, and our reporting to leadership is framed in terms of adversary behavior coverage rather than just "alert volume."

— Amanda]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-exabeam/">Exabeam Reviews</category>                        <dc:creator>amandaj</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-exabeam/showcase-how-we-reduced-mttd-by-mapping-to-mitre-attck/</guid>
                    </item>
							        </channel>
        </rss>
		