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.

Perimeter

9/19/2011
01:16 PM
Adrian Lane
Adrian Lane
Commentary
50%
50%

Segregating DBA And Admin Duties

Keeping platform admins out of your database

A reader's question via email asked for an elaboration on separation of duties (SoD) between DBAs and IT administrators. SoD gets lumped in with compliance requirements, but, in reality, it's a critical security concern, so I thought it would be beneficial to dig into this topic.

The idea is that you don't want the administrator of the platform to access the database internals, alter database functions, or arbitrarily view the contents of the database.

IT's job is to ensure the underlying machines -- real or virtual -- support the database engine. That role does not permit them access to the database. It's the database administrators job to make sure the database application performs correctly, that database users have appropriate permissions to do their jobs, and that critical database controls are secured. The two roles should overlap as little as possible.

The fewer the number of people accessing database controls, the less likely it is for a rogue employee to steal data. Closing off the avenues to which a DBA can access the underlying OS -- or removing facilities IT administrators' use to access the database -- makes it less likely an attacker can compromise it.

This is not just theory, either. Just look at the history of database attacks: Though SQL injection gets the headlines now, it was not always that way. The bidirectional exploitation of external procedures was the most damaging tool in an attacker's arsenal. That's because if you could get into the database, the external procedure allowed use of OS or shell commands, leveraging a database attack into a platform compromise.

Similarly, if an attacker could gain access to the host, then it was easy to compromise the database. When database security became a problem a decade ago, patches and vulnerability assessment policy updates invariably contained fixes to limit database-to-platform security issues. Today, every Fortune 1000 IT organization enforces separation of duties between the IT and database administrators for security and compliance reasons.

There are four basic configuration steps to aid in separation of duties between the platform administrator and the database administrator.

1. Turn off external stored procedures. Every database platform offers a pathway for the database to use OS commands, as well as database interfaces from the OS layer. Commonly called "external stored procedures," these are nothing more than OS utilities accessed by the database much in the same way a user would call an internal procedure (i.e., SQL statements). You'll need to revoke permissions to these utilities from all users, including administrators. In rare cases, you can remove these functions entirely because they are included as an add-on package. In most cases, however, revoking user rights is enough.

2. Don't provide local IT admins with DBA credentials, and don't use the same user name and password. IT admins have no reason to be able to log into the database. If your IT department is one person, then it might not make sense to have that person use a second login to manage each platform -- but, trust me, you want this extra layer of protection. If an attacker can hijack one account, then he automatically has permission to the other when you share credentials.

3. Don't install the database under the local IT admin account. This means the database is the local admin, and the DBA has admin rights to the local platform. Similarly, if the database is installed as the local IT admin, then the admin can run database commands. You want the database to run as a separate user who is not the domain or local platform administrator. And you want the database files and archives to be readable by only the account the database is installed under.

4. Don't use mixed mode credential management: Use domain. Your IT department likely uses Active Directory or LDAP to manage user accounts. But every database has built-in user management as well. You want the database to manage generic roles and groups per database function, and the domain to manage actual users. Don't use mixed-mode authentication because it allows an attacker to choose one that suits his purpose, and often allows him to access administrative privileges.

Maintaining separation between platform and database administrators offers an extra degree of security. Once a skilled attacker gains access to the database, the first thing he will do is attain extra privileges, and the second is to open holes to the OS in order to write and execute code.

These steps provided are the basic steps, but it's likely you will want to take extra measures, such as segregation of the DBA role and monitor permissions changes to detect attacks.

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
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.