Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security //

Database Security

5/24/2013
01:40 PM
Adrian Lane
Adrian Lane
Commentary
50%
50%

De-FUD-ing Privileged User Management

A helpful contrast shows you what not to do

I am proud to write this column for Dark Reading. The biggest reason is I get to share two decades of stuff I've seen with databases and security with you, and it starts really good conversations every time I attend security conferences and meet readers face-to-face. I can share perspective, help clarify issues around database threats, and explain the pros and cons of database security products.

On occasion, I even get to call BS on things I believe only confuse DBAs and security practitioners about database security. This is one of those occasions. The recent blog post "Privileged user management a must for DBAs" attempts to touch on the tricky subject of monitoring DBA activity, but falls down trying. The topic is really important, but the advice provided is so far off that I feel it warrants a discussion. In fact, I think the contrast between the two perspectives will be really helpful for all.

Here are a couple of important points you should consider when considering privileged user management and monitoring:

Issue #1: Terminology matters! Gartner uses the unfortunate label "database audit" as an umbrella term to describe both database vulnerability assessments as well as database activity monitoring. I know this because Gartner did me the magnificent courtesy of discussing the name change from database activity monitoring (DAM) to database audit prior to its launch, fully describing its sensible rationale for the name change. While it's logical, it is also unfortunate; to DBAs, "database audit" means the native audit capabilities of the database.

Further confusing the issue is, when a security or compliance practitioner "audits" a database, he looks at patch levels, adherence to change management processes, and configuration settings for the database engine and users alike. The three definitions don't jibe, so you can't use them interchangeably. Worse, none actually describes privilege user "management," which is a combination of segregation of admin roles and monitoring admin activity for compliance and security.

Issue #2: The biggest current issue with privileged user management at this time is segregation of database administrative roles. It's an issue because it reduces DBAs' productivity when they only get to perform a small part of their job function. And you need to have more than one DBA to make this approach effective at catching fraud; many small and midsize firms have only one DBA for SQL Server and one for Oracle, so it defeats the purpose.

Still, you gain the advantages that you slow down an attacker because a compromise is limited to a subset of admin functionality and not a complete loss of control. Second, you can monitor individual admin accounts because you have distinct names for each DBA role.

Issue #3: The issue that really motivated me to write this post is the virtual desktop monitoring solution described: You don't monitor DBAs by watching their keystrokes or capturing their screen sessions. There are many reasons, but I'll limit myself to two examples. The first is that what actually occurs inside the database may or may not be evident from the user session. If a DBA runs a stored procedure, you can't see what took place on the screen. If he kicks off an admin application, it may make hundreds of changes to which endpoint is entirely blind. Second, and most importantly, if you want to catch fraud, you need to see all admin activity. An attacker is not going to use your controlled endpoint when he abuses your database.

If you focus on the insider threat, then you're missing the most critical part. Go back and look at any of the Black Hat or RSA talks by David Litchfield or Esteban Martínez Fayó: They got admin control by leveraging Oracle features that inadvertently gave them DBA rights. Even if you simply want to perform change control verification, you sure as heck don't do it from an endpint session capture.

Issue #4: Reliance on native database auditing for monitoring admin activity works only when a nonmalicious DBA wants you to track what he does, or a malicious DBA simply doesn't care that you have forensic data. Even then, a native audit -- regardless of database type -- may or may not offer a complete picture of activity. It depends on what the database platform offers and how it is configured. Some simply don't collect all of the activity you are interested in. This is (one of the many reasons) why we use DAM to capture database activity for trusted and nontrusted admin activity.

And for the record, Moore's Law does not drive innovation and evolution; Moore's Law is a theorem that chip performance will double every 18 months. It does not pertain to database security. What does pertain to database security is, over the past 15 years, DBAs have gone from being responsible for one database to 100 databases. This is possible because automation tools have made administration across many systems is easier. But they are stretched very thin!

This trend is mainly economic, as employee costs continued to rise in relation to hardware costs. When mainframes were introduced, administrator salaries were a fraction of hardware costs. Now personnel form the bulk of IT costs. But the change speaks more about the evolution of software and the escalation of employee costs than it does to the relative drop in chip cost vs. performance.

Adrian Lane is an analyst/CTO with Securosis LLC, an independent security consulting practice. Special to Dark Reading. Adrian Lane is a Security Strategist and brings over 25 years of industry experience to the Securosis team, much of it at the executive level. Adrian specializes in database security, data security, and secure software development. With experience at Ingres, Oracle, and ... View Full Bio

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/9/2020
4 Security Tips as the July 15 Tax-Day Extension Draws Near
Shane Buckley, President & Chief Operating Officer, Gigamon,  7/10/2020
Russian Cyber Gang 'Cosmic Lynx' Focuses on Email Fraud
Kelly Sheridan, Staff Editor, Dark Reading,  7/7/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15105
PUBLISHED: 2020-07-10
Django Two-Factor Authentication before 1.12, stores the user's password in clear text in the user session (base64-encoded). The password is stored in the session when the user submits their username and password, and is removed once they complete authentication by entering a two-factor authenticati...
CVE-2020-11061
PUBLISHED: 2020-07-10
In Bareos Director less than or equal to 16.2.10, 17.2.9, 18.2.8, and 19.2.7, a heap overflow allows a malicious client to corrupt the director's memory via oversized digest strings sent during initialization of a verify job. Disabling verify jobs mitigates the problem. This issue is also patched in...
CVE-2020-4042
PUBLISHED: 2020-07-10
Bareos before version 19.2.8 and earlier allows a malicious client to communicate with the director without knowledge of the shared secret if the director allows client initiated connection and connects to the client itself. The malicious client can replay the Bareos director's cram-md5 challenge to...
CVE-2020-11081
PUBLISHED: 2020-07-10
osquery before version 4.4.0 enables a priviledge escalation vulnerability. If a Window system is configured with a PATH that contains a user-writable directory then a local user may write a zlib1.dll DLL, which osquery will attempt to load. Since osquery runs with elevated privileges this enables l...
CVE-2020-6114
PUBLISHED: 2020-07-10
An exploitable SQL injection vulnerability exists in the Admin Reports functionality of Glacies IceHRM v26.6.0.OS (Commit bb274de1751ffb9d09482fd2538f9950a94c510a) . A specially crafted HTTP request can cause SQL injection. An attacker can make an authenticated HTTP request to trigger this vulnerabi...