The document discusses how increasing regulatory compliance is impacting database administration. It outlines several key regulations and how they influence data quality, long-term data retention, database security, auditing, and controls over database administration procedures. Compliance is driving the need for improved data management practices to ensure data is properly protected, retained, and accessible over time. Failure to comply can result in significant fines or prosecution.

1. The Impact of Regulatory Compliance
on Database Administration
Craig S. Mullins
Corporate Technologist
NEON Enterprise Software, Inc.

2. Authors
This presentation was prepared by:
Craig S. Mullins
Corporate Technologist
NEON Enterprise Software, Inc.
14100 Southwest Freeway, Suite 400
Sugar Land, TX 77478
Tel: 281.491.6366
Fax: 281.207.4973
E-mail: craig.mullins@neonesoft.com
This document is protected under the copyright laws of the United States and other countries as an unpublished work. This
document contains information that is proprietary and confidential to NEON Enterprise Software, which shall not be disclosed
outside or duplicated, used, or disclosed in whole or in part for any purpose other than to evaluate NEON Enterprise Software
products. Any use or disclosure in whole or in part of this information without the express written permission of NEON Enterprise
Software is prohibited. © 2006 NEON Enterprise Software (Unpublished). All rights reserved.
2

3. Agenda
An Overview of Government Regulations and Issues
Impacts on Data and Database Management
 Data Quality
 Long-term Data Retention
 Database Security
 Database and Data Access Auditing
 Data Masking
 Controls on DBA Procedures
— Backup & Recovery
— Change Management
 Metadata Management
3

4. Compliance Continues to Exert Pressure
Increasing compliance pressure. Compliance
requirements, such as Sarbanes-Oxley, HIPAA, CA
SB 1386, and the Gramm-Leach-Bliley Act
(GLBA), are driving interest for all enterprises to
take strong security measures to protect
private data. These include initiatives around
data-at-rest encryption, granular auditing,
intrusion detection and prevention, and end-to-
end security measures.
Source: Trends 2006: Database Management Systems, Forrester Research
4

5. Regulatory Compliance
GLB
HIPAA
PCI-DSS
Basel II
Sarbanes-Oxley
CA SB1386
Federal Information Security Management Act
“Red Flag” Rules (FRCA)
5

6. Legislation & Compliance
The Gramm-Leach-Bliley Act (GLB), is a federal law enacted in the
United States to control the ways that financial institutions deal with the
private information of individuals. The Act regulates the collection and
disclosure of private financial information; stipulates safeguards requiring
security programs; and prohibits the practice of pretexting.
HIPAA (Health Insurance Portability and Accountability Act) creates
national standards to protect individuals' medical records & personal
health information. The Privacy Rule provides that, in general, a covered
entity may not use or disclose an individual’s healthcare information
without permission except for treatment, payment, or healthcare
operations.
PCI DSS (Payment Card Industry Data Security Standard) includes
requirements for security management, policies, procedures, network
architecture, software design and other critical protective measures. This
comprehensive standard is intended to help organizations proactively
protect customer account data.
6

7. Legislation & Compliance
Basel II is an international banking regulation the goal of which is to
produce uniformity in the way banks and banking regulators approach
risk management across national borders.
The Sarbanes-Oxley Act (SOX) establishes standards for all U.S. public
company boards, management, and public accounting firms. The
Section Public Company Accounting Oversight Board (PCAOB) was created by
404 SOX to oversee auditors of public companies. The primary goals of SOX
were to strengthen and restore public confidence in corporate
accountability and to improve executive responsibility.
The California Security Breach Notification Law (CA SB 1386)
requires companies to notify California customers if PII maintained in
computerized data files have been compromised by unauthorized
access.
7

8. FISMA: Federal Information Security Mgmt Act
Title III of the E-Government Act, FISMA basically states that
federal agencies, contractors, and any entity that supports
them, must maintain security commensurate with potential
risk.
The Fair and Accurate Credit Transactions Act of 2003
(FACTA), requires all federally regulated financial institutions
to be in full compliance by Nov. 1, 2008. This is also known as
the "Red Flag" rules.
 Requires that financial institutions and creditors develop and
