DAM Sees Everything but Does Not Know Which Access Was Approved

An auditor writes a single sentence on the screen: "This quarter 412 schema changes ran on the production servers. How many were approved?" There are two teams in the room. Security holds the database activity monitoring (DAM) report: every change, account, time and query. Change management holds the request list: who asked, who approved, when. Both lists are correct. But neither looks at the other.

The next two weeks go on matching the two tables by hand. This is called change reconciliation, and in most organisations it is still a spreadsheet job.

What DAM Sees and What It Cannot

DAM's strength is coverage. It sees every route into the database: the DBA's own connection, application service accounts, vendor accounts, the emergency account. It gives a complete answer to which account ran which query, from which machine and when. What it cannot see is intent: "Was this approved? Was the text that ran the text that was approved?" Approval does not live inside the database; it lives in a process system.

What the Process System Knows and Does Not

The process system's strength is knowledge: it knows the request, the reason, the approver, the risk, the digest of the text that ran and the result. What it lacks is coverage: it only sees work that passes through it. If the same database was entered another way, that work never happened as far as the process system is concerned.

• DAM sees everything and does not know which access was approved.
• The process system knows what was approved and does not see the rest.

The two gaps are two halves of the same story.

What Happens When They Combine

If the governance layer gives DAM and SIEM three pieces of information, rules become possible.

1. Which account is expected. SQL Change Guard connects to a production server with a single SQL account. The "expected accounts" report gives only that account. The organisation adds its own application accounts to its own DAM and SIEM list; the product does not know those accounts and does not need to.
2. Which session belongs to which request. The product opens every connection under a name that identifies it: role and request number, such as SQL Change Guard/Execute/123. The DAM records then read "this session is the execution of request 123".
3. In which window the work was done. An event goes to the SIEM when execution starts and when it ends. The event carries the start and end time, the SQL account used and the name of the executing machine (executorHost).

What happened on Tuesday at 14:02 reads like this:

If an ALTER TABLE appears on the same server at 14:20 under another account, there is no matching event. Alarm.

The Rule Is "Three Things Together"

The application name is the connecting party's own declaration. Anyone with an account can write the same name in a connection string. So the right rule does not look at the name alone; it looks for three things together:

• Is the account the executor's account?
• Does the client address in DAM match the executing machine name in the event (executorHost)?
• Is there a matching event in that window?

The name is a hint that makes matching easier. The evidence is the account, the address and the event.

What It Enforces and What It Does Not

• Enforcement happens in the database.
• Detection happens in DAM and SIEM.
• Evidence lives in the governance layer.

An organisation that only enforces cannot learn that enforcement has been bypassed. An organisation that only monitors cannot know whether what it watches was approved.

Three Questions for Your Own Organisation

1. Last month, how many changes that ran in production had an approved request? Can you produce that number within an hour?
2. Does your DAM have an "expected accounts" list, or is every account treated as allowed?
3. Could you notice that the account that runs approved work is being used somewhere else?

If your answer to the third question is "no", the back door is open even if the approval system is sound.

Frequently Asked Questions

Can DAM and a change management tool replace each other?

No. DAM sees every route into the database but does not know the approval. The process system knows the approval but only sees work that passes through it. They complement each other: DAM gives coverage and the governance layer gives the knowledge of what was approved.

Can we tell an approved operation from the session name?

Not on its own. The application name is a declaration by the connecting party and anyone with an account can write the same name. The right rule looks at the account, the client address (compared with the executing machine name) and the matching event in that window together.

Does SQL Change Guard prevent entering the database another way?

No. SQL Change Guard is not a proxy. Enforcing access means removing standing privileges in the database and is the organisation's decision. Together with DAM and SIEM, the product makes it visible whether the enforcement holds.

How do the organisation's own application accounts get onto the expected accounts list?

The organisation adds its own application accounts to its own DAM and SIEM list. The product's "expected accounts" report gives only the product's own execution account.