Fortiva Technical Review

David Ferris recently wrote a bulletin about several interesting aspects of the Fortiva archiving solutions. I thought that our readers might be interested in a little more technical detail.

The architects of an archival and e-discovery product or service have to solve a number of difficult technical problems. These include, but are not limited to:

  1. Disaster tolerance
  2. Suitably fast accession (i.e., indexing)
  3. Suitably fast search
  4. Iron-clad security
  5. Assured destruction (at the end of a retention period)

The first three are, in general, solved much more economically by a shared service. This is because a shared service can more economically maintain storage across multiple data centers, and employ large grids of parallel computers to perform both accession and search (think Google). The fourth is more easily solved by an on-customer-premise product, while the fifth is a nightmare for both the architects of shared services and on-premise products.

Fortiva, as a well architected shared service, is able to economically offer disaster tolerance -- at least two copies of each archived record are maintained on RAID disk storage at a customer's primary Fortiva data center, while at least one other copy is maintained on RAID disk storage at another, remote, Fortiva data center. Their data centers are also equipped with sufficient shared processing power to operate suitably rapid accession and search. This is not what is unique to Fortiva; other archival and e-discovery services can take a similar approach. Whether they have done so to date is an open question.

What is unique to the Fortiva service is the vendor's approach to providing iron-clad security. Their solution is provided by an array of one or more on-customer-premise appliance/s that perform five tasks:

  1. An appliance extracts the search terms (words) in a record and individually encrypts them using a long-lived key. These encrypted words will be passed to the Fortiva accession service, which will employ them to index the record.
  2. It encrypts the entire record, again using a long-lived key before passing that record to the Fortiva service for storage.
  3. It employs Active Directory-based policies and Windows credentials to control access to the fourth task (see task 4 following).
  4. It constructs search queries using encrypted search terms (see task 1 above).
  5. It accesses and decrypts records referenced by a search query (see task 4 above) response.

Fortiva is not particularly forthcoming about how it encrypts search terms (tasks 1 and 4 above) - it's the company's secret sauce.

In addition to employing appliance-based encryption to ensure the privacy of customer data (both record and index), the Fortiva service also employs encryption to effect assured destruction. All records received by the Fortiva service, and we believe (Fortiva has not confirmed this) all full text indices maintained by the Fortiva service, are encrypted using a time-dependent (monthly) symmetric encryption key. If they are encrypted, then index blocks are decrypted using the same time-sensitive key in order to perform matching, as are records which are decrypted before being returned to an appliance.

At the end of a retention period, the time-sensitive keys employed to encrypt both record data and full text indices for that period are destroyed by the Fortiva service. This destruction must be total! Once a time-sensitive key is destroyed, any and all data encrypted with it can no longer be decrypted, and thus the data is assuredly destroyed. There is no need, given this approach, to physically scrub, or otherwise destroy, bits on physical media in order to achieve assured destruction!

...Nick Shelness

Post a comment

You must be logged in to post a comment. To comment, first join our community.