Everything enterprises need to know about end-to-end encryption

Here’s a sobering statistic: according to the 2009 Verizon Data Breach report, 285 million records were compromised in the 90 cases that Verizon investigated in 2008. That is close to one exposed record for each of the roughly 305 million citizens in the USA.

In response to stories like these many enterprises experience an overwhelming desire to encrypt everything, set insanely strict security controls and observably scrutinize every blip on in the audit log. Don’t give into that temptation; over-reactive security may protect data but it also results in unnecessary expenses, availability problems and system performance lags.

Data security in today’s business world is a classic Catch-22. We need to protect both data and the business processes that rely on that data. To do so we need to move from a reactive fear (or compliance) driven mode to a proactive risk-adjusted data security plan, centered on an analysis of an organization’s unique data risk factors and the use of a risk-adjusted methodology to determine the appropriate data-protection processes, policies and solutions for that organization.

This article discusses the most effective ways to protect data according to its risk classification, with a focus on end-to-end encryption but also including Format Controlling Encryption, tokenization, database activity monitoring, transparent encryption and other technologies. It also provides tips for evaluating encryption and key management solutions, as well as points to consider to determine whether an enterprise’s needs would best be met by an off-the-shelf or a custom “built on-site” data security management solution.

End-to-end encryption
There are different definitions of end-to-end encryption. To some people it means encrypting data throughout its entire lifecycle, from capture to disposal. This sort of end-to-end encryption (or tokenization) does provide the strongest protection of individual data fields.

Another way to think about end-to-end, and a very practical approach to data protection, is to provide end-to-end encryption between specific parts of a solution that are in high risk areas. This approach can be applied within an enterprise or between organizations. In the latter case a supporting infrastructure that includes functions to establish trust and key management can take a long time to implement. Encryption can only provide confidentiality and integrity and must always be combined with other aspects of security, including authentication, authorization and monitoring to provide a secure overall solution. While I am a strong proponent of end-to-end encryption, not every bit of data needs to be encrypted throughout its lifecycle. The sensible approach to adopt is a risk-adjusted methodology that protects data according to its value with the appropriate layers of security.

The risk level of the data collected, used and stored in the enterprise
Risk is ascertained by a number of factors. Data that is resalable for a profit – typically financial, personally identifiable and confidential information – is high risk data and requires the most rigorous protection; other data protection levels should be determined according to its value to your organization and the anticipated cost of its exposure — would business processes be impacted? Would it be difficult to manage media coverage and public response to the breach? You also need to consider data volumes, server, connectivity, physical security, HR aspects, geography, compensating controls – and more.

Organizations with robust data classification plans typically use an automated tool to assist in the discovery of the subject data. Available tools will examine file metadata and content, index the selected files, and reexamine on a periodic basis for changes made. The indexing process provides a complete listing and rapid access to data that meets the defined criteria used in the scanning and classification process. Most often, the indices created for files or data reflect the classification schema of data sensitivity, data type, and geographic region.
A smaller business could use a simpler approach. Assign a numeric value for each class of data; high risk = 5, low risk = 1. Determine whether the data would have value to an attacker. Then factor in the possibility of that data being exposed, either via an attack by malicious hackers as well as insider malfeasance or error. High risk data residing in places where many people can/could access it is obviously data that needs the strongest possible protection.

The sad truth is that critical data is always at risk, unless it’s stored offline in a server that is itself kept in a highly secure physical environment. That’s a scenario that is obviously unreasonable for virtually all business usage.

That said, we’re currently seeing the highest number of attacks against web services, databases and data-in-transit are at high risk. The type of asset compromised most frequently is online data, not offline data on laptops, back-up tapes, and other media. Hacking and malware proved to be the attack method of choice among cybercriminals, targeting the application layer and data more than the operating system. But these vectors change so keep an eye on security news sites to stay abreast of how criminals are attempting to steal data. Attackers tend to look for the next weak link in a data flow.

