On Thu, Dec 10, 2015 at 02:52:38PM -0800, John R Pierce wrote:
> thats a rather insane bunch of requirements. Reads like a wish list by
> academic security researchers.
Well, I don't know. Might be a wish list by insurance adjusters who
want to minimise liability. At least in the United States of
Liability, I think the day is rapidly approaching where people will
need insurance against database breaches. Therefore,
> https://www.stigviewer.com/stig/database_security_requirements_guide/2015-06-23/finding/V-58123
>
> ??!? The database server has no clue about the difference between an
> "application that it supports" and a user directly querying. The PSQL
> shell, or dbadmin, is an 'application that it supports'.
while I agree that there's no way for the RDBMS to tell when it's an
attacker mimicing an application's normal connection and query
pattern, I think there are some things you could do here that would
catch this. For instance,
• use strong authentication mechanisms for your clients. Kerberos
seems like a good alternative, but TLS (SSL) certificates might
do. Log connections and the connection origin. If you get
connections for a given user from the wrong place, you know you
have a problem.
• isolate your users, so that your application (or better, each
instance of your application) has an associated user. Your
humans are not allowed to log in with this username. Then,
queries issued by non-application usernames are your candidate
queries.
Again, this will not defend against, "Attacker got into my system and
subverted the application user." You need to have other lines of
defence for that. But depending on your auditor, this might be enough
to satisfy the condition.
Also, of course, there is the application_name (string) parameter. In
principle, you ought to be able to filter on this. Again, won't help
you if your application login is somehow compromised.
I agree that all of this depends on logging everything and filtering,
however.
Best regards,
A
--
Andrew Sullivan
ajs@crankycanuck.ca
