Clutter in the audit logs

[xostmoen]

I wanted to share an observation for anyone who might encounter a similar issue. Recently, I discovered that some customers I’ve been working with had up to 30% of their Sys Audit (sys_audit) and Audit Deleted Records (sys_audit_delete) logs filled with deletion records from the REST API Without Access Policy (isc_api_without_access_policy).

Upon investigation, I found that auditing was enabled by default for this table, including auditing deletions, with no exceptions.

Further investigation led to the findings that this functionality is something that comes with the Instance Security Center (ISC) which of September 2024 has reached end of sales, and is no longer supported or available for new activations.
So for newer instances, this is not activated. It has been replaced by the ServiceNow Security Center (SSC) which does not have the same setup and audit issues.

The isc_api_without_access_policy table is designed to reset every hour via the scheduled job [AppSec] Daily Data Management. This job deletes existing records, validates which REST APIs still lack access policies, and repopulates the table. If an access policy isn’t configured for all APIs, this process will continue indefinitely, resulting in the accumulation of unnecessary records in the audit tables, which consumes storage and impacts performance.

The good news is that this functionality isn’t enabled in new instances. However, the bad news is that we cannot count on this issue being fixed for older instances. We should consider whether any action is needed to address this.

In our case, we decided to turn off auditing for the entire table by setting the "Audit" field to "false" in the Dictionary Entries (sys_dictionary) for the table isc_api_without_access_policy. We also cleaned up old records from the Sys Audit (sys_audit), Audit Deleted Records (sys_audit_delete), and Rollback Sequence (sys_rollback_sequence) tables.

[Dominik Simunek]

Thanks for this insight. It is good to know for everybody who used older "Instance Security Center" if they want to optimize their Database Footprint. At least, customers should consider deactivating "ISC" related scheduled jobs as part of migrating to the newer "Security Center" store app.

FYI: This would be better written as an Article and not as a Question.

[xostmoen]

Agree, good point to do some cleanup of jobs related to the older ISC before/after moving to SC.
Would have made this into an Article, but it seems that it's no longer available to the broader public, have to be a MVP, Rising Star, ServiceNow employee or thought leader. So I added it as a Question just to get it out there.

[JC Moller]

To prevent this data or similar from ending up in the sys_audit_delete table, just add the table's name into this system property. With every new Servicenow version I am frequently adding some tables into the property, as Servicenow seems to forget to audit what happens to the data when it is permanently deleted.

On one Servicenow version we had all data created/deleted from sys_trigger table end up in sys_audit_delete table, but since we internally monitor disc usage/growth this issue was noticed in days. You could also analyze the table's content and maybe find something to add into the system property.

- Jan

glide.db.audit.ignore

Specifies the tables where the sys_audit_delete file is not updated when records are deleted. Type: string - a comma separated list of tables Location: System Property [sys_properties] table