DeepTempo’s cybersecurity foundation model, LogLM, played an integral role in discovering errors in a variety of datasets it was being evaluated on. Beyond proving superior performance and exposing critical flaws in public data, these rigorous evaluations and data quality checks power continuous model improvements.
In AI World, good data is always paramount, yet perhaps even more so when we’re applying deep learning to a category like Cybersecurity, where top accuracy is the sole goal. This is exactly what we do here at DeepTempo, and thus, along with experiencing the triumphs of our frontier LogLM’s performance, we’ve become well-versed in weathering the frustrations of bad data. Now, LogLM, our laconically yet aptly named vertical foundation model, is a transformer-based encoder-only model that we train from scratch end-to-end on cybersecurity logs, in order to detect AI-powered attacks. In this way, bringing advances in deep learning (particularly Attention) to bear on threat detection yields an AI model that achieves vastly superior false positive rates, compared to traditional, status quo machine learning approaches, and also detects the hidden signals of novel and AI-powered attacks that are invisible to the same.
But, alas, the model can only be as good as the data it’s trained on. Even small quantities of bad samples or bad labels can be enough to degrade performance: hence why no one puts regular in a Lamborghini. Fortunately, the training data mixture is something that we can police and control. However, when it comes to data and label quality in evals – where the stakes are highest – there is no safety nor assurance, and there is much that can go wrong: perhaps wrong enough even to begin breaking the hairline of a young AI researcher, if care isn’t taken!
One thing I’m grateful for in getting to work with LogLM is that not only can I rely on it to get great performance, but I can also count on it in the event of a (seemingly) bad result. Let me explain: usually, when confronted with a customer eval, LogLM backs up its state-of-the-art billing with superb metrics, often attaining F1 scores in the mid to high 90’s out-of-the-box on a zero-shot test. Traditional ML models can also get similarly high scores after weeks or months of feature tuning, all of which can go to waste if the underlying data distribution shifts: this is the ever-possible drift that LogLM is natively resilient against, due to the fact that attention is performed over sequences of logs, thus enabling the apprehension of the full behavioral intent of a threat actor.
Additionally, LogLM has demonstrated significant superiority over general-purpose frontier LLMs such as Claude, GPT and Gemini: both on classification metrics, and, especially, on cost and inference efficiency – as LogLM, an encoder, runs orders-of-magnitude cheaper than these decoders. To elucidate these differences, we recently open-sourced a new security-focused benchmark, SOCBench, to which we’d be thrilled to accept more community contributions for anyone interested in measuring AI detection performance! This further complements and solidifies our commitment to OSS, alongside Vigil – the leading open-source AI SOC that has rapidly matured since its initial release at RSA earlier this year.
A Customer Dataset: From Poor Performance to Quality Detector
Now, with this foregoing having been laudatory, albeit certainly merited, the skeptic here demands to hear about the model’s pitfalls, and scoffs at the claim that LogLM could be trusted even with a bad result; yet LogLM’s travails will not sate this cynicism. For although this new sequence-based deep learning approach, just like any method, is not exempt from limitations, overwhelmingly - in all the arduous evals it has undergone so far - whenever there has been lackluster performance, it was not LogLM’s fault.
Recently, LogLM underwent an eval for one titanic customer on an extensive dataset containing over 150 different malware variants hidden amidst millions of benign counterparts at about a 1:9 ratio – a veritable cornucopia of nastiness. Despite some strong indications, after submitting the predictions, the results came back and they were, frankly, awful. Basically, LogLM had “missed” a vast majority of the malware traffic (although Precision was still superb at around 98%); yet based on the minority that was captured, some of these confirmed malicious IPs were exhibiting unflagged signatures that appeared to be strange discrepancies: a single packet each was being sent between victim and attacker, except both packets registered zero bytes. This oddity, discovered based on correct LogLM predictions, caught the attention of myself and my colleagues on our AI engineering team.
After relaying this concern back to the customer, sure enough, it turned out that LogLM was not the problem: the data was the problem! What had happened was that the packet header data hadn’t been factored into the logs, and only the payload metrics had been included (ideally, LogLM needs both combined, although it was still able to infer a portion of the attacks in the packet-only version). But, what’s more, this development also resulted in the customer’s further discovery that ~62% of the malicious labels were false positives – i.e. 62% of the “attacks”, all of which had counted against LogLM, had actually been predicted correctly! Suffice it to say, this rocketed LogLM’s true F1 score from very bad, to pretty darn good.
The key takeaway here that I’d like to drive home is that LogLM played the integral role in diagnosing these data issues, despite it having been a blind test; it wasn’t mere happenstance that we were able to identify those errors. In effect, LogLM’s utility is not just constrained to making highly accurate predictions: for even its supposed failures wind up as strong indicators of data aberrations; thus, in an incidental manner, LogLM can also serve as a detector of data quality. Now at face value, this proposition admittedly sounds outrageous and absurd – not just a cop-out of poor performance, but to celebrate failure as an asset? Well, under the right pretexts, this can indeed follow quite naturally, as I’ll try to expound if I may nerd-out about math for a bit.
A Poor Track-Record for Cybersecurity Datasets
If we think about conditional probability, put crudely, it’s a science of shrinking the probability space around a given set of prerequisites. So in the general case of dataset trustworthiness, there’s a whole realm of possibilities, and given that anyone who creates a dataset will be intending it to redound towards good performance in some way, it’d be wise to trust a dataset’s integrity, barring any extra priors. But if a state-of-the-art model comes into play, this fundamentally narrows the scope of potentiality.
As an analogy, consider that when a top sports team is upset by an inferior opponent, it could be the case that the underdog truly outplayed the favorite; however, odds are, there was actually some other externality that caused the upset. Maybe the star athletes were playing hurt, or perhaps the refs had downloaded betting apps. No matter the cause, the point is that for the best-of-the-best, a truly catastrophic error is very unlikely, although for a lesser rival it could be closer to the norm. With that being said, it turns out that model quality isn’t even the most important prior here – in fact, its effect is amplified by a more glaring condition: cybersecurity datasets, specifically network intrusion datasets, are notoriously suspect. And this isn’t just a vibe; it’s an entire subarea of academic research in the security community!
Even if a dataset is properly captured or simulated, such that all of its features are sound, labeling can be very tricky and is often the primary culprit. As it happens, this is also the most high-leverage area where we can use LogLM to identify errors. Another case in point, from a large-scale customer eval on 11 different public datasets, LogLM helped identify that two of these datasets were significantly mislabeled (at the source, i.e. by the researchers who created them, not by the customer). The first indication, again, that something was amiss, was lackluster performance on these datasets. Of course, the only explanations were either that LogLM was bad, or the data was bad. And as it may be evident now, the course of action was to leverage LogLM.
Towards this end, rather than interrogating LogLM’s outputs directly, the key actually lies upstream of the final predictions, at the penultimate stage – where LogLM has compressed the original log inputs down to a single one-dimensional vector, called an embedding. In fact, the reason why LogLM is so effective is because it has learned how to translate similar behaviors into mathematically “close” embeddings. Effectively, this means that LogLM is able to abstractly sort different behaviors into their respective groupings, whether it be legitimate CDN deliveries to users, or an attacker executing SSH Brute Force, all the way up to malware commands: for all of it, LogLM is able to tell things apart. Thus, for a given dataset or distribution, if portions of benign and malicious traffic result in very similar collections of embeddings, that means that LogLM has failed. We can visualize an example here in a plot such as the following:
Open-Source Datasets Eval – An Unexpected Turn
After the zero-shot 11 dataset eval, the labels were revealed, and so the above blob is a snapshot of the portion of data that LogLM was predicting incorrectly in one of the mentioned problematic datasets (LogLM predicted this entire cluster as malicious, yet it’s mostly green, i.e. labeled as benign). But at this point, the reader can probably rightly predict what’s wrong with this plot: yes, it’s the colors – it should be 100% red! Since LogLM isolated these supposedly confused datapoints, indicating that they were all equivalent, the next step was to take a deep-dive back into the corresponding logs. And the results were damning. There were extensive DDoS and Recon attacks within the data, where the attacker IPs had their traffic labeled as both benign and malicious at almost simultaneous timestamps; the graphic below highlights the overlap between benign and malicious labeled logs for the attacker IP listed in the cluster plot:
Thus, this trajectory of LogLM-aided sleuthing made it manifestly obvious that this dataset was no good. And so, these errors having been established, the revelation of the dataset source became quite intriguing. It turned out to be a variant of the ToN-IoT dataset – a veracious mainstay in security academia; however, some other researchers in Australia had begun releasing offshoots of this dataset which they called NF-ToN-IoT, and is now up to three successive versions: all of them errant. The only changes that the NF-ToN-IoT researchers introduced was that they used the exact same ToN-IoT PCAP (packet capture) data, yet they just merely generated logs with a few extra features. Unfortunately, it would seem that they never bothered to cross-check their labels!
Even a cursory glance at the differing benign-vs.-malicious labeling ratios is enough to recognize the gaffe: the original ToN-IoT is almost entirely malicious (~96% labeled attacks), whereas the bungled NF-ToN-IoT-v3 has a malicious label proportion of just 39%. Again, realize, it’s the same underlying data, only with alternate log generations – which is definitely not enough of a change to account for such a yawning label disparity. Overall, it’s certainly a shame when any piece of research lacks basic rigor and is allowed to pass through review unchecked; but for a practice as important as security, mistakes like this aren’t just academic mishaps: by harming the efforts of defenders, they rise to the severity of ceding the advantage to malicious adversaries.
And lastly, the second dataset under issue turned out to be SIMARGL2021, and the problem with it turned out to be admittedly more tame. Within the dataset version that had been downloaded from Kaggle, an entire SlowLoris DDoS attack had been labeled as benign – although in the paper the researchers did describe their execution of this very attack. Thus, the fundamental methodology and generation of this dataset was sound, yet somehow what ended up being publicly released was faulty, and remains so. The following plot shows the discrepancy between the benign-labeled and malicious-labeled DDoS patterns, both of which were all detected by LogLM.
A Token of Appreciation
At this point, I think it’s most fitting to close on a magnanimous and hopeful note, as surely no bitter criticism is warranted here. Indeed, I remain only grateful for the efforts of cybersecurity researchers the world over, despite the mistakes of some; for the work and ineluctable innovation that we’re forging at DeepTempo would not be possible without them: again – AI is nothing without data. And since data is the true gold in this AI rush, we at DeepTempo have been heavily investing our time and resources into developing a robust and versatile data acquisition pipeline. Among other things, we’ve built out our own simulation infrastructure; a custom cyber range that we can blast with agentic hacking; a malware detonation lab; and a scalable data engine that rigorously tests the quality of external data: establishing repeatable workflows taken from our learnings in case trials like the ones described above, so as to forestall these headaches from recurring.
The best part is that LogLM, like all of the other artificial intelligences, is currently at its worst; if LogLM has demonstrated this superiority in its adolescence, it’s trivial to connect the dots and realize that it is eminently poised to be the last detection tool. Our opponents have also gained access to powerful new malign cyber capabilities, but if they’ll soon be caught at every turn, it doesn’t really matter how clever and lightning-fast their exploits become: defense is closer to being solved than we think. Hackers beware.
