Backend
SoK: Timestamps Are Not a Time Model: Rethinking Temporal Reasoning in Host-Based Intrusion Detection
arXiv cs.CR0 views
arXiv:2610.35151v1 Announce Type: new Abstract: Host-based intrusion detectors order events, window audit streams and sequence attack stages by their timestamps. Every conclusion they draw therefore rests on assumptions about clocks, delivery, entity identity and the integrity of the evidence, and most of these assumptions go unstated. This Systematization of Knowledge (SoK) makes them explicit. Drawing on temporal databases, stream processing and runtime verification, we distill five components of a time model, together with a checklist of evidence assumptions and four levels of guarantee, and walk through a running campaign with them. A documented search yields fifteen families of detection and investigation. For papers selected by screening role and period, plus named systems and landmarks, we check the stated assumptions in the full texts, and we assess eleven temporal knowledge representation and reasoning (KRR) formalisms and a learned baseline on nine attack patterns. Some early alert correlators stated clock and delivery assumptions, and forensics measures clock error. Current provenance-based detectors state no clock bound. Four audited papers describe input-ordering conditions or conventions, but none specifies conditions for conclusion validity across a stated class of delivery failures. In the selected provenance-based systems, campaign composition uses system-specific procedures or objectives, learned state, causal graph queries or language models, and beyond CEP-based query systems, we found no temporal rule language or stream reasoner from KRR applied to host audit data. In 28 of 38 audited provenance-era detector papers, capture or stored evidence is trusted or its manipulation is placed out of scope, and none says which conclusions survive deleted, delayed or forged records. Five open challenges follow from these gaps.
Source:https://arxiv.org/abs/2610.35151PreviousGuardRAG: A Post-Retrieval Defense against Poisoning Attacks in Retrieval-Augmented GenerationNextCan Open Be Too Open? On the Security and Trustworthiness of Fully Transparent LLMs
Related posts
Turn Today’s Messy Notes Into Tomorrow’s Checklist With AI
0dev.to AI
A 763B MoE at "2 Bits": Where the Bytes Really Go in the GSQ-RCO GGUFs, and Why 100% Recovery Sits Inside the Noise
0dev.to AI
How I ship fixes to open-source projects maintainers actually merge (with AI in the loop)
0dev.to AI
Prompt Injection Through Documents: How to Harden an LLM Extraction Pipeline
0dev.to AI
Keeping noindex, the sitemap and the image sitemap in agreement for programmatic pages
0dev.to AI
3 Things in AI You Should Know: Character.AI Files for Bankruptcy
0dev.to AI