Malware trends
There are two countervailing trends in malware, both likely to continue. One trend is toward the use of highly automated malware that uses basic building blocks and can be easily adapted to identify and exploit new vulnerabilities. This is the malware that exploits unpatched servers, poorly defined firewall rules, the OWASP top ten, etc. This malware is really aimed as the mass market – SMEs and consumers.

The other trend is the use of high-end malware which employs the “personal touch” – customization to specific companies, often combined with social engineering to ensure it is installed in the right systems. This is the type of malware that got TJX, Hannaford, and now Heartland. The point is: the more we create concentrations of valuable data, the more worthwhile it is for malware manufacturers to put the effort into customizing a “campaign” to go after specific targets. So, if you are charged with securing an enterprise system that is a prime target (or partner with/outsource to a business that is a major target) you need to ensure that the level of due diligence that you apply to data security equals or exceeds that expended by malicious hackers, who are more than willing to work really, really hard to access that data.

Enterprise data protection
Businesses can look at enterprise-class end-to-end encryption solutions along with newer approaches — such as tokenization, Format Controlling Encryption, and Database Activity Monitoring.

Tokenization
With tokenization, an alias of the original data points to real data or a secondary database from which the real data can be derived) — move the problem to another place where it may be more cost effective to address the problem. The solution is typically based on a central tokenization system that needs to be on-line and there may be a need for minor additional storage but the tokens usually save storage and CPU cycles. This approach can reduce the complexity on some systems but may require de-tokenization plug-ins on some of the systems. Key rollover is usually simple with this approach. This approach is emerging as a realistic protection method for some type of high risk data like credit card information and social security numbers — especially in this tough market when cost effective solutions are critical.

With tokenization (or Format Controlling Encryption – see below), high risk data is systematically protected from hackers and criminals over its lifecycle under an auditable and controllable process. At the same time, these techniques solve the challenge of separating duties from employees and administrators who need to manage data but perhaps don’t always need to see live data like SSNs. PCI is a good example of a regulation that specifically calls for this kind of separation of duties.

Format Controlling Encryption
Technologies like Format Controlling Encryption cannot make the process of retrofitting encryption into legacy application environments simpler but it will provide protection while the data fields are in use or transit. This aspect is similar to the tokenization approach.

Format Controlling Encryption puts an end to the need for expensive and time-wasting data format and schema changes caused by data scrambling, By preserving the character-by-character format of an encrypted string of data, the protected data can be plugged into existing fields with no need for database schema changes. This allows encrypted data to be used, for example, in testing and troubleshooting in less-controlled environments such as production servers, regardless of infrastructure or application format requirements and with no worries that the test data will be exposed.

Format Controlling Encryption also enables data-level encryption to be integrated into legacy and existing systems, supports numeric and alphanumeric data formats, allows formats to be defined on a character-by-character basis, provides platform independence and the ability to call encrypted data into a script or via command-line.

Database Activity Monitoring
In combination with file level encryption of databases Database Activity Monitoring can provide appropriate solutions for lower risk data. There is a need to discuss data risk factors and to use a risk adjusted methodology for determining appropriate solutions.

These approaches can be very important in the data warehouse, for example, where aggregation on the clear text values are frequent. Format Controlling Encryption may require 10 times more CPU cycles than Transparent Database Field Encryption during the decrypt and search operations. File level encryption of the database can provide fast search operations since data and index information is in the clear inside the database. In some cases we’re also seeing Database Activity Monitoring used by businesses that are just beginning to roll out a comprehensive data security plan, or companies are using Database Activity Monitoring alone to protect lower-risk data.

Issues with the use end-to-end encryption
Using recent firsthand examples from the retail sector, which apply in general to all industries, using end-to-end to protect payment card data involves encrypting that data at the initial point of capture (card swipe, Web site form or mobile payment). The data remains encrypted as it travels via internal network and is stored in temp files. It is only decrypted under very specific, controllable circumstances and by an extremely narrow set of persons and systems.

