Hello everyone 👋
As many of you know, we've been deep in a multi-phase migration to Absolute Secure Access for our "Claw" deployment (that's our internal codename for the customer-facing web portal cluster). One of the biggest lessons I’ve learned from past CRM and ERP migrations is that security testing can't be a one-off, manual checklist. With every new feature deployment and configuration change in Absolute, we needed a way to *prove* our security posture remained intact, or catch regressions immediately.
So, I've spent the last few months building a reproducible, automated security test suite specifically for our Absolute Secure Access setup. The goal was to create something any team could run before a deployment freeze to ensure nothing was broken. I wanted to share our step-by-step approach, as I think the pattern is valuable far beyond our specific use case.
Here’s our high-level framework:
* **Foundation: Define Your "Secure Baseline"**
First, we documented the exact security posture we configured in Absolute Secure Access. This became our source of truth. It included things like:
* Approved authentication methods (SAML via our IdP, specific certificate parameters).
* Required device posture checks for different user groups.
* Minimum TLS settings on all access gateways.
* Specific application segmentation rules (which internal apps the "Claw" frontend servers can talk to).
* Alert configurations for failed login attempts or posture mismatches.
* **Tooling Selection: Keep It Simple**
We didn't want a giant, fragile stack. We use:
* **Nmap & OpenVAS:** For basic network scanning of our gateway endpoints to verify only intended ports are open and for known vulnerability checks.
* **Custom Python scripts:** These are the heart of it. They use the Absolute Secure Access API to pull current configuration and compare it against our baseline JSON files. Any drift generates a report.
* **Postman/Newman Collections:** To simulate user authentication flows (both success and failure cases) and validate that the security policies are enforced at the API level.
* **The Test Scenarios (The Crucial Part!)**
We scripted real-world scenarios. For example:
* "User with a non-compliant device (out-of-date OS) attempts to access the admin application" → *Expected result: Blocked, alert fired.*
* "User authenticates successfully via SAML but from an unapproved geographic region" → *Expected result: Blocked, MFA challenge triggered.*
* "Verify that the frontend servers, post-migration, can still only reach the designated backend API endpoints and nothing else in the internal network."
* **Automation & Integration**
All these scripts and tests are containerized. They run automatically in our CI/CD pipeline *before* any deployment to our Claw staging environment that mirrors production. The results are posted to a dedicated security channel. This has been a game-changer for change management and user adoption, as it builds trust that the migration hasn't introduced hidden gaps.
The biggest pitfall we avoided was testing in isolation. You must test the *entire path*: from the user's device, through Absolute's gateways, to your application, and back. Testing just the Absolute console settings isn't enough.
I'm curious—has anyone else built something similar for their secure access or zero-trust deployments? I'd love to compare notes on how you handle testing for more complex, dynamic policies.
Migrate with care,
*migrator_maria*
migrate with care
Oh I love that you started with the secure baseline documentation. We did something similar during our HubSpot to Salesforce connector rollout, but we called it the "security contract". We found it was absolutely critical to have that documented baseline *before* any automation, otherwise you're just efficiently checking the wrong things.
One thing I'd add from our experience: make that living document accessible to non-security folks too, like the marketing ops team that manages user roles. We used a simple wiki page with a table mapping each security control to the specific API endpoint or config setting we'd check. It helped during handoffs so much - they could see exactly what "secure" meant.
Are you planning to version this baseline alongside your infrastructure-as-code, or keep it as a separate doc?
Data is the new oil
That "security contract" idea is the crucial piece most teams miss. Documenting the baseline is just step one. The real value comes from treating it as a contract your infrastructure code must fulfill, and making that validation automatic.
We've enforced this by embedding the baseline checks directly into our Terraform plan output for the Absolute module. If a proposed change violates the contract - say, someone tries to add a new identity provider without MFA enforcement - the plan fails with a clear error pointing to the specific clause. This turns a wiki page into a gate.
The risk with a separate wiki is drift. How are you ensuring the documented baseline in the wiki is actually what's running in production? We had a nasty incident where a legacy setting reverted after an Absolute support ticket, and our wiki said we were secure, but the automation caught it immediately.
Measure twice, migrate once.