Best Practices: IBM Data Server Security

®
IBM® Data Servers
Best Practices
IBM Data Server Security
Walid Rjaibi
Senior Technical Staff Member
Security Architect for DB2 LUW
James Pickel
Security Architect for DB2 for z/OS
Jonathan Leffler
Security Architect for IDS
Belal Tassi
DB2 Technical Evangelist
Last updated: October 2010

IBM Data Server Security Page 2
Introduction .......................................................................................................... 4
Security threats and countermeasures roadmap....................................... 4
Security outside the database....................................................................... 5
Assessing your security needs ........................................................................... 6
Threats ................................................................................................................... 8
Data Threats.................................................................................................... 9
Configuration Threats ................................................................................. 12
Audit Threats................................................................................................ 12
Executable Threats ....................................................................................... 13
Recommended countermeasures..................................................................... 14
Data Threats.................................................................................................. 15
Recommendations on when to use label-based access control ............. 19
Configuration Threats ................................................................................. 20
Audit Threats................................................................................................ 20
Executable Threats ....................................................................................... 21
Product overviews ............................................................................................. 22
IBM DB2 Version 9.7 for Linux, UNIX, and Windows........................... 22
IBM DB2 Version 9.1 for z/OS .................................................................... 23
IBM Informix Dynamic Server, Version 11 .............................................. 25
IBM Database Encryption Expert, Version 1.1.1...................................... 26
IBM Database Encryption Expert security policy overview.................. 27
IBM Optim .................................................................................................... 28
IBM DB2 Audit Management Expert 1.1 for z/OS .................................. 29
z/OS Security Server: Resource Access Control Facility ........................ 30
z/OS Communications Server: Application Transparent Transport
Layer Security............................................................................................... 30
Summary ............................................................................................................. 31
Further reading................................................................................................... 33
Contributors.................................................................................................. 36
Notices ................................................................................................................. 37
Trademarks ................................................................................................... 38
Introduction
Securing data requires a holistic and layered approach that considers the broad range of
threats. This is commonly referred to as defense in depth, and requires a “security by
design” approach, which espouses security as part of the core design of database
environments, the supporting infrastructures and business practices around these
environments. Multiple layers of security work together to provide the three ultimate
objectives of security, commonly known as the CIA triad: confidentiality, integrity, and
availability.
IBM understands these data security threats, and designs security features directly into
its DB2® and Informix® families of data servers. Both data server families are designed
with a wide range of security and auditing capabilities to help protect even the most
critical data.
Security threats and countermeasures roadmap

To simplify the task of implementing effective data server security, we have created this
white paper as a roadmap to assist in rolling out security mechanisms in your own
enterprise. This roadmap is based on multiple customer inquiries about how they can
ensure that they are protected against the common data security threats, and some
uncommon threats. This paper covers the most common data threats along with
proposed countermeasures to help address the threats.
The countermeasures reflect current best practices as recommended by the security teams
for each data server, and use IBM Information Management products and features that
are all available now. The countermeasures include the following actions:
• Using authentication and authorization methods that adhere to the principle of

“least privilege” — only permit users to do what they really need to do, and
minimize overlap 1
• Setting proper privileges and access control (such as LBAC) on sensitive data
• Auditing user access, particularly to sensitive data and actions by the DBA
• Revoking the data access authority from the DBA if they have no business need
to access data
• Limiting access given to PUBLIC
• Remembering to protect staging tables and MQTs
• Using trusted contexts in multi-tier environments
• Encrypting data and backup files at the operating system level
1
DB2 9.7 introduced a set of new authorities to help you adhere to this security principle. For example, the EXPLAIN authority
allows users to perform an explain operation on an SQL statement without the privileges to access objects referenced in that SQL
statement.
• Using SSL to transmit data securely on the network
• Using operating-system controls to prevent operating-system administrators

from gaining too much access
This paper focuses on the database tier and underlying data-level security. The first
section, “Assessing Your Security Needs” discusses how to determine what security your
system requires. The sections “Threats” and “Recommended Countermeasures” describe
the usual threats to security and their proposed countermeasures, respectively. “Product
Overviews” provides an introduction to each of the recommended security-enhancing
products. References to important additional information on the secure configuration
and operation of IBM Data Server products are listed in the “More Information” section
at the end of this document.
Security outside the database

To completely secure your environment you must also address other aspects of security
besides the database system itself, which are not covered by this paper:
• Physical security: Implement effective badge access to control who can

physically access the machine or machines hosting the data server.
• Host security: Secure the operating system, use virus and malware protection,
implement Web browser security, monitor and log activities of privileged system
users, and other host security techniques.
• Network security: Use firewalls, virtual private networks (VPNs), secure routers,
intrusion detection systems, detecting network sniffers, and other network
security techniques.
• Application security: Secure applications running on your system. For example,

one well-known threat is SQL injection, whereby a poorly developed application
can be forced to run unintended SQL statements. This vulnerability only exists in
dynamic SQL applications that do not validate any user input that is used in the
construction of dynamic SQL statements.
• Identity management: Use reliable systems and methods for identifying and
authenticating enterprise users effectively.
• Business controls: Implement rules, processes and practices to govern access to

assets and the use and management of data.
Assessing your security needs

At a minimum, rolling out an effective data security plan should always include the
following seven steps:
1. Data classification: Understand and classify your data. Which parts of the data
are most important, and which are less so? What is the value of the data to the
organization? What is the cost if the data is compromised?
2. User classification: Determine who is allowed to access the data. What is the
minimum level of authorities/privileges that employees need to do their jobs?
How long does each employee need to have this level of authority/privilege? At
this stage, the two security principles of least privilege and separation of duties
are vital.
3. Threat identification: Understand the threats you are facing. The threats that
you know about must be enumerated and categorized in a logical fashion.
Decide which threats apply to your environment and which ones (if any) do not.
Do your best to anticipant, and be prepared for, unforeseen threats.
4. Counter measures and preventative measures: Implement effective measures to

address every threat deemed important in your environment. It makes little
sense to buy a titanium front door to secure your house when the side door is
made of wood. In most cases, addressing threats involves multiple layers—
remember defense in depth. Lastly, these solutions should also be easy to deploy
and manage; otherwise, no one will use them, or worse, people will think the
solutions are applied properly when in fact they are not.
5. Testing: Test and validate that your security mechanisms are in place and
working properly. In many ways, this can be the hardest part; not only should
your system be secure but there must be a way to continuously validate that it is
so. This testing must be performed in various ways—including both
vulnerability (to detect any current vulnerabilities) and penetration testing (to
test the effectiveness of applied countermeasures and the impact of a breach).
6. Auditing: Audit and monitor your system to provide a historical trail of data
access and to detect any attempts to improperly access the data. Otherwise, as
happens all too frequently, no one is able to detect when a breach has occurred or
something has gone wrong. For example, you should audit access to any data
classified as sensitive from the data classification step. You might also want to
audit the actions of certain users, groups, or roles, as identified the user
classification step. Your audit policy is driven by business controls and any
corporate audit policy that may already exist. Effective data security is an
ongoing process, and auditing is the key feedback method in this process.
7. Maintenance: Keep everything maintained and secure. Effective security is not a

