There are several STIG items that deal with the differences between production and non-production systems.
Rule Title: Developers should not be assigned excessive privileges on production databases.
Vuln ID: V-15114
Severity: CAT III
Rule Version (STIG-ID): DG0089-ORACLE11
Discussion: Developers play a unique role and represent a specific type of threat to the security of the DBMS. Where restricted resources prevent the required separation of production and development DBMS installations, developers granted elevated privileges to create and manage new database objects must also be prevented from actions that can threaten the production operation.
Rule Title: Sensitive information from production database exports should be modified after import to a development database.
Rule ID: SV-24654r1_rule
Vuln ID: V-3819
Severity: CAT II
Rule Version (STIG-ID): DG0076-ORACLE11
Discussion: Data export from production databases may include sensitive data. Application developers do not have a need to know to sensitive data. Any access they may have to production data would be considered unauthorized access and subject the sensitive data to unlawful or unauthorized disclosure. See DODD 8500.1 for a definition of Sensitive Information.
Rule Title: Production databases should be protected from unauthorized access by developers on shared production/development host systems.
Rule ID: SV-24391r1_rule
Vuln ID: V-3820
Severity: CAT II
Rule Version (STIG-ID): DG0077-ORACLE11
Discussion: Developers granted elevated database, operating system privileges on systems that support both development, and production databases can affect the operation and/or security of the production database system. Operating system and database privileges assigned to developers on shared development and production systems should be restricted.
On the surface, these items seem pretty obvious:
- Don’t copy production data to development databases.
- Don’t allow developers to have elevated privileges in a production environment.
In reality things can be a little more complicated. Developers are not just writers of application code; they are very often functional experts in the type of data being handled by an application, whereas the DBA is generally more focused on architectural, security, performance, and capacity management issues and may not be an expert on the internal workings of the application. As such it is often necessary for a developer to be able to access production data (generally in a read-only capacity) in order to troubleshoot application-related issues in a timely manner. It may also be necessary to copy production data into development environments in order to properly test modifications to application code, especially if the data is complex and not easy to modify in such as way as to make it less sensitive, or if the volume of test data required is higher than can be easily generated.
So how do we handle these kinds of situations and still remain STIG-complaint? The first thing to remember is that even if production and development systems are physically separate, the network still (in most cases, unless development systems are on a physically isolated segment) connects them together. The network is a production environment with its own STIG, even if not all of the systems on it are used for true production purposes. Because of this, all systems attached to the network should be secured as though they are production systems, regardless of their true purpose.
If our development systems are secured at the same level as production, then storing production data in them is no longer a problem from a security perspective, provided that developers are properly cleared to see that data. The distinction between DBA and developer responsibilities becomes crucial, however. As Tom Kyte says in his book, Expert Oracle Database Architecture, 2nd Edition (page 49), “Setting up Oracle Net, getting the listener going, configuring the shared server, enabling connection pooling, installing the database, creating the database, and so on—these are functions … of the DBA. …Developers do not need to know how to run the database. They need to know how to run in the database.”
A developer may require elevated privileges within the development database in order to write and test application code, but they should never be granted so many privileges that they can circumvent the STIG-required security protocols put in place by the DBA. For instance, developers may need privileges like “create any procedure”, “create any view”, or even “select any dictionary”, but should not be allowed to create, alter, or delete user accounts, change initialization or networking parameters, alter storage, or disable mandatory auditing. The DBA is responsible for ensuring that all of these configurations remain unchanged once they are properly configured.
Finally, having a strong configuration management process in place (also a STIG requirement!) will ensure that development activity takes place on appropriate systems and that all changes are reviewed for impacts to security and performance before being installed in production. This process should apply just as much to architectural or configuration changes made by the DBA as it does to application code released by the developer.
All quotations from the Database STIG taken from:
Defense Information Systems Agency. Oracle 11 Database Installation STIG Version 8 Release 1.10. http://iase.disa.mil/stigs/app-security/database/Pages/index.aspx. Published January 2014. Accessed April 4, 2014.