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

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Mobile Banking Malware Up 50% in First Half of 2019
Kelly Sheridan, Staff Editor, Dark Reading,  1/17/2020
Active Directory Needs an Update: Here's Why
Raz Rafaeli, CEO and Co-Founder at Secret Double Octopus,  1/16/2020
New Attack Campaigns Suggest Emotet Threat Is Far From Over
Jai Vijayan, Contributing Writer,  1/16/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: I've never actually seen the corporate ladder before.
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
How Enterprises are Attacking the Cybersecurity Problem
How Enterprises are Attacking the Cybersecurity Problem
Organizations have invested in a sweeping array of security technologies to address challenges associated with the growing number of cybersecurity attacks. However, the complexity involved in managing these technologies is emerging as a major problem. Read this report to find out what your peers biggest security challenges are and the technologies they are using to address them.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-5216
PUBLISHED: 2020-01-23
In Secure Headers (RubyGem secure_headers), a directive injection vulnerability is present in versions before 3.9.0, 5.2.0, and 6.3.0. If user-supplied input was passed into append/override_content_security_policy_directives, a newline could be injected leading to limited header injection. Upon seei...
CVE-2020-5217
PUBLISHED: 2020-01-23
In Secure Headers (RubyGem secure_headers), a directive injection vulnerability is present in versions before 3.8.0, 5.1.0, and 6.2.0. If user-supplied input was passed into append/override_content_security_policy_directives, a semicolon could be injected leading to directive injection. This could b...
CVE-2020-5223
PUBLISHED: 2020-01-23
In PrivateBin versions 1.2.0 before 1.2.2, and 1.3.0 before 1.3.2, a persistent XSS attack is possible. Under certain conditions, a user provided attachment file name can inject HTML leading to a persistent Cross-site scripting (XSS) vulnerability. The vulnerability has been fixed in PrivateBin v1.3...
CVE-2019-20399
PUBLISHED: 2020-01-23
A timing vulnerability in the Scalar::check_overflow function in Parity libsecp256k1-rs before 0.3.1 potentially allows an attacker to leak information via a side-channel attack.
CVE-2020-7915
PUBLISHED: 2020-01-22
An issue was discovered on Eaton 5P 850 devices. The Ubicacion SAI field allows XSS attacks by an administrator.