point in time exercise. Everything should be kept up to date as new threats are
identified, new users are added, and your data environment changes as
inevitably it will. Security maintenance should be integrated in your standard

operational practices and people should be tasked with keeping it up to date as
an important part of their core everyday responsibilities.
Threats
You should know what type of threats you are up against. Data server security threats
can be divided into four broad categories: data threats, configuration threats, audit
threats, and executable threats.
Data threats: Threats against data are mechanisms whereby data can be accessed by
users or processes that are not authorized to access such data. This is by far the largest
category of threats, and is usually the first that comes to mind. These threats can be
aimed directly at the tables in the database, or through more indirect means, such as by
looking at the log files or directly at the table space files on the operating system.
Configuration threats: Threats against configuration are mechanisms whereby the

database or database manager configuration files can be tampered with. Because they
control critical aspects of your data server—such as how and where authentication is
performed—it is critical that the database configuration files are protected as securely as
the data itself.
Audit Threats: Threats against the audit facility are mechanisms whereby the audit
configuration, audit logs, or archive logs can be tampered with. In many cases, audit
records are the only way to determine what has happened in the past and the only form
of evidence to detect misuse; it is critical that they be able to withstand tampering.
Executable Threats: Threats against executables are mechanisms whereby database

manager executable files can be tampered with. This includes executable spoofing,
denial-of-service attacks and Trojan horse attacks.
In the following sections, each threat is uniquely identified by a three-part name: the
category followed by a unique number, and one word identifying the threat. This always
takes the form:
<category>.#.<threat short name>
For example, the threat Data.6.OSAdminAccess is threat #6 in the “Data” category and is
referenced by the short name “OSAdminAccess”.
Data Threats
Threat Threat Description Explanation
Data.1.Connection Exploiting poor An unauthorized user can exploit poor

database connection authentication practices on the database to
authentication and connect to the database.
authorization
The most common examples of these practices
include requiring no server-side credentials to
authenticate users when connecting (for
example, using the CLIENT-side
authentication), or by granting the CONNECT
privilege to the group PUBLIC.
Data.2.BaseTables Exploiting poor An unauthorized user can exploit poor

authorization controls authorization practices in the database to access
on base tables data in the base tables and system catalog
tables.
For example, leaving the group PUBLIC with

access to the system catalog tables allows any
user to access all their information.
Data.3.OtherTables Exploiting poor An unauthorized user can exploit poor

authorization controls authorization practices on the database to
on replicated tables, access data on other important non-base tables.
Materialized Query
Tables (MQTs), staging These non-base tables include:
tables, exception tables,
and relational OLAP SQL replicated tables
cubes
MQTs
Exception tables
Staging tables
Relational OLAP cubes
Clone tables
Data.4.CommonUser Loss of identity of Application servers often use a common user

ID connected users in N- ID to connect to the database that works on
tier architectures due to behalf of all its applications. This is also
common user ID referred to as connection pooling. This common
user ID weakens user accountability and the

ability to properly audit database access.
This also leads to over-granting of privileges to

this common user ID, effectively bypassing
most database privilege checking.
Data.5.DBAAccess Abusing database By default, DBAs have access to any table in

administrator their database. A privileged database
privileges administrator—or those who acquire database
administrator authority in an unauthorized
fashion—can abuse that privilege by reading or
modifying data that they should not be seeing.
This is a critical component of “insider abuse”.
Data.6.OSAdminAcc Abusing operating Both a user with OS administrator privileges

ess system administrator and the instance owner of the database have
privileges direct file system access to OS files where table
data resides.
They can abuse that privilege by directly

reading or copying the contents of these files
via the file system and bypass access controls
placed inside the database.
This is a critical component of “insider abuse”.
Data.7.InTransit Sniffing data in transit Data, user IDs, and passwords traveling in
on the network clear text over a network can be viewed by
network sniffers.
Data.8.Backups Exploiting poor Many times unauthorized access to data occurs

security on backups once the data has left the protection of a
and archives running data server environment.
If left unprotected, data can be accessed

directly from backup and archive images,
whether left onsite or put offsite for disaster
recovery (DR) purposes.
Data.9.TxnLogs Exploiting poor Transaction logs contain valuable data that can
security on transaction be exploited—such as inserted data values.
logs Because transaction logs are files on the file
system, they can be accessed directly by the OS
administrator on the production system.
Also, if transaction logs are mirrored or

replicated, these copies can also be exploited by
a privileged user as well.
Data.10.ArchiveLogs Exploiting poor Archived transaction logs contain valuable data

security on archived that can be exploited—such as inserted data
transaction logs values. Once transaction logs are archived for
recovery purposes, they usually leave the
protection of the production system and are
put on other servers or devices. Privileged
users on those archive servers or devices can
abuse their privileges and access data within
these archived transaction logs.
Data.11.Diagnostics Exploiting poor Many diagnostic logs, monitoring output, and

security on trace files, dump files contain valuable information that
dump files, and output can be exploited by attackers.
of monitoring and
diagnostic tools For example, data in the diagnostic logs and
trace files can contain data values and are
logged in clear text. Also, unloading of the
direct raw page images from tables directly to
disk can easily be done using tools such as
db2dart or IDS onunload. This dumped data
provides an indirect means to view data in the
data server.
Data.12.Extract Exploiting extracted Data is commonly extracted from the

data that has been production environment into an export file or
moved from its secure another database, usually for distribution or
home test purposes. Once it is extracted, it leaves the
security of the data server environment and is
often left exposed to unauthorized access. This
is also true for load input files that are waiting
to be loaded into a data server.
This threat can be split into different cases

according to the ultimate goal of the extraction:
1. Test: When the data is being used in test

environments, the data must have the
same properties as production data but
can safely be masked or changed to
preserve sensitive data such as credit card
numbers or social security numbers.
2. Distribution: When the data is being

extracted for distribution to another
location, the data must be left identical to
that in production. This includes data
extracted by Extract, Transform, and Load
(ETL) processing and those for replicated
tables. One scenario for distribution is
management of copies.
Configuration Threats
Threat Threat Description Notes
Config.1.Files Exploiting poor If the DBMS configuration files are insecure, an

security on database intruder can modify the way the system
configuration files behaves and make it reveal information that
should not be revealed.
Config.2.DBCreate Exploiting lack of Creating a database in a database management

authorization controls system is a privileged operation that is
on who can create controlled by the instance configuration. Only
databases trusted users should be authorized to create a
database within an instance.
Config.3.DBEnviron Exploiting poor Poor configuration includes poor database

ment configuration of the configuration parameter settings, database
database environment manager configuration parameter settings,
database administration server settings, not
running with the latest fix pack and others.
Audit Threats
Audit.1.Config Exploiting poor Unauthorized personnel should not be able to

security on audit alter the auditing behavior on the system. This
configuration files is a common way for attackers to hide their
tracks before performing an unauthorized
breach.
Unauthorized personnel should not be able to

