The parsing layer nobody owns.

A few years ago I was reconstructing the order of events during an incident at a regulated utility, and the timeline refused to make sense. Connections that should have followed each other arrived hours apart; a session looked like it had torn down before it was built. I assumed I'd made a query mistake, then a parsing mistake, and only after I'd exhausted the things that are usually my fault did I check the one thing nobody checks, which is whether the clocks agreed. They did not. The firewall fleet had been configured over years by different people in different regions, and the appliances were set to a spread of timezones, UTC on some, US/Eastern, Central, Mountain, and Pacific on others, so that across the estate the same instant could be stamped as much as eighteen hours apart depending on which box you asked. The timeline I'd been staring at wasn't wrong because of a bad query. It was wrong because the ground underneath it wasn't level.

Time is the foundation you're standing on in security. Almost everything we do to data after it lands assumes the timestamps are true: correlation across sources, impossible-travel math, the simple human act of saying this happened, and then that happened. A detection is a statement about sequence and rate, and sequence and rate are functions of time. When the clocks disagree by eighteen hours you don't have a small error you can absorb with a tolerance window; you have a fabricated history, and the dangerous part is that it still looks like a history. Nothing throws an exception. The dashboard renders, the query returns rows, and you are quietly, confidently wrong about when things happened, which during an investigation is the one thing you cannot afford to be.

The part of this that taught me the most wasn't the misconfiguration, it was what happened every time I raised it. I'd take the discrepancy to the firewall subject-matter experts, and they would open their Palo Alto console, the vendor's own tool, and show me that the time was fine. And in their tool it was fine. My read, and I can't see the internals, so I'll hold this as inference rather than fact, is that the appliance keeps richer, better-timestamped telemetry for its own management plane than it ships out over the syslog feed to the SIEM, so the vendor console always had enough fidelity to render a coherent picture while the SIEM was working from a thinner, zone-ambiguous copy. The practical effect was a lesson the organization kept relearning without ever quite saying it: if you want the real data, the high-quality data, you go to the vendor's tool. The SIEM, which is supposed to be the place where you correlate across every vendor you own, was quietly getting the second-class feed, and the people closest to the device had been trained by the tooling to believe the problem was on my end. Palo Alto and Splunk were not, in this respect, symbiotic partners. The data crossed the boundary between them and lost something on the way, and no one whose job it was to care about that boundary actually owned it.

If this were only a Palo Alto story I'd file it under one vendor's neglect and move on, but I've now seen the same shape enough times to think it's structural. Take Zeek, the open-source network-monitoring data that Corelight productizes, where I found and contributed parsing fixes to Corelight's Splunk app while I was their customer (I'd later go to work there, which I should disclose, though everything in this account predates it). Splunk, by default, timestamps an event using the first time value it encounters in the record, which is a reasonable general heuristic and the wrong one for Zeek specifically, because the first time value in a Zeek log is frequently the write timestamp, the moment the log was flushed on the sensor, and not the event start time, which is the timestamp security actually needs. The standard is that you stamp an event when it began, because that's the moment you're reasoning about, so stamping it when the sensor happened to write the record offsets your network telemetry by buffering and batching latency that has nothing to do with the event. It's a smaller error than eighteen hours, but it belongs to the same category: the time is wrong in a way that's invisible until you go looking, and it's wrong in the SIEM specifically, in the cross-vendor layer, while the vendor's own tool looks correct. I contributed that fix at the vendor level rather than just patching it locally for one employer, because the local patch is the easy move that quietly abandons everyone standing in the same hole. Fixing your own copy is real work and real relief, and it also lets the systemic problem persist for every other customer who hasn't figured it out yet.

Or take Tenable, where the failure was shaped differently but rhymes. The vulnerability data was reaching the SIEM, technically, except the genuinely valuable part, the structured CVE context you'd actually use to evaluate exposure across your infrastructure, arrived nested inside a field and unparsed, so until you happened to discover where the value was hiding you could not query your own CVEs in any way that crossed your environment. I ended up building a local SIEM app to extract that nested data into fields a human could reason about. The data was present and useless at the same time, which is its own kind of data-quality failure, and again it lived precisely at the handoff into the correlation layer rather than inside the vendor's own product.

