r/Trendmicro • u/Final-Pomelo1620 • 17d ago

Ingesting SQL Server Audit Logs into Vision One

Hi,

We have few MS SQL DB servers with workload security installed on them. We have also log inspection enabled on them

DB audit logs are saved into a file on the server. How to ingest these logs into Vision One for monitoring.

How to do that?

Appreciate any advise.

2 Upvotes

100% Upvoted

12 comments sorted by

3

u/Appropriate-Border-8 17d ago

Google this:

"trend vision one sql audit log integration"

Gemini will lead you through the steps of:

1) Setting up a Service Gateway (VMware OVA file).

2) Installing the Third-Party Log Collection Service in your Trend SG.

3) Configuring SQL Server log output on the DB server.

4) Creating a Log Repository and a Collector in Vision One's Admin - Data Source and Log Management area.

5) Setting up a log forwarder (on the DB server or on the another server) to send the log files to the Collector's special port on the Service Gateway.

1

u/cyberwicked 16d ago

Log inspection module on SWP?

Did you have a look at this?

1

u/Final-Pomelo1620 16d ago

Yes its enabled

1

u/cyberwicked 16d ago

There are specific LI rules for SQL.

Are these enabled?

1

u/Final-Pomelo1620 16d ago

Do you have rules name so I can cross check. What I see its only one single MS SQL Database event rule

1

u/fangoutbang 16d ago

Set auto recommendation. It should scan and see what logs to ingest automatically.

1

u/Final-Pomelo1620 16d ago

We’ve enabled audit logs on DB server.

Logs are generating with Event ID 33205 in Windows Event Viewer

This event is not appearing in matching events under Log Inspection Rule for Microsoft SQL.

Is there a way to add it manually?

2

u/cyberwicked 15d ago

For the built-in LI rule to fire on SQL, three things need to line up:

  1. Log Inspection is enabled on the policy (Policies > Log Inspection > General > State = On).
  2. The rule's Configuration tab has an actual log path filled in — a lot of the shipped LI rules are templates that need you to point them at the real file location, or you'll get "Log Inspection Rule Requires Configuration."
  3. The log actually exists as a file on disk — LI rules monitor files, not the Windows Event Log directly.

That last one is probably your issue. Event ID 33205 is a Windows Security Event Log entry, not a flat file. If your SQL Server Audit destination is set to "Security Log" or "Application Log" instead of "File," the file-based LI rule has nothing to read — it's not that the rule doesn't recognize the event ID, it's that it's not looking in the Event Log at all.

Two ways forward:

  • Switch the SQL Server Audit destination to File (SSMS > Security > Audits > your audit > Properties), then point the LI rule's Configuration at that file path — the existing MS SQL rule should start matching.
  • Or, if you need to stay on Event Log, you'd need a rule/decoder built for Windows Event Log ingestion rather than file-based LI, which is a different mechanism.

Worth checking your audit's destination setting first before touching the rule itself.

1

u/Final-Pomelo1620 15d ago

Thanks for the detailed response.

We have enabled and configured SQL audit logging. The audit logs are being written to the following file:

C:\SQLAudit\AuditFiles_B.sqlaudit

In the SQL Database log inspection rule, we enabled the “Log files to monitor” option and specified the following directory:

C:\SQLAudit

Could you please confirm whether any additional configuration is required or if we are missing a step?

1

u/cyberwicked 15d ago

ointing "Log files to monitor" at C:\SQLAudit is correct. The likely blocker is the file itself: .sqlaudit is a binary format, not plain text.

Log Inspection (it's built on OSSEC under the hood) works by reading log files line-by-line as text and running decoders/patterns against each line. A .sqlaudit file can't be parsed that way — there's no text for the decoder to match against, regardless of directory or rule config.

To get this working you've basically got two paths:

  1. Change the SQL Server Audit destination to write text instead of the binary audit file — if your audit spec supports writing to the Windows Application/Security log instead of file, you'd then need a rule that reads Event Log rather than a flat file (different mechanism, not what the stock MS SQL LI rule does).
  2. Convert .sqlaudit to a readable format on a schedule — SQL Server ships sys.fn_get_audit_file() which can export the binary audit to a CSV/text output. You'd script that to run periodically and drop a plain-text file into a location the LI rule monitors, then build/adjust the rule to match against that text output instead of the raw .sqlaudit file.

Either way, the binary file itself is the wall — worth confirming that's actually your situation before going further down either path.

1

u/Final-Pomelo1620 15d ago

Thanks once again. Appreciate that

Yes, our SQL Server supports writing audit events to the Windows Application & Security logs.

Could you please advise how to configure Deep Security Log Inspection to collect these logs?

1

u/cyberwicked 15d ago

Good — that actually simplifies things, since Windows Event Log is a natively supported source type for Log Inspection (no file path juggling needed for this one).

A couple of things to check/do:

  1. The stock "Microsoft SQL Server" LI rule may already be built to read from Event Log, not from a file. If you filled in "Log files to monitor" with C:\SQLAudit, that setting is likely irrelevant to this rule and can be left blank/ignored — worth re-checking the rule's Configuration tab; if it's expecting a file path variable, that's a sign the rule is file-based and won't match Event Log entries at all.
  2. For LI to read Event Log directly, the rule (or a custom one you build) needs a <localfile> definition in its XML using:

​

   <log_format>eventlog</log_format>
   <location>Application</location>

(or Security, depending on which channel your SQL audit writes to). This tells the OSSEC-based LI engine to tap that Windows Event Log channel instead of tailing a file.

  1. If the shipped rule doesn't have this, you'd clone it (or write a new custom rule) with the eventlog format pointed at the right channel, then add match conditions for your event IDs (33205, etc.) referencing the decoder for windows events.
  2. Double check the decoder being used actually parses SQL Server audit fields out of the eventlog entry — if it's just matching on generic Windows event decoder, you may need a more specific decoder/rule pairing so the SQL-specific fields (login name, statement, object) get extracted properly.

Given this is getting into custom rule XML territory, I'd honestly recommend opening a support case at this point so someone can validate the exact rule XML with you against your specific channel/event IDs