deploy an Identity Theft Prevention Program for combating ID
theft on new and existing accounts.
8

9. Other Regulations & Issues?
And, there are more regulations to consider, for example:
 the USA Patriot Act
 Can SPAM Act of 2003
 Telecommunications Act of 1996
 The Data Quality Act
And, there are more regulations to contend with; based
upon your industry, location, etc.
As well as, new regulations that will continue to be written
by government and imposed over time…
Regulations have brought to light some of the personal
financial information that has been compromised (stolen)
 More on this later…
9

10. Regulatory Compliance is International
Country Examples of Regulations
Australia Commonwealth Government’s Information Exchange Steering Committee, Evidence
Act 1995, more than 80 acts governing retention requirements
Brazil Electronic Government Programme, EU GMP Directive 1/356/EEC-9
Canada Bill 198, Competition Act,
France Model Requirements for the Management of Electronic Records, EU Directive
95/46/EC
Germany Federal Data Protection Act, Model Requirements for the Management of Electronic
Records, EU Directive 95/46/EC
Japan Personal Data Protection Bill, J-SOX
Switzerland Swiss Code of Obligations articles 957 and 962
United Data Protection Act, Civil Evidence Act 1995, Police and Criminal Evidence Act
Kingdom 1984, Employment Practices Data Protection Code, Combined Code on Corporate
Governance 2003
10

11. Regulations Tracked by Gartner
11

12. Regulations Impacting Security
Governance vs. Privacy
Governance Privacy
• • EU DPD
Basel II
• • AU/NZ NPP
Sarbanes Oxley
• • SB 1386/AB 1950
OFAC
• • GLBA
Turnbull Report
• HIPAA
• PCI
• FCRA -- “Red Flag”
Protect and control the process Protect the data
12

13. http://www.unifiedcompliance.com/it_impact_zones/
13

14. Regulatory Compliance and…
Impact: upper-level management is keenly aware of the need to
comply, if not all of the details that involves.
Prosecution: being successfully prosecuted (see next slide) can result
in huge fines and even imprisonment.
Cost: cost of complete compliance can be significant, but so can the
cost of non-compliance. No longer easier just to ignore problems.
Durability: although there have been discussions about scaling back
some laws (e.g. SOX), increasing regulations and therefore
increasing time, effort, and capital will be spent on compliance.
 That is, the issue will not just disappear if you ignore it long enough!
But, at the end of the day, ensuring exact compliance can be a gray
area.
14

15. The Reality of Prosecution
Enron – In May 25, 2006 Ken Lay (former CEO) was found guilty of 10 counts against him.
Because each count carried a maximum 5- to 10-year sentence, Lay could have faced 20 to
30 years in prison. However, he died while vacationing in about three and a half months
before his scheduled sentencing. Jeff Skilling (another former CEO) was found guilty of 19
out of 28 counts against him, including one count of conspiracy, one count of insider
trading. Skilling was sentenced to 24 years and 4 months in federal prison.
WorldCom – In June 2005, 800,000 investors were awarded $6 billion in settlements; the
payouts will be funded by the defendants in the case, including investment banks, audit
ROI? firms, and the former directors of WolrdCom. The judge in the case noted that the
settlements were “of historic proportions.” Additionally, Bernard Ebbers, former CEO of
WorldCom, was convicted of fraud and sentenced to 25 years in prison.
Tyco – In September 2005, Dennis Kozlowski (former Tyco CEO) and Mark Swartz (former
Tyco CFO) were sentenced to 8 to 25 years in prison for stealing hundreds of millions of
dollars from Tyco. Additionally, Kozlowski had to pay $70 million in restitution; Swartz $35
million.
Adelphia – In June 2005, John Rigas (founder and former CEO) was sentenced to 15 years
in prison; his son, Tony, was also convicted of bank fraud, securities fraud, & conspiracy -
he received a 20 year sentence.
HealthSouth – In March 2005, Richard Scrushy, founder and former CEO, was acquitted of
charges relating to 1 $2.7 billion earnings over-statement. Scrushy blamed his subordinates
for the fraud…
15

