Auditing Security Policy Updates

First in a series ... hopefully

This is the first of a series of Audit-related articles I'll be posting over the next few months. The goal is to discuss how to use existing systems and augment existing processes to track better, report on, and improve the security of your applications. The articles may touch various F5 technologies, or they may wander to adjacent technologies that I see our customers use. I invite you to comment below on my articles, add your own ideas or things you've done… maybe even contribute an article or two.

This article deals with a problem that is all too common … how do I audit my SecOps tools? In a future article, we'll address config drift … that's another one that comes up all the time. In another article, we'll talk about what reports are useful for your day-to-day operations and what helps steer and inform your management.

Let's start with a little story…

Panic at the SecOps

You get the calendar invite for the "Annual Security Audit," and the panic starts.

What are they going to ask this year?

How do I even know what I've done this year half of my year was panicked changes. What did we even do for Log4Shell?

The other half was planning for changes that never happened.

If there was only a way that we could report the things that have happened.

I feel the pain here… "looking back" is nearly impossible in today's business world. The speed of change and the number of things we all are responsible for are increasing while the amount of time we have for those items is inversely proportional and decreasing steadily.

The key to managing these reports is to create a way to see the changes in 'real-time' and then use the tools at hand to surface them when you need to see them.

I got this question from a FinTech customer earlier this year.

They wanted to show their auditors how their security policy is maintained throughout the year. They want to make sure that if there is a change, they are notified of the change so they can track those changes.

This customer uses F5 BIG-IP Advanced WAF, which provides a mechanism to track any changes to the configuration.  This information is stored in a database and is available for querying through the Management API.  So, we set about to build a process that would allow them to query these changes and then output a log of them.

I thought BIG-IP’s iControlREST API would be the way to get this information. Whenever a change is made to a Security Policy, there is an Audit record created.  This record includes the date/time of the change but also what was changed, who did the change, and info about the entities in the policy impacted.  You can learn more here: K42009442: Exporting ASM Policy audit logs manually 

Hey there, Mr Postman

My Postman calls started by getting an Auth Token from the BIG-IP:

curl --location --request POST 'https://management-ip/mgmt/shared/authn/login' \
--header 'Content-Type: application/json' \
--data-raw '{
"username": "admin",
"password": "myPW",
"loginProviderName": "tmos"

Then I want to get the PolicyID using my Policy Name:

curl --location --request GET 'https://management-ip/mgmt/tm/asm/policies?$filter=name eq scheff-working' \
--header 'Content-type: application/json' \
--header 'X-F5-Auth-Token;'

Note that the filter uses an 'eq' so it should return only one item.

Next, we request the audit logs for this policy-id:

curl --location --request GET 'https://management-ip/mgmt/tm/asm/policies/h-lJz2aGTVbmbwcbU-DBCQ/audit-logs/' \
--header 'Content-type: application/json' \
--header 'X-F5-Auth-Token;'

The returned data is an array of entry 'items'

"eventType": "update",
"lastUpdateMicros": 1.676116936e+15,
"description": "",
"deviceName": "/Common/",
"username": "",
"kind": "tm:asm:policies:audit-logs:audit-logstate",
"selfLink": "https://localhost/mgmt/tm/asm/policies/9qaSOCw0_eJtcHc-KbTpdg/audit-logs/h-lJz2aGTVbmbwcbU-DBCQ?ver=17.0.0",
"component": "SYSTEM",
"entityName": "Apply Policy",
"versionEvent": false,
"id": "h-lJz2aGTVbmbwcbU-DBCQ"

You can get a LOT of them. This is a list of the change items, tho you still need to iterate through each item and get the 'item details'.  So, Python can make this all work seamlessly...

Enter Python

Admittedly, writing this really was not a great effort, less than an hour in Postman and I was able to pull the information together. I took the basics from the Postman collection and used that to create a Python script.

The Python script takes the management IP, username, password, and an optional Policy Name as parameters and then it gets an Authorization Token, gets the Policy-ID, and then iterates through the list of Audit Log Items for the details.  There are a LOT of calls, but the information it gathers is very helpful and provides the details the customer needs for their Auditors.

python -h localhost -u admin -p MyP@assW3ird --name '?$filter=name eq aws-honeypot'

Policy: aws-honeypot

Policy change info (update):
Change Detail:Parent Policy was set to empty value.
Type was set to Security.
Encoding Selected was set to true.
Application Language was set to utf-8.
Case Sensitivity was set to Case Sensitive.
Security Policy Description was set to Comprehensive Policy.
GUI Configuration Level was set to basic.
Active was set to true.
Differentiate between HTTP and HTTPS URLs was set to Protocol Specific.
Has Parent was set to false.
Policy Name was set to /Common/aws-honeypot.
Passive Mode was set to disabled.
Enforcement Mode was set to Blocking.
On: 2023-01-04 08:56:59

I have posted this code up on Github, you can see it here: If you have questions or ways to improve on it, please open an issue there.  I look forward to seeing your ideas.

My next article is a collaboration with another F5er, we’re going to show you some other cool reporting you can do to understand your Policy effectiveness against today’s common attacks.

Please feel free to comment on this or other auditing ideas you have... maybe we can collaborate on a future article on how you solved your needs.

Updated Mar 29, 2024
Version 2.0

Was this article helpful?

No CommentsBe the first to comment