User talk:Ulfmattsson

From Wikipedia, the free encyclopedia

These methods represent three radically different ways to render data unreadable:

  1. Two-way cryptography with associated key management processes
  2. One-way transformations including truncation and one-way cryptographic hash functions
  3. Index tokens and pads


1. Two-way encryption of sensitive data is one of the most effective means of preventing information disclosure and the resultant potential for fraud. Cryptographic technology is mature and well proven. There is simply no excuse for not encrypting sensitive data. The choice of encryption scheme and topology of the encryption solution is critical in deploying a secure, effective and reasonable control. The single largest failure in deploying encryption is attempting to create an ad-hoc cryptographic implementation. Please see the references for solutions on DB2 and other platforms below.

2. Hash algorithms are one-way functions that turn a message into a fingerprint, usually not much more than a dozen bytes long. Truncation will discard part of the input field. These approaches can be used to reduce the cost of securing data fields in situations where you do not need the data to do business and you never need the original data back again. Please see the references for solutions on DB2 and other platforms below.

3. Tokenization is the act of replacing the original data field with reference or pointer to the actual data field. This enables you to store a reference pointer anywhere within your network or database systems. This approach can be used to reduce the cost of securing data fields along with proper network segmentation in situations where you do not need the data to do business, if you only need a reference to that data. Please see the references for solutions on DB2 and other platforms below.

Please see the following papers and articles that are reviewing and positioning different types of database encryption solutions for DB2 and other platforms : http://www.db2mag.com/shared/printableArticle.jhtml?articleID=199203560 , http://www.db2mag.com/db_area/archives/2003/q1/mattsson.shtml , http://database.ittoolbox.com/documents/peer-publishing/database-encryption-how-to-balance-security-with-performance-4503 , http://ssrn.com/abstract=934271 , http://papers.ssrn.com/sol3/papers.cfm?abstract_id=940287 , http://research.ittoolbox.com/white-papers/lg.asp?grid=3515&kb=Security&pl=&ref=http%3A%2F%2Fwww%2Egoogle%2Ecom%2Fsearch%3Fq%3Ddatabase%2Bencryption%26hl%3Den%26pwst%3D1%26start%3D10%26sa%3DN&sp= .

[edit] ENCRYPTING COLUMNS, ROWS, INDEXES AND DISK IN DB2 FOR z/OS

Different encryption solutions are utilizing fundamentally different methods to encrypt DB2 data on z/OS. Encryption does mean some tradeoffs in function, usability and performance.

An EDITPROC acts on a complete row of a table, as received from the database. The index is stored in the clear (in other words, unencrypted). If it is essential that indexes be encrypted, you should choose another method. A credit card number should not be exposed in the index if you need to be compliant to PCI DSS 1.1. PCI DSS is a set of collaborative security requirements for the protection of credit card transactions and cardholder data for all brands. This issue is not necessarily specific to credit card #s but credit card numbers are one important example of something you’d want to encrypt in an index. A column level encryption solution can be used to solve this issue.

A FIELDPROC transforms a single short-string column and allows the index to be stored as encrypted text. If multiple data elements in table need protection and none are in an INDEX, then EDITPROC is less resource intensive than multiple FIELDPROCs. If only one or few columns need protection then only those are encrypted. FIELDPROC can only be specified on short string COLUMNs, and cannot be specified on ROWID or LOB columns but columns with those data types are allowed in the TABLE. Queries with greater than, less than and range predicates are not supported. A column level UDF based encryption solution can be used to solve some of these issues (see below). FIELDPROC can be added by ALTER TABLE, so no need for unload, drop table, create table, reload sequence.

A User Defined Function (UDF) enables column-level encryption with views and triggers. The enhanced support for these functions in DB2 v.9 provides a higher level of application transparency than earlier DB2 versions. The lack of application transparency in earlier DB2 versions can be an issue when implementing UDF based encryption. UDF based encryption can be attractive if only one or few columns need protection and if support for additional data types is needed. UDF based column encryption also support a wide range of search operations on encrypted columns. Additional overhead, in some cases significant, can be expected if the search is forcing table scans and decryption of a large number of rows during the search operation.

A column level encryption solution can also be used in combination with SECLABEL based row-level security in DB2 V8, but you cannot define an EDITPROC on a table that has a SECLABEL column.

With DB2 V9, you can also use System z disk and tape controllers as a complement to encrypt some of the data at rest directly on these devices.

Please see http://www.db2mag.com/showArticle.jhtml?articleID=199203560 and http://www.protegrity.com for some additional information.

[edit] How production data can be securely used in a test system

Production data is in many cases need to ensure quality in system testing. Key data fields that can be used to identify an individual or corporation need to be cleansed to de-personalize the information. Cleansed data needs to be easily restored (for downstream systems and feeding systems), at least in the early stages of implementation. This therefore requires a two-way processing. The restoration process should be limited to situations for which there is no alternative to using production data (eg. interface testing with a third party or for firefighting situations). Authorization to use this process must be limited and controlled. In some situations, business rules must be maintained during any cleansing operation (e.g. addresses for processing, dates of birth for age processing, names for sex distinction). Scrambling should be either consistent or variable with different cleansings. There should also be the ability to set parameters, or to select or identify fields to be scrambled, based on a combination of business rules. A solution must be based on secure encryption, robust key management, separation of duties, and auditing. Please see http://www.db2mag.com/showArticle.jhtml?articleID=199203560 and http://www.protegrity.com for some additional information.

[edit] Best practice for column level encryption in Informix IDS 9.4:

Best practice for column level encryption in Informix IDS 9.4:

Specialized solutions are available from 3rd party providers for Informix IDS 9.4 and higher. These solutions are based on User Defined Function (UDF) and User Defined Types (UDT). The UDF provides column-level encryption through views and triggers. The UDT approach provides column-level encryption directly through special data types. These solutions offer a high level of application transparency and flexibility for tuning of performance for different types of queries. Some of the solutions also provide centralized key management and reporting across different platforms and separation of DBA duties. Please see http://papers.ssrn.com/sol3/papers.cfm?abstract_id=974957#PaperDownload and http://papers.ssrn.com/sol3/papers.cfm?abstract_id=934271 for some additional information and best practices for column level encryption.