Ask HN: How do you do threat detection for databases?

- fake data at every layer/canaries

- a lot of randomly seeded accounts with easily breakable password hashes and a very unique but believable email (like firstlast@company "admin" account) that will effectively trigger equivalent of SEV0 if someone tries to log in with it in production

- mtls everything + devs cannot log in to prod.

- have previously seen something interesting in that the same internal IPs were routed differently depending on where you originate and whether it was a protected server to server route: if you compromise a dev machine and use the credentials inside to connect to "prod", it would actually connect, but to a staging db. the same ip/hostname only reaches prod from a server machine w/correct certs+tls+etc

- same place as above would also tcp fingerprint clients connecting passively, so would set off alerts trying to connect via psql or mongo from another device not running an identical stack (including waiting for the right incrementing uptime modulus(!) - it knew what the uptime of the machines that were supposed to be connecting were) even if you successfully stole the mtls certs and were on the right network path. this was traditional finance, not startup/fintech/web3.

- same place as above also did very aggressive anomaly detection on average bandwidth use and consumption or in/out and would automatically terminate connections that seemed "off", someone trying to dump the db would near immediately drop the socket. this was done with multiple facets, so things like incremental s2s backups were unaffected but if you tried to pgdump from your dev machine it would terminate the connection shortly.

- security would also randomly "accidentally" leave quite a few tasty sounding credentials laying around in confluence/slack/equivalent of slack/etc; people do not have any reason to be randomly looking for these, but if someone is searching for things like copypastable creds, db logins, etc, virtually any common keyword combination will find these. using them triggers high severity page + someone to question you rapidly.

Can you elaborate what you are thinking threat detection means?

> not interested in how to secure a database using privileges/roles

I wanna bet that is the most prevalent threat vector for any system, getting someones account creds. Detecting a database login from a system that is unknown to the database server would be good threat detection.

Having worked on web applications for a couple decades, protecting against SQL injection and checking parameters in the apps that communicate to the database is good practice.

In order to detect these threats, usually you run scans on web apps (that attempt SQL injection) or I suppose you could run scans against the database server itself to determine if someone could get access, check for default accounts, etc.

AFAIK and what I've seen are mostly SQL query logs that are analyzed, in the sense that the queries that are expected (aka generated by the backend) are compared to queries that look suspicious (e.g. select * from users).

Of course that's kind of assuming that the database host OS isn't compromised at that point, but it's very likely that someone got either user access or found a way to do SQL injection in this scenario.

I'd also recommend to take a look at web application firewalls. Usually they mitigate all kinds of requests that look suspicious.