Automation and API Usage for Operations

Let us start with what an API is. API stands for Application Programming Interface. Think of it as a menu in a restaurant. You (the customer) have a menu that lists what you can order. You do not need to know how the kitchen cooks the food — you just tell the waiter your order, and the kitchen handles the rest. In IT, an API is that menu. It defines exactly what commands you can send to a piece of software and what responses you will get back.

Now, PAN-OS is the operating system that runs on Palo Alto Networks firewalls. It has its own API called the PAN-OS XML API. XML stands for eXtensible Markup Language. It is a way of writing data that both humans and computers can read. It looks like structured text with tags, similar to HTML but customisable. For example, a simple XML message might look like: <request><show><system><info/></show></request>. This is a request asking the firewall to show its system information.

So what does the PAN-OS XML API actually do? It lets you send commands to your firewall in a standardised way, and the firewall responds with structured data. You can do almost anything you can do through the web interface (GUI) — add a security rule, modify a policy, check logs, reboot the device, change an address object, and much more — but you do it by sending an XML message over HTTP or HTTPS.

Why does this matter? Before APIs, if you had 50 firewalls and needed to add a new rule blocking a malicious website on all of them, you would:

That takes hours and is incredibly boring. One typo and you might block legitimate traffic or leave a security hole. With the API, you write one script (a set of instructions that can be executed automatically) that sends the same XML message to all 50 firewalls. The whole job takes a few seconds.

Automation takes this a step further. Automation means having a computer perform a task repeatedly without human intervention. In the context of PAN-OS, you might write a script that runs every hour to check if any firewall rules are out of date, then automatically updates them. Or a script that checks for new threats and adds blocking rules instantly.

How does authentication work? To use the PAN-OS XML API, you need to prove you are allowed to make changes. You do this by providing an API key. An API key is a secret token — a long string of letters and numbers — that identifies you to the firewall. You generate this key once by sending your username and password to a special API endpoint (a specific URL on the firewall). The firewall returns an API key, and you use that key in all future requests instead of sending your password every time.

A typical API request looks like this: you send an HTTPS request (secure web request) to a URL like: https://YOUR-FIREWALL-IP/api/?type=config&action=set&xpath=/config/devices/entry/vsys/entry/rulebase/security/rules&element=<rule><name>Block-Bad-IP</name><action>deny</action></rule>&key=YOUR-API-KEY. That is one long URL with parameters. The firewall reads it and adds a new security rule called "Block-Bad-IP" that denies traffic.

What can you do with the API? The PAN-OS XML API supports several operation types:

Each of these operations uses a specific 'type' parameter in the API URL.

What tools do you use to send API calls? You can use almost any programming language. Python is the most popular because it has libraries (pre-written code) that make sending HTTP requests easy. For example, the 'requests' library in Python lets you send an API call in three lines of code. You can also use command-line tools like 'curl' (a tool for transferring data with URLs) or Postman (a graphical application for testing APIs). Some engineers use automation platforms like Ansible (which has a module specifically for Palo Alto Networks firewalls) or Terraform (for infrastructure as code).

What is a commit? In PAN-OS, when you make a configuration change via the API, the change is not active until you perform a 'commit'. A commit tells the firewall to apply all pending changes and make them part of the active running configuration. Without a commit, your changes are saved only as candidates. The API allows you to trigger a commit by sending an operational command: type=op with a command like <commit></commit>.

How do you handle errors? The API returns XML responses that include status codes. A successful request returns a status of 'success'. An error returns a status of 'error' with a message explaining what went wrong, such as "invalid key" or "object already exists". Your automation scripts should check these responses to know if the request succeeded.

In summary, the PAN-OS XML API gives you a programmable way to control your firewalls. Automation uses that API to execute repetitive tasks automatically. This replaces tedious manual work with efficient, scripted operations.

Consider this: Sarah is a network security engineer at a mid-sized company called TechFlow Ltd that has 30 Palo Alto Networks firewalls deployed in offices around the world. One Monday morning, the company's security team identifies a new malicious IP address that is actively trying to attack their web servers. They need to block this IP on all firewalls immediately — ideally within minutes.

Without automation, Sarah would have to:

This would take at least an hour, and Sarah might make a typo in one of the 30 firewalls, leaving one unprotected.

Instead, Sarah uses automation. She has a Python script saved on her laptop called 'block_ip.py'. She opens a terminal, types: python block_ip.py --ip 5.5.5.5 --reason "Emergent threat"

The script does the following: 1. It reads a list of all 30 firewall IP addresses and their API keys from a secure configuration file. 2. For each firewall, it constructs an XML API request to add a new security rule with the malicious IP. 3. It sends the request via HTTPS to each firewall's API endpoint. 4. It checks the response from each firewall to confirm the rule was added successfully. 5. If any firewall returns an error, it logs that for Sarah to review. 6. Once all rules are added, the script sends a commit command to all 30 firewalls simultaneously.

Total time: about 30 seconds for the script to run, plus a minute for the commits to complete. Sarah then runs another script to verify the new rules are active by querying each firewall's rulebase and printing a status report.

Later that week, Sarah needs to generate a report of all traffic blocked by the new rule over the last 48 hours. She uses another script that calls the 'log' API to retrieve the traffic logs, filters them for the rule name "Emergency-Block-2025-03-24", and compiles them into a CSV file (Comma-Separated Values — a simple table format for data).

At the end of the quarter, the compliance team needs an audit of all firewall rule changes made in the last three months. Sarah uses an API script to export the full configuration of each firewall, which she stores in a version control system (like Git) to track every change. This way, if a problem arises, she can instantly see who changed what and revert to a previous configuration using the API.

Sarah also uses scheduled automation. She has a cron job (a time-based job scheduler on Linux) that runs every night at 2 AM:

This means Sarah does not have to sit up all night watching logs. The automation handles the routine tasks, and she only gets involved for exceptions.

The key takeaway from Sarah's experience is that automation and API usage turn a reactive, manual, error-prone job into a proactive, efficient, and reliable operation. The engineer becomes a supervisor of automated processes rather than a manual labourer.