Sometimes the problem isn't deciding whether to do encryption, but how to do it across a variety of systems and environments. For one travel industry service supplier, that question has recently been answered.

TRX, based in Atlanta, supplies services, such as online booking, reservation processing, and data intelligence, to travel agencies, corporations, travel suppliers, government agencies, and credit card organizations. Each year, the firm, which has 1,000 employees in eight locations, processes 150 million transactions for its customers.

As new regulations, such as Payment Card Industry Data Security Standards (PCI DSS), were being enacted, the travel industry service supplier decided to take a close look at its security practices. “We had confidential data sitting in some of our databases that needed to be encrypted,” said Chris Mauer, director of security and controls at TRX.

While the problem was clear, the potential solution was not. Because the service supplier had grown via acquisitions throughout its history, TRX found itself in a highly heterogeneous environment. The company supports multiple operating systems (Microsoft’s Windows, Linux), database management systems (Oracle, SQL Server, IBM’s DB2), and programming languages (Java, Microsoft’s Visual Studio).

Because the systems had evolved in a haphazard manner, the company’s encryption mechanisms were inefficient. The corporation stored data that was not encrypted, used different encryption products, stored keys in different locations (some in the applications and others by the users), and had a hodgepodge of key management systems.

With new applications -- such as TravelTrax, a hosted travel data reporting services -- in the pipeline, the firm determined it was time to make its DBMS encryption procedures more consistent and more cohesive.

In the spring of 2007, the company went to the market to find a suitable product but was left with few selections. “Not many companies could support the broad range of systems that we had,” stated TRX’s Mauer.

The evaluation eventually was narrowed down to Vormetric Inc.’s Data Security Expert or an internally developed encryption system. The TRX supplier decided to go with the former for a couple of reasons. The Vormetric system was appliance-based, so it could be easily slipped into TRX’s network. It did not require a great deal of programming: The travel industry services supplier did not have to change any data table structures, data fields, or application source code.

However, DBMS encryption products can be expensive, costing as much as $10,000 per DBMS. Since TRX has about 30 databases, its cost quickly shot past the $100,000 mark. Yet this cost was still less than developing a DBMS encryption system in-house.

The decision to purchase the Vormetric product was made in August, but the rollout came a few months later. Because the DBMS information is mission critical, TRX wanted to be sure that its new solution was stable. Near the end of 2007, the company starting adding Vormetric’s Data Security Expert to its DBMSs in a piecemeal fashion and finished the job in the fall of 2008

Performance degradation is one concern with encryption products, but TRX hasn't run into that problem so far. “From our performance testing, we have seen only negligible increases in CPU usage,” said Mauer.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.