An Oracle White Paper June 2013 Security and Compliance with Oracle Database 12c
Introduction... 3 Oracle Database 12c Security... 4 Locating and Cataloging Your Sensitive Data... 4 Monitoring the Configuration of Sensitive Databases... 5 Configuration Scanning... 5 Auditing Sensitive Operations... 5 Protecting Against Database Bypass Threats... 6 Advanced Security TDE... 6 Protecting Data in Non-Production Environments... 7 Data Masking... 7 Limiting Sensitive Data Exposure in Applications... 8 Advanced Security Data Redaction... 8 Protecting Against Common Threats... 8 Database Vault Privileged Account Controls... 9 Database Vault Command Controls... 10 Audit Vault and Database Firewall Detective Controls... 10 Audit Vault and Database Firewall SQL Injection Prevention... 10 Building More Secure Applications... 11 Database Vault Privilege Analysis... 11 Code Based Access Control... 11 Real Application Security... 12 Data Classification for Government and Defense Applications... 12 Label Security Access Control... 12
Oracle Database 12c Secure By Default... 13 Oracle Database Security and Applications... 13 Conclusion... 14
Introduction The need to secure data is driven by an expanding privacy and regulatory environment coupled with an increasingly dangerous world of hackers, organized crime, and other groups intent on stealing valuable data. The security picture is complicated even more by the rapid expansion of access to the Internet, an unprecedented understanding of technology, increasing economic competition, and the push to achieve greater efficiencies through consolidation and cloud computing. Information targeted for attack has included citizen data, intellectual property, credit card data, financial information, government data, and competitive bids. Attack methodologies include hacking of privileged user accounts, exploitation of application vulnerabilities, media theft, and other sophisticated attacks collectively known as advanced persistent threats or APT. In response to the increasing threat to data, regulations have been put in place that include the numerous U.S. State privacy laws, Payment Card Industry Data Security Standard (PCI-DSS), the U.K Data Protection Act, and the Korean Act on Protection of Personal Data, to name a few. To better understand the importance of database security one needs to consider the potential sources of vulnerability. Threats that target the operating system can circumvent the database by accessing raw data files, bypassing application security, access controls inside the database, network security, and encrypted drives. Proliferation of production data beyond the controls of the production environment expand the scope of compliance and increase the risk to data. Privacy related information by be exposed to individuals without a true need-to-know due to an oversight in the development process or the complexity of modifying legacy application modules. Privileged user accounts and over privileged applications may become targets for highly specialized attacks or the source of insider threats. Ad-hoc access to application data by privileged accounts may violate internal policies, regulatory mandates, service level agreements, as well as expose data to external attacks. Application bypass through SQL injection can expose large amounts of sensitive data to attackers or unauthorized users. Configuration drift or changes that create deviation from internal deployment standards and security best practices can result in audit findings, impact business continuity, and increased security risks. 3
Oracle Database 12c Security Security and compliance requires a defense in depth, multi-layered, security model that includes preventive, detective, and administrative controls that are aligned with the sensitivity of the data, its location, its environment, applicable regulations and business impact should the data be lost, stolen, or used for unauthorized purposes. Oracle Database 12c increases security for both existing and new application development by enabling controls to be moved closer to the data itself and providing solutions to the tighten security of existing applications. New capabilities such as privilege analysis, conditional auditing, real application security, data redaction, mandatory realms, separation of duty, and integration with the Oracle Multitenant are just a few of the exciting new security capabilities available with Oracle Database 12c. Deploying security with Oracle Database 12c is even easier with simplified setup and configuration combined with enhancements to Oracle Enterprise Manager Grid Control. Performance optimizations across all areas, including encryption, auditing, and access control, enable security to be deployed without impacting business operations or service level agreements. Oracle Database 12c Security combined with the latest release of Oracle Audit Vault and Database Firewall provides unprecedented capabilities to protect data using a combination of preventive, detective, and administrative controls. Locating and Cataloging Your Sensitive Data Knowing where your sensitive data resides is an important first step in deploying a defense in depth security model. Identifying sensitive data based on the type of application running is a common method used to classify databases. In some cases, more granular controls on data within a given application may be desired. Knowing where specific data resides can be challenging due to the complexity and size of large applications. Oracle Enterprise Manager Data Discovery and Modeling and Sensitive Data Discovery (SDD) can be used to facilitate the process of locating sensitive data within an application and applying security controls on that data. SDD can be used with Oracle Data Masking and other database security solutions to identify and protect sensitive data. Oracle has created Application Accelerators for both Oracle Fusion Applications and Oracle E- Business Suite. The Application Accelerators list the sensitive data for each of the applications. Oracle Data Masking uses the Application Accelerators to facilitate masking of data from production databases to test and development environments. In addition, the new Oracle Database 12c feature Transparent Sensitive Data Protection (TSDP) can load sensitive information from Oracle Enterprise Manager Data Discovery and Modeling into the Oracle database and apply security controls such as Oracle Advanced Security Data Redaction. 4
Monitoring the Configuration of Sensitive Databases Preventing and detecting configuration drift increases both business continuity and high availability. Oracle Database 12c provides both administrative controls and detective controls to help maintain a secure configuration. Fundamental to preventing configuration drift is blocking unauthorized or out of policy changes. Configuration Scanning Configuration monitoring and the prevention of configuration drift is an important part of the security deployment architecture. Oracle Enterprise Manage Database Lifecycle Management Pack can be used to scan databases for numerous security related settings, including checks for default passwords. Monitoring database accounts, managing privilege entitlements, enforcing password complexity, and maintaining a secure configuration are all part of the monitoring process. Proactive assessment of key compliance areas such as security, configuration, and storage help identify areas of vulnerabilities and areas where best practices are not being followed. Important components of Oracle Enterprise Manager Database Lifecycle Management include out-of-the-box policy checks as well as the ability to define custom configuration checks. Auditing Sensitive Operations Oracle Database 12c unified auditing provides a comprehensive syntax for managing auditing inside the Oracle database that is both policy based as well as context sensitive aware. The new implementation provides a policy based syntax that is easy to use for managing auditing within the database. For example, audit policies can be configured to audit based on the IP address or program name of the database connection. If a connection is coming from an unidentified IP address or using an ad hoc tool, audit records will be generated for the activity and recorded in the new unified_audit_trail inside the Oracle database. New roles have been introduced for management of policies and viewing of audit data. This new separation of duty capability provides flexibility to organizations who wish to designate specific users for managing audit settings and viewing audit activity. For example, audit policies can be defined based on factors such as time of day, IP address, program name, and proxy user name. In addition, the policies can be enabled with exception clauses that disable auditing for specific users. The new architecture unifies the existing audit trails into a single audit trail, enabling simplified management and increasing the security of audit data generated by the database. Audit data can only be managed using the built-in audit data management package within the database and not directly updated or removed using SQL commands. Three default policies are configured and shipped out of the box. The traditional audit commands available in previous releases continue to be supported in Oracle Database 12c. 5
Protecting Against Database Bypass Threats Database bypass threats include attacks that target backup media, discarded media, and the operating systems. One of the most widely used technologies used to protect against database bypass threats is encryption. A key milestone in the widespread recognition of encrypt technologies came in 2003 with the passage of California Senate Bill 1386 (SB1386). SB1386 introduced the topic of encryption to a broad audience and since then many other states have passed their own privacy-related laws. Today the need to protect privacy-related information is a global issue as companies expand their operations and businesses. In addition to privacy laws, the payment card industry data security standard (PCI-DSS), first introduced in 2006, has raised awareness across the board for security and the need to render cardholder data unreadable where it is stored and transmitted. While encryption of backup media and proper disposal of media are probably the two most well understood security controls, increasing sophisticated attacks have focused on attacking the servers themselves and gaining access to the raw data files that hold sensitive information. Advanced Security TDE Oracle Advanced Security Transparent Data Encryption (TDE) encrypts and decrypts data through the Oracle database kernel. Data stored on disk is automatically encrypted when loaded into the database and automatically decrypted when users or applications authenticate to the database and pass all database enforced access controls. Plain text data is unavailable when access is attempted at the operating system layer. TDE provides transparent of encryption of data at rest, a requirement today for regulations that range from privacy laws to PCI-DSS as well as protecting against threats directly targeting storage either on production servers or backup media. TDE enables data owners to maintain control over the data by ensuring that sensitive data does not reside in clear text on the underlying media. Without encryption, operating system attacks leave open the possibility of unimpeded access to sensitive data via direct access at the operating system layer to the files, or disk blocks, that comprise the database, bypassing the authentication and access controls of the database. TDE has distinct advantages over other encryption solutions in that a user has to be authenticated to the database and pass authorization checks at both the application and database levels before the data is decrypted. Encryption is especially important when data is moved into cloud environments where the management of storage media and transmission of data is transparent to the data owners themselves. TDE transparently leverages hardware cryptographic acceleration available on Intel XEON 5600 and Oracle SPARC T4 and T5 processors, enabling encryption to be performed with negligible performance overhead in most workload environments. TDE tablespace encryption is integrated with Oracle Compression technologies, enabling storage to be optimized without sacrificing security. 6
Protecting Data in Non-Production Environments The need for realistic data sets for development and test environments has resulted in the proliferation of data beyond the boundaries of production applications. This movement of production data dramatically increases the risk to data and increases the overall cost of security and compliance. Masking of data before it is moved from production eliminates the risk of data breaches in non-production environments by irreversibly replacing the original sensitive data with fictitious data so that data can be safely shared with IT developers or business partners. Data Masking Oracle Data Masking provides end to end automation for provisioning test databases from production in compliance with regulations. Sensitive information such as credit card or social security numbers can be replaced and used for development and testing without expanding the security perimeter. This reduces the number of database systems that need to be monitored for compliance and security. Important considerations in masking include the ability to maintain referential relationships between application tables after the masking process has taken place. Application records that span application tables and are linked by a given column need to have those values consistently replaced across the related tables. Data Masking discovers these relationships and masks all related data elements automatically while preserving referential relationships. The combination of sensitive data columns and the associated primary key-foreign key relationships are stored in an Application Data Model in the Oracle Enterprise Manager repository. Data Masking ships with pre-defined accelerators for Oracle Applications that can discover the metadata relationships in existing Oracle Fusion Applications and Oracle E-Business Suite applications and create Application Data Models to store these relationships. Data Masking provides a centralized library with out-of-the-box mask formats for common types of sensitive data, such as credit card numbers, phone numbers, national identifiers (social security number for U.S., national insurance number for U.K.). By leveraging the Format Library in Data Masking, enterprises can apply data privacy rules to sensitive data across enterprise-wide databases from a single source and thus, ensure consistent compliance with regulations. Enterprises can also extend this library with their own mask formats to meet their specific data privacy and application requirements. Once the work of associating masking definitions with application attributes is complete, the formats and data associations can be saved in the Application Data Model and re-executed when test, development or partners need a refresh of data. Oracle Data Masking Pack can support masking of data in heterogeneous databases, such as IBM DB2 and Microsoft SQLServer, through the use of Oracle Database Gateways. 7
Limiting Sensitive Data Exposure in Applications Oracle Data Masking provides an excellent solution for irreversible changing data so that it can be moved into test and development environments. However, enforcing consistent handling of sensitive data in production applications across multiple development teams can be complex and error prone. In addition, changing existing applications to limit exposure of sensitive data may not always be possible. Advanced Security Data Redaction Oracle Advanced Security with Oracle Database 12c introduces a powerful new capability with data redaction. Data redaction complements Oracle Advanced Security transparent data encryption (TDE). While TDE helps protect information from database bypass attacks, data redaction helps protect information by enforcing controls inside the database that redact data before it is returned to the application. Since data is redacted before it is returned to the application, exposure of sensitive information is reduced. Take for example, a credit card number, using Oracle Advanced Security Data Redaction the first 12 digits can be redacted to the same value, with only the last 4 digits being shown in the clear. Data redaction is applicable to a wide range of sensitive data, including social security numbers, birthdates, bank account numbers, and drivers license number, to name a few. Oracle Advanced Security Data Redaction supports a number of different transformations that can redact all data in specified columns, preserve certain pieces of the data, or randomly generate replacement data. Data Redaction makes the business need-to-know decision based on declarative policy conditions that utilize rich runtime contexts available from the database and from the applications themselves. Examples include user identifiers, user roles, and client IP addresses. Context information available from Oracle Application Express (APEX), Oracle Real Application Security, and Oracle Label Security also can be utilized. Redacting APEX applications is straightforward because you can create policy conditions using the application users and application identifiers that APEX automatically tracks. Multiple runtime conditions can be joined together within a Data Redaction policy for fine-grained control over when redaction occurs. The policies are stored and managed inside of the database, and they go into effect immediately upon being enabled. Protecting Against Common Threats A common characteristic of many data breaches has been the use of privileged user credentials and their far-reaching access inside the database. Some of these data breaches were perpetrated by insiders, while others were executed by hackers. Privileged user accounts inside the database and their unimpeded 24/7 access to application data create prime targets for hackers and other groups. Consolidation has further complicated the situation by potentially exposing massive amounts of sensitive information should those accounts be targeted and compromised. In 8
addition, SQL injection vulnerabilities within applications have been frequent points of attack. These vulnerabilities can be even harder to detect and block because they are commonly passed through to the database by applications using credentials that are trusted. Protecting against these common types of attacks requires a defense-in-depth approach. The depth of the security controls required will depend on the application and sensitivity of the data. For example, while privileged user controls may be vital on production systems, they most likely are less applicable on test and development systems where sensitive data has been masked or swapped out with production like data. At the same time, multiple preventive controls may be applicable on highly sensitive systems, while a subset may be applicable on less sensitive systems. In addition, some controls may be applicable to both Oracle and non-oracle databases, while others may only be available in the Oracle database. Database Vault Privileged Account Controls Oracle Database Vault with Oracle Database 12c creates a highly restricted application environment ( Realm ) inside the Oracle database that prevents access to application data from privileged accounts while continuing to allow the regular authorized administrative activities on the database. Realms can be placed around all or specific application tables and schemas to protect them from unauthorized access while continuing to allow access to owners of those tables and schemas, including those who have been granted direct access to those objects. Oracle Database Vault Realms also place controls on powerful system privileges, roles and ad hoc account creation. Periodic access to production environments by IT support staff or application DBAs is a common requirement and is typically associated with patching activity or diagnosing a performance issue. This task may typically involve recreating indexes and triggers, patching PL/SQL packages, or adding new tables, views, and other objects. During such maintenance windows, security would be improved if there were an ability to seal off access to tables and views containing highly sensitive data, even to those with direct object grants or the application owner. This is an increasingly common security need driven by data governance requirements and cross country regulations. Oracle Database Vault with Oracle Database 12c introduces Mandatory Realms that effectively seal off application tables, views, or other objects from all access, including the object owner and privileged users, unless access has been specifically granted. Mandatory Realms can be preconfigured, enabled during maintenance operations or as temporary response to a known threat. Mandatory Realms can also be used as an additional line of defense to protect applications. In this case, they would not only prevent privileged user access, just like regular realms, but also provide an additional authorization check on all users who have access to the application including those with direct object grants and the application owner. These users can be authorized to the Mandatory Realm and additional checks can be performed before allowing access to application data. 9
Database Vault Command Controls Oracle Database Vault Command Controls can be used to block or enforce additional checks on SQL commands that may impact the security and availability of the application and the database. Oracle Database Vault Command Controls introduce an additional layer of rules and checks before the SQL command is executed. Command controls can be used to block activity such as ad hoc creation of database links or the creation of tables using a create table as select * from syntax. These types of operations can be indicators of potential threats originating from inside the organizations or by someone who has penetrated the perimeter firewall. Command Controls can also be used to restrict access to databases from a specific subnet, application server, and program, creating a trusted path from the application to the database. Built-in factors, such as IP address, host name and session user name can be used in conjunction with command controls. Oracle Label Security user label factors can also be used to control activity based on the security clearance of the database session. In addition, Oracle APEX native functions and factors can be used with Oracle Database Vault Command Controls to determine whether to allow access to specific DML or DDL statements. Audit Vault and Database Firewall Detective Controls Oracle Audit Vault and Database Firewall provides a first line of defense for databases and consolidates audit data from databases, operating systems, and directories. Database activity monitored on the network is combined with detailed audit data for comprehensive compliance reporting and alerting. With Oracle Audit Vault and Database Firewall, auditing and monitoring controls can be easily tailored to meet enterprise security requirements. Oracle Audit Vault and Database Firewall consolidates database activity from audit logs that includes privileged user activity inside the database. Oracle Audit Vault and Database Firewall can also consolidates audit data from Microsoft Active Directory, Microsoft Windows, Oracle Solaris, Linux, and Oracle ASM Cluster File System. A plug-in architecture consolidates custom audit data from application tables and other sources. Audit Vault and Database Firewall SQL Injection Prevention Oracle Audit Vault and Database Firewall provides a sophisticated next-generation SQL grammar analysis engine that inspects SQL statements going to the database and determines with high accuracy whether to allow, log, alert, substitute, or block the SQL. Oracle Database Firewall supports white list, black list, and exception list based polices. A white list is simply the set of approved SQL statements that the database firewall expects to see. These can be learned over time or developed in a test environment. A black list includes SQL statements from specific users, IP addresses, or specific types that are not permitted for the database. Exception listbased policies provide additional deployment flexibility to override the white list or black list policies. Policies can be enforced based upon attributes, including SQL category, time of day, application, user, and IP address. This flexibility, combined with highly accurate SQL grammar 10
analysis, enables organizations to minimize false alerts, and only collect data that is important. Database Firewall events are logged to the Audit Vault Server enabling reports to span information observed on the network alongside audit data. Security controls can be customized with in-line monitoring and blocking on some databases and monitoring only on other databases. The Database Firewall can be deployed in-line, out-ofband, or in proxy mode to work with the available network configurations. For monitoring remote servers, the Audit Vault Agent on the database server can forward the network traffic to the Database Firewall. Delivered as a soft appliance, a single Audit Vault Server can consolidate audit logs and firewall events from thousands of databases. Both Audit Vault Server and the Database Firewall can be configured in a HA mode for fault tolerance. Building More Secure Applications Most application today use 3-tier architectures, connecting as one big application user to the database. These users commonly have very powerful privileges within the database. Understanding these privileges, how and if they are used, is a complex task. In addition, application users, roles, and privileges are commonly all managed in custom application tables and are unknown to the underlying database. This model, while widely used, relies on the application for all security enforcement. Direct connections to the database generally result in unimpeded access to all application data. Database Vault Privilege Analysis Oracle Database Vault with Oracle Database 12c provides the ability to monitor privileges and roles used by applications, database users, and administrators through Privilege Analysis. Privilege Analysis can be used to analyze privileges and roles used database wide or condition based. Conditions can include a specific user name, program name, or any other value available through SYS_CONTEXT. This powerful new capability can be used to scope down the privileges and roles used by applications, database users, and database administrators. Scoping down the privileges and roles increased the security of the database by limiting the attack surface should an application account be breached. New views inside the database provide the ability to report on used and unused privileges and roles. Database Vault Privilege Analysis can be used to analyze the privileges and roles of existing applications and used throughout the development lifecycle of new applications. Code Based Access Control Oracle Database 12c Code Based Access Control enables database roles to be granted to stored procedures, functions, and packages. This new security feature enables limited privilege elevation within the stored program unit. Applications that rely on definers or invokers rights procedures can use this new feature to grant roles to the stored program unit. When the stored program unit 11
is invoked, the privileges associated with the granted role will be available in the runtime context of the stored program unit. Real Application Security Oracle Database 12c introduces the next generation Oracle virtual private database (VPD) with new security technology to support application security requirements. Oracle Database 12c Real Application Security (RAS) provides a declarative model that enables security policies that encompass not only the business objects being protected but also the principals (users and roles) that have permissions to operate on those business objects. RAS is more secure, scalable, and cost effective than traditional Oracle virtual private database technology. Unlike the traditional Oracle VPD, RAS provides a declarative interface that allows developers to define the data security policy, application roles, and application users without requiring application developers to create and maintain PL/SQL stored procedures. With RAS, the data security policies are defined inside the database kernel using the Oracle Database 12c RAS API. The permissions associated with business objects are stored in Access Control Lists (ACLs). ACLs are a key component of Real Application Security and store the privileges assigned to principals and control the type operations select, insert, update and delete that can be performed on the objects. Data Classification for Government and Defense Applications Enforcing access controls based on classification labels is a common requirement found in government and defense environments. Commonly referred to as multi-level security, access to rows in application tables is controlled based on a data classification label assigned to the data and a user label or security clearance assigned to the user. Label Security Access Control Oracle Label Security enables government and defense organizations to control access to data and enforce multi-level security. Label Security restricts access to data based on the classification of the data and the security clearance of the application user. Based on U.S. Department of Defense Multi-Level Security (MLS) concepts, Label Security assigns a data label or data classification to application data, enabling sensitive data to reside in the same table with less sensitive data. Oracle Label Security enforces control by comparing the data label with the label or security clearance of the user requesting access. Data Labels can be attached as hidden columns to existing tables, providing transparency to existing applications by mediating access based on the data label but not returning the actual data label in the SQL statement. Alternatively, the data label can be explicitly requested, but only for those rows the security clearance of the user permits. Data labels can be comprised of three components. The first component is a mandatory hierarchical level. Examples of Levels include public, confidential, and highly sensitive. The second 12
component is optional and is known as a compartment. Multiple compartments can be assigned to a data label and are used to enforce additional special access requirements. For example a data label protecting special customer accounts might be protected by a compartment. The third and final component of a label is optional and is known as a group. Multiple groups can be assigned to a label and typically correspond to ownership hierarchies, territories, or jurisdictions. User labels, or security clearances, can also be used as conditional factors within Oracle Advanced Security Data Redaction policies and Oracle Database Vault Command Rules, providing additional controls over whom sees redacted versus actual data and who can perform sensitive operations inside the database. Oracle Database 12c Secure By Default Oracle Database 12c has numerous enhancements that provided increased configuration security by default. Included in these enhancements are reduced dependency on SYSDBA, expanded support for SHA-512, stronger security on sensitive data dictionary tables, display of last login time after authentication in tools such as SQL*Plus, removal of the UNLIMITED TABLESPACE privilege from the RESOURCE role, support for multiple forms of authentication within the same database, and support for network encryption and strong authentication in the SE and EE editions of the database. Oracle Database 12c introduces new roles for separation of duty, including SYSDG (Data Guard), SYSBACKUP (RMAN), and SYSKM (Advanced Security Key Management), enabling more secure management of the database by reducing the frequency and conditions under which the SYSDBA role needs to be used. In addition, the AUDIT_ADMIN and AUDIT_VIEWER roles have been introduced for management and monitoring of the new Oracle Unified and Conditional auditing. Oracle Database Security and Applications Oracle Advanced Security TDE and Oracle Database Vault have been certified with many applications include Oracle E-Business Suite, Oracle Siebel Applications, Oracle PeopleSoft Applications, Oracle JDEdwards EnterpriseOne, Oracle Primavera, and Oracle Retek. Third party certifications include SAP and Finacle. Oracle Audit Vault and Database Firewall can be used for monitoring SQL traffic being sent to the database or consolidating audit data from the underlying operating system and directories supporting the application. Oracle Audit Vault and Database Firewall can also be used to consolidate audit data from tables inside application. 13
Conclusion Perimeter firewalls are insufficient in today s world of ubiquitous Internet access, technology awareness, and global economic competition. The push toward data consolidation and cloud computing combined with an ever-changing regulatory landscape require solutions to be highly transparent and cost effective to deploy. Securing databases requires a defense-in-depth approach spanning preventive, detective, and administrative controls. Attack vectors targeting privileged accounts inside and outside the database, application vulnerabilities, and data in test and development environments are just a few of the reasons why security must be moved closer to the data. Perimeter firewalls must be supplemented with additional controls that are aligned with the sensitivity of the data, its location, its environment, applicable regulations and business impact should the data be lost, stolen, or used for unauthorized purposes. 14
Security and Compliance with Oracle Database 12c June 2013 Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 oracle.com Copyright 2013, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. 0109