modify the audit configuration files.
Audit.2.Logs Exploiting poor Audit logs contain valuable data that can be
security on audit log exploited—both from the perspective of
files modifying past auditing results and of
understanding data server access patterns for
would-be attackers. This is a common way for
attackers to hide their tracks after performing
an unauthorized breach. Unauthorized
personnel should not be able to alter or view
the audit records or archived audit records.
Executable Threats
Executable.1.Files Maliciously modifying Data server executable files can be

data server executable maliciously modified, for example by adding
files an identically named version containing a
Trojan horse, or can be removed to perform a
denial-of-service attack.
Also executables and libraries used by stored

procedures and UDFs can also similarly be
maliciously modified.
Only the user entrusted with installing the

software should be able to modify the
executables used by the data server.
Executable.2.Dirs 2 Exploiting poor If the directories containing the executables or

security on directories the data files are not secure, then attackers
containing executables could modify directory paths to mount a denial-
or data of-service attack on the database system.
2
This threat is not applicable on z/OS systems
Recommended countermeasures
Effectively protecting your database from the threats outlined in “Threats” demands
effective organizational processes and controls as well as technical components. Your
protection plan must include both aspects.
The tables below document the technical components of the recommended

countermeasures to help address each of the threats. The recommended countermeasure
is presented followed by the features and solutions needed to implement the
recommended countermeasure using the latest product version as outlined in ”Product
overviews”.
The “Products recommended” columns in the tables that follow use the following
abbreviations for product names:
Linux®, UNIX®, and Windows® platforms:
Products Abbreviation
DB2 for Linux, UNIX, and Windows DB2
Informix Dynamic Server IDS
IBM Database Encryption Expert IBM DEE
IBM Optim Test Database IBM Optim TDM
Management
IBM Optim Archive IBM Optim Archive
z/OS® platform:
Products Abbreviation
DB2 for z/OS DB2
IBM Audit Management Expert for IBM AME
z/OS
IBM Optim Test Database IBM Optim TDM
Management
IBM Optim Archive IBM Optim Archive
z/OS Security Server (Resource z/OS RACF
Access Control Facility, RACF®, or
equivalent)
IBM Data Encryption for IMS and z/OS Encryption
DB2 Database tool
z/OS Communication Server z/OS AT-TLS
Application Transparent Transport
Layer Security
IBM System Storage® TS1120 z/OS Tape Drive
Tape Drive
IBM System Storage DS8700 z/OS Disk Encryption
Disk
Data Threats
Threat Threat Countermeasure Products
Description Recommended
Data.1.Connection Exploiting poor Use authentication and authorization DB2 or IDS

database practices that follow the principle of
connection least privilege. For authentication,
authentication you should not use client
and authentication, as it is not secure. Use
authorization SERVER, LDAP, or Kerberos
authentication.
Data.2.BaseTables Exploiting poor ALL OBJECTS DB2 or IDS

authorization
controls on base • Set proper database IBM AME
tables privileges and access controls (z/OS
based on data sensitivity only)
classification and principle of
least privilege. z/OS RACF
• REVOKE all privileges from

those who do not absolutely
need them.
• Assign privileges to roles and

not directly to specific users.
• Have sensitive objects owned

by roles and limit all access of
these roles to users
connecting from trusted
contexts.
• When creating new database

objects, ensure that access is
never granted to PUBLIC.
BASE or SYSTEM CATALOG

TABLES
• Audit all access to important

tables
• When possible, make sure

that access to the system
catalogs is not granted to
PUBLIC
• The use of Label-Based

Access Control (LBAC) or
z/OS MLS on sensitive tables
is recommended in
government and other highly
sensitive and regulated
environments. For more
information, see the
“Recommendations on when
to use LBAC” section of this
document.
Data.3.OtherTables Exploiting poor • Violation, exception, and DB2 or IDS

authorization staging tables should be fully
controls on protected against
replicated tables, unauthorized access, just as
Materialized the corresponding base tables
Query Tables are.
(MQTs), staging
tables, exception • MQTs serve as a results set
tables, and cache for improving query
relational OLAP performance (via MQT
cubes routing). As such, MQTs
should be regarded as
internal tables, and users
should not be given direct
access to them.
• If direct access to the MQT is

required, turn on fine-grained
auditing of all SQL access to
the MQT.
Data.4.CommonUs Loss of identity Use the Trusted Context feature in DB2

erID of connected any N-tier environment. Trusted
users in N-tier contexts allow the middle-tier to
architectures due assert the identity of the end user
to common user accessing the database. The end user's
ID database identity and database
privileges are then used for any
database requests by that end user.
Because the user identity is
preserved, you can use audit to track
user access and actions.
Data.5.DBAAccess Abusing DB2 or IDS

database • Monitor: Audit all actions
administrator requiring DBA authority. IBM AME
(z/OS
privileges • Restrict access to DBA
only)
Authority: Assign DBA
authority only through a role
and control access to this role
using trusted contexts. This
restricts access to only trusted
connections originating from
trusted hosts.
Prevent DBA from accessing data:
• Revoke DATAACCESS and

ACCESSCTRL from the DBA
• Protect the data with LBAC

or z/OS MLS features
Data.6.OSAdminAc Abusing • Prevent the data from being IBM DEE

cess operating system copied or read directly from
administrator the file system by using disk z/OS
privileges encryption is needed on non
z/OS platforms. AES Encryption
encryption is recommended.
z/OS RACF
z/OS RACF protection
protects the data from being
copied or read directly from
the file system.
• Prevent sensitive files, such

as the table space files, from
being modified directly by
the OS administrator. This
requires extended OS access
control functionality, such as
that provided by IBM DEE
and z/OS RACF.
Data.7.InTransit Sniffing data in • Encrypt the data before it is DB2 or IDS

transit on the transferred on the wire.
network z/OS AT-TLS
• In most cases, the
recommendation is to use SSL
encryption 3 when possible.
Data.8.Backups Exploiting poor • Encrypt all backup images

IBM DEE
security on and archive images on any
backups and media type (disk, tape, etc.). IBM Optim
archives Archive
• Restoration of the backup
z/OS Tape
image must require
Drive
controlled access to the
encryption key and must be
audited.
Data.9.TxnLogs Exploiting poor Prevent files from being modified IBM DEE
security on directly by the OS administrator
transaction logs or any other user using extended z/OS RACF
OS access control.
Data.10.ArchiveLo Exploiting poor Prevent the logs from being copied or IBM DEE
gs security on read directly from the file system by
archived using disk encryption. z/OS Tape
transaction logs
Drive
Data.11.Diagnostics Exploiting poor • Prevent files from being IBM DEE

security trace modified directly by the OS
files, dump files, administrator or any other z/OS RACF
and output of user using extended OS
monitoring and access control.
diagnostic tools
• Audit any direct file system
access to these files.
Data.12.Extract Exploiting Countermeasure depends on the IBM Optim

extracted data reason the data is being
that has been extracted: TDM
moved from its
secure home 1. Test: Use the data privacy IBM DEE
capabilities of Optim Test Data
Manage to automatically mask z/OS RACF
3
Turning on network encryption will cause any third-party data sniffing application to no longer function.
out all sensitive information

