data breach protection from a db2 perspective

56
May 20, 2008 • 04:00 p.m. – 05:00 p.m. Platform: Multi-platform Craig S. Mullins NEON Enterprise Software, Inc. Session: H08 Data Breach Protection From a DB2 Perspective

Upload: craig-mullins

Post on 05-Dec-2014

1.234 views

Category:

Technology


5 download

DESCRIPTION

 

TRANSCRIPT

Page 1: Data breach protection from a  DB2 perspective

May 20, 2008 • 04:00 p.m. – 05:00 p.m.Platform: Multi-platform

Craig S. MullinsNEON Enterprise Software, Inc.

Session: H08

Data Breach ProtectionFrom a DB2 Perspective

Page 2: Data breach protection from a  DB2 perspective

2

Objectives• Understand the various laws that have been enacted to combat

data breaches and the trends toward increasing legislation • Learn how to calculate the cost of a data breach based on

industry best practices and research from leading analysts • Gain knowledge of several best practices for managing data with

the goal of protecting the data from surreptitious or nefarious access (and/or modification)

• Learn about techniques for securing, encrypting, and masking data to minimize exposure of critical data

• Uncover new data best practices for auditing access to database data and for protecting data stored for long-term retention

Page 3: Data breach protection from a  DB2 perspective

3

Agenda

• Objectives

• Data Breach Overview

• Legislation and Compliance Issues

• Examples and Resources

• The Cost of a Data Breach

• Best Practices for Data Protection • Data Masking • Database Security & Encryption • Data Access Auditing • Database Archiving • Metadata Management

• Synopsis

Page 4: Data breach protection from a  DB2 perspective

4

What is a Data Breach?

Page 5: Data breach protection from a  DB2 perspective

5

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.

Page 6: Data breach protection from a  DB2 perspective

6

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 Public Company Accounting Oversight Board (PCAOB) was created by 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.

Page 7: Data breach protection from a  DB2 perspective

7

Personal Data Privacy and Security Act of 2007

Page 8: Data breach protection from a  DB2 perspective

8

Impact of The Personal Data Privacy and Security Act • Defines regulatory requirements for data brokers, defined as any

company that is "collecting, transmitting, or otherwise providing personally identifiable information" (PII) of 5,000 or more people that are not customers or employees.

• New penalties for database intrusions. • Fines and 10 years in prison for trespassing in a "data broker's" system;• Five years in prison for "willfully" concealing certain types of breaches.

• Mandate a "comprehensive personal data privacy and security program" for most businesses and individuals acting as sole proprietors (similar to what Gramm-Leach-Bliley Act required).

• Requires notification if a computer security breach "impacts more than 10,000 individuals."

• Requires review of federal sentencing guidelines for misuses of PII, and provides grants to states to for enforcement of ID fraud crimes.

• Create additional "privacy impact assessments" when a federal agency relies on a commercial database consisting "primarily" of information on U.S. citizens.

Page 9: Data breach protection from a  DB2 perspective

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 • Federal Information Security Mgmt Act

• Different regulations to contend with based upon your industry, location, etc.

• And new regulations will continue to be written by government and imposed over time.

• These regulations have brought to light big problems• More on this later…

Page 10: Data breach protection from a  DB2 perspective

10

http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=304931

Page 11: Data breach protection from a  DB2 perspective

11

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 Kingdom

Data Protection Act, Civil Evidence Act 1995, Police and Criminal Evidence Act 1984, Employment Practices Data Protection Code, Combined Code on Corporate Governance 2003

Page 12: Data breach protection from a  DB2 perspective

12

http://www.itcinstitute.com/ucp/index.aspx

Page 13: Data breach protection from a  DB2 perspective

13

Examples of Data Breaches

OK, so let’s look at:• A few examples of

recent data breaches

• A resource for finding and tracking data breaches

Page 14: Data breach protection from a  DB2 perspective

14

http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9026166

Page 15: Data breach protection from a  DB2 perspective

15

http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9014782

Page 16: Data breach protection from a  DB2 perspective

16

http://www.infoworld.com/article/08/01/08/Sears-sued-over-privacy-breach_1.html?source=NLC-BIZINTELL&cgd=2008-01-09

Page 17: Data breach protection from a  DB2 perspective

17

Privacy Rights Clearinghouse

• The Chronology of Data Breaches is a very useful web resource for tracking just how pervasive this problem is:• http://www.privacyrights.org/ar/ChronDataBreaches.htm

Page 18: Data breach protection from a  DB2 perspective

18

Total Number of Records Breached

• According to the Privacy Rights Clearinghouse, the total number of records containing sensitive personal information involved in security breaches in the U.S. is:

218,621,856

As of February 29, 2008

