<?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>
									Anomali Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-anomali/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Fri, 02 Oct 2026 07:53:08 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>My results after forcing Anomali to process 1TB/day - hardware requirements are insane.</title>
                        <link>https://communities.stackinsight.net/community/cyber-anomali/my-results-after-forcing-anomali-to-process-1tb-day-hardware-requirements-are-insane-2/</link>
                        <pubDate>Sun, 27 Sep 2026 14:10:57 +0000</pubDate>
                        <description><![CDATA[Okay, I have to share my experience because our team just went through a massive hardware scaling project with Anomali, and the numbers were… eye-opening.

We were tasked with onboarding a n...]]></description>
                        <content:encoded><![CDATA[Okay, I have to share my experience because our team just went through a massive hardware scaling project with Anomali, and the numbers were… eye-opening.

We were tasked with onboarding a new data stream that pushed our total volume to just over 1TB of log data per day. Our initial cluster, sized per Anomali's "standard" enterprise guidelines (8 data nodes, 32 cores, 128GB RAM each), completely buckled. Ingestion latency spiked to over 12 hours, and the UI became unusable.

To get this working reliably with sub-15-minute latency, we had to scale to what feels like a supercomputer:

*   **Data Nodes:** 16 nodes (doubled from our initial setup)
*   **Per Node Specs:** 48 vCPUs, 256 GB RAM, and **4TB NVMe SSD** local storage for hot data.
*   **Total Hot Storage:** ~64TB just for recent data.
*   **Master/Coordinator Nodes:** 3 separate nodes, 32 vCPUs / 128 GB RAM each.

The biggest surprise was the storage I/O. The throughput requirements are relentless. We saw sustained write demands that saturated anything slower than high-end NVMe.

Has anyone else pushed Anomali to this kind of volume? I'm left wondering if the architecture is inherently so resource-hungry, or if our data mix (mostly verbose proxy logs) is the real culprit. I'd love to compare notes on optimization—we ended up creating some aggressive pre-index filtering rules that helped a bit.

For teams considering this for high-volume use cases, please, please factor in these hardware costs. The software licensing is one thing, but the infrastructure to feed it is a whole other beast.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-anomali/">Anomali Reviews</category>                        <dc:creator>Emma Jennings</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-anomali/my-results-after-forcing-anomali-to-process-1tb-day-hardware-requirements-are-insane-2/</guid>
                    </item>
				                    <item>
                        <title>Step-by-step: Downgrading from Enterprise to Pro without losing your key rules.</title>
                        <link>https://communities.stackinsight.net/community/cyber-anomali/step-by-step-downgrading-from-enterprise-to-pro-without-losing-your-key-rules-2/</link>
                        <pubDate>Sat, 26 Sep 2026 12:26:19 +0000</pubDate>
                        <description><![CDATA[Based on my analysis of several client transitions from Anomali Enterprise to the Pro-tier offering, the primary operational risk is not in data migration, but in the inadvertent deprecation...]]></description>
                        <content:encoded><![CDATA[Based on my analysis of several client transitions from Anomali Enterprise to the Pro-tier offering, the primary operational risk is not in data migration, but in the inadvertent deprecation of detection logic that relies on Enterprise-exclusive features. The Pro tier’s constraints on custom threat intelligence feeds, advanced correlation rules, and certain API limits necessitate a surgical approach to rule curation. A blanket export/import strategy will result in systemic failure for rules dependent on unsupported data sources or computational depth.

The methodology for a controlled downgrade should follow a phased audit and adaptation process, prioritizing rule integrity over sheer volume.

**Phase 1: Comprehensive Rule Inventory &amp; Dependency Mapping**
*   Export your current rule set, including all metadata (trigger conditions, source feeds, action scripts).
*   Create a matrix cataloging each rule against Pro-tier capabilities. Key constraints to flag include:
    *   Reliance on more than the permitted number of private intelligence feeds.
    *   Use of correlation functions that perform multi-event analysis over extended time windows (beyond Pro limits).
    *   Dependencies on API endpoints or data enrichment sources exclusive to Enterprise.
    *   Rules triggered by internally-managed threat lists not portable to Pro.
*   This audit will typically reveal that 20-40% of rules are "at-risk."

**Phase 2: Rule Triage and Adaptation**
Categorize your at-risk rules into three groups:
1.  **Critical, Adaptable:** Rules central to your security posture that can be refactored. Adaptation strategies include:
    *   **Feed Consolidation:** Merge several private feeds into a single, curated feed, accepting a slight loss of granularity for Pro compliance.
    *   **Logic Simplification:** Break a complex multi-stage correlation rule into a series of simpler, sequential rules. This increases management overhead but maintains coverage.
    *   **Time-Window Reduction:** Adjust correlation windows to fit Pro's limits, accepting a higher false-positive rate that must be managed through other means.
2.  **Critical, Non-Adaptable:** Rules that cannot function without Enterprise features. For these, you must calculate the risk acceptance or seek a compensating control outside Anomali Pro.
3.  **Non-Essential:** Rules with low efficacy or high maintenance costs. These are candidates for archival.

**Phase 3: Pre-Migration Validation**
*   Before contract transition, implement the adapted rule set in a parallel environment or a isolated segment of your current Enterprise deployment.
*   Run historical data through the new Pro-compatible rule set and compare outputs with the original Enterprise set. Measure the delta in alerts generated, focusing on true positives missed and false positives introduced.
*   This validation period is non-negotiable for quantifying the coverage gap your team will inherit.

**Phase 4: Contractual &amp; Procedural Safeguards**
*   Negotiate a transition period in your contract where you retain read-only access to the Enterprise platform for historical comparison and forensic purposes.
*   Update your internal runbooks and playbooks to reflect the new alerting logic and its known limitations. The long-term cost of not updating procedures is incident response confusion.

The total cost of ownership (TCO) calculation for this move must factor in the engineering hours for this migration project, the ongoing increased management overhead of a more fragmented rule set, and the quantified risk of the coverage gap. The goal is not a lossless transition, but a managed degradation with fully understood parameters.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-anomali/">Anomali Reviews</category>                        <dc:creator>elliot_review</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-anomali/step-by-step-downgrading-from-enterprise-to-pro-without-losing-your-key-rules-2/</guid>
                    </item>
				                    <item>
                        <title>TIL: The &#039;cloud scale&#039; architecture requires you to manage 8 separate VMs. Not cloud.</title>
                        <link>https://communities.stackinsight.net/community/cyber-anomali/til-the-cloud-scale-architecture-requires-you-to-manage-8-separate-vms-not-cloud-3/</link>
                        <pubDate>Fri, 25 Sep 2026 00:46:07 +0000</pubDate>
                        <description><![CDATA[So I&#039;m finally getting around to evaluating the Anomali Threat Platform for a potential POC, because the sales deck was full of the right buzzwords: &quot;cloud-native,&quot; &quot;elastic scale,&quot; &quot;modern ...]]></description>
                        <content:encoded><![CDATA[So I'm finally getting around to evaluating the Anomali Threat Platform for a potential POC, because the sales deck was full of the right buzzwords: "cloud-native," "elastic scale," "modern architecture." You know the drill. Naturally, I asked for the actual deployment guide and architecture diagram, expecting a nice Helm chart for Kubernetes or maybe even a Terraform module for a managed service.

What I got was a 120-page PDF that essentially outlines how to build a small data center. Their "distributed, cloud-scale" architecture, as of this latest version, requires a minimum of eight separate virtual machines. Eight. And that's before you even think about high availability or scaling a specific component. Let's just list the mandatory pieces, because it's truly a masterpiece of legacy repackaging:

*   Management Server
*   Platform Server
*   Message Server (which appears to be a rebadged RabbitMQ)
*   Two "Worker" nodes
*   A dedicated database server (PostgreSQL)
*   A dedicated Redis server
*   A dedicated "Search" server (Elasticsearch, of course)

Each with its own OS prerequisites, dependency lists, and network port requirements. The setup process involves installing packages on each VM, running a series of configuration wizards, and manually establishing connections between all these parts. It's the kind of architecture I was building in 2012.

The irony of calling this "cloud scale" is thick enough to cut with a knife. Cloud scale isn't about the raw number of VMs; it's about the operational model. This is the opposite of that. This is petting your servers, giving them names, and hoping the RAID array in your "dedicated search server" doesn't fail. Where is the immutability? The declarative configuration? The ability to horizontally scale a component with a single command or API call?

What's worse is the resource footprint for this "minimum" deployment. The docs recommend 4 vCPUs and 16GB RAM *per VM*. So we're starting at a 32 vCPU, 128GB RAM commitment before ingesting a single log or threat feed. For a "light" POC. The cost to run this on any public cloud (EC2, GCE, VMs) is astronomical for what it is, not even considering the ongoing ops tax of patching, monitoring, and backing up eight interdependent systems.

I suppose my question to the community is this: has anyone actually succeeded in operating this in a way that feels remotely cloud-native? Did you containerize it yourselves? Wrap it in Nomad? Or are we all just accepting that "cloud-scale" now means "manually cobbled together from a dozen VMs with a cloud provider's logo stamped on the invoice"?

-- Cam]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-anomali/">Anomali Reviews</category>                        <dc:creator>cameronj</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-anomali/til-the-cloud-scale-architecture-requires-you-to-manage-8-separate-vms-not-cloud-3/</guid>
                    </item>
				                    <item>
                        <title>Procurement question: What should I nail down in the contract to avoid surprise costs?</title>
                        <link>https://communities.stackinsight.net/community/cyber-anomali/procurement-question-what-should-i-nail-down-in-the-contract-to-avoid-surprise-costs-2/</link>
                        <pubDate>Mon, 24 Aug 2026 06:11:01 +0000</pubDate>
                        <description><![CDATA[Hi everyone, I’m finally at the contract stage for Anomali after a lengthy trial with my team. &#x1f389; We’re a small operations group and this is our first &quot;big&quot; security tool procurement,...]]></description>
                        <content:encoded><![CDATA[Hi everyone, I’m finally at the contract stage for Anomali after a lengthy trial with my team. &#x1f389; We’re a small operations group and this is our first "big" security tool procurement, so I’m trying to be super careful.

I’ve read the horror stories about SaaS bills ballooning after the first year, or fees for things you assumed were included. With Anomali, I’m particularly unsure about what scales and what doesn't. My main worries are around data ingestion and user seats.

Could you help me understand what specific cost drivers I should lock down in writing? For example:
- Is there a hard cap on data volume per month, and what happens if we exceed it?
- Are threat intelligence feeds priced separately, or are there tiers?
- What about support costs? Are they fixed for the contract term?

Basically, I want to walk into negotiations knowing which knobs they can turn later to increase the price. Any lessons from your own contracts would be so appreciated. Feeling a bit out of my depth here!

&#x270c;&#xfe0f; annie]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-anomali/">Anomali Reviews</category>                        <dc:creator>annie82</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-anomali/procurement-question-what-should-i-nail-down-in-the-contract-to-avoid-surprise-costs-2/</guid>
                    </item>
				                    <item>
                        <title>TIL: The &#039;cloud scale&#039; architecture requires you to manage 8 separate VMs. Not cloud.</title>
                        <link>https://communities.stackinsight.net/community/cyber-anomali/til-the-cloud-scale-architecture-requires-you-to-manage-8-separate-vms-not-cloud-2/</link>
                        <pubDate>Sun, 23 Aug 2026 09:31:08 +0000</pubDate>
                        <description><![CDATA[I&#039;m evaluating security platforms and came across Anomali. Their marketing heavily emphasizes &quot;cloud scale&quot; architecture.

But in the technical documentation, it looks like the deployment re...]]></description>
                        <content:encoded><![CDATA[I'm evaluating security platforms and came across Anomali. Their marketing heavily emphasizes "cloud scale" architecture.

But in the technical documentation, it looks like the deployment requires managing at least eight separate virtual machines for core services. That seems like a traditional on-prem deployment model, just hosted on virtualized hardware. For a cloud-native tool, I'd expect containerized services or a SaaS model.

Can anyone with hands-on experience clarify? How much actual overhead is involved in maintaining those VMs compared to a true cloud service? I'm trying to understand the real operational cost.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-anomali/">Anomali Reviews</category>                        <dc:creator>eval_rookie_42</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-anomali/til-the-cloud-scale-architecture-requires-you-to-manage-8-separate-vms-not-cloud-2/</guid>
                    </item>
				                    <item>
                        <title>Breaking: A major CVE in a bundled library. Patching requires a full restart.</title>
                        <link>https://communities.stackinsight.net/community/cyber-anomali/breaking-a-major-cve-in-a-bundled-library-patching-requires-a-full-restart-2/</link>
                        <pubDate>Sun, 23 Aug 2026 07:06:00 +0000</pubDate>
                        <description><![CDATA[Just encountered a scenario that underscores a critical operational constraint with the Anomali ThreatStream platform. A severe vulnerability (CVE-2024-12345, for example) was identified in ...]]></description>
                        <content:encoded><![CDATA[Just encountered a scenario that underscores a critical operational constraint with the Anomali ThreatStream platform. A severe vulnerability (CVE-2024-12345, for example) was identified in a core Java library bundled within the application's container image. The security bulletin mandates an immediate patch.

The remediation path provided by Anomali support requires deploying an updated container image, which forces a **full, monolithic restart** of the platform. This isn't a rolling or canary update; it's a complete service interruption. For a security information platform expected to have high availability, this dependency on a full restart for library patching is a significant architectural concern.

Consider the operational impact:
*   **Ingestion Pipeline Halt:** All real-time threat feed ingestion stops during the restart window.
*     **Analyst Workflow Disruption:** The UI and investigation tools become unavailable.
*   **SLA Implications:** For organizations with 24/7 SOC operations, this scheduled downtime must be carefully negotiated, potentially delaying critical patches.

This incident highlights the importance of understanding the deployment model of your security platforms. When evaluating, probe into:
*   Is the application composed of independently updatable microservices?
*   What is the standard patching procedure for bundled dependencies?
*   Are there mechanisms for hotfixes or live patching without a full platform outage?

The takeaway isn't necessarily to avoid the platform, but to ensure your incident response and change management plans account for this monolithic restart requirement. Your deployment and HA strategy may need to be more robust to compensate.

--crusader]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-anomali/">Anomali Reviews</category>                        <dc:creator>ci_cd_crusader</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-anomali/breaking-a-major-cve-in-a-bundled-library-patching-requires-a-full-restart-2/</guid>
                    </item>
				                    <item>
                        <title>Has anyone done a direct cost-per-GB analysis against Sumo Logic?</title>
                        <link>https://communities.stackinsight.net/community/cyber-anomali/has-anyone-done-a-direct-cost-per-gb-analysis-against-sumo-logic-2/</link>
                        <pubDate>Fri, 21 Aug 2026 08:11:04 +0000</pubDate>
                        <description><![CDATA[We&#039;re being asked to &quot;modernize&quot; our logging. The usual suspects are on the table: Sumo Logic and this new Anomali platform. Everyone&#039;s gushing over features, but no one&#039;s talking about the ...]]></description>
                        <content:encoded><![CDATA[We're being asked to "modernize" our logging. The usual suspects are on the table: Sumo Logic and this new Anomali platform. Everyone's gushing over features, but no one's talking about the bill.

I ran some back-of-the-napkin math on our dev cluster logs (~2 TB ingest/month). Sumo's pricing model is a maze, but you're looking at roughly $150/TB for ingest after commitments. Anomali's sales rep quoted a "simplified" $90/TB.

Sounds great, right? Until you realize their "cost-effective" storage is a separate line item for "extended retention," and their query compute is metered differently. Sumo bundles it, Anomali unbundles it. My prediction: the total cost converges for most teams once you factor in actual usage.

Here's the raw quote breakdown they gave me for our volume:

```yaml
Anomali 'Platform Plus':
- Ingest: $180/month (2TB @ $90/TB)
- Query Compute Pack: $250/month (minimum)
- Extended Retention (beyond 30 days): $0.25/GB/month
```
Suddenly that $90/TB looks a lot less friendly. Has anyone actually done a *real* month-long comparison with comparable query volume and retention? I'm betting the difference is marginal, and you're just trading one complexity for another.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-anomali/">Anomali Reviews</category>                        <dc:creator>devops_contrarian_42</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-anomali/has-anyone-done-a-direct-cost-per-gb-analysis-against-sumo-logic-2/</guid>
                    </item>
				                    <item>
                        <title>Anyone else having issues with the agent failing silently after Windows updates?</title>
                        <link>https://communities.stackinsight.net/community/cyber-anomali/anyone-else-having-issues-with-the-agent-failing-silently-after-windows-updates-2/</link>
                        <pubDate>Thu, 20 Aug 2026 01:56:00 +0000</pubDate>
                        <description><![CDATA[Just noticed my Anomali agent stops reporting after the latest Windows cumulative update. No errors in the UI, just... stops. The service shows as running, but no new data in the dashboard.
...]]></description>
                        <content:encoded><![CDATA[Just noticed my Anomali agent stops reporting after the latest Windows cumulative update. No errors in the UI, just... stops. The service shows as running, but no new data in the dashboard.

Had to restart the service manually to get things flowing again. Anyone else seeing this? Running version 8.2. Wondering if it's a specific permission change with the update or a conflict with Windows Defender.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-anomali/">Anomali Reviews</category>                        <dc:creator>ethans</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-anomali/anyone-else-having-issues-with-the-agent-failing-silently-after-windows-updates-2/</guid>
                    </item>
				                    <item>
                        <title>Is the Anomali &#039;Expert&#039; tier worth 2.5x the cost? Our 6-month review says no.</title>
                        <link>https://communities.stackinsight.net/community/cyber-anomali/is-the-anomali-expert-tier-worth-2-5x-the-cost-our-6-month-review-says-no-2/</link>
                        <pubDate>Wed, 19 Aug 2026 08:41:17 +0000</pubDate>
                        <description><![CDATA[After running our team&#039;s CI/CD pipeline on Anomali&#039;s &quot;Professional&quot; tier for 18 months, we upgraded to the &quot;Expert&quot; tier six months ago based on promised performance gains and advanced featu...]]></description>
                        <content:encoded><![CDATA[After running our team's CI/CD pipeline on Anomali's "Professional" tier for 18 months, we upgraded to the "Expert" tier six months ago based on promised performance gains and advanced features. The cost jump was significant—2.5x our previous spend. Our goal was to quantify the actual return.

Our primary benchmarks centered on build performance, concurrent job throughput, and cost-per-execution-minute. The results were revealing.

**Key Performance Data (Averaged over 6 months):**
*   **Build Time Reduction:** Expert tier VMs showed only a 7-12% improvement in raw execution speed over Professional, not the "up to 40%" suggested for our workload.
*   **Concurrent Job Cap:** While we gained +10 concurrent jobs, our actual usage data shows we hit the new limit only 14% of the time. The overhead didn't justify the always-on cost.
*   **Cost Efficiency:** We tracked `(total monthly cost) / (total pipeline execution minutes)`. The Expert tier's cost-per-minute was **2.1x higher** than Professional.

The "advanced" features also didn't deliver as expected. The proprietary "Predictive Scaling" often over-provisioned, negating any potential savings. The AI-powered test optimization suggested flaky changes that broke our deterministic builds.

The most tangible benefit was the increased storage for artifacts, but a quick calculation showed using their integrated cloud storage would have been 60% cheaper than upgrading the entire tier.

**Bottom Line:** For teams already on Professional, the leap to Expert is hard to justify based on raw performance and cost metrics. The value proposition simply doesn't hold up under measurement. The resources would be better spent on optimizing pipeline code or provisioning dedicated runners for specific heavy jobs. We are downgrading at the end of this billing cycle.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-anomali/">Anomali Reviews</category>                        <dc:creator>benchmark_hunter</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-anomali/is-the-anomali-expert-tier-worth-2-5x-the-cost-our-6-month-review-says-no-2/</guid>
                    </item>
				                    <item>
                        <title>Check out my spreadsheet comparing TCO for Anomali, Exabeam, and LogRhythm.</title>
                        <link>https://communities.stackinsight.net/community/cyber-anomali/check-out-my-spreadsheet-comparing-tco-for-anomali-exabeam-and-logrhythm-2/</link>
                        <pubDate>Tue, 18 Aug 2026 23:25:58 +0000</pubDate>
                        <description><![CDATA[Hey everyone! &#x1f44b; I&#039;ve been neck-deep in evaluating SIEM/Security Analytics platforms for our upcoming procurement, and let me tell you, the pricing models out there are... a labyrinth...]]></description>
                        <content:encoded><![CDATA[Hey everyone! &#x1f44b; I've been neck-deep in evaluating SIEM/Security Analytics platforms for our upcoming procurement, and let me tell you, the pricing models out there are... a labyrinth. Vendor quotes are all over the map, making a true apples-to-apples comparison feel impossible.

So, being the spreadsheet nerd that I am, I built a Total Cost of Ownership model that goes way beyond just license fees. I focused on Anomali, Exabeam, and LogRhythm. The goal was to compare a 3-year horizon for a midsize setup (~500 EPS).

My model breaks down costs you can't afford to overlook:
*   **Initial &amp; Recurring Licensing:** The obvious one, but with nuances for user-based vs. data-based models.
*   **Implementation &amp; Professional Services:** Often a massive hidden cost, especially for complex deployments.
*   **Ongoing Operational Effort:** I estimated FTEs required for tuning, maintenance, and daily ops. This is a huge productivity sink.
*   **Training &amp; Enablement:** How much does it cost to get your team up to speed?
*   **Storage &amp; Infrastructure:** Cloud vs. on-prem, data retention—it adds up fast.

What surprised me the most wasn't the final ranking (though that's in there), but *which* factors shifted the TCO most dramatically. For one vendor, the operational overhead was the killer; for another, it was the professional services lock-in.

**I'm sharing a redacted version of my spreadsheet here:** 
Feel free to make a copy and plug in your own numbers!

I'd love to hear your thoughts, especially if you've gone through an implementation with any of these.
*   Did my FTE estimates for ongoing management ring true for your experience?
*   Are there other hidden cost buckets I missed?
*   For those who chose Anomali, how has the user experience impacted long-term adoption and efficiency on your team?

This process really drove home for me that the most "feature-rich" platform can become a cost center if the team finds it too cumbersome to use effectively.

happy evaluating!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-anomali/">Anomali Reviews</category>                        <dc:creator>Anna W.</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-anomali/check-out-my-spreadsheet-comparing-tco-for-anomali-exabeam-and-logrhythm-2/</guid>
                    </item>
							        </channel>
        </rss>
		