from the data during extraction
to your test environment.
2. Distribution: Prevent extract file

from being read or modified by
using disk encryption. On z/OS
z/OS RACF protection protects
the files from being read or
modified.Audit all access to the
extract file.
Make sure that you remember to

audit the extraction of data, such
as during export.
Recommendations on when to use label-based access control

The following guidelines help determine when you should use label-based access control
(LBAC) to protect your data.
Use row-level LBAC for:
• Government applications that manage classified information
• Other applications, where all of the following apply:
o Data classification is known
o Data classification can be represented by one or more LBAC security

label components
o Authorization rules can be mapped to the security label components
Use column-level LBAC for:
• Protecting sensitive columns from table owners and DBAs
• Tables that contain data which you want to protect from access by the table
owner or the DBA. To protect this data, follow these steps:
1. Assign a security label to all columns in the table.
2. Assign that security label to a role.
3. Assign that role to all users who need access to the table. Only users who
are members of that role are able to access data in that table.

Config.1.Files Exploiting poor Prevent files from being modified DB2 or IDS
security on directly by the OS administrator or
IBM DEE
database any other user using extended OS
configuration files access control. z/OS RACF
Config.2.DBCreate Exploiting lack of • Revoke this privilege except DB2 or IDS

authorization for authorized DBA.
controls on who
can create • Audit all attempts to create
databases databases.
Config.3.DBEnviro Exploiting poor Consider following the DB2 for LUW

nment configuration of recommendations in Security
Configuration Benchmark For DB2
the database
8, 9 & 9.5 for Linux, Unix and
environment Windows from the Center for Internet
Security (CIS) to properly configure
DB2 LUW. A copy can be obtained
from: www.cisecurity.org
Audit Threats

Audit.1.Config Exploiting poor Prevent files from being modified DB2 or IDS
security on audit directly by the OS administrator or
IBM DEE
configuration files any other user using extended OS
access control. z/OS RACF
Audit.2.Logs Exploiting poor Use a secure centralized audit DB2 or IDS

security on audit repository such as IBM AME
IBM AME (z/OS
log files (z/OS only)
only)
Use extended OS access control to
IBM DEE
prevent files from being modified
directly on file system by the OS
administrator or any other user.
Encrypt the audit logs records on
disk.
Executable Threats

Executable.1.Files Maliciously Use executable security feature, such IBM DEE

modifying data as the “operational controls”
z/OS RACF
server functionality in IBM DEE, to prevent
executable files executable modification.
Executable.2.Dirs Exploiting poor Use extended OS access control to IBM DEE

security on prevent directories from being
z/OS RACF
directories modified by unauthorized users.
containing
executables or
data
Product overviews
IBM DB2 Version 9.7 for Linux, UNIX, and Windows

The DB2 for Linux, UNIX, and Windows security capabilities can be divided into four
broad areas:
• Authentication
• Authorization
• Encryption
• Auditing.
Authentication is the first security capability encountered when a user attempts to use
the DB2 database system. The user must be identified and authenticated before they are
allowed to use any of the DB2 services. The DB2 database system relies on a security
plug-in architecture for authentication. The security plug-in determines where
authentication takes place, which is generally the operating system but it can also be
Kerberos or an LDAP server.
Authorization is the next security capability encountered. The authenticated user must
be authorized to perform the action they are attempting. Authorization can be coarse-
grained (for example, at a table) or fine-grained (for example, views). For a given
operation, the DB2 database system checks whether or not the user’s permissions are
sufficient to allow them to carry out that operation. Users can acquire permissions either
directly or indirectly through membership in roles and groups.
Packages provide an elegant model to give users access to database objects without
having to give them actual privileges on those objects, especially for packages that
contain static SQL. To run a package, a user requires only EXECUTE privilege on that
package. The static SQL in the package executes under the authorization ID of the
package owner. Authorization for the static SQL in the package is checked once when the
package is created, and the package owner must be authorized to execute all the static
SQL in that package. For dynamic SQL in the package, the authorization checking
depends on the settings of the DYNAMICRULES bind option. The authorization
checking can be based on either the package owner authorization ID or on the
authorization ID that is executing the package.
While dynamic SQL provides some flexibility for applications to dynamically construct
the SQL, it also opens the door for SQL injections. A poorly developed application, for
example one that does not validate user input, can be forced to execute unintended SQL.
There are at least two options a customer can take to handle the SQL injection problem.
First, by using IBM pureQuery, a DBA can guard against SQL injection by restricting
access to only captured SQL. If the target database is DB2, the captured SQL can be
bound into packages for static execution to improve security. Second, by using an
application scanning tool such as IBM Rational AppScan, a DBA can detect and then
eliminate potential vulnerabilities that can be exploited through SQL injection attacks.
Label-based access control (LBAC) was enhanced so that security administrators can
assign security labels and exemptions to roles and groups. DB2 Version 9.7 also provides
a new security capability that helps address the security concerns that arise from the use
of a single user ID to access the database in three-tier environments. This capability is
referred to as trusted contexts. Trusted contexts also allow security administrators to gain
more control over when a privilege or an authority becomes available to a user. For
example, a security administrator can use trusted contexts to make sure that a database
administrator (DBA) can exercise their role only when they are connecting to the
database from a specific IP address.
Encryption can be employed to keep information confidential when it is transmitted

between a DB2 server and a DB2 client or when it is stored on disk. For data transmission
confidentiality, the DB2 database system provides two options: the native
DATA_ENCRYPT capability and Secure Sockets Layer (SSL). For data storage, there are
also two options: the native encryption and decryption column functions and the IBM
Database Encryption Expert. It is highly recommended to use IBM Database Encryption
Expert as this provides additional security features, improved performance, and most
importantly requires no application-level changes.
Lastly, the audit facility can be turned on to track user actions. For example, the security
administrator can consult the audit trail to find out what actions a particular user
executed in a given timeframe. The audit facility has been substantially improved to
provide finer granularity and to reduce the auditing performance overhead.
IBM DB2 Version 9.1 for z/OS