16. But Business Benefits Do Exist
Source: Unisphere Research, OAUG Automating Compliance 2006 Survey
16

17. Why Should DBAs Care About Compliance?
Compliance starts with the CEO…
 But the CEO relies on the CIO to ensure that IT
processes are compliant
 And the CIO relies on the IT managers
 One of whom (DBA Manager) controls the database
systems
— Who relies on DBAs to ensure that data is protected and
controlled.
17

18. So What Do Data Mgmt Folks Need to Do?
Implement standard controls and methods for
improving:
 Data Quality
 Long-term Data Retention
 Database Security
 Database and Data Access Auditing
 Data Masking
 Backup & Recovery
18
 DBA Procedures

19. Issue #1: Data Quality
A recent SAS/Risk Waters
Group survey indicated
that 93% of respondents
had experienced losses of
$10 million in one year…
 And 21% of respondents said
that at some point, their
company suffered a loss
between $10,000 and
$1,000,000 in a single day.
The prime reasons given
for such losses were
incomplete, inaccurate or
obsolete data, and
inadequate processes. Source: Gartner (April 2006)
19

20. Examples of Data Quality Regulations
The Data Quality Act
 Careful, it sounds better than it actually is.
 Written by an industry lobbyist and slipped into a giant
appropriations bill in 2000 without congressional discussion
or debate
 Basically consists of two sentences directing the OMB to
ensure that all information disseminated by the federal
government is reliable.
Sarbanes-Oxley
 Financial reports must be ACCURATE
 Without good data quality this is impossible.
20

21. Data Quality: Is it Really a Major Concern?
How good is your data quality?
Estimates show that, on average, data quality is suspect:
 Payroll record changes have a 1% error rate;
 Billing records have a 2-7% error rate, and;
 The error rate for credit records: as high as 30%.
Source: T.C. Redman, Data Quality: Management and Technology,
(New York, Bantam Books).
Similar studies in Computer World and the Wall Street Journal
back up the notion of overall poor data quality.
 W.M. Bulkeley, "Databases Are Plagued by Reign of Error," The Wall Street Journal, 26
May 1992, B2.
 B. Knight, "The Data Pollution Problem," ComputerWorld, 28 September 1992, 81-84.
21

22. The High Cost of Poor Quality Data
“Poor data quality costs the typical company at
least ten percent (10%) of revenue; twenty
percent (20%) is probably a better estimate.”
Source: Thomas C. Redman, “Data: An Unfolding Quality Disaster”,
DMReview Magazine, August 2004
Valid &
Accurate?
22

23. Database Constraints
By building constraints into the database, overall
data quality may be improved:
 Referential Integrity
— Primary Key
— Foreign Key(s)
 UNIQUE constraints
 CHECK constraints
 Triggers
 Domains
23

24. Data Profiling
With data profiling, you can:
 Discover the quality, characteristics and potential
problems of information before beginning data-driven
projects
 Drastically reduce the time and resources required to
find problematic data
 Allow business analysts and data stewards to have
more control on the maintenance and management
of enterprise data
 Catalog and analyze metadata and discover metadata
relationships
24

25. Issue #2: Long-Term Data Retention
The average installed storage
capacity at Fortune 1000
corporations has grown from
198TB to 680TB in less than
two years.
This is a growth rate of more
than 340% as capacity
continues to double every 10
months.
Source: TIP (TheInfoPro). 2006 www.theinfopro.net
25

26. More Data, Stored for Longer Durations
Data Retention Issues:
Volume of data (125% CAGR)
Length of retention
n requirement
io
ct
Amount of Data
e
r ot Varied types of data
P
e
a nc Security issues
i
pl
C om
0 Time Required 30+ Yrs
26

27. Data Retention Drives Data(base) Archiving
Data Retention Requirements refer to the length
of time you need to keep data
Determined by laws – regulatory compliance

 More than 150 state and federal laws
 Dramatically increasing retention periods for
corporate data
Determined by business needs

 Reduce operational costs
 Large volumes of data interfere with operations:
performance, backup/recovery, etc.
 Isolate content from changes
27
 Protect archived data from

28. Regulatory Compliance & Data
Retention Requirements
28

29. Can You Read This?
29

30. E-Discovery
Electronic evidence is the predominant form of discovery
today. (Gartner,Research Note G00136366)
Electronic evidence could encompass anything that is
stored anywhere. (Gartner,Research Note G00133224)
When data is being collected (for e-discovery) it is
imperative that it is not changed in any way. Metadata
must be preserved… (Gartner,Research Note G00133224)
Gartner Strategic Planning Assumption: Through 2007,
more than half of IT organizations and in-house legal
departments will lack the people and the appropriate skills
to handle electronic discovery requirements (0.8
probability). (Gartner,Research Note G00131014)
30

31. E-Discovery and the FRCP
Federal Rules of Civil Procedure, Rule 34b
 Took effect December 2006
 A party who produces documents for inspection
shall produce them . . . as they are kept in the
usual course of business..."
 The amended rules state that requested information
must be turned over within 120 days after a
complaint has been served.
So data stored in database systems must be able
to be produced in electronic form.
31

32. What “Solutions” Are Out There?
 Keep Data in Operational Database
— Problems with authenticity of large amounts of
data over long retention times
— Operational performance degradation
 Store Data in UNLOAD files (or backups)
— Problems with schema change and reading archived data
— Using backups poses even more serious problems
 Move Data to a Parallel Reference Database
— Combines problems of the previous two
 Move Data to a Database Archive
32

33. Components of a Database Archiving Solution
Database Archiving: The process of removing
selected data records from operational databases
Purge that are not expected to be referenced again and
Databases
storing them in an archive data store where they
can be retrieved if needed. Data Data
Extract Recall
Metadata
Archive data store and retrieve
capture, design,
maintenance
Archive data
Archive
query and
access
metadata data
policies metadata
history
Archive
administration
33

34. Issue #3: Data and Database Security
75% of enterprises do not have a DBMS
security plan.
Source: Forrester Research,
“Your DBMS Strategy 2005”
A single intrusion that compromises
private data can cause immense damage
to the reputation of an enterprise — and
in some cases financial damage as well.
Source: Forrester Research,
“Comprehensive Database Security…”
Database configurations are not secure
by default, and they often require
specialized knowledge and extra effort to
ensure that configuration options are set
in the most secure manner possible.
Source: Forrester Research,
“Comprehensive Database Security…”
34

35. Obstacles to Database Security
Source: Forrester Research,
“Comprehensive Database Security…”
35

36. Database Security By the Numbers
s 67% of 1,100 security pros said securing databases was
an important or very important challenge for 2008
— #1 in a list of 13 data protection initiatives
s 45% of security pros will spend more time on data
protection in 2008 vs. 2007.
— #3 on a list of 19 security activities
s 41% will spend more time on database security
specifically
Source: TechTarget
36

37. What is a Data Breach?
37

38. Data Breaches: A Threat to Your Data
Privacy Rights Clearinghouse
http://www.privacyrights.org/ar/ChronDataBreaches.htm
Since 2005:
 In excess of 230 million total records containing sensitive
personal information were exposed due to data security
breaches…
— ChoicePoint: (Feb 15, 2005) – data on 165,000 customers breached
— Since then, there have been 230,454,030 total records breached that
contained sensitive personal information*
* As of June 30, 2008
38
* As of Feb 27, 2007, reported by http://www.privacyrights.org/ar/ChronDataBreaches.htm

39. How Prevalent is this Problem?
68% of companies are losing sensitive data or having it stolen
out from under them six times a year
An additional 20%
are losing sensitive
data 22 times or
more per year.
Sources: eWeek, March 3, 2007
IT Policy Compliance Group
http://www.eweek.com/c/a/Desktops-and-Notebooks/Report-Some-Companies-Lose-Data-Six-Times-a-Year/
39

40. The Cost of a Data Breach
According to Forrester Research, the
average cost per record is between
$90 and $305
According to the Ponemon Institute,
the average cost per lost customer
record is $182
 Average cost per incident: $5 million
