Financial companies are looking to extend their secure infrastructure to their business partners, service providers and clients. One of the main technologies they're using to accomplish this is encryption. Whether the company is concerned about the possibility of sensitive information being intercepted while in transit on the Internet, or must conform to regulations demanding protection of personally identifiable information (PII) or other confidential data, making information unreadable to all but authorized parties is the only way to ensure against prying eyes. But as companies begin to explore encryption services for secure communications, they're running into more deployment issues than they expected.
In order to understand the implications of how encryption works, you have to realize that there are three components that make up an encryption service: the system that does the encryption, the encryption standard used to encrypt the information, and the key used by the standard to encode the information. These components must be complementary on all three levels between the sender and the recipient in order to successfully encrypt/decrypt content.
The first component, the encryption system, can be one of three types:
- Applications -- i.e. e-mail client, plug-ins and native encryption modules.
- Infrastructure services -- i.e. messaging boundary appliances, portals, Web services and secure FTP servers.
- communications -- i.e. TLS/SSL and Session Initiation Protocol (SIP).
The problem is that these encryption systems don't necessarily interoperate. If a company's employee encrypts a document that includes PII information and sends this document to a business partner, the recipient will find the document unreadable without having a complementary system to the one used to encrypt it.
Not only must the sender and recipient have interoperable encryption systems, the recipient must also be able to support the encryption standard the sender's system used. There are multiple encryption standards, including: Public Key Infrastructure (X.509),encrypted HTML, identity-based encryption (IBE), S/MIME, SIP, Extensible Messaging and Presence Protocol (XMPP), OpenPGP and TLS. In some applications and devices, a certain encryption standard may not be supported. For example, a BlackBerry may not be able to decipher a desktop application encrypted file simply because the encryption standard isn't supported on that platform.
Finally, as if the issues above don't complicate things enough, in order to successfully encrypt/decrypt content, a recipient must be sent a key or password to decode the information. The recipient also must know whether the encryption key is asymmetric or symmetric. In some cases, such as transport-level encryption, this information is hidden from the end user, but in cases where applications or an email system initiated the encryption, the key must be derived or obtained in advance in order for the recipient to gain access to the information. In either case, key management and the distribution of keys can become a huge effort, especially if the company has many partners or clients. In particular, client access to secure content can be cumbersome since clients generally have limited access to company resources and obtaining the keys must be simple so help desk calls don't escalate.
Like any service with an enterprise scope, companies must carefully plan and design how they will use encryption in communicating with their business partners and clients. This typically involves creating a technical architecture, new processes for how sensitive information is sent, and new outside communications channels for sharing information on how to decrypt the content with recipients. In some cases, a training program must also be created for both senders and recipients on how to successfully communicate with each other using encryption services.
Organizations must understand the capabilities of the constituents they wish to communicate with and whether the organization will manage and run the services for them. In addition, with some outside entities like large client populations, an easily accessible registration process is generally needed in order for the client's applications to get the keys necessary to decrypt the messages.
Because of the complexity of managing secure communications, many financial companies have decided to keep secure content only on their Internet-facing portals and Web applications. They then draw business partners and customers to these sites where they authenticate the recipient and give them access to their sensitive information, keeping the encryption architecture confined to the company's environment where they can implement stronger protection controls. While this short-term "pull" encryption service eliminates the need to set up encryption services to a myriad of remote constituents, the cost of implementing these solutions along with client training, support and maintenance to manage these services has put a strain on many company budgets. But until a common set of standards in each of the three components that make up encryption services is completed -- or at least reduced to a few choices -- this may be the most viable solution.
On another front, the insurance industry addressed the issue of secure communications in a 2006 report, "Independent Agency Preferences for Carrier Electronic Communications," from the Agents Council for Technology (ACT), part of the Independent Insurance Agents and Brokers of America. In the report, agents identified how they wished to receive secure communications from the carriers they represented. They generally agreed they want customer PII information via email notification with a link to a secure TLS/SSL connection to the carrier's site that contains a portal with the information.
While this report only satisfied one constituent group, it did start the move by insurance companies towards standardizing how to send sensitive information. Before financial companies can begin to move their secure communications systems beyond their boundaries, other industry sectors need to conduct similar work in order to reduce the complexity of business encryption needs.
About the author:
Randall Gamby is an enterprise security architect for a Fortune 500 insurance and finance company who has worked in the security industry for more than 15 years. He specializes in security/identity management strategies, methodologies and architectures.
This was first published in October 2009