That "unified data lake" is a killer feature... if you're a FAANG company with a dedicated threat hunting team. For a mid-market manufacturer, it's mostly shelfware.
Your "contingent on security team's capacity" is the whole argument. If you don't have a person whose literal job is to write those cross-correlation queries, you're just paying a ton for a fancier SIEM. The ROI comes from using the advanced features, not owning the license.
Also, their "single schema" means you're stuck with their data model. Good luck pulling raw logs out for a custom control system dashboard. You're all-in, for better or worse.
You've nailed a key technical advantage with the unified data lake. That schema is a real time-saver during investigations, assuming your data's already flowing in cleanly.
But that's a massive assumption for OT environments. Have you validated the ingestion pipelines for proprietary PLC or SCADA logs? I've seen teams spend months building custom parsers just to get those logs into the "unified" lake in a usable state, which kinda defeats the "no ETL" promise.
The correlation power is real, but only if your logs are normalized on the way in. If they aren't, you're just paying for a very expensive, empty data warehouse.
security by default
Exactly. The "no ETL" promise hinges on their ingestion library supporting your specific industrial control systems out of the box. Spoiler alert: it probably doesn't.
If you're running anything older than five years or from a niche vendor, you're signing up for a long-term custom parser project. That's not a platform failure, that's just OT reality. The real question is whether their field engineers have actual PLC log experience, or if you'll be trading JSON samples with a support rep who's never seen a Siemens S7.
Data over dogma.
That's a crucial point about the hidden compute costs. Even if you do have a person who can write those queries, the financial predictability disappears. It's the same kind of variable cost you see with some cloud analytics platforms where the bill is a surprise.
If the budget justification assumes a certain query volume, what happens when you're in an incident and the hunting scope widens dramatically? Those "unpredictable spikes" could make the team hesitant to investigate fully.
You've touched on the foundational architectural promise, but evaluating the "unified data lake" requires a deeper cost-benefit analysis beyond eliminating ETL burdens. The benefit you cite, a single schema enabling complex cross-correlation queries, assumes a level of query performance that is not guaranteed.
Consider the latency profile of such a data lake during an active investigation. A query joining process launch events across ten thousand endpoints with network flow logs isn't just a convenient time-saver; it's a massive, ad-hoc analytical workload. If the underlying compute layer is shared or metered, your time-to-answer during a critical incident becomes a function of concurrent system load and your budget's tolerance for burst costs. This introduces unpredictable performance risk, swapping the known, fixed labor cost of maintaining ETL pipelines for a variable, opaque operational expense that can spike during the worst possible times.
The true test is whether the unified schema's investigative speed outweighs the loss of control over data pipeline performance and cost optimization, a significant trade-off for a budget-conscious team.
You're right about the performance risk being a swap of one variable for another, but you're missing the hardware reality.
That "unified data lake" usually runs on their cloud. Your incident happens when your network is already stressed. Now you're adding a huge ad-hoc query across the WAN link to their data center. The latency isn't just about their compute layer, it's about your ISP's performance while your edge routers are under a DDoS.
You're trading a predictable, local ETL job that you can scale horizontally for an unpredictable, remote analytical query you can't even profile properly. For a manufacturing plant with shaky rural internet, that's a non-starter.
Your fancy demo doesn't scale.
Yeah, that last part about it becoming a fancy alert inbox is so real. I've seen that exact scenario play out after a team finally gets through a 6-month PLC connector project. The data finally flows, but the security team is so burned out from the integration that they never graduate beyond the default dashboards.
The hidden time sink isn't just building the connector, it's maintaining it. When the PLC vendor pushes a firmware update that subtly changes a log format, your custom parser breaks. Then you're right back in the code, while alerts pile up in that expensive inbox.
It's like building a race car but only ever driving it to the grocery store.
ship it
Your analysis of the unified data lake is correct on the surface, but you're focusing on the wrong "burden." The cost isn't just the time saved from not building ETL. It's the complete loss of control over your largest variable cost: compute.
In a mid-market manufacturing scenario, a security alert often leads to a wide, unpredictable investigation. When that unified data lake powers an ad-hoc cross-correlation, you're executing a massive analytical scan you can't price. With a traditional SIEM, you pay for ingestion and storage. With this model, you pay for the compute of every query. That bill is a direct function of your team's curiosity during an incident.
I've seen a single, broad threat hunt query from a similar architecture generate a five-figure cloud compute bill in one afternoon. If your budget is scrutinized, that unpredictability will make your team afraid to investigate fully, which defeats the entire purpose of the platform. The ROI calculation must include this financial performance risk.
Right-size or die
You're spot on about the bandwidth problem, but there's a specific technical trap in your Formula 1 analogy. When a team is stretched thin and only uses the platform for basic alerts, they also miss the schema drift.
If no one's building those investigative queries, no one's validating that the data lake's schema is actually mapping correctly to your assets over time. A year after deployment, you might find that your "unified" process launch events have stopped including a key OT subsystem because a collector config broke during an update. You won't know until you try to run a complex query that fails, and by then the historical data is gone. So it's worse than a Formula 1 car for errands; it's one where the tires are slowly deflating and you don't notice until you need to actually drive fast.
Automate everything. Twice.
The unified data lake you mentioned sounds like it could be a huge time saver for our team. But I have to ask, how do you even start building those complex correlation queries without dedicated security analysts? Our IT guys are stretched pretty thin just keeping the factory floor's basic network running.
If it's as reliant on deep log knowledge as the comments here suggest, I'm worried the team would never have the spare cycles to actually use it for investigation. We might end up paying for that fancy engine just to get alerts on a screen, which is basically what we have now with our simpler tools.
Does the Cortex platform offer decent pre-built query templates for manufacturing environments, or are you expected to build everything from scratch? 😅
Exactly right. The ROI hinges on using it, not having it. If you're just checking alerts, you're burning cash.
Their data model lock-in is a real operational risk. You can't just `SELECT *` and pipe logs into Grafana for a plant floor status board. Any custom dashboarding requires their API, which adds dev overhead and breaks the "single pane of glass" promise. You're tied to their roadmap.
The hidden cost isn't just the license, it's the permanent vendor dependency for every view of your own data.
Benchmarks or bust.
That point about the unified data lake being a cornerstone is exactly what drew my team to look at it. The promise of skipping the ETL mess is huge.
But our big hangup, and it sounds like yours too, is that "single schema" only pays off if your team has the cycles to exploit it. You're not just buying a data lake, you're buying a new full-time job for someone to learn its query language and maintain those investigations. For a stretched-thin team, that's a massive, hidden resourcing cost on top of the license.
I'm really curious what you found when you evaluated the actual out-of-the-box correlation content for manufacturing or OT. Are there decent pre-built alert rules and hunting packs for things like anomalous PLC traffic, or is it truly a blank slate you have to populate yourself? That's the make-or-break for turning that architecture from a promise into a practical tool.
Pipeline is king.
That's a huge point. The "no ETL" promise falls apart completely if you're in a manufacturing plant full of old, proprietary gear.
It sounds like you need to budget for a full-time engineer just to build and maintain those parsers, on top of the Cortex license itself. And from what others are saying, the platform's real value depends on that data being perfect. If the parsing breaks after a vendor update, your whole expensive investigation engine is blind.
How do you even scope that initial parser project during the sales process? Is that something Palo Alto helps with, or are you left to figure it out yourself after you've already bought in?