<?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>
									Elastic Security Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-elastic-security/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Fri, 24 Jul 2026 06:06:55 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Is Elastic Security worth the price? Honest review after 12 months</title>
                        <link>https://communities.stackinsight.net/community/cyber-elastic-security/is-elastic-security-worth-the-price-honest-review-after-12-months/</link>
                        <pubDate>Tue, 21 Jul 2026 22:01:09 +0000</pubDate>
                        <description><![CDATA[Hey everyone, junior dev here. My team has been using Elastic Security (the SIEM/security part of the Elastic Stack) for a year now. We&#039;re a mid-sized SaaS on AWS. I was tasked with helping ...]]></description>
                        <content:encoded><![CDATA[Hey everyone, junior dev here. My team has been using Elastic Security (the SIEM/security part of the Elastic Stack) for a year now. We're a mid-sized SaaS on AWS. I was tasked with helping manage it because I know a bit of Terraform.

I'm trying to figure out if we should keep it. The price tag is getting noticeable on our cloud bill. &#x1f605;

The good: Setting up the agent with Terraform was straightforward. The detection rules are powerful once you get them. I like that it's not a black box.

```hcl
resource "aws_instance" "log_forwarder" {
  # ... instance config
  user_data = templatefile("elastic-agent.yml.tftpl", {
    fleet_url = var.elastic_fleet_url
    enrollment_token = var.enrollment_token
  })
}
```

The not-so-good: The learning curve is steep. Tuning alerts to avoid noise took months. Also, the cost scales with data ingestion, and we sometimes get surprised by volume spikes from our own apps.

For a team with limited security experts, is it worth it? Or are we better with a more managed service? Curious about your experiences.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-elastic-security/">Elastic Security Reviews</category>                        <dc:creator>cloud_infra_newbie</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-elastic-security/is-elastic-security-worth-the-price-honest-review-after-12-months/</guid>
                    </item>
				                    <item>
                        <title>Thoughts on the new pre-built rules for SaaS app compromise? Any good?</title>
                        <link>https://communities.stackinsight.net/community/cyber-elastic-security/thoughts-on-the-new-pre-built-rules-for-saas-app-compromise-any-good/</link>
                        <pubDate>Tue, 21 Jul 2026 20:14:38 +0000</pubDate>
                        <description><![CDATA[Hey everyone! I&#039;ve been trying to get a better handle on securing our SaaS apps (we use a bunch like Salesforce, HubSpot, and Google Workspace). I saw Elastic Security rolled out a bunch of ...]]></description>
                        <content:encoded><![CDATA[Hey everyone! I've been trying to get a better handle on securing our SaaS apps (we use a bunch like Salesforce, HubSpot, and Google Workspace). I saw Elastic Security rolled out a bunch of new pre-built rules focused on "SaaS app compromise" and got really excited! &#x1f60a;

I'm still pretty new to this side of things though. Has anyone had a chance to test these out? I'm curious if they're actually useful for catching real-world stuff, like weird login patterns or data exfiltration from these platforms.

What's the setup like? Do they work well out of the box, or do they need a ton of tweaking? Also, are they covering the main apps most businesses use? I'd love to hear if anyone has any early experiences or even gotchas.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-elastic-security/">Elastic Security Reviews</category>                        <dc:creator>hannahb</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-elastic-security/thoughts-on-the-new-pre-built-rules-for-saas-app-compromise-any-good/</guid>
                    </item>
				                    <item>
                        <title>Just built a custom dashboard for our SOC. Sharing the JSON config.</title>
                        <link>https://communities.stackinsight.net/community/cyber-elastic-security/just-built-a-custom-dashboard-for-our-soc-sharing-the-json-config/</link>
                        <pubDate>Tue, 21 Jul 2026 18:55:29 +0000</pubDate>
                        <description><![CDATA[Hey everyone, been lurking for a while but this is my first post. I&#039;m a junior analyst on our SOC team, and I&#039;ve been tasked with helping to make our Elastic Security dashboards a bit more a...]]></description>
                        <content:encoded><![CDATA[Hey everyone, been lurking for a while but this is my first post. I'm a junior analyst on our SOC team, and I've been tasked with helping to make our Elastic Security dashboards a bit more actionable for the tier 1 folks. The default ones are great, but we wanted something that combined threat alerts with some of our internal asset context.

I spent the last couple of weeks learning the ins and outs of Lens and the Dashboard JSON structure. It was a bit of a deep dive! I just finished a custom "SOC Overview" dashboard that our team lead actually liked. The goal was to have a single pane showing high-priority alerts, correlated with the top noisy source IPs and a breakdown by our critical asset tags.

I'm sharing the JSON config below in case it's useful for anyone else starting out. I'd also love any feedback, especially on the KQL filters or visualization choices—I'm sure there are better ways to do this.

```json
{
  "title": "SOC Overview - Custom",
  "description": "Overview of high &amp; critical alerts with asset context.",
  "panelsJSON": "[{"version":"8.13.0","panelIndex":"panel_1","gridData":{"x":0,"y":0,"w":24,"h":15,"i":"panel_1"},"panelType":"lens","embeddableConfig":{"attributes":{"title":"","visualizationType":"lnsDatatable","state":{"datasourceStates":{"indexpattern":{"layers":{"layer_1":{"columns":{"col_1":{"label":"Alert Count","data]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-elastic-security/">Elastic Security Reviews</category>                        <dc:creator>data_diver_43</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-elastic-security/just-built-a-custom-dashboard-for-our-soc-sharing-the-json-config/</guid>
                    </item>
				                    <item>
                        <title>Elastic Security deployment for a healthcare org - what we wish we knew</title>
                        <link>https://communities.stackinsight.net/community/cyber-elastic-security/elastic-security-deployment-for-a-healthcare-org-what-we-wish-we-knew/</link>
                        <pubDate>Tue, 21 Jul 2026 18:52:11 +0000</pubDate>
                        <description><![CDATA[They sold us on the &quot;single platform&quot; vision. Now we&#039;re the ones paying for it.

Our team spent months trying to make the default agent configs work for our HIPAA logging requirements. The v...]]></description>
                        <content:encoded><![CDATA[They sold us on the "single platform" vision. Now we're the ones paying for it.

Our team spent months trying to make the default agent configs work for our HIPAA logging requirements. The volume of data from Windows endpoints alone required a separate Elasticsearch cluster just to keep ingestion from falling over. The "security" features are fine if your network looks like their tutorials. Ours doesn't.

The real cost isn't the license. It's the constant tuning, the proprietary agent syntax, and the fact that every new detection rule assumes you're using their entire stack. Want to point their SIEM at a Postgres audit log? Enjoy writing custom ingest pipelines that break on every minor version update.

We're now evaluating a switch to a more modular setup. The migration plan looks painful.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-elastic-security/">Elastic Security Reviews</category>                        <dc:creator>henryg</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-elastic-security/elastic-security-deployment-for-a-healthcare-org-what-we-wish-we-knew/</guid>
                    </item>
				                    <item>
                        <title>Elastic Security after 18 months - real experience from a SOC team</title>
                        <link>https://communities.stackinsight.net/community/cyber-elastic-security/elastic-security-after-18-months-real-experience-from-a-soc-team/</link>
                        <pubDate>Tue, 21 Jul 2026 17:47:14 +0000</pubDate>
                        <description><![CDATA[Hi everyone! I&#039;m still pretty new to the DevOps/SecOps world, so I really appreciate this community. &#x1f60a;

We&#039;ve been running Elastic Security in our SOC for about a year and a half now...]]></description>
                        <content:encoded><![CDATA[Hi everyone! I'm still pretty new to the DevOps/SecOps world, so I really appreciate this community. &#x1f60a;

We've been running Elastic Security in our SOC for about a year and a half now. Overall, it's powerful, but I wanted to share some real hurdles we faced that might help other beginners.

The biggest surprise was the resource usage. Our initial dev cluster specs were way too low. We learned the hard way that you need to plan for growth from day one. Here's a snippet from our updated `elasticsearch.yml` that helped stabilize things:

```yaml
# Had to adjust these after constant memory pressure alerts
thread_pool.search.queue_size: 2000
thread_pool.write.queue_size: 1000
bootstrap.memory_lock: true
```

Also, custom rule creation has a steep learning curve. Writing precise detection rules in KQL took our team months to feel comfortable with. The prebuilt rules are great, but tuning them to avoid false positives was a constant task.

For those of you with more experience, what are your best practices for managing Elastic's resource footprint over time? And any tips for streamlining alert tuning? Thanks in advance for any guidance!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-elastic-security/">Elastic Security Reviews</category>                        <dc:creator>devops_rookie_2025</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-elastic-security/elastic-security-after-18-months-real-experience-from-a-soc-team/</guid>
                    </item>
				                    <item>
                        <title>Migrated from Splunk to Elastic Security - 6 month deployment report</title>
                        <link>https://communities.stackinsight.net/community/cyber-elastic-security/migrated-from-splunk-to-elastic-security-6-month-deployment-report/</link>
                        <pubDate>Tue, 21 Jul 2026 09:52:45 +0000</pubDate>
                        <description><![CDATA[Six months ago, the powers that be decided our Splunk bill was an excellent source of venture capital for their shareholders. We were ordered to migrate our security operations to Elastic Se...]]></description>
                        <content:encoded><![CDATA[Six months ago, the powers that be decided our Splunk bill was an excellent source of venture capital for their shareholders. We were ordered to migrate our security operations to Elastic Security. The mandate was delivered with the usual buzzwords: "unified platform," "cost efficiency," and "open source ethos." Having now lived through the deployment and half a year of daily use, I can offer a somewhat drier, more grounded assessment.

Let's start with the obvious win: cost. It's cheaper. Dramatically so. We're not paying per gigabyte ingested, which changes the entire calculus around log verbosity. You can actually turn on debug logging for a problematic system without triggering a financial review. That part of the "unified platform" pitch is, for once, not marketing fluff.

However, the transition was akin to swapping a fully furnished apartment for a plot of land and a pile of lumber. The Elastic Stack is powerful, but it expects you to be your own architect and carpenter. Out of the box, the security content is decent but sparse compared to Splunk's vast ecosystem. We spent months:
- Normalizing our custom logs to ECS. A noble goal, but a tedious, ongoing process.
- Building detection rules that Splunk Enterprise Security provided off-the-shelf.
- Recreating dashboard visualizations that our analysts had taken for granted.

The pain point isn't capability; it's convenience. Kibana is a capable visualization tool, but its UX for security workflows feels like a dashboard tool that had security features bolted on. The separation between Discover, Dashboards, and the Security app creates friction. An analyst hunting an anomaly shouldn't need to understand the architectural nuances of the Elastic suite.

Performance is a mixed bag. Searches across hot data are blisteringly fast. But once you're into warmer tiers, the experience degrades noticeably, and tuning index lifecycle management becomes a new part-time job for someone. The assumption that you'll have a dedicated Elastic engineer on staff is not unfounded. If you don't, you'll be developing that expertise rapidly, often during incidents.

So, the final tally? For a lean, engineering-oriented team willing to invest significant upfront effort in building their own security "product," Elastic can be a justifiable choice. The cost savings are real and substantial. But if you're expecting a polished, out-of-the-box SOC experience that lets you focus on threats instead of tooling, you've migrated to the wrong planet. You'll be building that SOC yourself, one painstakingly crafted detection rule at a time.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-elastic-security/">Elastic Security Reviews</category>                        <dc:creator>eliot77</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-elastic-security/migrated-from-splunk-to-elastic-security-6-month-deployment-report/</guid>
                    </item>
				                    <item>
                        <title>Troubleshooting: High latency on dashboards with only 50GB of daily ingest.</title>
                        <link>https://communities.stackinsight.net/community/cyber-elastic-security/troubleshooting-high-latency-on-dashboards-with-only-50gb-of-daily-ingest/</link>
                        <pubDate>Tue, 21 Jul 2026 09:30:25 +0000</pubDate>
                        <description><![CDATA[Hi everyone! &#x1f44b; I’ve been running Elastic Security for a few months now, primarily for our email security and marketing infrastructure log monitoring. I’m a huge fan of the feature se...]]></description>
                        <content:encoded><![CDATA[Hi everyone! &#x1f44b; I’ve been running Elastic Security for a few months now, primarily for our email security and marketing infrastructure log monitoring. I’m a huge fan of the feature set, especially the ability to segment alerts by campaign or user behavior—it feels like my martech brain’s playground!

However, I’ve hit a persistent issue that’s really puzzling my methodical side, and I wanted to lay it all out to see if anyone has done a similar comparison or found a fix. Our daily ingest is relatively modest—around 50GB—but we’re experiencing surprisingly high latency on our security dashboards. We’re talking 10-15 second load times for some of the prebuilt Elastic Security overviews, and even custom visualizations with simple filters feel sluggish.

Here’s what I’ve already checked and compared side-by-side with our staging setup:

*   **Indexing Rate:** Steady, no huge spikes. The 50GB/day is consistent.
*   **Shard Configuration:** We’re using the default ILM policy from the Elastic Security integration. Our primary hot phase has about 15 shards per data stream (like `logs-*` and `metrics-*`), each shard sitting around 2-4GB.
*   **Hardware Resources:** The dedicated data nodes have 16 vCPUs, 64GB RAM, and SSD storage. CPU usage hovers around 40-60%, memory pressure seems okay.
*   **Query Complexity:** The latency happens even on dashboards that don’t seem *that* complex, like the “Overview” page. It’s not just the fancy, widget-heavy ones.

My gut tells me the issue might be in one of these areas, but I’d love your collective wisdom:

*   **Shard Saturation:** Could 15 shards per stream be too many for our volume, causing overhead? I’ve read conflicting things about shard count versus ingest size.
*   **Field Mapping Explosion:** With all the ECS fields being populated, are we dealing with a mapping or field count issue that’s slowing searches? Is there a way to audit that easily?
*   **Dashboard Composition:** Maybe some hidden expensive aggregations in the prebuilt visualizations? I haven’t dug into each one’s underlying query yet.

Has anyone with a similar ingest volume run into this and done a successful side-by-side before/after test with a configuration change? I’m particularly curious if tweaking the `index.number_of_shards` for new indices or reviewing the list of enabled modules made a difference for you.

I’m ready to put on my troubleshooting hat and run some tests—any pointers on where to start would be incredibly appreciated]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-elastic-security/">Elastic Security Reviews</category>                        <dc:creator>elena_g</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-elastic-security/troubleshooting-high-latency-on-dashboards-with-only-50gb-of-daily-ingest/</guid>
                    </item>
				                    <item>
                        <title>Anyone actually using Elastic Security in production for threat hunting?</title>
                        <link>https://communities.stackinsight.net/community/cyber-elastic-security/anyone-actually-using-elastic-security-in-production-for-threat-hunting/</link>
                        <pubDate>Tue, 21 Jul 2026 08:44:33 +0000</pubDate>
                        <description><![CDATA[Alright, I have to ask this because I&#039;ve been knee-deep in feature matrices and Gartner reports for weeks, and there&#039;s a gap between what&#039;s on paper and what&#039;s happening on the ground. I see...]]></description>
                        <content:encoded><![CDATA[Alright, I have to ask this because I've been knee-deep in feature matrices and Gartner reports for weeks, and there's a gap between what's on paper and what's happening on the ground. I see all the capabilities listed for Elastic Security—the open source foundation, the integrations, the promise of blending SIEM, endpoint, and cloud data for proactive hunting. But when I talk to peers at other shops, the conversation always pivots to Splunk, Sentinel, or CrowdStrike for the "serious" threat hunting work.

So, I'm genuinely curious: is anyone here **operationally** using Elastic Security (not just ingesting logs, but actively hunting) in a production environment? I'm talking about a dedicated person or team building custom detection rules, using the Timeline feature in Kibana to pivot across indices, and regularly running EQL (Event Query Language) queries to find weirdness that the canned alerts missed.

My interest comes from our own A/B testing background—I love the idea of having all our telemetry (web app logs, CRM events, network data) in one place to correlate with security events. The potential for a unified data layer is huge from an analytics perspective. But I need some real-world validation before I advocate for a deeper investment.

Specifically, I'd love to hear about:

*   **Your data scale &amp; team size:** Are you hunting over terabytes per day? Is this a one-person show or a dedicated SOC?
*   **The hunting workflow:** Do you live in Kibana's Security app? How do you structure your timelines? Are pre-built rules (like the Elastic pre-packaged ones) actually useful as a starting point, or do you end up writing everything custom?
*   **The pain points:** I'm sure there are some. Is it the learning curve for EQL? Performance when querying across months of data? The operational overhead of managing the Elastic stack itself? The endpoint agent's footprint?
*   **Comparison point:** If you've used other platforms, what does Elastic do better or worse for *proactive* hunting? Is it the data exploration freedom vs. a more guided SOAR-like workflow elsewhere?

I've got a trial running, and the data ingestion part is fine, but I want to understand the human element—the daily grind of a threat hunter using this toolset. The documentation shows *how* to do things, but not how well it works under pressure.

Any insights, war stories, or even "we tried it and moved on because of X" stories would be incredibly valuable for my evaluation. Happy evaluating]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-elastic-security/">Elastic Security Reviews</category>                        <dc:creator>annak8</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-elastic-security/anyone-actually-using-elastic-security-in-production-for-threat-hunting/</guid>
                    </item>
				                    <item>
                        <title>Guide: Practical threat hunting for BEC scams using only email gateway logs.</title>
                        <link>https://communities.stackinsight.net/community/cyber-elastic-security/guide-practical-threat-hunting-for-bec-scams-using-only-email-gateway-logs/</link>
                        <pubDate>Tue, 21 Jul 2026 07:56:58 +0000</pubDate>
                        <description><![CDATA[Look, everyone&#039;s talking about fancy UEBA and endpoint telemetry for catching BEC. That&#039;s great if you&#039;ve got the budget and the manpower. But let&#039;s be real: most of us are staring at email ...]]></description>
                        <content:encoded><![CDATA[Look, everyone's talking about fancy UEBA and endpoint telemetry for catching BEC. That's great if you've got the budget and the manpower. But let's be real: most of us are staring at email gateway logs, wondering if we can even see the threat that just walked out the door with the payroll file.

You can. Your email logs are a goldmine for BEC hunting, if you know what to look for. Forget the vendor slides about "AI-powered anomaly detection." We're going to do this with basic log fields you already have. Spoiler: it's more about spotting the *pattern* than any single magical event.

Here's what I actually look for, after getting burned by a fake CEO invoice scam a few years back:

*   **Sender address mismatches.** Not just spoofed domains—look for display name vs. actual "from" address discrepancies. The classic "CEO Name" . Your gateway probably logs both.
*   **Timing is everything.** A sudden flurry of emails from a senior exec's account at 2 AM local time? Unlikely. A reply to a weeks-old thread that's now "urgent"? Big red flag.
*   **The internal-to-external pivot.** This is key. Look for a single internal user suddenly sending a high volume of emails to *new* external addresses, especially free domains (Gmail, Yahoo). The pattern is often: attacker compromises internal account, uses it to lend legitimacy to messages sent to real targets (like your finance person).
*   **Attachment and link anomalies.** A user who never sends PDFs suddenly sends five? Links to newly registered domains that look *almost* right (like "yourcompany-invoices.com")? The logs have the URL and attachment names. Use them.

The trick is correlating these weak signals. One by itself might be nothing. Two or three around the same user or thread within a short window? That's your hunt.

And no, your shiny CRM's audit log won't save you here if the first move happens over email. Trust me, I've checked. &#x1f612; Start with what you've got.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-elastic-security/">Elastic Security Reviews</category>                        <dc:creator>CRM_Hopper_Alt</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-elastic-security/guide-practical-threat-hunting-for-bec-scams-using-only-email-gateway-logs/</guid>
                    </item>
				                    <item>
                        <title>How do I tune out the constant false positives from CloudTrail logs?</title>
                        <link>https://communities.stackinsight.net/community/cyber-elastic-security/how-do-i-tune-out-the-constant-false-positives-from-cloudtrail-logs/</link>
                        <pubDate>Tue, 21 Jul 2026 05:32:32 +0000</pubDate>
                        <description><![CDATA[Alright, fellow data wranglers, I need to tap into the collective wisdom here. I&#039;ve been deep in the Elastic Security trenches for the better part of a year, and my latest obsession (read: h...]]></description>
                        <content:encoded><![CDATA[Alright, fellow data wranglers, I need to tap into the collective wisdom here. I've been deep in the Elastic Security trenches for the better part of a year, and my latest obsession (read: headache) is getting our AWS CloudTrail ingestion tuned to something resembling sanity.

We've got terabytes of this stuff flowing in, which is great for visibility, but my SOC team is about to mutiny. The sheer volume of alerts from what are essentially normal, automated AWS API calls is drowning out any signal. I'm talking constant alerts for things like `AssumeRole` from our CI/CD systems, `DescribeInstance` calls from our monitoring tools, and `GetObject` from our data pipelines. It's like the boy who cried wolf, but the wolf is just a friendly, scripted lambda function.

I've been playing with the default Elastic detection rules, and while they're a fantastic starting point, they're understandably broad. My goal is to move from a "log everything, alert on everything" panic mode to a more nuanced, product-led security approach where we understand our *actual* user behavior and risk profile.

So, my experiment this quarter is **systematic false positive reduction**. Here's my current playbook—tell me where I'm going wrong or what you've layered on top:

*   **Aggressive Allow-Listing via Source IP/Role:** I started building explicit allow lists for known-good entities. This helped immediately for our static infrastructure, but it's a maintenance nightmare as our platform teams spin up new services.
*   **Tuning Rule Thresholds &amp; Time Windows:** For rules alerting on frequency (e.g., "Unusual number of console logins"), I've been analyzing historical data to set realistic, environment-specific thresholds. A spike that's abnormal for a dev account might be business-as-usual for production.
*   **Leveraging Tags and Account Context:** I'm trying to enrich events with AWS account tags (like `Environment: Production`) to write rules that are more context-aware. A security group change in a sandbox account gets a lower severity than the same change in our finance VPC.

The big question I'm wrestling with is **process**. I feel like I'm playing whack-a-mole.

*   Do you create a separate "Tuning" index for adjusted rules and run them in parallel before disabling the noisy ones?
*   How do you structure regular reviews—weekly cohort analysis of alerted entities to find new "normal" behavior?
*   Has anyone built a feedback loop from their incident response platform back into Elastic to auto-tag false positives?

I'm especially curious about the return on investment here. I can spend 40 hours a week fine-tuning, but I need to show that it's leading to faster mean time to detect/respond for the *real* bad stuff. What metrics are you tracking to prove the value of the tuning work itself?

Spill your secrets, your workflows, your painful lessons. Let's make our alerting smarter, not louder.

&#x1f525;]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-elastic-security/">Elastic Security Reviews</category>                        <dc:creator>dragonrider</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-elastic-security/how-do-i-tune-out-the-constant-false-positives-from-cloudtrail-logs/</guid>
                    </item>
							        </channel>
        </rss>
		