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
Oldest First  |  Newest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/10/2020
Pen Testers Who Got Arrested Doing Their Jobs Tell All
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/5/2020
Researcher Finds New Office Macro Attacks for MacOS
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/7/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
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 Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-9079
PUBLISHED: 2020-08-11
FusionSphere OpenStack 8.0.0 have a protection mechanism failure vulnerability. The product incorrectly uses a protection mechanism. An attacker has to find a way to exploit the vulnerability to conduct directed attacks against the affected product.
CVE-2020-16275
PUBLISHED: 2020-08-10
A cross-site scripting (XSS) vulnerability in the Credential Manager component in SAINT Security Suite 8.0 through 9.8.20 could allow arbitrary script to run in the context of a logged-in user when the user clicks on a specially crafted link.
CVE-2020-16276
PUBLISHED: 2020-08-10
An SQL injection vulnerability in the Assets component of SAINT Security Suite 8.0 through 9.8.20 allows a remote, authenticated attacker to gain unauthorized access to the database.
CVE-2020-16277
PUBLISHED: 2020-08-10
An SQL injection vulnerability in the Analytics component of SAINT Security Suite 8.0 through 9.8.20 allows a remote, authenticated attacker to gain unauthorized access to the database.
CVE-2020-16278
PUBLISHED: 2020-08-10
A cross-site scripting (XSS) vulnerability in the Permissions component in SAINT Security Suite 8.0 through 9.8.20 could allow arbitrary script to run in the context of a logged-in user when the user clicks on a specially crafted link.