Just wrapped up our quarterly security audit. The headline? Our Cato SASE deployment, which we've been running for about a year, left way more doors open than we thought. Their default security policy templates, especially for new applications or subnets, are shockingly permissive. It's like they assume you're going to meticulously review and lock down every single rule—which, of course, you should—but the starting point feels designed for "ease of use" over actual security.
For example, spinning up a new dev environment automatically got a policy that allowed "Any" for source and destination with a bunch of common service ports. No alert, no flag, just a wide-open rule sitting there. We found several similar instances where the defaults essentially created an implicit trust zone. I get that they want to avoid breaking things on day one, but this feels like handing someone a car with the gas pedal already floored and saying "just steer."
Anyone else run into this? What's your process for hardening the initial setup? I'm starting to think we need to treat their default templates as a "deny all" baseline and build from scratch, which kind of defeats the purpose of having templates in the first place.
just sayin'
Data over dogma.
Yep, that default "Any-Any" rule for new subnets is a classic. Seen it with a few other SASE/cloud network vendors too. Their sales pitch is always about simplicity, but the default posture is basically a flat network.
We skipped the templates entirely after our first audit scare. Now our process is: deploy any new app or VPC segment with a placeholder rule that denies all traffic, then build the explicit allow rules from the actual observed flow logs over the first 48 hours. It's more work, but you start secure.
It feels like the vendors are optimizing for a quick proof-of-concept win, not for production.
Totally agree on the "optimizing for PoC" point. That default any-any is a huge trap for busy teams.
Your flow log method is smart. We do something similar, but started tagging our placeholder deny rules with a "Bootstrap - [App Name]" comment. It forces a conversation with the app team before we convert it to allow rules, so they're involved in the security model from day one.
It's extra steps, but you're right, it's the only way to avoid that scary audit finding. The vendor defaults just can't be trusted.
Let's build better workflows.
That "gas pedal floored" analogy is spot on. It's exactly how I felt when I first saw our Cato setup.
We're a smaller team, so we actually relied on those templates hoping they'd save time. This post is a real wake-up call. Thanks for sharing your audit findings.
Is there any part of the default setup you think is actually worth keeping, or is it really just a full wipe and start from deny all?
That "placeholder deny rule with a comment" method user623 mentioned is gold for smaller teams. It turns a technical rule into a required conversation starter.
To your question on keeping defaults, I'd keep the basic service account and admin access rules that tie back to your directory, like AD or Okta groups. Those are usually sane. But the network rules for new apps or subnets? Scrap 'em. It feels painful to start from deny all, but the initial time you spend reviewing flow logs is less than the panic during an audit.
ship it
Yep, that default "Any-Any" rule for new subnets is a classic. Seen it with a few other SASE/cloud network vendors too. Their sales pitch is always about simplicity, but the default posture is basically a flat network.
We skipped the templates entirely after our first audit scare. Now our process is: deploy any new app or VPC segment with a placeholder rule that denies all traffic, then build the explicit allow rules from the actual observed flow logs over the first 48 hours. It's more work, but you start secure.
It feels like the vendors are optimizing for a quick proof-of-concept win, not for production.
ship it
That flow log method is solid, but you have to watch out for background noise. We tried it once and had to filter out a ton of cloud metadata polling and health checks before we could see the real app traffic.
Still, your main point stands. Starting from a deny-all placeholder is the only way to guarantee you aren't inheriting those overly permissive defaults.
You've hit on a real tension in product design. That "ease of use" default is, in my experience, less about helping the admin and more about avoiding initial support calls from app owners complaining their stuff is broken. The vendor shifts the security burden entirely onto your operational review process.
One nuance I've seen is that this permissive default often extends to their API and automation workflows. If you're provisioning a new site or segment programmatically, the default policy objects attached are frequently the same risky templates. It means you can't treat "Infrastructure as Code" as a secure-by-default pipeline either; you have to explicitly embed a restrictive policy in your Terraform or Ansible playbooks. So the "gas pedal floored" problem gets automated and scaled.
Your idea of treating the template as a "deny all" baseline is correct. But to make it practical, we scripted the creation of a new, locked policy as the first step in any environment build. The template isn't the starting point, it's just a source of pre-defined service objects we might reference. The actual starting rule is always an explicit DENY.
IntegrationWizard
Exactly! Shifting the burden to avoid support calls totally explains the vendor mindset. It's a support cost vs security risk trade-off they make for you.
Your point about IaC is so critical. We got bitten by that exact issue last month. Our Terraform module for a new app stack pulled in the default "SASE-App-Template" policy. We assumed it was a tagged, restrictive baseline. It was not. The automation just silently replicated the problem.
We're doing something similar to your scripted policy now. Every pipeline has a mandatory first step that applies our own locked-down baseline template from a secure internal repo. Vendor templates are treated as a library of service objects at best, but never trusted for initial posture.
It feels like we have to build our own guardrails because theirs are just too far apart.
Your audit findings mirror what I've seen at three different companies now. That "gas pedal floored" feeling is exactly right - vendors are terrified of being blamed for a blocked connection during a sales demo.
You asked if you should treat defaults as a deny-all baseline and build from scratch. My unpopular take: yes, you absolutely should, and it doesn't defeat the purpose of the templates. The purpose is wrong. The template should be a restrictive, explicit-allow framework, not a connectivity wish list.
We created our own single, internal "seed" template that only allows IAM and logging services outbound. Every new resource, dev or prod, gets that. Then we use a scheduled Lambda to flag any policy that still uses a vendor default template ID after 72 hours. It forces the issue. The vendor's templates are now just a library of service object definitions we might copy-paste from, never a starting posture.
The time we "lost" building our own baseline was paid back tenfold by never having this exact audit conversation again.
keep it simple
That Lambda check is a fantastic enforcement mechanism, makes it operational instead of just a policy document. The "seed" template approach is the right move.
Your point about the template's purpose being wrong hits home. It reminds me of A/B testing tools - the default is always to show the variation to 50% of traffic. That's great for speed, but terrible if your variation has a bug. You have to override that default to ramp up safely. Same principle here; the vendor default is set for demo speed, not for safe operation.
Do you tag your internal template resources in a specific way so teams can still find and use them easily, or do you keep it locked to a central account?
✌️