Which Bloombase Product Is Good For You?
Enterprises and organizations are headache with sensitive data compromises and unauthorized exposures. Malicious attacks or inadequate secret data handling procedures can cause corporations significant financial loss. The public have growing incentives to protecting their own personal data, together with worsening cyber crime, governments in various nations set up electronic data privacy regulatory. For those organizations fail to comply, penalties are levied.
Over the past few years, many companies have implemented perimeter security measures such as firewalls, virtual private network (VPN), intrusion detection system (IDS) and malware protector (antiviral mechanisms), etc. As an entry point of company core data protection against outsider attacks, these security endeavors have proven adequate. However, effective data backup-restore, mature disaster recovery practice and distributed networked storage architecture increases chances of data outbound threats - sensitive corporate data can hardly be kept inside company network perimeters. Perimeter access control is inadequate to protect sensitive data. Thus, organizations are facing an entirely new security initiative - storage data cryptography.
Like firewalls, VPN, IDS and antivirus, data at-rest security solutions should also be self-contained, standards-based, of broad platform suport and highly optimized for performance and availability. Bloombase StoreSafe family of persistence data encryption servers are such solutions built upon a proven high speed cryptographic engine and adapted for use in a wide range of enterprise applications.
Something You Should Know Before You Start
Why Data Confidentiality
Before you choose among Bloombase StoreSafe for your target persistence data security solution, understanding reasons for pursuing an encryption strategy is important.
- Identify relevant regulatory obligations (e.g. SB 1836, Payment Card Industry Data Security Standard, EU Data Privacy, PDPO, HIPAA, etc)
- Review corporate policies relevant to data security
- Identify dependencies of data protection
- Identify data privacy deficiencies in your current corporate IT environment
Classify and Rank Your Sensitive Corporate Data
To most customers' first perception, encrypting all of an organization's data seems to be a reasonable choice. However, data sensitivity, criticality, volume of data, costs etc might affect how the data should be protected.
- Identify mission critical, sensitive and confidential data
- Identify the applications that generate and process the data to be protected
- Determine hosts that access and use the sensitive data
- Identify data owners and business units
- Identify physical storage devices or media where secret persistence data are stored
- Identify the networks (IP or fiber channel) sensitive data are transported
- Identify geographic locations sensitive data reside
Data Throughput Estimation
Bloombase StoreSafe is highly scalable and scales linearly with the computation power of the appliance it runs on. By estimating volume of sensitive data that need to be encrypted or decrypted on-the-fly over time, it gives a rough estimate of how much cryptographic power the storage encryptor should offer.
- Identify data protection measures and temporary storage usage
- Determine volume of sensitive data generation and consumption
- Estimate proportion of actual sensitive data access from and to storage as a result of application cache invalidation or warm-up
- Determine data replication and disaster recovery scale
- Determine system peak hours and system utilization
- Consult normal and minimum service level
Sweet Point of Encryption
Now, a decision has to be made to which level encryption should be applied. The sweet point of encryption represents the location within the IT environment where data are brought to before it is decrypted and usable as if in plain. It is the level of abstraction to actual users and applications of encrypted storage data.
Levels of Abstraction |
Application |
Database |
File |
Device |
|
Application Level
Systems demanding the finest granularity of control and maximum insight into the sensitive application data should implement application level data encryption. The following visual illustrates a typical setup of application level storage data encryption using Bloombase KeyCastle cryptographic server.
The system is composed of
- Bloombase KeyCastle cryptographic server, a stand-alone encryption appliance with built-in key management and cryptographic services to be invoked by remote clients. Bloombase KeyCastle clients consume Bloombase KeyCastle cryptographic services by sending plain data to be encrypted or ciphered data to be decrypted
- Application server requires a plain view to process sensitive corporate data. When plain data are captured and submitted from users to application server, application server invokes Bloombase KeyCastle for the cryptographic service and keys encryption to be applied before the ciphered form to be sent to data server. On the other hand, when application server pulls ciphered contents from data server, they must be deciphered before they are further processed or presented to users
- Data server processes ciphered sensitive contents just like a garbage-in-garbage-out (GIGO) device
A typical sample Java code to invoke Bloombase KeyCastle from within application server is as shown below
String keyName = "key";
String creditCardNumber = "1234123412341234";
String cipheredCreditCardNumber =
(String) BloombaseKeyCastle.getSingleton().invoke(
"AESEncryptor",
new String[] {
"Mode",
"BitLength",
"Padding",
"KeyName",
"Data" },
new Object[] {
"CFB",
new Integer(256),
"NoPadding",
kayName,
creditCardNumber}).get("Result");
|
|
In this example, the credit card number to be secured is encrypted using AES 256 bit CFB cipher with key identified by the parameter keyName.
Pros and cons of application level protection is summaried as below
| Pros |
Cons |
-
Sensitive information are secured selectively and at the finest granularity suiting all application requirements
- Zero change required at data servers and storage sub-systems
- Database administrations can see only ciphered contents and have no ways of decipher the protected contents
- Encryption keys are centrally managed at Bloombase KeyCastle
- Channels to/from Bloombase KeyCastle must be authenticated and are secured by strong encryption
- Systems having well-defined and classified minority of storage data are good candidates of application level encryption
|
- Requires tedious initial migration of data for existing systems
- Second development required at the application codes, very high integration costs for existing systems and implementation difficulty or impossibility for off-the-shelf applications
- Data to be encrypted range from awkward sizes of a few bytes to kilo or mega bytes, cryptographic speeds are limited
- Huge performance impact as result of cryptographic overheads for data of small sizes
- Where ciphered data are stored into relational databases, range queries or sorting will suffer from huge performance degradation due to possibly table scans, not recommended for business intelligence systems or data warehouses
- Indexes are corrupted and query optimizers often choose to carry out table scans for encrypted columns
|
|
Database Level
Where cryptographic processing has to be carried out per data unit as small as fields or database rows, yet application changes are to be avoided, one might consider having cryptographic processes taking place at the data server level.
- Bloombase StoreSafe for Database with bundled Bloombase KeyCastle runs as an independent cryptographic resource on the network accessed by database server
- Bloombase StoreSafe for Database client module is installed onto database server to be invoked by database objects as stored procedures
- Additional database triggers are created at the database server such that cryptographic services are invoked via the stored procedures, hence, achieving transparent database protection
Bloombase StoreSafe Database for Oracle AES encryption in action
...
DECLARE
credit_card varchar2(16) := '1234123412341234';
key_name varchar2(8) := 'key';
encrypted_credit_card varchar2(22);
error_spitfire_storesafe EXCEPTION;
PRAMA_EXCEPTION_INIT(error_spitfire_storesafe, -39121);
SPITFIRE_STORESAFE_ERROR_MSG varchar2(100) := 'Bloombase StoreSafe Exception';
BEGIN
spitfire_storesafe.encrypt(
cipher => 'AES',
mode => 'CBC',
bit_length => 128,
padding => 'NoPadding',
key_name => key_name,
data => credit_card,
result => encrypted_credit_card );
dbms_output.put_line('Encryption credit card : || encrypted_credit_card);
EXCEPTION
WHEN error_spitfire_storesafe THEN
dbms_output.put_line(SPITFIRE_STORESAFE_ERROR_MSG);
END;
|
|
Please note that Bloombase StoreSafe Database encryption of string values will introduce additional length of one-third of the original contents whereas no change for raw values.
As an example, below shows how Bloombase StoreSafe Database for Oracle is invoked from within an Oracle database trigger automatically using stored procedure calls
create or replace trigger TRIG_CREDIT_CARD_BEF_UPD
before UPDATE of CREDIT_CARD
on TBL_CREDIT_CARD for each row
DECLARE
encrypted_credit_card varchar2(22);
BEGIN
spitfire_storesafe.encrypt(
cipher => 'AES',
mode => 'CBC',
bit_length => 128,
padding => 'NoPadding',
key_name => 'key',
data => :NEW.CREDIT_CARD,
result => encrypted_credit_card );
:NEW.CREDIT_CARD := encrypted_credit_card;
END;
|
|
Pros and cons of database level protection is summaried as below
| Pros |
Cons |
- Sensitive information are secured selectively and at the finest granularity suiting all application requirements
- Zero change required at application codes and storage sub-systems
- Database operators can see only ciphered contents
- Encryption keys are centrally managed at Bloombase KeyCastle
- Channels to/from Bloombase KeyCastle must be authenticated and are secured by strong encryption
- Systems having well-defined and classified minority of relational database data are good candidates of database level encryption
|
- Database administrators have ways of decipher the protected contents
- Requires tedious initial migration of data for existing databases
- Second development required at database stored procedures and data binding application codes, high integration costs for existing systems and implementation difficulty or impossibility for off-the-shelf systems
- Data to be encrypted range from awkward sizes of a few bytes to kilo or mega bytes, cryptographic speeds are limited
- Huge performance impact as result of cryptographic overheads for data of small sizes
- Range queries or sorting will suffer from huge performance degradation due to possibly table scans, not recommended for business intelligence systems or data warehouses. Only point queries can benefit from indexes
- Indexes are corrupted and query optimizers often choose to carry out table scans for encrypted columns
|
|
File Level
Application or database level encryption can be too fine a level of granularity for some systems where protection is only required per storage entity unit - file, directory, volume. While majority of applications use filesystem as data server and have data persisted in form of files, it is reasonable to secure sensitive contents inside files with file perimeter a unit of protection entity. Oracle tablespaces are implemented as individual files. C or Java program source codes are organized and managed as files. Some authentication sub-systems store their user credentials in a single flat file. Documents are stored as files. Spreadsheets holding secret business data are persisted as files as well.
File level protection means the smallest unit of encryption is confined to file perimeter. A file encrypted at file level is secured by the same key, cryptographic cipher algorithm, cipher mode, bit length, block size, padding settings etc. Regardless of the proportion of sensitive data or how data are physically organized, the same file protection strategy applies per single file.
Below visual depicts a typical setup of transparent file encryption using Bloombase StoreSafe NAS.
- Bloombase StoreSafe NAS server sits between storage host and storage sub-system
- When storage host writes sensitive files to storage sub-system via Bloombase StoreSafe, Bloombase StoreSafe determines cryptographic cipher and encryption keys associated to the file destination, plain sensitive contents of files are ciphered by Bloombase StoreSafe before they are physically persisted in storage sub-system
- During a file read operation, ciphered contents of protected files are pulled out from storage sub-system and decrypted by Bloombase StoreSafe, virtual plain sensitive contents of deciphered files then reach storage host to be consumed by applications
Pros and cons of file level protection is summaried as below
| Pros |
Cons |
- Zero change at application and storage sub-systems
- Filesystem independent
- On-demand encryption and decryption
- Application transparent operation
- No application or database re-development required
- Encryption keys are centrally managed at Bloombase KeyCastle
- User customizable encryption block size to adapt to application's file access pattern
- Backup operators see only ciphered contents
- Simple initial data migration by file copy, no special tool or programming required
- High file cryptographic performance
- No index corruption for relational databases
- Small performance penalty for database range queries or sort
- Perfect for file server or document management system protection
- Immediate and low cost information security regulatory compliance
- Highly available
|
- Encryption applies to entire file, even if only a tiny portion of file contains sensitive contents, the rest of non-sensitive contents are encrypted as well
- As database sits above the encryption level, authorized database users can view sensitive contents in virtual plain
- A fixed increment of file size for Bloombase StoreSafe secured files
|
|
Device Level
Some enterprise systems or applications might manipulate storage system as a raw device without filesystem, or uncooked/raw filesystem, due to performance concern. Others might consider file-level protection is still too fine and would opt for encryption per storage volume/partition/device. In these cases, device level encryption is the perfect choice.
Storage device is accessed via storage communication commands, for instance, SCSI. Encryption on device is essentially having sensitive plain payload of storage commands ciphered or deciphered during data submission or request processes.
Device level encryption implementation takes similar setup like file-based encryption as shown in below figure
- Storage host sends plain data as encapsulated in storage communication commands as payload to Bloombase StoreSafe SAN, Bloombase StoreSafe parses the storage commands, extracts sensitive plain data, ciphers it, re-constructs storage command by replacing plain contents with ciphered data, finally, sends to storage sub-system to be persisted
- When a storage read is issued from host, storage sub-system responds by encapsulating ciphered storage contents in storage communication commands to Bloombase StoreSafe, Bloombase StoreSafe extracts the ciphered contents, deciphers it, then re-construct the storage response by replacing original ciphered contents with virtual plain data before they are sent to host for application use
Pros and cons of device level protection is summaried as below
| Pros |
Cons |
- Zero change at application and storage sub-systems
- Filesystem independent and requires no filesystem
- On-demand encryption and decryption
- Application transparent operation
- No application or database re-development required
- Encryption keys are centrally managed at Bloombase KeyCastle
- User customizable encryption block size to adapt to application's storage device access pattern
- Backup operators see only ciphered contents
- Simple initial data migration by backup-restore, no special tool or programming required
- Very high cryptographic performance
- No index corruption for relational databases
- Very small performance penalty for database range queries or sort
- Perfect for large scale database or content management system protection
- Immediate and low cost information security regulatory compliance
- Highly available
|
- Encryption applies to entire device/volume/partition, even if only a tiny portion of device contains sensitive contents, the rest of non-sensitive contents are encrypted as well
- As database and filesystem sit above the encryption level, authorized database users or system users can view sensitive contents in virtual plain
- Requires more sophisticated backup restore handling to achieve at encrypted backup archives
|
|
All Purpose Generic Persistence Data Security Platform
Enterprise data systems always span across RDBMS and beyond, for instance, file system, proprietary content repository, and raw volumes, etc. Sensitive data stored in databases which need to be protected might also available in its plain form in other persistence sub-systems, whereas the same rule applies - privacy.
Below table summarizes various Bloombase models and their recommended applications
Product |
Applications |
| Bloombase KeyCastle |
- Application and user specific security requirements
- Not for business intelligence applications
|
| Bloombase StoreSafe Database |
- Database-specific security requirements
- No application code change needed
- Not for business intelligence
|
| Bloombase StoreSafe NAS |
- File server and content management system protection
- Database protection
- Good for business intelligence
|
| Bloombase StoreSafe SAN |
- Volume and backup archive protection
- Immediate regulatory compliance
|
|
Bloombase StoreSafe is an all-purpose and generic storage encryption solution powering secure persistence data in virtually all applications. Where there is a need for data privacy, there is a solution for you from Bloombase.
Contact us for more information at sales@bloombase.com
|
