End-to-End Security with FLAM
The issue of end-to-end security is a very familiar one for us. For the use of FLAM we have always advised to encrypt data, where possible, immediately at their creation and delay decryption to immediately before processing. We have been able to implement this transparently (subsystems) and made sure with our interfaces that only records needed for processing are decrypted and decompressed (minimal CPU load and maximum security). Via the FLAM key management extension (FKME) any cryptographic infrastructure can be connected. The key-management is instrumental in allowing or disallowing access to data. All these capabilities have made FLAM a solution that provides great protection of your investment, as is shown with the compliance with the Payment Card Industry Data Security Standards (PCIDSS), because with FLAM, Data-at-Rest and Data-on-Transit need not be multiply encrypted and decrypted. This not only saves considerable CPU time and helps protecting the environment, it also enhances security and makes the solution future-proof.
Our recommendation to our customers has been to encrypt data by our subsystem immediately at generation and only then store them out to tape, transfer them to partners, etc. Transfers should be done from a system separate from the generating one in order to avoid having the key protecting the data on the same system as that connecting to the world outside.
This approach requires in addition to FLAM an administration of the encrypted files. With the FLAM's new network-capability (as of version 5) we retain end-to-end security while permitting storage of the compressed and encrypted data in the network. That means, as illustrated in the image above, that an end node (user A) may continue protecting his data via smartcard, softwre token, or hardware security module (HSM) by some cryptographic scheme (KMIP, FINPIN, x509v3PKI) transparently for the application. But the compressed and encrypted data segments need no longer be stored locally but may be centralized remotely, for example at some data cloud in the internet.
In this setup, FLAM5 supports anonymized searching and accessing compressed and encrypted data sets by admitting any one-way hash algorithm for positioning in the data. This allows, for example, retrieving from a central archive all transactions belonging to a particular credit card number as compressed and encrypted segments without revealing its true value. This ability makes, on top of privacy, integrity, and completeness, anonymization of data an additional security feature of FLAM.
Hence the key management scheme controlling the local crypto device decides who may read what data, how the person must authenticate and how well keys for FLAM are protected. FLAM extends the security of this cryptographic infrastructure literally to the entire backend for data exchange, data management, and storage. Thus, the client can be sure that its data benefit everywhere from the same security level as they do locally.