Put those next to each other and a pattern shows through. In each case the data technically arrived, and a naive integration would report success: bytes moved, events ingested, a green check on the source-health page. And in each case the data was wrong in a way that mattered and was hard to see, the timezone that didn't exist, the field that slid one position, the write-time wearing the event-time's clothes, the context folded into an unparsed blob. The common thread is that the corruption happens at the boundary between systems, in the parsing and normalization layer, which is exactly the layer no single party in the chain is paid to get right.

I've since measured how common this is across real logs. I took twelve thousand real production log lines (public samples across six systems, parsed by code against each format's published grammar, with no model in the loop) and the gap between what the standard documents and what the systems actually emit ran from zero to forty-three percent depending on the source. The case I keep coming back to is the one a detection engineer would never think to check: the same sshd daemon, on two different real deployments, writes its program field two different ways. One emits sshd, exactly as the syslog standard describes. The other emits sshd(pam_unix), the PAM module that did the logging folded into the program token, on every one of its six-hundred-odd authentication events. A detection or a normalization rule keyed on the documented program name sshd silently matches none of them; the authentication failures and the attempted break-ins are all sitting in the data under a token the rule was never told to expect, and nothing fires. The standard never sanctioned that form, the deployment emits it anyway, and the only way to know is to measure your own feed against the spec instead of trusting that the two agree. These are operating-system and application logs rather than a commercial security vendor's feed, and the rate tracks how a given deployment is configured rather than being a fixed property of the source, but that is the unowned layer again one level down, where whether your parser is right depends on a convention nobody wrote down.

What's missing is anyone whose incentive is aligned with the practitioner across the whole market rather than with a single product, a single contract, or a single retained client. Standards help with part of this, and I don't want to undersell them. The Open Cybersecurity Schema Framework gives you a defined place to put a normalized timestamp and a typed home for fields that used to land in a free-text blob, which is genuine progress and a lot of my own benchmarking work measures how completely real vendor schemas map into it. But a schema can only describe where a correct value should go; it cannot manufacture a correct value out of a feed that never carried a timezone, and it cannot decide for Splunk that the Zeek event-start time matters more than the write time. Field-mapping fidelity asks whether there's a correct place to put the value. Data quality asks whether the value that lands there is true. You can have a flawless schema mapping carrying a confidently wrong timestamp, and most of the time nobody will notice, because the pipeline is green and the dashboard renders.

That gap is the reason I'm building Security Data Works the way I am. The idea is to act as a fair broker: to benchmark the things vendors and integrators have an incentive to keep quiet, and to say them out loud, on the record, with reproducible evidence and disclosed positions. Palo Alto's syslog feed ships without a timezone, and the community Splunk app carried well over a hundred broken and missing field extractions for years. Splunk's default timestamp logic picks the wrong field for Zeek. Tenable's most useful context arrives nested and unparsed. None of those is a secret to the people who've hit them; all of them are effectively secret to the practitioner who hasn't yet, because the knowledge is locked inside vendor consoles, unmerged pull requests, and integrator playbooks. The evidence I produce is meant to make that knowledge public and checkable, not vendor assurances, not integrator promises, but tests and teardowns you can run yourself and disagree with line by line. Some of those checks already run as code: the public demonstration stack ships a data-health gate (./moar healthcheck in security-data-that-works) that tests exactly this class of failure: timestamps actually in epoch UTC, no NULL hiding inside a filter set, row counts that agree across engines. On clean data it reports healthy, and the same checks caught every fault injected into the demonstrator.

I should be honest about the limits, because a fair broker who oversells is just another interested party. I'm one person with a point of view, not an institution; the evidence I produce is reproducible practitioner-grade work, which is a real tier but not peer review; and I hold positions I have to disclose rather than pretend away. This isn't a solved problem with a product bolted on. It's a structural gap in how the security-data market is organized, where the cost of bad data at the boundaries is paid by practitioners and the durable incentive to fix it sits with no one. I don't think naming that fixes it overnight. I do think someone has to stand in the gap and name it plainly, with evidence, without something else to sell you, and that the absence of anyone doing so is most of why the problem has lasted as long as it has.