Or use the Data Loss Calculator, free on the web
at http://www.tech-404.com/calculator.html
40

41. Most Prevalent Causes of Data Loss
41

42. Database Security Issues in a Nutshell
Authentication
 Who is it?
Authorization
 Who can do it?
Encryption
 Who can see it?
Audit
 Who did it?
42

43. Security From a DB2 Perspective
43

44. 44

45. Database Security
Who has access to high-level “roles”:
Install SYSADM, SYSADM, SYSCTRL, DBADM, etc.
Auditors will have issues with this, but it is
difficult, if not impossible, to remove.
Do any applications require DBA-level authority?
Why?
Security monitoring
 Data Access Auditing (more on this in a moment)
 Additional tools
45

46. SYSADM and Install SYSADM
Install SYSADM bypasses the DB2 Catalog when checking for
privileges.
 So, there are no limits on what a user with Install
SYSADM authority can do.
 And it can only be removed by changing DSNZPARMs
 Basically, needed for catalog and system “stuff”
SYSADM is almost as powerful, but:
 It can be revoked
 Biggest problem for auditors: SYSADM has access to
all data in all tables.
46

47. Suggestions
• Limit the number of SYSADMs
 And audit everything those users do.
• Consider associating Install SYSADM with a
group (RACF)
 Authids that absolutely need Install SYSADM can be
connected to the group using secondary authids.
• Similar issues with SYSOPR and Install SYSOPR
47

48. Data Encryption Considerations
California's SB 1386 protects personally identifiable
information; obviously it doesn't matter if encrypted data
becomes public since it's near impossible to decrypt.
Source: “Encryption May Help Regulatory Compliance”
Edmund X. DeJesus, SearchSecurity.com
Types of encryption
 At Rest
 In Transit
Issues
 Performance
— Encrypting and decrypting data consumes CPU
 Applications may need to be changed
— See next slide for DB2 V8 encryption functions
48

49. DB2 V8: Encryption / Decryption
Encryption: to encrypt the data for a column
ENCRYPT_TDES(string, password, hint)
 ENCRYPT_TDES [can use ENCRYPT() as a synonym for compatibility]
Exit  Triple DES cipher block chaining (CPC) encryption algorithm
Routine? — Not the same algorithm used by DB2 on other platforms
 128-bit secret key derived from password using MD5 hash
INSERT INTO EMP (SSN)
VALUES(ENCRYPT('289-46-8832','TARZAN','? AND JANE'));
Decryption: to decrypt the encrypted data for a column
DECRYPT_BIT(), DECRYPT_CHAR(), DECRYPT_DB()
 Can only decrypt expressions encrypted using ENCRYPT_TDES
— Can have a different password for each row if needed
 Without the password, there is no way to decrypt
SELECT DECRYPT_BIT(SSN,'TARZAN') AS SSN FROM EMP;
49

50. DB2 9 for z/OS: Encryption in Transit
 DB2 9 supports SSL by implementing z/OS
Communications Server IP Application Transparent
Transport Layer Security (AT-TLS)
 AT-TLS performs transport layer security on behalf of
DB2 for z/OS by invoking the z/OS system SSL in the
TCP layer of the TCP/IP stack
 When acting as a requester, DB2 for z/OS can request
a connection using the secure port of another DB2
subsystem
 When acting as a server, and from within a trusted
context SSL encryption can be required for the
connection
50

51. Auditing
In a world replete with
regulations and threats,
organizations have to go well
beyond securing their data.
Essentially, they have to
perpetually monitor their data in
order to know who or what did
exactly what, when and how –- to
all their data.
Source: Audit the Data – or Else:
Un-audited Data Access Puts Business at High Risk.
Baroudi-Bloor, 2004.
HIPAA, for example, requires
patients to be informed any time
someone has even looked at their
data.
51

52. Regulations Impacting Database Auditing
ISO
Audit CobiT PCI CMS 17799
NIST
HIPAA GLBA NERC 800-53
(SOX) DSS ARS (Basel
Requirements II)
(FISMA)
1. Access to Sensitive

