Voltage SecureData Provides End-to-End Encryption of Data
Voltage Security has announced major enhancements to Voltage SecureData, supporting more environments and platforms, including end-to-end encryption across distributed environments such as those used by retail and payment processors. "Voltage customers are finding it easier to protect their data end-to-end, comply with regulations and protect sensitive customer information from the moment it is collected."
"Large structured databases have been crying out for better protection," said Trent Henry, principal analyst, Burton Group. "Although data breaches are caused by a variety of factors, improved data protection is a big piece of the solution. Unfortunately, many organizations haven't been able to improve underlying data security because it required costly application changes or coding. Customers are looking for solutions that provide protection without changes to legacy infrastructure."
Voltage SecureData now integrates with Hardware Security Modules (HSMs) to store cryptographic information in order to meet internal company security requirements. HSMs are widely accepted as an industry best practice for securing encryption keys that protect an organization's most sensitive data.
For IBM mainframe customers using z/OS, Voltage SecureData now operates natively, providing a simple API that can be accessed by COBOL and other Language Environment (LE) programs to protect data, as well as an integration and scripting tool called z/FPE that enables bulk encryption and masking of z/OS data (CICS, DB2, IMS, QSAM, VSAM) -- providing full end-to-end data encryption, accessible from within or outside the z/OS system.
These new Voltage SecureData capabilities build upon two core cryptographic and key management innovations: Identity-Based Encryption (IBE) and Format-Preserving Encryption (FPE).
"Voltage SecureData makes it extremely fast -- not to mention much easier and more cost effective -- to encrypt data as soon as it's collected in a database, then keep it protected wherever it goes and while used by various applications," explained Terence Spies, chief technology officer, Voltage.
"Other cryptographic approaches turn a 16-digit credit card number into an alphanumeric string with as many as 50 characters. This poses big problems for databases, applications, and legacy systems that are set up to accept only 16 digits, requiring heavy-duty re-architecting and modifications. By contrast, by leveraging FPE, Voltage SecureData enables encrypted credit card numbers to continue to look and feel exactly like the real thing, eliminating those problems and the associated complexities altogether."
In addition to supporting distributed environments, mainframe and HSMs, the latest version of Voltage SecureData also makes it easier for customers to:
- Manage encryption across multiple servers. Voltage SecureData allows administrators to manage several servers from a single point, speeding updates and lowering operational costs.
- Secure data in a cross-platform environment. Supports Windows, Linux, AIX, Solaris, HP-UX, z/Linux and z/OS.
- Encrypt databases directly. With the Voltage SecureData Command Line, customers can encrypt data directly without building a separate encryption application or creating extracts.
- Meet compliance requirements. Includes built-in PCI audit reports, comprehensive logging across infrastructure and integration with third party log management systems.
- Integrate encryption in existing applications. Developers can add encryption with just two lines of code; competing products require as many as 100 lines to accomplish the same task.
Interest in encryption will likely increase in the coming months, as the new president shines the spotlight on the need for data protection. President Obama's Homeland Security agenda mandates standards for securing personal data and requires companies to disclose data breaches. In particular, he has indicated that encryption will play a key role in efforts to protect consumers. As a result, government efforts will expand beyond infrastructure protection and focus on database encryption, as well as mobile data, storage encryption, PKI and key management solutions.
For more information on 'Data Protection Risks and How to Avoid Them,' join Voltage Security, Burton Group and MphasiS (an EDS company), in a discussion about the top five risks of protecting customer data and what to do about them on February 19th at 9:00am Pacific and 12:00pm Eastern. Click here to register.





Did you check if the AES encryption mode that you are planning to use is PCI approved? You should check with the PCI Security Standards Council if they approve the Voltage FPE that you are suggesting. You may start by checking the list of encryption algorithms and modes that are currently approved by NIST ( http://csrc.nist.gov/CryptoToolkit/modes/ ). In Special Publication 800-38A, five confidentiality modes are specified for use with any approved block cipher, such as the AES algorithm. The modes in SP 800-38A are updated versions of the ECB, CBC, CFB, and OFB modes that are specified in FIPS Pub. 81; in addition, SP 800-38A specifies the CTR mode.
Posted by: Ulf Mattsson | September 04, 2009 at 07:12 PM
I found this analysis at http://securosis.com/blog/format-and-datatype-preserving-encryption/ , saying that the business justification for this type of encryption is a little foggy.
The PCI Security Standards Council and firms like Gartner can give us important guidance. Some people think that not all QSA’s understand PCI. The PCI Security Standards Council looked at "format-preserving encryption" techniques and did not approve it for cardholder data. Gartner published a Research Report with the title 'Using Tokenization to Reduce PCI Compliance Requirements' on Aug 5, 2009 saying that 'Some encryption vendors offer "format-preserving encryption" techniques. This approach can be used to maintain the original size and structure of the encrypted data, but must be done carefully so as not to reduce the overall security of the encryption algorithm'.
FPE (or the FFSEM subset) and FCEM are "format-preserving encryption" techniques that are new suggested confidentiality modes for AES that are currently not approved by NIST.
Posted by: Ulf Mattsson | September 12, 2009 at 01:03 PM
I found some additional information at http://tinyurl.com/lwd2hq
Posted by: Ulf Mattsson | September 20, 2009 at 06:56 AM
I found a Gartner Research Note about Data Tokenization, PCI Compliance, FPE and “Format and Datatype Preserving Encryption” at http://tinyurl.com/5or2a4 and some additional information at http://tinyurl.com/lwd2hq
Posted by: Ulf Mattsson | September 20, 2009 at 03:18 PM