An Oracle White Paper

June 2013

Security and Compliance with

Oracle Database 12c
 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
 Security and Compliance with Oracle Database 12c

Oracle Database 12c Secure By Default ......................................... 13

Oracle Database Security and Applications ..................................... 13
Conclusion ...................................................................................... 14
 Security and Compliance with Oracle Database 12c

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
 Security and Compliance with Oracle Database 12c

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
 Security and Compliance with Oracle Database 12c

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
 Security and Compliance with Oracle Database 12c

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
 Security and Compliance with Oracle Database 12c

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
 Security and Compliance with Oracle Database 12c

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
 Security and Compliance with Oracle Database 12c

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 pre-
configured, 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
 Security and Compliance with Oracle Database 12c

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 list-
based 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
 Security and Compliance with Oracle Database 12c

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-of-
band, 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
 Security and Compliance with Oracle Database 12c

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
 Security and Compliance with Oracle Database 12c

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
 Security and Compliance with Oracle Database 12c

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
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
Oracle Corporation
warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or
World Headquarters
fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are
500 Oracle Parkway
formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any
Redwood Shores, CA 94065
means, electronic or mechanical, for any purpose, without our prior written permission.
U.S.A.

Worldwide Inquiries: Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective

Phone: +1.650.506.7000 owners.

Fax: +1.650.506.7200
oracle.com 0109