Data (Successful/Failed     
(OMB)
SELECTs)
2. Schema Changes (DDL)
      
(Create/Drop/Alter Tables, etc.)
3. Data Changes (DML)
  
(Insert, Update, Delete)
4. Security Exceptions
       
(Failed logins, SQL errors, etc.)
5. Accounts, Roles &
       
Permissions (Entitlements)
52

53. Database and Data Access Auditing
An audit is an evaluation of an organization,
system, process, project or product.
 Database Control Auditing
— Who can do what (who has the authority)
 GRANT, REVOKE, RACF/ACF2/Top Secret
 Data Access Auditing
— Who did do what
— INSERT, UPDATE, DELETE
— SELECT
— Database Object Auditing
 DCL: GRANT, REVOKE
53
 DDL: CREATE, DROP

54. Key Stakeholder Requirements
SECURITY
OPERATIONS
 Real-time policies  Separation of duties  Minimal impact
 Secure audit trail  Best practices reports  Change management
 Data mining &  Automated controls  Performance
forensics
100% Visibility &
Unified View
54

55. How to Audit Database Access?
1. Audit trails in tables
2. Native DBMS traces
3. Log-based
4. Network sniffing
5. Capture requests at the server
55

56. Audit Trails in Tables
Sometimes the first “knee jerk” reaction is to add
“audit columns” to tables, such as:
LAST_MODIFIED_DATE
Auditors don’t like this; it is a problem because:
 Audit trails should be kept outside of the database
(because if you delete the row you lose the audit data)
 How can you guarantee that the last modified data is
completely accurate?
— Couldn’t someone have set it by accident (or
nefariously)?
56

57. Native DBMS Audit
The native DBMS audit capability may not be optimal:
 Separation of duties – logging typically is turned on
and off by DBAs, who need to be audited
 Overhead – many require traces to be started,
which can consume precious resources (as much as
10% overhead?)
 Comprehensive capture – may not capture
everything that needs to be captured for
compliance
57

58. DB2 Audit Trace
The DB2 Audit Trace can record:
 Changes in authorization IDs
 Changes to the structure of data (such as dropping a table)
 Changes to data values (such as updating or inserting data)
 Access attempts by unauthorized IDs
 Results of GRANT statements and REVOKE statements
 Mapping of Kerberos security tickets to IDs
 Other activities that are of interest to auditors
Audit Trace Classes are listed on page 287, Admin Guide
CREATE TABLE . . . AUDIT ALL . . .
58
-START TRACE (AUDIT) CLASS (4,6) DEST (GTF) LOCATION (*)

59. Limitations of the audit trace
The audit trace doesn’t record everything:
s Auditing takes place only when the audit trace is on.
s The trace does not record old data after it is changed (the log records old data).
s If an agent or transaction accesses a table more than once in a single unit of
recovery, the audit trace records only the first access.
s The audit trace does not record accesses if you do not start the audit trace for
the appropriate class of events.
s The audit trace does not audit some utilities. The trace audits the first access of
a table with the LOAD utility, but it does not audit access by the COPY,
RECOVER, and REPAIR utilities. The audit trace does not audit access by stand-
alone utilities, such as DSN1CHKR and DSN1PRNT.
s The trace audits only the tables that you specifically choose to audit.
s You cannot audit access to auxiliary tables.
s You cannot audit the catalog tables because you cannot create
59
or alter catalog tables.

60. What About Using the Log?
Database transaction log(s) capture ALL* changes made to data.
DBMS
Database
SQL
Changes
Transaction Log(s)
60
*
Well, maybe not all changes, all the time.

61. Issues With Database Log Auditing & Analysis
 Log format is proprietary
 Volume can be an issue
 Easy access to online and archive logs?
— But how long do you keep your archive logs?
 Dual usage of data could cause problems?
— Recovery and protection
— Audit
 Tracks database modifications, but what about reads?
— Transaction logs do not record information about SELECT.
 And what about non-logged operations?
