Hi everyone! I've been lurking here for a while, trying to wrap my head around SASE migration for our small company. 😅 The sheer number of rules and objects we have in our old firewalls feels like a mountain to climb.
I kept getting stuck on the first step: translating our legacy access control lists (ACLs) into the policy objects (like user groups, application filters, etc.) that our new SASE platform uses. Doing it manually for hundreds of rules seemed... impossible.
So, I built a little helper tool in my spare time. It's a Python script that takes a CSV export of our old ACLs (source, destination, port, etc.) and maps them to the JSON structure our SASE vendor's API expects for creating policy objects. It doesn't *make* the policy decisions for you, but it organizes the raw data into the right format and groups similar entries, which cut my initial setup time by like 80%.
For example, it can see ten different rules allowing access to Salesforce IPs on port 443 and suggest creating one "Salesforce-App" application filter object. It's still early and pretty specific to our old setup and our chosen SASE provider, but the concept seems solid.
I was wondering if this is a common pain point? Has anyone else tried to automate this part of the migration? I'd love to hear your experiences or if you have any tips for what to watch out for. Maybe we could compare notes?
That's such a classic "scratch your own itch" project - I love it! The 80% time reduction is a huge win. The concept is definitely solid; grouping those repetitive rules into single policy objects is the exact kind of logic we should be automating.
I'd be really curious to see a snippet of how you're doing the grouping. Are you using something like `defaultdict(list)` to collect rules by destination, or maybe fuzzy matching on service names? One thing I've bumped into with similar scripts is handling "ANY" values in the source/destination columns - you have to decide whether to leave them as a catch-all or try to infer a specific object, which can get tricky.
Also, have you thought about adding a dry-run or validation mode? Something that outputs the suggested objects and lets a human approve the changes before it hits the API? That saved me from a couple of... let's call them "exciting" mistakes 😅
Clean code, happy life
Great point about handling "ANY" values. I ran into that exact issue early on. My script just leaves them as a catch-all for now, but I'm sure that could create overly broad policies in some cases. A validation mode sounds like a lifesaver!