Like DB2 for Linux, UNIX, and Windows, the DB2 for z/OS security capabilities can be
divided into four broad areas:
• Authentication
• Authorization
• Encryption
• Auditing.
Because for many years z/OS has been designed to run multiple applications
simultaneously on the same server, these capabilities are mature, proven technologies.
Authentication is the first security capability encountered when a user attempts to use
the DB2 for z/OS product. The user must be identified and authenticated before allowed
to use any of the DB2 for z/OS services. DB2 for z/OS uses the z/OS Security Server
(RACF or equivalent) for authentication and authorization to access any DB2 subsystem.
Authorization is the next security control encountered. When an application gains access
to a subsystem, the user has been authenticated and access to DB2 for z/OS is checked
using RACF. DB2 for z/OS then controls access to data through the use of identifiers
associated with the authenticated user. A set of one or more DB2 for z/OS identifiers,
called authorization IDs, represent the user on every process that connects to or signs on
to DB2 for z/OS. These IDs make up the SQL ID. The SQL ID and role, if running in a
trusted context, are used for authorization checking within the DB2 database system.
Access to DB2 for z/OS requires the use of packages. Packages are required to execute
SQL statements. Packages have an owner ID or role associated with them. The owner
might be different from the SQL ID or role executing the package. To execute any SQL
statements bound in a package, the SQL ID or role associated with the package must
have the execute privilege on the package. The package owner is used for privilege
checking for any static SQL statements in the package. When executing a dynamic SQL
statement, the SQL ID or role must be authorized to perform the action against the DB2
database system, not the owner. This allows DB2 for z/OS to perform as much
authorization checking when the package is created and not every time it is used. Also
this approach eliminates the need to authorize all users to all objects used in a package.
You can take advantage of mandatory access control in the DB2 database system to
protect table data based on the security labels of the rows. When a user accesses a row or
a field in the row with an SQL statement, DB2 for z/OS calls RACF to verify that the user
is allowed to perform the type of access that is required for the SQL statement. The access
is allowed only if the user has the requested access right to all of the rows containing
fields that are accessed as part of the SQL statement. For all fields that the SQL statement
accesses, DB2 for z/OS checks the security label of the row containing the field and denies
access when the user security label does not dominate the security label of any one of the
rows containing the fields.
A powerful security enhancement in DB2 9 for z/OS is the introduction of trusted

contexts, a feature that supplies the ability to establish a connection as trusted when
connecting from a certain location or job. Having established a trusted connection, it
provides the possibility of switching to other user IDs, thus giving the opportunity of
taking on the identity of the user associated with the SQL statement. In addition, it is
possible to assign a role to a user of a trusted context. The role can be granted privileges
and can therefore represent a role within the organization in the sense that it can hold the
sum of privileges needed to perform a certain job, application, or role. These two
constructs together supply security enhancements for various different scenarios ranging
from any three-tier layered application, such as SAP, to the daily duties of a DBA
maintaining the DB2 for z/OS subsystem.
Encryption can be employed to help protect the confidentiality of information when it is

transmitted between a DB2 for z/OS subsystem and a DB2 for z/OS client or when it is
stored on disk. For data transmission confidentiality, DB2 for z/OS provides two options:
native data stream encryption supported in the database protocols and Secure Sockets
Layer (SSL) supported in the network layer. The native data stream encryption uses DES
to provide a level of performance over SSL. For SSL, DB2 for z/OS exploits z/OS
Communications Server’s Application Transparent Transport Layer Support (AT-TLS).
This facilitates the use of SSL encryption of data during data transmission between DB2
for z/OS systems on behalf of DB2 for z/OS.
For data-at-rest encryption, there are also two options: IBM System Storage DS8700
Disk Encryption or database encryption methods either the encryption and decryption
column functions provided by the DB2 for z/OS or the IBM Data Encryption for IMS and
DB2 Databases tool used to encrypt a table. Both the column functions and encryption
tool have limited or restricted usage that needs to be reviewed before deploying these
encryption techniques. It is recommended to utilize IBM System Storage Disk Encryption
which includes a robust and sophisticated key management in order to meet your long
term encryption requirements.
To satisfy Payment Card Industry (PCI) security standards encryption requirements

when disk encryption is used (rather than table or column-level encryption), logical
access must be managed independently of native operating system access control. z/OS
RACF protection and self encrypting disks provide this level of encryption. This solution
encrypts the data at rest with no performance degradation or no impact to your
applications.
When offloading backups and archive logs, the tape units offer encryption built-in to the
drive to protect the archive tape. All exploit System z™ Crypto hardware features
designed to provide better performance and industry level security built-in to z/OS.
The audit facility integrated into z/OS can be turned on to track user actions in the DB2
database system. Auditors can collect log and trace data in an audit repository, and then
view, analyze, and generate comprehensive reports on the data using the IBM DB2 Audit
Management Expert for z/OS. You can selectively filter SELECT, INSERT, UPDATE, and
DELETE activity by user or by object, and export these filters for use on another DB2
subsystem.
IBM Informix Dynamic Server, Version 11

Similar to the DB2 database system, the security capabilities of Informix Dynamic Server,
Version 11 (IDS) can be split into the four broad areas:
• Authentication
• Authorization
• Encryption
• Auditing
Before a user is permitted to connect to an IDS database, the system authenticates them.
You can configure the way that IDS authenticates users. The primary authentication
mechanism is based on the operating system identity of the user. However, you can
configure IDS to use PAM (Pluggable Authentication Modules) to authenticate users

using other systems such as LDAP.
Once authenticated, a user is still denied access unless they are also authorized to
perform the intended action. This includes permission to access a particular database, as
well as separate controls for each object in the database.
IDS also supports mandatory access control through LBAC. This LBAC implementation
is similar to the version for DB2 for Linux, UNIX, and Windows. You can apply labels to
columns and rows, and grant labels to users, and the system determines whether the user
is permitted to see or modify the data.
IDS supports encryption in a number of ways. For the Informix client applications using
the SQLI protocol, you can configure the communications between the client and server
so that all communications between them are encrypted using the ENCCSM module, or
you can encrypt the password using the SPWDCSM. If you are using DRDA clients, you
can configure them to use SSL. To enhance the secrecy of data in the database, you can
use column-level encryption to encrypt particular values. Alternatively, you can use IBM
Database Encryption Expert to help secure the disks on which your data is stored.
Depending on the backup system you use, you can encrypt the backup data.
The auditing facilities in IDS permit you to track who did what to the data in the system
and when they did it. You can control which users and which actions are audited.
IBM Database Encryption Expert, Version 1.1.1

The IBM Database Encryption Expert, Version 1.1.1 (IBM Database Encryption Expert) is
a data access control tool that combines file encryption with host-level access controls
and operational controls. It provides the means, through centrally managed policy, to
control the “who, what, when, where, and how” data is accessed on the files on the
operating system. These controls can be applied to the database applications, database
containers, and other elements in the operating environment.
IBM Database Encryption Expert is a two-component solution composed of one or more

software security servers and data security agents. This architecture provides separation
of duties so the database administrator does not have the same data security privileges as
the Database Encryption Expert administrator. The security server acts as the centralized
point of administration for encryption key, data security policy, and audit log collection.
IBM Database Encryption Expert currently has two agents:
• Online data protection agent (EE FS Agent in the diagram) provides encryption
services and access controls for data in online storage accessed by file systems.
• Secure backup agent (EE DB2 Backup Agent in the diagram) provides
encryption services for data being backed up to offline storage—both disk and
tape.
Figure 1 shows the architecture of the IBM Database Encryption Expert when it is
installed and used with a DB2 database system.
DB2
DB2 offline files Web
Server
Server Administration
DB2 backup
DB2 backup
https
EE DB2 Backup
EE FS Agent EE DB2 Backup
EE FS Agent Agent
Agent
Encryption Expert
Security Key, Policy,