— LOAD LOG NO, REORG LOG NO
— Non-logged table spaces (new feature in DB2 9 for z/OS)
 Cannot invoke real-time actions using log-based auditing
61

62. Network Capture (aka Network Sniffers)
Database auditing via network sniffing captures SQL
requests as they go across the network.
 But not all requests go across the wire
— Mainframe applications
— DBA access directly on the server
 Be careful, many third-party database auditing solutions
use this approach
62

63. A Better Approach
 Audit database calls at the server
— Capture all SQL requests at the server
— All SQL access is audited, not just network calls
— Retain all pertinent audited information
 No reliance on the DBMS
— No need to keep the active/archive log files
— No need to start a DBMS trace
— No need to modify the database schema
— Must be selective, comprehensive, and non-invasive
— Requires purchasing additional ISV software
63

64. Server-Based Database Auditing Requirements
Surveillance Mechanism
 Selective – must be rules-based to enable the
capture of audit details only on the specific
data that requires auditing.
 Comprehensive – must be able to capture the
complete scenario of auditable information.
 Non-invasive – must be able to audit access to
data without incurring expensive performance
degradation.
64

65. Auditing Has to be at the Server Level
If you are not capturing all pertinent access
requests at the server level, nefarious users can
sneak in and not be caught.
65

66. On the Need to Monitor Privileged Users
66

67. Data Masking
67

68. The Problem
Data is required to test application designs.
 Data (or reports) may also need to be sent to other individuals,
or organizations, on an on-going basis for various purposes.
Some of the data is sensitive and should not be
accessible by programmers:
 PII such as SSN, salary, credit card details, etc.
Referential integrity must be maintained in test,
even as data values are changed.
68

69. The Solution
Data masking is the process of protecting
sensitive information in non-production databases
from inappropriate visibility.
Valid production data is replaced with useable,
referentially-intact but incorrect and invalid data.
After masking, the test data is usable just like
production; but the information content is secure.
 Masking in the database or to the reports…
May need to create and populate test data from
scratch, as well as sanitize existing information.
69

70. Data Masking in action
Masking must change names, credit card and telephone numbers
(invalid), e-mail addresses (invalid), postal addresses (including
street names, zip codes, and postal codes), false company
names, and so on.
191-64-9180 275-99-0194
Craig S. Mullins John Q. Public
Pittsburgh, PA 15230
Sugar Land, TX 77478
70

71. What PII Might Need to be Masked?
71

72. How Data Masking Protects Data
If the data has been sanitized by
masking it, it won’t matter if
thieves gain access to it.
72

73. Management & Admin Procedures
Are changes made to your
database environment using
standard methods and in a
controlled manner?
Are your databases properly
backed up and recoverable
within the timeframe
mandated by your business
(and any regulations)?
73

74. CobiT and Backup & Recovery
COBIT and Recoverability
DS1 Define and Manage Service Levels
Recovery Time Objectives = recovery SLAs
DS4 Ensure Continuous Service
Prove recoverability and therefore, data availability
DS11 Manage Data
Ensures back ups are available for recovery
74

75. CobiT and Change Management
Control Objectives
 Changes to data structures are authorized, made in
accordance with design specifications and are
implemented in a timely manner.
 Changes to data structures are assessed for their impact
on financial reporting processes.
“Unauthorized change is one of the best (and worst) ways to get
your auditor’s attention.”
Source: Scheffy, Brasche, & Greene,
IT Compliance for Dummies,
(2005, Wiley, ISBN 0-471-75280-0)
75

76. Compliance Requirement for
Database Change Management
Changes to the database are widely communicated, and their impacts are known beforehand.
Installation and maintenance procedure documentation for the DBMS is current.
Data structures are defined and built as the designer intended them to be.
Data structure changes are thoroughly tested.
Users are apprised, and trained if necessary, when database changes imply a change in
application behavior.
The table and column business definitions are current and widely known.
The right people are involved throughout the application development and operational cycles.
Any in-house tools are maintained and configured in a disciplined way.
Application impacts are known prior to the migration of database changes to production.
Performance is maintained at predefined and acceptable levels.
The database change request and evaluation system is rational.
Turn-around time on database changes is predictable.
Any change to the database can be reversed.
Database structure documentation is maintained.
Database system software documentation is maintained.
Migration through development, test, and especially, production environments is rational.
Security controls for data access is appropriate and maintained.
Database reorganizations are planned to minimize business disruption.
76 Source: SOX Requirements for DBAs in Plain English by James McQuade
http://www.dbazine.com/ofinterest/oi-articles/mcquade2