Page 19: Data breach protection from a  DB2 perspective

19

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/

Page 20: Data breach protection from a  DB2 perspective

20

What is the Payoff?

How Stolen Data is Used

• Once breached, there are many potential “uses” (and misuses) of personally identifiable information (PII).

Page 21: Data breach protection from a  DB2 perspective

21

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

Page 22: Data breach protection from a  DB2 perspective

22

Data Breach Cost Breakdown

• Tangible costs• Lost employee productivity• Stock price• Lost customers

• Studies have shown that most customers would take their business elsewhere if they received two or more security breach notices.

• Regulatory fines

Page 23: Data breach protection from a  DB2 perspective

23

A Costly Example: ChoicePoint• February 2005: Bogus accounts established by ID thieves. The

initial number of affected records was estimated at 145,000; later revised to 163,000.

• January 2006: The Federal Trade Commission assessed a $10 million civil penalty against the company in January 2006 for violations of the Fair Credit Reporting Act.

• May 2007: ChoicePoint reached an agreement with the attorneys general in 43 states and DC. It promised to make changes in the way it screens and authenticates new customers. The company also agreed to pay a total of $500,000 to the states to cover legal fees and costs.

• January 2008: ChoicePoint agreed to pay $10 million to settle the last remaining class-action lawsuit filed against the company in connection with a data breach disclosed in early 2005 in which the personal information of more than 160,000 people was exposed.

Page 24: Data breach protection from a  DB2 perspective

24

So What’s Next?

Compliance Drives Security Initiatives • 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: Forrester Research (Trends 2006: Database Management Systems)

Page 25: Data breach protection from a  DB2 perspective

25

Security Best PracticesFor Preventing Data Breaches

• Data Masking

• Database Security & Encryption

• Data Access Auditing

• Database Archiving

• Metadata Management

Page 26: Data breach protection from a  DB2 perspective

26

Data Masking

Page 27: Data breach protection from a  DB2 perspective

27

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.

Page 28: Data breach protection from a  DB2 perspective

28

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 database is usable just like production; but the information content is secure.

• May need to create and populate test data from scratch, as well as sanitize existing information.

Page 29: Data breach protection from a  DB2 perspective

29

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

Craig S. Mullins

Sugar Land, TX 77478

275-99-0194

John Q. Public

Pittsburgh, PA 15230

Page 30: Data breach protection from a  DB2 perspective

30

What PII Might Need to be Masked?

Page 31: Data breach protection from a  DB2 perspective

31

How Data Masking Protects Against Data Breaches

• If the data has been sanitized by masking it, it won’t matter if thieves gain access to it.

Page 32: Data breach protection from a  DB2 perspective

32

Database Security & Encryption

Page 33: Data breach protection from a  DB2 perspective

33

Database Security in a Nutshell

• Authentication• Who is it?

• Authorization• Who can do it?

• Encryption• Who can see it?

• Audit• Who did it?

Page 34: Data breach protection from a  DB2 perspective

34

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.

• Types of encryption• At Rest• In Transit

• Issues• Performance

• Encrypting and decrypting data consumes CPU• Access paths

• Applications may need to be changed• See next slide for DB2 V8 encryption functions

Source: “Encryption May Help Regulatory Compliance” Edmund X. DeJesus, SearchSecurity.com

Page 35: Data breach protection from a  DB2 perspective

35

DB2 V8: Encryption / Decryption• Encryption: to encrypt the data for a column

• ENCRYPT_TDES [can use ENCRYPT() as a synonym]• Triple DES cipher block chaining (CPC) encryption algorithm

• Not the same algorithm used by DB2 on other platforms

• 128-bit secret key derived from password using MD5 hash

• Decryption: to decrypt the encrypted data for a column

• 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

ENCRYPT_TDES(string, password, hint)

DECRYPT_BIT(), DECRYPT_CHAR(), DECRYPT_DB()

INSERT INTO EMP (SSN)VALUES(ENCRYPT('289-46-8832','TARZAN','? AND JANE'));

SELECT DECRYPT_BIT(SSN,'TARZAN') AS SSN FROM EMP;

Page 36: Data breach protection from a  DB2 perspective

36

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

Page 37: Data breach protection from a  DB2 perspective

37

Data Access Auditing

• Who did what to which data when?

• And how?

Page 38: Data breach protection from a  DB2 perspective

38

• Most organizations have access control policies… but how do you enforce them?• Privileged users have unfettered (and often anonymous)

access

• Transaction logs don’t provide sufficient visibility (e.g., read operations)

• Trace logs impose high overhead & require changes to database schemas

• Web-facing applications expose corporate data in new ways• SQL injection, vulnerabilities, non-current patches, scripting,

