Six Correlation Rules for Your SIEM: What DAM and Governance Catch Together

Earlier articles explained the idea: DAM sees everything, the governance layer knows what was approved, and together they make alerts possible. This article is the kitchen. We write the rules as vendor neutral logic; you adapt them to the syntax of your own SIEM platform. Before the rules there are four prerequisites. Writing rules without them builds a false alarm factory.

Four Things Before You Start

1. An "expected accounts" list. For every production server, the allowed accounts: the product's execution account and the organisation's own application accounts. The report gives the product's account; the organisation adds application accounts to its own list.
2. The filter. The start and end events from the governance layer are ordinary (Notice) events. A SIEM whose threshold is raised above Notice, or whose Audit stream is switched off, silently loses these events and the rules start producing false alarms. The product's setup check screen shows this in a separate row. For the rules in this article the SIEM threshold (SiemMinSeverity) must be Notice or lower.
3. Clocks. DAM, the database server, the executing machine and the SIEM must share a time source. Most rules look for a match within "a few minutes either way". Clock drift is the first cause of false alarms.
4. A false alarm list. Scheduled jobs, backup accounts and monitoring probes must belong on the "expected accounts" list or be excluded from the rule.

K1. Change Under an Unexpected Account

Logic: DDL, DML or a permission command on a production server, and the account is not on the expected accounts list. Catches: direct access, shared accounts, forgotten permissions, vendor accounts. Watch out: hundreds of alerts can appear on day one. This rule is a discovery tool: the alerts give you the list of accounts to close. Run it in monitoring mode first.

K2. Product Account Without an Event

Logic: DAM shows activity under the product's execution account, but there is no start event in the SIEM within ±N minutes. Catches: the product's account and password being used elsewhere. This is the sneakiest case: because the account is on the expected list, K1 does not see it. Watch out: N depends on execution time. For scheduled jobs the start event arrives at the planned time.

K3. Spoofed Name

Logic: The session name starts with the product prefix (SQL Change Guard/), but the account is not the executor's account, or the client address in DAM does not match the executing machine name in the matching event (executorHost). Catches: name spoofing. The application name is the connecting party's own declaration; anyone with an account can write the same name. This rule writes into the system that the name alone is not evidence. Watch out: if the client address is behind NAT or a load balancer it may not match executorHost. In that case lean on the account and event match.

K4. Out of Window Activity

Logic: Activity under the product's account, but outside the window between the start and end events. Catches: the same account being reused after a job has finished. Watch out: add a small tolerance to the window (a few seconds). Writing the event and the database operation do not happen at the same instant.

K5. A Job That Starts and Never Ends

Logic: A start event exists and neither an end nor a failure event has arrived within N hours. Catches: a stuck execution, a dropped connection, a crashed service. This rule is as much an operations rule as a security rule and is valuable to the DBA team too.

K6. An Emergency Change That Is Not Reviewed

Logic: The execution event has isEmergency true and there is no ChangeRequest.EmergencyReviewed event within 24 hours. Catches: emergency work that entered with shortened approval but was never closed the next day. Watch out: the review event cannot be filtered out, but the execution event is an ordinary event. The rule works if the SIEM threshold (SiemMinSeverity) is Notice or lower; if the threshold has been raised the execution event never reaches the SIEM and the rule stays silent.

Make False Alarms Part of the Rule

No rule works correctly on day one. Three habits make it easier:

• Monitoring mode. Run every rule first without raising alarms, only counting.
• Account owner. Every account on the list should have an owner, so it is clear who receives a K1 alarm.
• Monthly review. An "expected accounts" list that is built once and left will rot within three months.

The Limit: The Product Does Not Write the Rule

The governance layer does not generate SIEM rules. The rule is written on the organisation's own platform with its own risk appetite. The product supplies three things: the expected accounts report, the session tag and the start and end events. The rule itself is yours. This is deliberate: if the product wrote the rule, the organisation would have handed over its own definition of "allowed".

Frequently Asked Questions

What prerequisites are needed to write these rules?

An expected accounts list, start and end events that are not filtered (SIEM threshold at Notice or lower), a common time source and a false alarm list. Without them the rules produce false alarms.

Is an operation trustworthy if the session name carries the product prefix?

No. The application name is the connecting party's own declaration and anyone with an account can write the same name. Rule K3 does not treat the name as evidence on its own: it compares the account, the client address in DAM and the executing machine name in the event (executorHost) together.

When does the unreviewed emergency change rule not work?

The execution event is an ordinary event. If the SIEM threshold (SiemMinSeverity) is raised above Notice, the execution event never reaches the SIEM and the rule stays silent. The review event, on the other hand, cannot be filtered out.