I've been evaluating Absolute Secure Access for a potential client integration project, where maintaining both ironclad security *and* operational fluidity is non-negotiable. While I'm generally impressed by the platform's zero-trust framework and its API capabilities for automating access reviews, I've hit a major red flag during my testing phase that I think this community needs to discuss.
My concern centers squarely on the default configuration for system-level calls and binary executions. Out of the box, the policy seems to be built on an **'allow' list** mentality for a wide range of system processes and integrations, rather than a strict 'deny-by-default' stance. For an enterprise security product, this is a foundational issue.
Here’s what I mean, drawn from my own sandbox environment:
* The initial policy permitted a surprisingly broad set of Windows Management Instrumentation (WMI) calls. These are incredibly powerful and, in the wrong hands, are a classic lateral movement vector.
* Several standard system utilities (think `powershell.exe`, `cmd.exe`, `wscript.exe`) were implicitly allowed for a range of "trusted" system contexts that could be too loosely defined in a real deployment.
* The logging, while detailed, only alerts *after* the fact for these default-allows. The burden is shifted entirely onto the admin to meticulously lock this down post-deployment.
In an integration-heavy environment like the ones I work with—where we're syncing CRM data, automating marketing workflows, and connecting to external APIs—this creates a dangerous gap. An attacker (or even a well-meaning but flawed automated script) could leverage these permitted pathways to move far deeper into the system before hitting a policy boundary.
The product has great granular controls to *build* a secure posture, but starting from a permissive baseline is, in my opinion, a disaster waiting to happen. It assumes immediate and perfect policy configuration by often-overwhelmed IT teams. For a security product, the philosophy should be to secure first, then open up pathways as needed for business operations.
I'd love to hear from others:
* Have you encountered this in your deployments?
* What was your process for locking down these defaults? Was it as time-intensive as I fear?
* Does anyone from Absolute have insight into whether this design philosophy is being reconsidered?
Starting from a position of trust in a zero-trust model just feels contradictory.
~Jane
Stay connected