etc.

Database Security Issues

Page 39: Data breach protection from a  DB2 perspective

39

Levels of Database Auditing

• An audit is an evaluation of an organization, system,

process, project or product. • Database Control Auditing

• Who has the authority to…

• Database Object Auditing• DCL: GRANT, REVOKE• DDL: CREATE, DROP

• Data Access Auditing• INSERT, UPDATE, DELETE• SELECT

Page 40: Data breach protection from a  DB2 perspective

40

Audit Logging Requirements

CobiT (SOX)

PCI DSS

HIPAACMS ARS

GLBA

ISO 17799

(Basel II)

NERCNIST

800-53 (FISMA)

1. Read access to sensitive data (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 (DCL)(GRANT, REVOKE)

Regulations Driving Auditability

Page 41: Data breach protection from a  DB2 perspective

41

How to Audit Database Access?

1. DBMS traces

2. Log based

3. Network sniffing

4. Capture requests at the server

Page 42: Data breach protection from a  DB2 perspective

42

Why Server-based Capture is Important?• Audit within the DBMS (traces)

• Must start performance trace• DDL changes required to audit tables• Overhead as trace records are written by DB2

• Audit over the network• Capture SQL requests as they are sent over the network• What about non-network requests?

• CICS w/DB2, IMS w/DB2, SPUFI

• Audit from the database transaction log files• Modification are on the log anyway so…

• What about reads? Non-logged utilities?

Page 43: Data breach protection from a  DB2 perspective

43

Auditing Has to be at the Server Level

• Requires a software tap to “capture” relevant SQL at the DBMS/server level to review for auditing.

• If you are not capturing all pertinent access requests at the server level, nefarious users can sneak in and not be caught.

Page 44: Data breach protection from a  DB2 perspective

44

Database Archiving

• Long-term data retention requires the implementation of database archival processes

Page 45: Data breach protection from a  DB2 perspective

45

More Data, Stored for Longer Durations

Am

ou

nt

of

Data

Time Required

Complia

nce Pr

otect

ion

0 30+ Yrs

Data Retention Issues:

Volume of data (125% CAGR)

Length of retention requirement

Varied types of data

Security issues

Page 46: Data breach protection from a  DB2 perspective

46

Retention Regulations Drive Database Archiving Needs

Data Retention Requirements refer to the length of time you need to keep data

Determined by laws – regulatory compliance Over 150 state and federal laws Dramatically increase retention periods for corporate

dataDetermined by business needs

Reduce operational costs: Large volumes of data interfere with operations: performance, backup/recovery, etc.

Isolate content from changes: Protect archived data from modification

Page 47: Data breach protection from a  DB2 perspective

47

Example Retention Regulations

Source: Enterprise Strategy Group

Page 48: Data breach protection from a  DB2 perspective

48

Solution: Database Archiving

Data DataExtract Recall

Archive data store and retrieveMetadata

capture, design,maintenance

Archive dataquery and

access

Archive administration

datametadata

Archive

Databases

metadatapolicieshistory

Database Archiving: The process of removing selected data records from operational databases that are not expected to be referenced again and storing them in an archive data store where they can be retrieved if needed.

Purge

Page 49: Data breach protection from a  DB2 perspective

49

Needs for Database Archiving

• Policy based archiving: logical selection

• Keep data for very long periods of time

• Store very large amounts of data in archive

• Maintain archives for ever changing operational systems

• Become independent from Applications/DBMS/Systems

• Become independent from Operational Metadata

• Protect authenticity of data

• Access data directly in the archive when needed; as needed

• Discard data after retention period

Page 50: Data breach protection from a  DB2 perspective

50

Why Archiving Can Help to Prevent Data Breaches

• Data is removed from the database• If the database is breached, the archived data is

not because it is no longer there

• Data cannot be accessed by SYSADM • …or any other database users

• Data is protected against modification• Archived data cannot be changed

Page 51: Data breach protection from a  DB2 perspective

51

Metadata Management

Page 52: Data breach protection from a  DB2 perspective

52

Compliance Requires Metadata

• 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

Page 53: Data breach protection from a  DB2 perspective

53

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?

Page 54: Data breach protection from a  DB2 perspective

54

http://www.eweek.com/article2/0,1895,2186652,00.asp

Page 55: Data breach protection from a  DB2 perspective

55

Synopsis

• Regulations are requiring more stringent protection of data

• Data breaches occur frequently and are costly

• Implementation of best practices canmitigate the occurrence of data breaches

Page 56: Data breach protection from a  DB2 perspective

56

Craig S. MullinsNEON Enterprise Software, Inc.

[email protected]

www.CraigSMullins.com

Session H08

Data Breach Protection From a DB2 Perspective