We have talked with organizations that have implemented end-to-end encryption, and over and over again they say the real problem they run into with encryption is enterprise key management. And for companies that “grow into” end-to-end encryption, key management can rapidly become a nightmare. Based on our research with these leading companies, I’d argue that a tactical approach to key management is very counter-productive.

A tactical approach — a staged rollout — virtually always results in numerous point solutions. Implementing a series of point solutions at each protection point will introduce complexity that will ultimately cause significant rework. Protecting each system or data set as part of an overall strategy and system allows the security team to monitor and effectively administer the encryption environment including managing keys and key domains without creating a multi-headed monster that is difficult to control.

Key management?
The way cryptographic keys are generated and managed throughout their lifecycle is critical because your data security solution is only as good as the protection offered by your keys. Real security depends on two factors: where are the keys stored and who has access to them?

Enterprises should look for solutions that provide the capability to centralize all key management tasks on a single platform and automate administrative key management tasks. This provides both operational efficiency and reduced management costs. Other features to look for include:

  • The ability to securely synchronize local data encryption keys with the back-end decryption systems.
  • End to end only encryption keys should be created per terminal
  • Keys should be generated in a secure environment
  • Changes to the encryption state of application must be securely controlled.

Some software and database based encryption schemes often lack these basic encryption key management security controls.

Other essential key management features include a secure mechanism for key rotation, replication and backup. Any encryption product that does not provide a secure means of recovering/replicating keys is a catastrophe waiting to happen, and one that’s unfortunately likely to manifest in a disaster recovery situation where complete backups and necessary files may not be immediately accessible and keys need to be replicated quickly. Look for a solution that allows keys to be replicated when a quorum comprised of a pre-determined number of people authenticate themselves to the system.

Keys should also be securely backed up and rotated periodically to ensure absolute security. The backup benefits are obvious and key rotation is a process that automatically decrypts data using existing encryption keys and then re-encrypts it with new keys, at pre-selected intervals. Depending on the sensitivity of data that is being encrypted and the government and industry regulations that effect a particular organization, companies may want to look for a solution that supports Dual-Control and Split-Knowledge implementation of encryption key management. This feature blocks one-party changes and requires two people to authenticate major changes, in the same way as particularly large bank checks require two signatures to be valid.

Custom encryption solutions – the on-site development projects – vs. off-the-shelf solutions?
The build vs. buy decision is made purely based on the misconceived notions from management about one option or the other. This is a decision that requires analysis and insight. Why re-invent the wheel if several vendors already sell what you want to build? The complexity of today’s computing environments only magnify the difficulties of implementing “on-site service’ development. For example, time consuming “on-site service’ development requires considerable due diligence to scope and plan the entire project. Developers must be trained and get experience on the specific platform and code must be carefully tested. This process normally takes several years on some platforms before the required quality is reached. And unless the programmers are versed in the latest integration best practices, you risk ending up with something that’s less than what you hoped and planned for.

I suggest that enterprises use a Build or Buy Analysis to determine whether it is more appropriate to custom build or purchase a product. When comparing costs in the buy or build analysis, include indirect as well as direct costs in both sides of the analysis. For example, the buy side of the analysis should include both the actual out-of-pocket cost to purchase the packaged solution as well as the indirect costs of managing the procurement process. Be sure to look at the entire life-cycle costs for the solutions.

  • Is the additional risk of developing a custom system acceptable?
  • Is there enough money to analyze, design, and develop a custom system?
  • Does the source code have to be owned or controlled?
  • Does the system have to be installed as quickly as possible?
  • Is there a qualified internal team available to analyze, design, and develop a custom system?
  • Is there a qualified internal team available to provide support and maintenance for a custom developed system?
  • Is there a qualified internal team available to provide training on a custom developed system?
  • Is there a qualified internal team available to produce documentation for a custom developed system?
  • Would it be acceptable to change current procedures and processes to fit with the packaged software?

