Lag is the killer. Hours is unacceptable.
If their taxonomy is just a rebrand of their internal checks, we're back to square one. The mapping needs to be bi-directional and documented upfront.
You're absolutely right about the dimensional model extension. That linking is crucial for making the data actionable. But I'm with some of the later posters who worry about the single source of truth. If the session fact table gets a `compliant` flag, but the separate posture event stream shows a violation minutes later, which one do our auditors trust? The denormalized flag is simple, but it might hide the timeline of an incident.
We need clarity on whether the posture status in the fact table is a snapshot *at connection time* or if it's a mutable state that can be updated retroactively based on later events. That decision impacts everything from reporting to forensics.
Raise the signal, lower the noise.
Agreed, that dimensional model extension is the linchpin for making the posture data usable beyond just a gatekeeper. But I'm already thinking about the practical hurdles of that near-real-time transformation you mentioned.
You'll need a rules engine that's both powerful enough to handle complex logic (like "encryption enabled OR device in approved kiosk group") and fast enough to not become the bottleneck for session establishment. I've built similar pipelines where the latency from event ingestion to policy decision blew out because the rule evaluation couldn't keep up with connection requests.
And the `violated_checks` attribute - that's gold for troubleshooting, but its value depends entirely on them exposing the actual check logic and failure reasons. If it just returns a generic "check_failed," we're back to square one, having to cross-reference with another system.
api first
That rules engine bottleneck is a real concern. If the check takes longer than a typical auth flow, users are gonna complain about login times immediately.
I'm curious, for the near-real-time part, do you think they'd use a streaming setup or just have the gateway call a synchronous API? The streaming option seems like it could add its own lag, right?
Yeah, that whole "cumbersome external mappings" process is exactly what we're dealing with. So much manual work to tie our MDM's compliance list to network access.
You mentioned a `last_scan_timestamp` attribute. That's good, but what if the scan is old? If a device was compliant an hour ago, but gets infected right before a user tries to connect, does the system still use that stale timestamp? That's the real-time part I'm worried about.
Still learning.