De-FUD-ing Privileged User Management

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.