Crown Jewels and Encryption Opportunities

As long as there is a need to accept, transmit and store personal and financial information, organized criminals and other self-righteous entities will attempt to breach the caretaker’s enterprise to obtain this information.

Mastering the art and science of information security is an elusive quest. Few will ever achieve their goal. Few will ever reach the finish line. It is this evolving challenge some of us thrive on. The steady development and application of point and counter point. I believe that when you reduce complexity in a thing, you increase your success results. Going back to my approach to data security, without our data sources, technology is rendered impotent, business stops. We should treat every connection to our data sources as a remote connection. It does not matter whether this connection is attached to a human input device connected directly or a source located across the galaxy, the point is these are all remote connections. Simple rules can be applied. You might have source and destination rules governing and controlling connections. You will also have system and application ports and connection protocols established available for your control. What we do not have in our control is the revelation of a new system bug exploited by some remote entity. One very effective method in mitigating and thwarting threats to our data sources is with encryption technologies. We have end to end encryption treatments covering source and destinations associated with a transaction, there are application treatments covering encryption and obfuscation within an application, lastly the data at rest encryption opportunities to protect our Crown Jewels.

Database encryption is commonly used to protect confidential records. Various methods and tools exist to encrypt fields, records or an entire database. There are both software and hardware products and solutions available on the market today. Databases can be encrypted on a single server or on an enterprise distributed server configuration. Database encryption does not protect data once it is transmitted into an application screen or across the network. Database encryption is but one facet in a holistic treatment.

Source destination encryption involves some application of hardware or software or both to establish a secure tunnel between systems. Hardware based encryption methods are typically built around an exploit resistant hardware module that generally sits at a central location on a company’s network or at both ends of the solution conduit, providing strong key management and secure key storage. Hardware based encryption is widely held to be superior to software based encryption. However, these hardware based solutions can be very expensive to deploy. This does not offer a complete solution in itself as there are still pockets of information that remain for most data processing scenarios at the end points of the encrypted tunnel. Software based encryption schemes address the problem in a similar way except key management becomes more the issue to identify. Where are they maintained? Who has access? That’s a question anyone considering software based encryption should be asking. Software solutions are generally less expensive to deploy. As with any technology, at some time it will be circumvented. The extreme need to implement rigorous controls around these systems that house the cryptographic keys to your kingdom are obvious. While hardware based solutions theoretically are more secure than software, the concerns are really unilateral. Once again, this is only a single part of what should be a comprehensive cryptographic application of technology.

Application encryption or obfuscation involves protecting information that comes in the acquisition or transmission of sensitive date. I certainly recommend taking the “need to know” approach here. If I don’t need to know what your credit card number is to provide my help desk function, the application should obfuscate this information. If my DBA does not need to know what your social security number is, don’t provide a view. In most cases, a simple hash created within an application will provide good controls in this space. A database itself should be at least partially encrypted at rest. The DBA or intruder targeting your data store is the biggest threat to the enterprise. Database encryption again as I’ve mentioned is fundamental to your success. It takes a bit more effort to properly code an application for encryption and obfuscation. It does take more technology horsepower to process encryption, however, the expenses to implement far outweigh the expense of compromised information.

The basic information security life-cycle consists of three components, protection, detection, and remediation. Encryption covers the protection component of this life-cycle, but a mature security practice and implementation must have the ability to detect attempted or successful breaches, and mitigate the damage from detected or actual security breaches. Information security vigilance from the RFP phase to the decommissioning, cradle to grave, of a system is paramount. It is human nature to become complacent. Complacency creates the opportunities those who lay-in-wait salivate over.