Hacker News Reader

Comment by wyldfire | Hacker News Reader

Your question is unclear. IBM designed this product to audit for things that look like signs of an attack/probing and if it generated a lot of false alerts, the product would be worthless.

How often do you design a database query to get the count of all rows from a table? It sounds like an uncommon use case, but probably one you could mute from the audit if you do it intentionally.

View on HN

I just wanted to mention that this product has the capability of capturing queries and match them to a particular login session. Given this there may be other reasons why this particular query stood out after reviewing administrative queries for irregularities or using some of the analytics available in the IBM product. There's a couple of ways this could have come up and it depends on a particular security team's policy and review strategy. They may have been able to look at the rest of the queries in the session to have an immediate feel that something totally irregular was happening. Generally you get used to the application traffic/change requests/administrative surgery style of queries after monitoring a particular database for a while so when something new comes up it immediately looks weird, like a log message for a familiar daemon you've never seen before.

> How often do you design a database query to get the count of all rows from a table?

Any time I paginate a list, so it can show the "x of y pages"?

You aren't keeping the count somewhere else, in a cache, let's say?

Sure, but even if you're caching, you're presumably populating that "how many users do we have" widget's cache at least once a day or so.

Specifically in this case, there's no reason to show a list of all of the users in the system. What would you do with a list with millions of rows?

A search makes more sense here.

> What would you do with a list with millions of rows?

Not much, but that doesn't mean folks won't.

https://stackoverflow.com/questions says "17,335,212 questions " and the pagination goes "1 2 3 4 5 … 346705", if you want a real-world example.

Doesn't make sense to query the db for a count of the number of records that are returned. You can figure that out from the result set inside your application.

If the result set is "all users", you probably don't want to pull tens or hundreds of millions of records just to count them up if you're showing 100 per page.

I think that something like a query for hundreds of millions of records that also required pagination for the exact number of records returned is anomalous and not something that their application would do.

Reply on news.ycombinator.com