A cost effective approach can be to use a single solution and process to provide a high quality of data across development, testing and staging environments and to protect sensitive data across development, testing, staging and production environments. In my experience packaged software offers a compelling alternative to the low-quality, time-consuming quagmire of “on-site service’ development.

Issues to consider when evaluating an end-to-end encryption solution
The first thing to ascertain is whether the solution really does encrypt the cardholder data at every high-risk point in the enterprise. By some definitions, end-to-end must start at the card swipe and end at the acquirer or the archiving system in each enterprise. Some applications in the data flow will need to see clear text or partial clear text data. This will require proper security controls to limit the exposure on these systems. This can be defined as End-to-end protection, or Point-to-point encryption which is more practical in a legacy environment than a more purist full end-to-end encryption. Solutions that do not provide appropriate end to end protection capabilities leave unprotected cardholder data within the enterprise and criminals may target this data. End to end encryption schemes will require that the final destination is part of an infrastructure including trust and key management. A balanced risk-based protection approach can minimize encrypt-decrypt-encrypt cycles can have an adverse impact on network resources, and will add processing overhead to system components. This approach can provide the highest level of transparency to legacy applications and minimize the performance impact on the overall system.

The protection of less-critical data
Enterprises can look at one, or more likely a combination of the following solutions to secure data that isn’t ranked high risk.

  • Web Application Firewall – Protects against malicious attacks by inspecting application traffic and blocking dangerous activity
  • Data Loss Prevention – Tags and monitors movement of sensitive assets and protects against the unintentional outbound leakage of sensitive assets
  • Database Activity Monitoring – Inspects , monitors, and reports database traffic into and out of databases; can block malicious activity; but often produces false positives.
  • Database Log Mining – Mines log files that are created by databases for good or bad activity.

The role of policies and procedures in protecting data

The role of policies and procedures in protecting data
Far too often enterprises establish good strong data security policies, everyone signs off on those policies and then blithely wanders off and resumes business as usual. Studies from Forrester, Ponemon and other research firms indicate blatant disregard for security policies is widespread – users either don’t understand the policies or disregard policies that they believe are too strict and which interfere with getting the work done easily and quickly.

Businesses need to have comprehensive training programs detailing the importance of protecting private data, and the reasons for the policies that are in place to do so, and real consequences for any and all attempts to thwart security policies. Then we need to enforce those policies using technologies like role-based access to ensure that no one accesses information that their job doesn’t require them to see, automated enforcement of security policies to block forbidden activities, system auditing to see who is doing what with protected data. Managers can use this information to track trends, analyze potential threats, support future security planning, and assess the effectiveness of the solutions, policies and procedures already in place.

Auditing shouldn’t be a huge data dump of every possible bit of information; to be useful it should be selective. Selective and granular auditing saves time and reduces performance concerns by focusing on sensitive data only. Ideally, the logs should focus on the most useful information for security managers; that is, activity around protected information. Limiting the accumulation of audit logs in this way means more critical security events are highlighted and reviewed.

Strong database security policies and procedures must be in place to accommodate the regulatory compliance environment. To comply with most privacy regulations you must protect, audit and segregate duties for sensitive data in databases. A mature encryption solution will offer automatic and enforced segregation of duties between DBAs and security officers–enabling centralized management of security parameters as well as a system of integrity checks and self-protection of individual modules, user accounts, and database extensions in distributed environments and across the leading relational databases, including Web and Internet-enabled database applications.

Security tools play an important role in securing sensitive data from acquisition by the enterprise until its storage and deletion. However, it remains the task of management to make real-world assessments of risks to data, how those risks are best mitigated and how these assessment decisions are promulgated and enforced throughout the enterprise. Establishing appropriate enterprise architecture key management, with policy-driven enforcement and auditing, maximizes data security efforts. Neglecting to support security investments with sensible policies and practices results in wasted time, money and vulnerable systems.

Don't miss