online files Security
soap/https Server
Server Log Store
Figure 1 IBM Database Encryption Expert Architecture
An important distinction between IBM Database Encryption Expert and other solutions
that offer encryption is how the encryption is performed. IBM Database Encryption
Expert leaves the file metadata in clear text (unencrypted) while encrypting the file
contents. This technique provides an additional level of file access control in addition to
what the file system offers—access without viewability. Effectively, an application can be
granted access to a file for the purposes of management without decrypting its contents.
Privileged superusers can continue to manage their environments and access the file but
be restricted from having clear-text access to the file content. This capability helps
mitigate risks from internal malicious activity targeted at private or confidential data.
IBM Database Encryption Expert security policy overview

Security policies are at the core of IBM Database Encryption Expert.
They control the following aspects of data security:
• Who and what can access data
• When data can be accessed
• Where data can be accessed from
• How data is accessed
Policies also control the use of encryption keys and what events are logged (for example,
all file accesses and policy violations). These data security policies allow organizations to
translate business rules into data access control and protection policies.
The policy engine is managed through a browser interface hosted from the security
server. From one security server, the policies for many database servers and Database
Encryption Expert agents can be managed. Geographical proximity is not a restriction as
long as there is IP connectivity between the IBM Database Encryption Expert agents that
reside on a DB2 for Linux, UNIX, and Windows database server and the security server.
It is possible (in fact, it is a best practice) to cluster the security servers for high
availability and failover.
IBM Optim
IBM Optim software is a single, scalable, interoperable information lifecycle management
solution providing a central point to deploy policies to extract, store, port, and protect
application data from creation through to deletion.
Figure 2 below illustrates at a high level the functionality of the IBM Optim enterprise
data management software.
Figure 2 IBM Optim software functionality
IBM Optim can provide the following core functionality:
Test data management: IBM Optim assists in application deployment by streamlining

the way you create and manage test environments. Subset and migrate data to build
realistic and right-sized test databases. It helps to reduce the expense and effort of
maintaining multiple database clones.
Data privacy: Protecting your sensitive data does not stop at your production system.
This data is commonly replicated in multiple test environments across your organization,
as well as in extract files and staging tables. IBM Optim provides automatic data
transformation capabilities to mask personal information and de-identify confidential
information to help protect privacy. You can then use the transformed data safely for
application testing, which helps you address compliance requirements and maintain
client loyalty.
Archive: IBM Optim provides proven database archiving capabilities, empowering

organizations to segregate historical from current data, and helping to store it securely
and cost-effectively while maintaining universal access to the data, thus allowing your
production databases to serve your business applications at higher performance levels.
IBM DB2 Audit Management Expert 1.1 for z/OS

IBM DB2 Audit Management Expert 1.1 for z/OS is a tool that gives auditors, security
administrators, and database administrators the capabilities they need to deliver
accurate, timely data and reports for use in auditing activities. It collects the audit records
generated from the DB2 audit facility for your DB2 data servers in one audit repository,
and allows the auditor to easily view, analyze, and generate reports from these audit
records.
From this one centralized tool, auditors can:
• Selectively audit all inserts, updates, deletes, and reads in DB2 databases using
automatic processes.
• View all reported activity on specific DB2 objects.
• Generate meaningful reports on the data collected in the audit repository.
IBM DB2 Audit Management Expert separates the roles of auditor and DBA, freeing up
the valuable DBA resources used to support auditing requests today. Auditors are not
required to be privileged users on the systems they are auditing so database security is
preserved. Where a significant auditing exposure is suspected, DB2 Audit Management
Expert allows an authorized auditor to investigate the exposure by reviewing what data
has been changed in the system. This enables auditors to do database auditing work
without DBA involvement. And in a similar fashion, DBAs and security administrators
can use the tool to ensure that their system is audit-ready.
With the benefit of an easy-to-use graphical user interface, auditors can customize data
collection capabilities, defining filter policies based on any combination of DB2 objects,
DB2 user IDs, applications connecting to the DB2 database system, and time of collection.
DB2 Audit Management Expert also provides a reporting interface that facilitates
common auditing tasks such as determining who updated a particular object in a certain
timeframe, or monitoring unauthorized access for specific systems or objects. Robust
reporting options enable auditors to view and report on data from several perspectives.
Lastly, a separate user-friendly administration interface enables DB2 Audit Management

Expert administrators to easily define DB2 Audit Management Expert entities such as
collection criteria, users, and groups. The interface simplifies administrative tasks with
easy-to-use wizards to guide the administrator through each task.
z/OS Security Server: Resource Access Control Facility

The Resource Access Control Facility (RACF) software is a component of z/OS System
Authorization Facility (SAF), used to protect all resources on z/OS including your
network and communications. SAF is the high-level infrastructure that allows you to
plug into any commercially available security product.
RACF has evolved over more than 30 years to provide protection for various resources,
features, facilities, programs, and commands on the z/OS platform. The RACF concept is
simple: it keeps a record of all the resources that it protects in the RACF database. It can,
for example, set permissions for file patterns even for files that do not yet exist. Those
permissions are then used should the file (or other object) be created at a later time. In
other words, RACF establishes security policies rather than just permission records. The
RACF initially identifies and authenticates users by user ID and password when they log
on to the system. When a user tries to access a resource, RACF checks its database and,
based on the information that it finds in the database, it either allows or denies the access
request.
z/OS Communications Server: Application Transparent

