Securing application data while maintaining full functionality
StartFragment
At a recent CISO event in the NY Metro area, there was considerable interest in security application data while maintaining full application functionality. 2 key requirements to consider in evaluating data security are:
Referential Integrity
Database schema/application format
Applications commonly rely on referential integrity for indexing, searching, data analytics and “joining” data. Often the fields used involve Personally Identifiable Information (PII) data such as social security number, primary account number or credit card numbers to provide reference across databases and applications. Traditional encryption schemes for data necessary for compliance and security break referential integrity. Referential Integrity
ngIf: link
Fig. 1 Referential Integrity
Data Schema/application format Data is stored in fields that have specifically defined formats – defined lengths and specific data sets (i.e. integers, characters…). Applications are written with formats built into the code base including in definitions of variables, allocation of temporary space, layout of user interfaces, etc. When data is encrypt the number of characters increases and the character set may be greater. For example, 000-00-0000 encrypted with AES becomes Ija&2924kUEF65%QarotugDF2390^32KNqL. Needless to say, application field formats and database schema requiring modification to handle data encrypted with AES. Modification of application field formats and database schemas involve substantial time and expense.
Format Preserving Encryption (FPE) addresses both the referential integrity and the database scheme/application format issues. FPE encrypted data encrypts data to the same value every time. Thus, there referential integrity is maintained. Searching, data analytics, and table “join” will continue to work with encrypted data.
Since the encrypted data with FPE is the same length and character set as the original there is not a need to modify the database schema or the application field formats.
Additionally, FPE has minimal implementation and operations overhead costs relative to native application encryption. Minimal changes to the application are required (strategic use of APIs) and no modification to the database minimize implementation costs. Data only needs to be decrypted when required for use by end users. Administrators never have access to the decrypted data. Searching and analytics can be done with the encrypted data.
Also, there is never a need to change encryption keys due to the nature of FPE algorithm eliminating the need to decrypt and re-encrypt the data with the introduction of new keys (due to key expiration or key compromise).
It is no wonder the CISOs in the NY Metro area are excited about data centric security and FPE for protection of PII, PHI and big data in Hadoop and Teradata.
First Published - Hewlett Packard Enterprise Community
EndFragment
