User talk:Ulfmattsson

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

Two-way cryptography with associated key management processes
One-way transformations including truncation and one-way cryptographic hash functions
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= .

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.

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.

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.

Protegrity name came from "protection and integrity"

The Protegrity name came from "protection and integrity" (www.protegrity.com ) in 1994. The technology was initially created in 1994 by Ulf Mattsson (www.ulfmattsson.com) based on the emerging data security and privacy requirements in Europe (http://www.cdt.org/privacy/eudirective/EU_Directive_.html). The technology implementation was developed during 1994 and 2009 in joint projects with research and development teams at IBM (https://www-304.ibm.com/partnerworld/gsd/solutiondetails.do?solution=27627&lc=en ), Microsoft, Hewlett-Packard, Oracle (http://www.nyoug.org/Presentations/SIG/DataWarehousing/NYOUGFeb3-UlfMattsson-WEB.pdf) , Sybase, Informix, Teradata, Checkpoint, nCipher, Thales and RSA. The innovations are covered by a number of patents filed in 1996 and later (http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=0&f=S&l=50&TERM1=protegrity&FIELD1=&co1=AND&TERM2=&FIELD2=&d=PTXT). The technology is currently used by organizations that are subject to PCI DSS (Payment Card Industry Data Security Standard, https://www.pcisecuritystandards.org/security_standards/index.php) and other data privacy regulations in US (http://www.ncsl.org/default.aspx?tabid=13489) and Europe (http://www.cdt.org/privacy/eudirective/EU_Directive_.html). The innovations are covered by a number of Protegrity patents filed in 1996 and later. Protegrity filed suit against Ingrian Networks in April 2008, and against nuBridges, Inc. and Voltage Security, Inc. in May 2010. These suits, which seek to protect Protegrity’s intellectual property, were all filed in the Federal Court in Hartford, Conn. As Safenet, Inc. acquired Ingrian, and because the company is now selling what used to be Ingrian’s products, Safenet has been added as a co-defendant to the Ingrian litigation. http://www.protegrity.com/node/565.

Protegrity name came from "protection and integrity"

The Protegrity name came from "protection and integrity" (www.protegrity.com ) in 1994. The technology was initially created in 1994 by Ulf Mattsson (www.ulfmattsson.com) based on the emerging data security and privacy requirements in Europe (http://www.cdt.org/privacy/eudirective/EU_Directive_.html). The technology implementation was developed during 1994 and 2009 in joint projects with research and development teams at IBM (https://www-304.ibm.com/partnerworld/gsd/solutiondetails.do?solution=27627&lc=en ), Microsoft, Hewlett-Packard, Oracle (http://www.nyoug.org/Presentations/SIG/DataWarehousing/NYOUGFeb3-UlfMattsson-WEB.pdf) , Sybase, Informix, Teradata, Checkpoint, nCipher, Thales and RSA. The innovations are covered by a number of patents filed in 1996 and later (http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=0&f=S&l=50&TERM1=protegrity&FIELD1=&co1=AND&TERM2=&FIELD2=&d=PTXT). The technology is currently used by organizations that are subject to PCI DSS (Payment Card Industry Data Security Standard, https://www.pcisecuritystandards.org/security_standards/index.php) and other data privacy regulations in US (http://www.ncsl.org/default.aspx?tabid=13489) and Europe (http://www.cdt.org/privacy/eudirective/EU_Directive_.html). The innovations are covered by a number of Protegrity patents filed in 1996 and later. Protegrity filed suit against Ingrian Networks in April 2008, and against nuBridges, Inc. and Voltage Security, Inc. in May 2010. These suits, which seek to protect Protegrity’s intellectual property, were all filed in the Federal Court in Hartford, Conn. As Safenet, Inc. acquired Ingrian, and because the company is now selling what used to be Ingrian’s products, Safenet has been added as a co-defendant to the Ingrian litigation. http://www.protegrity.com/node/565.

Speedy deletion nomination of Protegrity

A tag has been placed on Protegrity, requesting that it be speedily deleted from Wikipedia for multiple reasons. Please see the page to see the reasons. If the page has since been deleted, you can ask me the reasons by leaving a message on my user talk page.

If you think that this notice was placed here in error, contest the deletion by clicking on the button labelled "Click here to contest this speedy deletion," which appears inside of the speedy deletion ({{db-...}}) tag (if no such tag exists, the page is no longer a speedy delete candidate). Doing so will take you to the talk page where you will find a pre-formatted place for you to explain why you believe the page should not be deleted. You can also visit the the page's talk page directly to give your reasons, but be aware that once tagged for speedy deletion, if the page meets the criterion, it may be deleted without delay. Please do not remove the speedy deletion tag yourself, but don't hesitate to add information to the page that would render it more in conformance with Wikipedia's policies and guidelines. If the page is deleted, you can contact one of these administrators to request that the administrator userfy the page or email a copy to you. Singularity42 (talk) 00:26, 17 June 2011 (UTC)[reply]

June 2011

Hello Ulfmattsson. If you are affiliated with some of the people, places or things you have written about in the article Protegrity, you may have a conflict of interest. In keeping with Wikipedia's neutral point of view policy, edits where there is a conflict of interest, or where such a conflict might reasonably be inferred, are strongly discouraged. If you have a conflict of interest, you should avoid or exercise great caution when:

editing or creating articles related to you, your organization, or its competitors, as well as projects and products they are involved with;
participating in deletion discussions about articles related to your organization or its competitors; and
linking to the Wikipedia article or website of your organization in other articles (see Wikipedia:Spam).

Please familiarize yourself with relevant policies and guidelines, especially those pertaining to neutral point of view, verifiability of information, and autobiographies.

For information on how to contribute to Wikipedia when you have a conflict of interest, please see our frequently asked questions for organizations. Thank you. Singularity42 (talk) 00:27, 17 June 2011 (UTC)[reply]