Transport Layer Security
The Transport Layer Security software, or TLS, is the latest evolution of Secure Sockets
Layer (SSL) technology. With it, you can encrypt and protect your most important e-
commerce transactions and other data transmissions as they cross the network.
Implementing and taking advantage of this highly secure approach used to require
extensive programming changes to applications within the mainframe environment.
With the availability of Application Transparent Transport Layer Security (AT-TLS), you
can now deploy TLS encryption helping to avoid the time and expense of re-coding your
applications.
AT-TLS support is policy driven and is managed by a Policy Agent or PAGENT. Socket
applications continue to send and receive clear text over the socket, but data sent over the
network is protected by system SSL. Support is provided for applications that require
awareness of AT-TLS for status or to control the negotiation of security.
Summary
To comprehensively secure your environment you must address all aspects of security,
not just the database system itself. As described in the section “Security outside the
database”, this includes securing the network, your host computer, and any applications
you are running, plus controlling physical access and implementing business controls.
Figure 3 illustrates data security and its accompanying threats as part of the broader
enterprise security picture.
Application Security
Data Security
Identity Management
Business Controls
Data Threats
Audit Threats
Executable Threats
Host Security
Network Security
Physical Security
Figure 3 Data security model and security threats
Threats to data security can be divided into four broad categories: data threats,
configuration threats, audit threats and executable threats. The following tables
summarize for each of these categories the threats and their countermeasures for your
database system:
Data threats:
Threat Countermeasure Products
Recommended
Data.1.Connection Use authentication and authorization best practices DB2 or IDS
following the principle of least privilege
Data.2.BaseTables • Classify data and set privileges based on the DB2 or IDS
principle of least privilege IBM AME
• Assign privileges via roles and not directly to the z/OS RACF
users
• Ensure sensitive objects owned by roles
• Limit all access of these roles to users connecting
via trusted contexts
• Audit all access to important tables
• Do not grant access to PUBLIC
• Use LBAC or MLS on sensitive tables in classified
government environments
Data.3.OtherTables • Protect violation, exception and staging tables the DB2 or IDS
same as base tables
• Do not grant direct access to MQTs
Data.4.CommonUserID • Use the Trusted Context feature in any N-tier DB2
environment
Data.5.DBAAccess • Monitor: Audit all actions requiring DBA authority DB2 or IDS
• Restrict access to DBA Authority: Make DBA IBM AME
authority available only via a role and control access
to this role using trusted context
• Prevent DBA from accessing data: Protect the
data with LBAC or MLS
Data.6.OSAdminAccess • Encrypt data at rest (AES recommended) IBM DEE
• Use extended operating system access control z/OS Encryption
z/OS RACF
Data.7.InTransit • Encrypt data in motion (SSL recommended) DB2 or IDS
z/OS AT-TLS
Data.8.Backups • Encrypt all backup images and archive images on IBM DEE
any media type IBM Optim Archive
• Implement access control and full auditing for any z/OS Tape Drive
attempt to access the backup encryption keys
Data.9.TxnLogs • Use extended operating system access control IBM DEE
z/OS RACF
Data.10.ArchiveLogs • Encrypt data at rest (AES recommended) IBM DEE
z/OS Tape Drive
Data.11.Diagnostics • Use extended operating system access control IBM DEE
• Audit any access to these files z/OS RACF
Data.12.Extract 1. Test: IBM Optim TDM
• Use Optim TDM’s data privacy capabilities to IBM DEE
mask out all sensitive information z/OS Encryption
2. Distribution:
• Encrypt data at rest (AES recommended)
• Audit all access to the extract file
Configuration threats:
Recommended
Config.1.Files • Use extended operating system access control DB2 or IDS
IBM DEE
z/OS RACF
Config.2.DBCreate • Revoke this privilege except for authorized DBA DB2 or IDS
• Audit all create database attempts
Audit threats:
Recommended
Audit.1.Config • Use extended operating system access control DB2 or IDS
IBM DEE
z/OS RACF
Audit.2.Logs • Use a secure centralized audit repository DB2 or IDS
• Encrypt data at rest (AES recommended) IBM AME
IBM DEE
Executable threats:
Recommended
Executable.1.Files • Use executable security, such as the “operational IBM DEE
controls” z/OS RACF
Executable.2.Dirs • Use extended operating system access control on IBM DEE
directories z/OS RACF
Further reading
• DB2 Best Practices http://www.ibm.com/developerworks/db2/bestpractices/
• DB2 for Linux, UNIX, and Windows Security
[1] DB2 Information Center

http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp
[2] DB2 9.7 for Linux, UNIX, and Windows - Security Manual
ftp://public.dhe.ibm.com/ps/products/db2/info/vr97/pdf/en_US/DB2Secu
rity-db2sece971.pdf
[3] IBM Redbooks® Publication: DB2 Security and Compliance Solutions for
Linux, UNIX, and Windows
http://www.redbooks.ibm.com/redbooks.nsf/RedpieceAbstracts/sg24755
5.html?Open
[4] DB2 Label-Based Access Control, A Practical Guide, Part 1: Understand

the basics of LBAC http://www.ibm.com/developerworks/edu/dm-dw-
dm-0605wong-i.html?S_TACT=105AGX11&S_CMP=LIB
[5] DB2 Label-Based Access Control: A Practical Guide, Part 2: A step-by-step

guide to protect sensitive data using LBAC
http://www.ibm.com/developerworks/edu/dm-dw-dm-0605wong2-
i.html
[6] Document-level security using DB2 9 pureXML and LBAC

http://www.ibm.com/developerworks/edu/dm-dw-dm-0607williams-
i.html
[7] DB2 Trusted Contexts: Making Security Compliance Easier, IDUG

Solutions Journal, Volume 14, Number 2, Summer 2007
• DB2 for z/OS Security
[8] Securing DB2 & MLS z/OS

http://www.redbooks.ibm.com/abstracts/sg246480.html
[9] Introduction to the New Mainframe: z/OS (Security Section)

[10] Introduction to the New Mainframe: Security

[11] Communications Server for z/OS V1R8 TCP/IP Implementation Volume

4: Policy-Based Network Security
[12] Data Encryption for IMS and DB2 Databases User's Guide
http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/topic/com.ibm.i
mstools.deu.doc.ug/decu1a10.pdf?noframes=true
[13] Introduction to RACF: z/OS Version 1 Release 8 RACF Implementation

http://www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/sg24724
8.html?Open
[14] IBM System Storage DS8700 Disk Encryption

http://www.redbooks.ibm.com/redpapers/pdfs/redp4500.pdf
• Informix Security
[14] Informix Security Guide: IBM Informix Dynamic Server v11 Information
Center http://publib.boulder.ibm.com/infocenter/idshelp/v111/index.jsp
[15] Security and Compliance Solutions for IBM Informix Dynamic Server
http://www.redbooks.ibm.com/redbooks.nsf/RedpieceAbstracts/sg24755
6.html?Open
[16] Enhance Informix Dynamic Server Security Using the Pluggable

Authentication Module Framework and JDBC
http://www.ibm.com/developerworks/db2/library/techarticle/dm-
0704anbalagan/
[17] Using the PAM Authentication Method with ESQL/C

http://www.ibm.com/developerworks/db2/zones/informix/library/techar
ticle/0306mathur/0306mathur.html
• Information Management Data Governance Tools
[18] IBM Data Governance Web site

http://www.ibm.com/software/data/db2imstools/solutions/compliance.ht
ml
[19] IBM Database Encryption Expert: Securing data in DB2

ftp://ftp.software.ibm.com/software/data/db2imstools/whitepapers/IMW
14003-USEN-01.pdf
[20] Employing IBM Database Encryption Expert to meet encryption and

access control requirements for the Payment Card Industry Data Security
Standards (PCI DSS)
ftp://ftp.software.ibm.com/software/data/db2imstools/whitepapers/IMW
14002-USEN-01.pdf
[21] IBM Optim Data Privacy

http://www.optimsolution.com/Solutions/DataPrivacy.asp
[22] IBM Database Encryption Expert Web site

http://www.ibm.com/software/data/db2imstools/database-encryption-
expert/
[23] IBM DB2 Audit Management Expert Web site

http://www.ibm.com/software/data/db2imstools/db2tools/db2ame/
[24] IBM DB2 Audit Management Expert for z/OS User's Guide, Version 2
Release 1
http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/topic/com.ibm.d
b2tools.adh.doc.ug/adhugb20.pdf?noframes=true
[25] IBM Tools—All Product Manuals

