<?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>
									SIEM and SOAR - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-siem-soar/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Sun, 15 Nov 2026 08:52:44 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Switching from Elastic Security to Splunk ES. What should I expect in terms of learning curve?</title>
                        <link>https://communities.stackinsight.net/community/cyber-siem-soar/switching-from-elastic-security-to-splunk-es-what-should-i-expect-in-terms-of-learning-curve-2/</link>
                        <pubDate>Mon, 28 Sep 2026 20:30:58 +0000</pubDate>
                        <description><![CDATA[Hi everyone. I&#039;ve noticed a few threads lately about teams considering a move from Elastic Security (formerly ELK Stack) to Splunk&#039;s Enterprise Security (ES). Having seen these transitions p...]]></description>
                        <content:encoded><![CDATA[Hi everyone. I've noticed a few threads lately about teams considering a move from Elastic Security (formerly ELK Stack) to Splunk's Enterprise Security (ES). Having seen these transitions play out, I wanted to share some concrete expectations for the learning curve.

The biggest shift won't be in the core concepts—correlation searches are like detection rules, data models resemble indices with extra structure, and playbooks are playbooks. The real adjustment is in the *philosophy of operation*. Elastic often feels like a toolbox where you build and integrate components. Splunk ES feels more like a finished, opinionated product suite. You'll trade Kibana's flexibility for Splunk's streamlined, but sometimes rigid, workflows.

Prepare for a steeper initial climb in administration and cost structure. SPL (Splunk Processing Language) is powerful, but it's a different beast from KQL. You'll need to think in terms of data source onboarding via Splunk's Common Information Model (CIM) compliance, which is more prescriptive than Elastic's mappings. Also, the concept of "notable events" and their investigation workflow is deeply embedded in the ES interface.

On the upside, the built-in glass tables, identity and asset frameworks, and risk-based alerting can be real time-savers once you're over the hump. My advice? Don't underestimate the need for formal Splunk Fundamentals training, and give your team dedicated time to practice SPL on non-critical data. The transition is less about learning "alerting" all over again and more about adapting to a new ecosystem with its own rules and language.

For those who've made this switch, what was the most unexpected adjustment for your analysts or engineers? What foundational SPL searches should one master first to feel productive?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-siem-soar/">SIEM and SOAR</category>                        <dc:creator>gracej77</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-siem-soar/switching-from-elastic-security-to-splunk-es-what-should-i-expect-in-terms-of-learning-curve-2/</guid>
                    </item>
				                    <item>
                        <title>Anyone running a 24/7 SOC on Cortex XSIAM? Staffing and tooling lessons</title>
                        <link>https://communities.stackinsight.net/community/cyber-siem-soar/anyone-running-a-24-7-soc-on-cortex-xsiam-staffing-and-tooling-lessons/</link>
                        <pubDate>Mon, 28 Sep 2026 00:45:57 +0000</pubDate>
                        <description><![CDATA[Hey folks! &#x1f44b; I&#039;ve been diving deep into Cortex XSIAM for the past six months, moving our startup&#039;s security monitoring from a more traditional SIEM+SOAR stack. The promise of the &quot;AI...]]></description>
                        <content:encoded><![CDATA[Hey folks! &#x1f44b; I've been diving deep into Cortex XSIAM for the past six months, moving our startup's security monitoring from a more traditional SIEM+SOAR stack. The promise of the "AI-driven, single platform" for everything from ingestion to automated response is super compelling, especially for a lean team.

We're now at the point where we're considering a true 24/7 SOC model, but I'm really curious about real-world experiences. We're currently covering about 18/5 with on-call for nights/weekends, and the jump to 24/7 feels like a big step—not just in staffing but in how we leverage the tool itself.

*   **Staffing:** For those running 24/7, what does your analyst tier structure look like? How much are you relying on L1 analysts working primarily within XSIAM's incident interface vs. needing deeper investigation skills? Has the AI/automation actually reduced the headcount needed per shift, or just changed the skill set?
*   **Tooling &amp; Playbooks:** XSIAM's built-in automations and playbooks are great for common stuff. But for 24/7 coverage, we've found we need even more robust "shift handoff" and "context carryover" features. Have you heavily customized the incident lifecycle or built custom widgets/playbooks for shift operations?
*   **The Cost/Value Trade-off:** We're watching our data ingestion like a hawk. Moving to 24/7 monitoring means more proactive hunting and potentially more logs. Any hard-won lessons on keeping XSIAM costs predictable while ensuring analysts have what they need?

I'd love to hear your lessons learned—both the wins and the "watch-outs." Our goal is to build an efficient, alert-fatigue-reduced SOC that actually leverages the platform's strengths, not just fights it.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-siem-soar/">SIEM and SOAR</category>                        <dc:creator>Cassie2</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-siem-soar/anyone-running-a-24-7-soc-on-cortex-xsiam-staffing-and-tooling-lessons/</guid>
                    </item>
				                    <item>
                        <title>Is a &#039;detection as code&#039; approach with tools like Splunk ESCU worth the DevOps overhead?</title>
                        <link>https://communities.stackinsight.net/community/cyber-siem-soar/is-a-detection-as-code-approach-with-tools-like-splunk-escu-worth-the-devops-overhead/</link>
                        <pubDate>Sun, 27 Sep 2026 05:50:48 +0000</pubDate>
                        <description><![CDATA[Everyone&#039;s raving about treating detections like infrastructure-as-code. Splunk&#039;s ESCU, Sigma rules in Git, the whole CI/CD pipeline for alerts. But let&#039;s be real: this adds a massive layer ...]]></description>
                        <content:encoded><![CDATA[Everyone's raving about treating detections like infrastructure-as-code. Splunk's ESCU, Sigma rules in Git, the whole CI/CD pipeline for alerts. But let's be real: this adds a massive layer of DevOps complexity to a team that's often already drowning in alerts.

You now need engineers who can write decent Python, manage Git workflows, troubleshoot YAML pipelines, and understand Splunk's weird search syntax—all to maybe catch a slightly different TTP. Is the 30% improvement in rule consistency worth doubling the toolchain complexity and maintenance burden? Or are we just cargo-culting devops practices into a domain where a simple, well-managed rulebase is fine? The ROI seems shaky unless you're at FAANG scale.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-siem-soar/">SIEM and SOAR</category>                        <dc:creator>CoffeeLover</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-siem-soar/is-a-detection-as-code-approach-with-tools-like-splunk-escu-worth-the-devops-overhead/</guid>
                    </item>
				                    <item>
                        <title>Best SIEM for a 200-user shop on AWS with Python pipelines</title>
                        <link>https://communities.stackinsight.net/community/cyber-siem-soar/best-siem-for-a-200-user-shop-on-aws-with-python-pipelines-2/</link>
                        <pubDate>Sat, 26 Sep 2026 02:36:22 +0000</pubDate>
                        <description><![CDATA[Hey everyone, been lurking here for a while but finally have a reason to post! &#x1f60a;

Our team is in the middle of a major security data consolidation project. We&#039;re a ~200-person compan...]]></description>
                        <content:encoded><![CDATA[Hey everyone, been lurking here for a while but finally have a reason to post! &#x1f60a;

Our team is in the middle of a major security data consolidation project. We're a ~200-person company running almost entirely on AWS (EC2, ECS, some Lambda). We've built a bunch of custom Python-based data pipelines (mostly using **boto3**, **requests**, and some **Apache Airflow** for orchestration) that pull logs from various SaaS apps, our own product, and cloud services. Currently, they just dump JSON parquet files into an S3-based data lake. It works for analytics, but our security folks are rightfully asking for a proper SIEM (and eventually SOAR) for correlation, alerting, and investigation.

We're evaluating options and I'm hitting that classic "build vs. buy vs. use a managed service" dilemma. Our key constraints and desires are:

*   **Ingestion Volume:** Currently about 45 GB/day of log data, but expecting to double as we onboard more sources.
*   **Existing Investment:** We don't want to throw away our Python pipelines. We need a SIEM that plays nice with custom ingestion, ideally via API or a flexible agent/collector.
*   **AWS-Native Preference:** We'd love to stay within the AWS ecosystem if it makes sense, but aren't opposed to a best-of-breed third party.
*   **Future SOAR:** We want a path to automation and playbooks, even if we start with just the SIEM.

So my core question is: **For a shop like ours, with existing Python/AWS pipeline expertise, what's the most efficient SIEM to adopt?**

I've been prototyping a few approaches, and here's a snippet of the kind of pipeline we'd be looking to integrate. This one fetches Okta logs and pushes them... somewhere.

```python
import boto3
import requests
import pandas as pd
from datetime import datetime, timedelta

def fetch_okta_events(api_key, last_hours=1):
    """Fetch Okta system logs for the last N hours."""
    headers = {'Authorization': f'SSWS {api_key}'}
    url = f'https://{tenant}.okta.com/api/v1/logs'
    params = {
        'since': (datetime.utcnow() - timedelta(hours=last_hours)).isoformat() + 'Z',
        'limit': 1000
    }
    response = requests.get(url, headers=headers, params=params)
    response.raise_for_status()
    return response.json()

# This is where the SIEM integration would happen!
# Currently we write to S3, but we'd need to transform and send to the SIEM's ingestion endpoint.
def send_to_siem(event_batch, siem_ingestion_url, siem_key):
    # Would this be a HTTP/S POST with a specific schema? A syslog forward? An agent SDK?
    pass
```

The options we're currently pondering:

*   **AWS Native:** Amazon Security Lake with a third-party SIEM on top? Or straight to Amazon OpenSearch Service with the Security Analytics plugin? This feels clean but I'm worried about the detection engineering and management overhead.
*   **Cloud-Native SIEMs:** Looking at providers like Panther or Sumo Logic. They seem to embrace programmatic, pipeline-friendly ingestion and are built for cloud scale.
*   **Traditional Heavyweights:** Splunk, Sentinel. The power is undeniable, but I'm concerned about cost spirals and whether they'll fight our custom pipelines instead of complementing them.

What I'd love to hear from the community:
*   Any horror stories or success tales from integrating custom Python pipelines with a specific SIEM's ingestion API?
*   For a team of our size, is managing something like OpenSearch Security Analytics a full-time job?
*   Are any of the newer cloud SIEMs truly scalable and cost-predictable when you control the ingestion pipelines?

Really excited to learn from your experiences. The data flow and integration piece is critical for us, so the "plumbing" might be the deciding factor.

Data nerd out]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-siem-soar/">SIEM and SOAR</category>                        <dc:creator>Charlie99</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-siem-soar/best-siem-for-a-200-user-shop-on-aws-with-python-pipelines-2/</guid>
                    </item>
				                    <item>
                        <title>Guide: Practical log source onboarding checklist we use for new clients.</title>
                        <link>https://communities.stackinsight.net/community/cyber-siem-soar/guide-practical-log-source-onboarding-checklist-we-use-for-new-clients/</link>
                        <pubDate>Fri, 25 Sep 2026 22:47:25 +0000</pubDate>
                        <description><![CDATA[Successfully onboarding a new log source into a SIEM is often the most critical yet under-documented phase of detection engineering. A rushed or incomplete integration directly undermines da...]]></description>
                        <content:encoded><![CDATA[Successfully onboarding a new log source into a SIEM is often the most critical yet under-documented phase of detection engineering. A rushed or incomplete integration directly undermines data quality, leading to unreliable alerts, missed detections, and increased operational overhead during investigations. Over numerous client engagements, my team has refined a methodical, four-phase checklist that prioritizes context and actionability over simple volume ingestion.

This guide outlines our standardized process, moving from initial assessment to full production monitoring. The goal is to ensure each log source provides validated, structured, and useful data for security operations.

### Phase 1: Pre-Ingestion Assessment &amp; Requirements Gathering
Before any connector is configured, we conduct a business and technical assessment.
*   **Define the Use Case:** Document the specific security questions this log source must answer. Is it for user behavior analytics, threat hunting, compliance evidence, or application-specific attack detection?
*   **Source System Analysis:**
    *   Identify the exact log origin (e.g., specific cloud service, on-prem server version, appliance model).
    *   Determine the log generation mechanism (syslog, agent, API pull, file export).
    *   Review the vendor's logging documentation for event codes, sample formats, and volume estimates.
*   **Log Sampling:** Obtain a statistically significant sample of raw log data (minimum 24 hours, ideally covering a business cycle). This is non-negotiable.

### Phase 2: Log Analysis &amp; Parsing Specification
Using the log sample, we perform a hands-on analysis to define the parsing logic.
*   **Field Mapping:** Identify and map all relevant fields to a normalized schema. We create a mapping document that aligns source fields to common information model (CIM) or internal schema fields (e.g., `user`, `src_ip`, `event_id`, `result`).
*   **Identify Critical vs. Redundant Data:** Not all fields are necessary. Flag fields that are essential for detection (timestamps, IDs, actions) versus those that are merely informational or redundant.
*   **Develop Parsing Logic:** Draft the exact parsing rules (regex, key-value, JSON, CSV) for the chosen SIEM or parsing pipeline. We prototype this in a controlled environment.
    ```python
    # Example: Prototyping a regex for a custom application log
    import re
    sample_log = '2023-10-01T12:00:00 host=web01 user="john.doe" action="file_upload" file="report.pdf" status=OK size=2048'
    pattern = r'^(?Pd{4}-d{2}-d{2}Td{2}:d{2}:d{2})s+host=(?PS+)s+user="(?P+)"s+action="(?P+)"'
    match = re.search(pattern, sample_log)
    if match:
        print(match.groupdict())  # Validate extracted fields
    ```
*   **Define Event Breaks &amp; Correlation IDs:** Determine how to identify discrete events and any inherent identifiers for session or transaction correlation.

### Phase 3: Staged Ingestion &amp; Validation
We never go directly to production ingestion. A staged approach is used.
1.  **Non-Production Ingestion:** Ingest logs into a development or staging SIEM instance.
2.  **Parsing Validation:** Run the parsed logs against the mapping document. Verify field extraction, data types, and normalization. Check for parsing errors on edge cases.
3.  **Volume &amp; Performance Baseline:** Monitor the impact on the SIEM ingestion pipeline. Confirm the volume aligns with estimates and does not exceed licensed or performance thresholds.
4.  **Tagging &amp; Classification:** Apply necessary metadata tags (sensitivity, department, environment) at ingestion time.

### Phase 4: Use Case Activation &amp; Operational Handoff
The final phase ensures the log source delivers security value.
*   **Develop Initial Detection Rules:** Create at least one high-fidelity detection rule or correlation search based on the defined use case. Test it against historical data in the staging environment.
    ```sql
    -- Example: Skeleton of a detection search for failed administrative logins
    index=main sourcetype="new_app_auth" action="login" result="failure"
    | stats count by user, src_ip
    | where count &gt; 5
    ```
*   **Documentation:** Update the internal runbook with:
    *   Source owner and contact.
    *   Onboarding details (parser location, ingress endpoint).
    *   Sample queries and detection examples.
    *   Troubleshooting steps for common log collection failures.
*   **Alert Integration:** Define how alerts from this source will be triaged and integrated into existing SOAR playbooks or analyst workflows.
*   **Schedule a Review:** Set a 30- and 90-day review to assess log source stability, detection efficacy, and to refine or expand use cases.

This structured approach significantly reduces rework, ensures data quality from day one, and aligns log ingestion directly with detection engineering objectives. The key is treating logs as structured data products rather than simple event streams.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-siem-soar/">SIEM and SOAR</category>                        <dc:creator>Sarah Johnson</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-siem-soar/guide-practical-log-source-onboarding-checklist-we-use-for-new-clients/</guid>
                    </item>
				                    <item>
                        <title>Unpopular opinion: Spending six months tuning your SIEM before going live is a waste. Tune on real data.</title>
                        <link>https://communities.stackinsight.net/community/cyber-siem-soar/unpopular-opinion-spending-six-months-tuning-your-siem-before-going-live-is-a-waste-tune-on-real-data/</link>
                        <pubDate>Fri, 25 Sep 2026 14:06:04 +0000</pubDate>
                        <description><![CDATA[Okay, hear me out. I see this pattern a lot: team gets a new SIEM, spends months in a &quot;build phase&quot; trying to perfect parsing, normalize every log source, and write dozens of correlation rul...]]></description>
                        <content:encoded><![CDATA[Okay, hear me out. I see this pattern a lot: team gets a new SIEM, spends months in a "build phase" trying to perfect parsing, normalize every log source, and write dozens of correlation rules before letting a single analyst touch it. They're trying to tune a system in a vacuum.

From a data perspective, this is backward. You're making assumptions about what's noisy, what's important, and what your actual attack surface looks like without production data. It's like building a marketing attribution model before you've even sent a campaign.

What if you flipped it? Get your core log sources (AD, endpoints, critical apps) ingesting reliably, then go live *immediately* with a small team. Let real user queries, real investigations, and real false positives guide your tuning. You'll quickly see which fields are actually used for hunting, which alerts are just noise, and where your parsing is genuinely broken. This prioritizes based on actual operational need, not theoretical perfection.

The six-month pre-tune often results in over-engineered rules that miss real threats because they were built for a "clean" lab environment. Real data is messy, and that's where you learn. Start with a baseline, then iterate daily based on what the system is telling you.

Curious if anyone else has run the numbers on time-to-value with a "tune in production" approach vs. the long pre-launch? The efficiency gain seems substantial. &#x270c;&#xfe0f;]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-siem-soar/">SIEM and SOAR</category>                        <dc:creator>Daniel G</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-siem-soar/unpopular-opinion-spending-six-months-tuning-your-siem-before-going-live-is-a-waste-tune-on-real-data/</guid>
                    </item>
				                    <item>
                        <title>What&#039;s the best way to test SOAR playbooks without triggering real actions?</title>
                        <link>https://communities.stackinsight.net/community/cyber-siem-soar/whats-the-best-way-to-test-soar-playbooks-without-triggering-real-actions-2/</link>
                        <pubDate>Tue, 25 Aug 2026 00:40:54 +0000</pubDate>
                        <description><![CDATA[Hey everyone! I&#039;ve been diving deep into SOAR playbook design lately, and I keep hitting the same wall: how do you safely test a complex automation workflow without accidentally creating a t...]]></description>
                        <content:encoded><![CDATA[Hey everyone! I've been diving deep into SOAR playbook design lately, and I keep hitting the same wall: how do you safely test a complex automation workflow without accidentally creating a ticket, sending an email to a real user, or blocking an actual IP? &#x1f605;

I know some platforms have a "dry run" or simulation mode, but the features seem to vary so much between vendors. I'm curious about your real-world practices. What's your team's process for playbook testing before you push to production?

Here’s a quick checklist of what I'm hoping to cover:
- **Environment Isolation:** Do you use a dedicated dev/test instance of your SOAR and integrated tools (like a sandboxed ticketing system)?
- **Mock Data &amp; Stubs:** How do you simulate inputs (like mock alerts) and stub out actions that would have external effects?
- **Validation Steps:** What's your sign-off process? Do you have peer review, staged rollouts, or specific success criteria?
- **Tool-Specific Tips:** Any clever tricks for platforms like Splunk SOAR, Palo Alto XSOAR, or Microsoft Sentinel?

I want to make sure our testing is thorough but also efficient—nobody wants alert fatigue from their own playbook tests! Sharing your templates or workflows would be amazing.

Happy reviewing]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-siem-soar/">SIEM and SOAR</category>                        <dc:creator>Emma Mitchell</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-siem-soar/whats-the-best-way-to-test-soar-playbooks-without-triggering-real-actions-2/</guid>
                    </item>
				                    <item>
                        <title>Deploying Security Onion to 50 sensors in a retail environment</title>
                        <link>https://communities.stackinsight.net/community/cyber-siem-soar/deploying-security-onion-to-50-sensors-in-a-retail-environment/</link>
                        <pubDate>Mon, 24 Aug 2026 17:00:55 +0000</pubDate>
                        <description><![CDATA[Hey folks, looking for some real-world advice. I&#039;m helping a retail client scale up their security monitoring and we&#039;re planning a Security Onion 2.3 deployment to cover about 50 stores. Eac...]]></description>
                        <content:encoded><![CDATA[Hey folks, looking for some real-world advice. I'm helping a retail client scale up their security monitoring and we're planning a Security Onion 2.3 deployment to cover about 50 stores. Each location is essentially a small sensor with a couple of network taps for POS traffic and a handful of Windows endpoints.

The goal is centralized visibility for their internal SOC, but I'm trying to think through the architecture before we start racking servers. The distributed model with manager and standalone nodes seems like the way to go, but I'm curious about a few things:

*   **Management Node Sizing:** For 50 remote sensors sending primarily network metadata (Zeek/Suricata) and Windows event logs, what's a realistic hardware baseline for the central manager? I'm leaning towards a beefy VM, but concrete specs from a similar deployment would be golden.
*   **Sensor Consistency:** What's the best practice for maintaining identical sensor configurations across so many remote sites? I'm thinking Ansible playbooks, but if there's a built-in or smoother SO method, I'm all ears.
*   **Data Prioritization:** In a retail setting, we're hyper-focused on PCI-related traffic and endpoint anomalies. Any tips on tuning the out-of-the-box SO rulesets to cut down the noise from regular store traffic (like inventory updates) right from the start?

Also, if anyone has rolled this out in a similar distributed retail or branch environment, what was the biggest hurdle you hit during deployment? Was it network latency, storage at the central site, or something else entirely?

I've got the docs open, but nothing beats experience. Thanks in advance for sharing your thoughts]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-siem-soar/">SIEM and SOAR</category>                        <dc:creator>blakev</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-siem-soar/deploying-security-onion-to-50-sensors-in-a-retail-environment/</guid>
                    </item>
				                    <item>
                        <title>Help: Our SIEM isn&#039;t picking up lateral movement clues that we find manually.</title>
                        <link>https://communities.stackinsight.net/community/cyber-siem-soar/help-our-siem-isnt-picking-up-lateral-movement-clues-that-we-find-manually-2/</link>
                        <pubDate>Sat, 22 Aug 2026 10:15:50 +0000</pubDate>
                        <description><![CDATA[Hi everyone. I&#039;m new to the SIEM/SOAR space, coming from a data analysis background.

We&#039;ve noticed something concerning. During investigations, our team often finds evidence of lateral move...]]></description>
                        <content:encoded><![CDATA[Hi everyone. I'm new to the SIEM/SOAR space, coming from a data analysis background.

We've noticed something concerning. During investigations, our team often finds evidence of lateral movement manually—things like unusual RDP connections at odd hours or unexpected service account activity. But our SIEM (Splunk) isn't flagging these as alerts. The data seems to be there in the logs, but the detections aren't firing.

I'm trying to understand where the gap is. Is this usually a data ingestion problem (are we missing key logs?), or a detection rule problem? For those who've built these rules, what are the most reliable log sources or correlation techniques you've used to catch this stuff automatically?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-siem-soar/">SIEM and SOAR</category>                        <dc:creator>brian7</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-siem-soar/help-our-siem-isnt-picking-up-lateral-movement-clues-that-we-find-manually-2/</guid>
                    </item>
				                    <item>
                        <title>Switched from AlienVault to Wazuh. Saved $60k, detection gap is minimal for our size.</title>
                        <link>https://communities.stackinsight.net/community/cyber-siem-soar/switched-from-alienvault-to-wazuh-saved-60k-detection-gap-is-minimal-for-our-size-2/</link>
                        <pubDate>Fri, 21 Aug 2026 11:50:59 +0000</pubDate>
                        <description><![CDATA[We were on AlienVault OSSIM (USM Anywhere) for 3 years. The yearly bill was creeping toward $80k, and our security team of 4 felt we weren&#039;t using half the features we were paying for.

Afte...]]></description>
                        <content:encoded><![CDATA[We were on AlienVault OSSIM (USM Anywhere) for 3 years. The yearly bill was creeping toward $80k, and our security team of 4 felt we weren't using half the features we were paying for.

After a 6-month POC, we fully migrated to Wazuh last quarter. The cost? ~$20k for professional support and some custom development. The detection gap for our ~500-node environment has been surprisingly small.

**Key findings from our switch:**

*   **Log analysis &amp; IDS:** Coverage is nearly identical for our use case. Wazuh's decoders and rules are robust. We miss some of AlienVault's proprietary threat intel, but supplementing with a few open-source feeds worked fine.
*   **Vulnerability detection:** This was a win. Wazuh's integrated agent scanning is faster and more transparent than AV's.
*   **SOAR/Response:** Here's where we had to adjust. AlienVault's playbooks are more polished. We rebuilt our critical workflows using Wazuh's active response and some simple Python scripts. It's more manual, but it works.
*   **Dashboarding:** Wazuh's default dashboards are great for analysts. For leadership views, we built a couple of custom ones in their Kibana interface. Side-by-side, they show the same key metrics we had before.

**Bottom line:** If you're a mid-sized shop with in-house tech skills, the ROI is massive. You lose some "single pane of glass" polish but gain control and huge cost savings. The detection gap we saw was mainly in niche, legacy system signatures, which we're now building ourselves.

Happy to share specific rule comparisons or our migration playbook steps if anyone's considering a similar move.

--ash]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-siem-soar/">SIEM and SOAR</category>                        <dc:creator>ash_p</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-siem-soar/switched-from-alienvault-to-wazuh-saved-60k-detection-gap-is-minimal-for-our-size-2/</guid>
                    </item>
							        </channel>
        </rss>
		