77. Database Change Management
Databases protected with controls to prevent unauthorized changes
 Proper security for DBAs - including access to tools
Ensure controls maintained as changes occur in applications, software,
databases, personnel
 Maintain user ids, roles, access
 Ability for replacement personnel to perform work
 Test processes
 Change control logs to prove what you said was done, has been done
 Backout procedures
 Reduce system disruptions
 Accurate and timely reporting of information
Routine, non-routine, emergency process defined and documented
 Complex and trivial changes follow the same procedures?
77

78. And it all Requires…
As data volume expands and more regulations hit
the books, metadata will increase in importance
 Metadata: data about the data
 Metadata characterizes data. It is used to provide
documentation such that data can be understood and
more readily consumed by your organization.
Metadata answers the who, what, when, where,
why, and how questions for users of the data.
Data without metadata is meaningless

Consider: 27, 010110, JAN
78

79. Data Categorization
Data categorization is critical
 Metadata is required to place the data into proper
categories for determining which regulations apply
— Financial data  SOX
— Health care data  HIPAA
— Etc.
 Some data will apply to multiple regulations
 Who does this now at your company? Anyone?
79

80. Convergence of DBA and DM
 Database Administration  Data Management
— Backup/Recovery — Database Security
— Disaster Recovery — Data Privacy Protection
— Reorganization — Data Quality Improvement
— Performance Monitoring — Data Quality Monitoring
— Application Call Level Tuning — Database Archiving
— Data Structure Tuning — Data Extraction
— Capacity Planning — Metadata Management
Managing the database environment Managing the content and uses of data
80

81. So, What is the Impact of Regulatory Compliance?
Data Management vs. Database Administration
 Data Governance
Business acumen vs. bits-and-bytes
 Can’t abandon technical skills, but must add more
soft skills to your bag of tricks
Communication and Inter-organizational
Cooperation
 IT, Lines of Business, Legal
81

82. Forecast: DBA challenges
Performance and tuning
Patch/upgrade
B&R
Security
2002 2003 2004 2005 2006 2007 2008 2009 2010
82

83. Challenges: Compliance & Database Management
Source: Unisphere Research, OAUG Automating Compliance 2006 Survey
83

84. Web References
Industry Organizations and References
 www.itcinstitute.com
 www.isaca.org
 www.coso.org
 www.aicpa.org/news/2004/2004_0929.htm
 www.auditnet.org/sox.htm
 www.itgi.org
 www.sox-online.com/coso_cobit.html
 www.bis.org/publ/bcbs107.htm - (Basel II)
 www.snia-dmf.org/100year
 https://www.pcisecuritystandards.org/
84

85. Some Recommended Books
 Implementing Database Security and Auditing by Ron
Ben Natan (2005, Elsevier Digital Press, ISBN: 1-55558-334-2)
 Manager’s Guide to Compliance by Anthony Tarantino
(2006, John Wiley & Sons, ISBN: 0-471-79257-8)
 IT Compliance for Dummies by Clark Scheffy, Randy
Brasche, & David Greene (2005, Wiley Publishing, Inc., ISBN:
0-471-75280-0)
 Cryptography in the Database: The Last Line of
Defense by Kevin Kenan (2006, Addison-Wesley, ISBN:
0321-32073-5)
 Electronic Evidence and Discovery: What Every
Lawyer Should Know by Michele C.S. Lange and
Kristin M. Nimsger (2004, ABA Publishing, ISBN:
1-59031-334-8)
85

86. Craig S. Mullins
NEON Enterprise Software
craig.mullins@neonesoft.com
www.neonesoft.com
www.craigsmullins.com
www.DB2portal.com
86