http://www.ibm.com/software/data/db2imstools/db2tools-
library.html#auditxpertmp-lib
Contributors
Danny Arnold
Paul Bird
DB2 Development
Fred Booker
IBM Optim Solutions Specialist
Curt Cotner
IBM Fellow
Information Management Software
Chris Eaton
Bob Harbus
Bruce Johnson
IBM
Joyce Simmonds
DB2 Information Development
Dwaine Snow
Senior DB2 Technical Evangelist
Kevin Street
Tim Vincent
Chief Architect DB2 LUW
Paul Zikopoulos
Program Director
Worldwide DB2 Technical Evangelism
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other
countries. Consult your local IBM representative for information on the products and services
currently available in your area. Any reference to an IBM product, program, or service is not
intended to state or imply that only that IBM product, program, or service may be used. Any
functionally equivalent product, program, or service that does not infringe any IBM
intellectual property right may be used instead. However, it is the user's responsibility to
evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in
this document. The furnishing of this document does not grant you any license to these
patents. You can send license inquiries, in writing, to:
IBM Director of Licensing

IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where
such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES
CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-
INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do
not allow disclaimer of express or implied warranties in certain transactions, therefore, this
statement may not apply to you.
Without limiting the above disclaimers, IBM provides no representations or warranties

regarding the accuracy, reliability or serviceability of any information or recommendations
provided in this publication, or with respect to any results that may be obtained by the use of
the information or observance of any recommendations provided herein. The information
contained in this document has not been submitted to any formal IBM test and is distributed
AS IS. The use of this information or the implementation of any recommendations or
techniques herein is a customer responsibility and depends on the customer’s ability to
evaluate and integrate them into the customer’s operational environment. While each item
may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee
that the same or similar results will be obtained elsewhere. Anyone attempting to adapt
these techniques to their own environment do so at their own risk.
This document and the information contained herein may be used solely in connection with
the IBM products discussed in this document.
This information could include technical inaccuracies or typographical errors. Changes are
periodically made to the information herein; these changes will be incorporated in new
editions of the publication. IBM may make improvements and/or changes in the product(s)
and/or the program(s) described in this publication at any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only
and do not in any manner serve as an endorsement of those Web sites. The materials at
those Web sites are not part of the materials for this IBM product and use of those Web sites is
at your own risk.
IBM may use or distribute any of the information you supply in any way it believes
appropriate without incurring any obligation to you.
Any performance data contained herein was determined in a controlled environment.

Therefore, the results obtained in other operating environments may vary significantly. Some
measurements may have been made on development-level systems and there is no
guarantee that these measurements will be the same on generally available systems.
Furthermore, some measurements may have been estimated through extrapolation. Actual
results may vary. Users of this document should verify the applicable data for their specific
environment.
Information concerning non-IBM products was obtained from the suppliers of those products,
their published announcements or other publicly available sources. IBM has not tested those
products and cannot confirm the accuracy of performance, compatibility or any other
claims related to non-IBM products. Questions on the capabilities of non-IBM products should
be addressed to the suppliers of those products.
All statements regarding IBM's future direction or intent are subject to change or withdrawal
without notice, and represent goals and objectives only.
This information contains examples of data and reports used in daily business operations. To
illustrate them as completely as possible, the examples include the names of individuals,
companies, brands, and products. All of these names are fictitious and any similarity to the
names and addresses used by an actual business enterprise is entirely coincidental.
COPYRIGHT LICENSE: © Copyright IBM Corporation 2008, 2010. All Rights Reserved.
This information contains sample application programs in source language, which illustrate
programming techniques on various operating platforms. You may copy, modify, and
distribute these sample programs in any form without payment to IBM, for the purposes of
developing, using, marketing or distributing application programs conforming to the
application programming interface for the operating platform for which the sample
programs are written. These examples have not been thoroughly tested under all conditions.
IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these
programs. The sample programs are provided "AS IS", without warranty of any kind. IBM shall
not be liable for any damages arising out of your use of the sample programs.
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International
Business Machines Corporation in the United States, other countries, or both. If these and
other IBM trademarked terms are marked on their first occurrence in this information with a
trademark symbol (® or ™), these symbols indicate U.S. registered or common law
trademarks owned by IBM at the time this information was published. Such trademarks may
also be registered or common law trademarks in other countries. A current list of IBM
trademarks is available on the Web at “Copyright and trademark information” at
www.ibm.com/legal/copytrade.shtml
Windows is a trademark of Microsoft Corporation in the United States, other countries, or

both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.

Best Practices: IBM Data Server Security

Uploaded by

Copyright:

Available Formats

Best Practices: IBM Data Server Security

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Best Practices: IBM Data Server Security

Uploaded by

Copyright:

Available Formats

®

IBM® Data Servers

Last updated: October 2010

Security threats and countermeasures roadmap

• Using authentication and authorization methods that adhere to the principle of

• Limiting access given to PUBLIC

• Remembering to protect staging tables and MQTs

• Using trusted contexts in multi-tier environments

• Encrypting data and backup files at the operating system level

• Using SSL to transmit data securely on the network

• Using operating-system controls to prevent operating-system administrators

Security outside the database

• Physical security: Implement effective badge access to control who can

• Application security: Secure applications running on your system. For example,

• Business controls: Implement rules, processes and practices to govern access to

Assessing your security needs

4. Counter measures and preventative measures: Implement effective measures to

7. Maintenance: Keep everything maintained and secure. Effective security is not a

inevitably it will. Security maintenance should be integrated in your standard

Configuration threats: Threats against configuration are mechanisms whereby the

Executable Threats: Threats against executables are mechanisms whereby database

<category>.#.<threat short name>

Data.1.Connection Exploiting poor An unauthorized user can exploit poor

Data.2.BaseTables Exploiting poor An unauthorized user can exploit poor

For example, leaving the group PUBLIC with

Data.3.OtherTables Exploiting poor An unauthorized user can exploit poor

Relational OLAP cubes

Data.4.CommonUser Loss of identity of Application servers often use a common user

user ID weakens user accountability and the

This also leads to over-granting of privileges to

Data.5.DBAAccess Abusing database By default, DBAs have access to any table in

This is a critical component of “insider abuse”.

Data.6.OSAdminAcc Abusing operating Both a user with OS administrator privileges

They can abuse that privilege by directly

This is a critical component of “insider abuse”.

Data.8.Backups Exploiting poor Many times unauthorized access to data occurs

If left unprotected, data can be accessed

administrator on the production system.

Also, if transaction logs are mirrored or

Data.10.ArchiveLogs Exploiting poor Archived transaction logs contain valuable data

Data.11.Diagnostics Exploiting poor Many diagnostic logs, monitoring output, and

Data.12.Extract Exploiting extracted Data is commonly extracted from the

This threat can be split into different cases

1. Test: When the data is being used in test

numbers or social security numbers.

2. Distribution: When the data is being

Config.1.Files Exploiting poor If the DBMS configuration files are insecure, an

Config.2.DBCreate Exploiting lack of Creating a database in a database management

Config.3.DBEnviron Exploiting poor Poor configuration includes poor database

Audit.1.Config Exploiting poor Unauthorized personnel should not be able to

Unauthorized personnel should not be able to

modify the audit configuration files.

Executable.1.Files Maliciously modifying Data server executable files can be

Also executables and libraries used by stored

Only the user entrusted with installing the

Executable.2.Dirs 2 Exploiting poor If the directories containing the executables or

The tables below document the technical components of the recommended

Linux®, UNIX®, and Windows® platforms:

Data.1.Connection Exploiting poor Use authentication and authorization DB2 or IDS