(Or perhaps it just speaks API now.)
Classic migration project. ASA to Firepower.
The customer needed another hundred or so network objects and NAT statements adding.
As soon as I heard “about a hundred”, my first thought wasn’t “Right, let’s get clicking.”
It was “This is an automation problem.”
I’d solved something similar before using Postman, importing a CSV and letting the Collection Runner do the heavy lifting.
Except… the Collection Runner now sits behind a paid subscription.
Fair enough. Postman is a commercial product, and good software deserves paying for.
Unfortunately for them, As my children will tell you I’m spectacularly reluctant to spend money especially if I think I can build a workaround..
So necessity became the mother of invention.
A short Python script converted the CSV into the JSON structure the Firepower API expected. Paste the JSON into the request body, hit send…
“…is that working?”
It was.
Around a hundred objects and NAT statements created in less time than it took to ask the question.
The interesting part isn’t really the Python.
It’s how quickly our daily work is changing. Five years ago I’d have accepted repetitive configuration as part of the job.
Today, if I find myself doing the same task more than a handful of times, my first instinct is to ask whether the API can do it instead.
#Automation #Python #APIs #CyberSecurity #NetworkEngineering
The useful shift here is treating “about a hundred” as a design signal rather than merely a large manual task. Converting CSV into the API’s JSON shape separates the source data, transformation, and request, which also makes it possible to validate object names or produce a dry-run report before changing Firepower. For a repeatable migration, I would also want each request to log its result and handle an object that already exists, so rerunning after a partial failure does not duplicate work. That is where the CLI has not disappeared so much as become a transparent, testable front end for the API.
LikeLike