09/19/2011

Why not encrypt everything? The Value of Policy Configuration

by Dave Robertson

Push and pull delivery methodologies have evolved and improved over many years, and “ease of reading” has become better. At the end of the day though, reading encrypted messages requires more clicks and/or keystrokes than transparent encrypted messages, which require no passwords or extra steps. When the recipient opens such a message and sees his Social Security Number inside, that user will likely feel the effort was justified in the interest of personal information protection. If extra clicks and keystrokes lead to an email without sensitive content, especially if that happens repeatedly, frustrated users are going to ask questions and voice complaints.

To eliminate unnecessary frustration, organizations can enable programmable policies to decide what rules determine when encryption must occur, whether delivery is transparent or not. The policies can also determine which encryption delivery method is used, once a particular rule is triggered. For example, policies can determine whether to use push or pull methodologies. In addition, policies determine alternative message treatment, such as the addition of confidentiality warnings or ‘bounce back to the sender’ if the message contains information that simply should not go outside of the sender’s company.

ZixCorp can trigger encryption policies based on complex combinations of personal identifiers and information terms using context-specific lexicons. Thus, when instances of sensitive healthcare or financial information are found in individual email messages, only then does encryption occur. This automation of the encryption process is the most transparent for end users. I like to think of it as a safety net in the event users don’t remember to press the “encrypt button” themselves.

There are also options to trigger encryption based on a keyword/phrase in the email subject line, such as the word “Secure”. The lexicon-based scanning of all content within email and attachments and flexible policy controls, which allow you to decide how to encrypt or redirect email that contain sensitive content, are a foundational part of ZixCorp solutions and its core portfolio value proposition.

Rules based on combinations of subject keywords, email addresses, source or destination domains and many other attributes can also be assembled. Our users have found no end of interesting and valuable things to do with these capabilities. Here are a few examples to illustrate:

1) Provide ZixMobility delivery (instead of transparency delivery) for specified recipients who are almost always using their smart phones and prefer the extra message privacy that results.

2) Add special text to messages to certain destination domains which enable other policy triggers in other back office or mail systems, like Lotus Notes.

3) Bounce a notification back to senders when they have sensitive information in the subject heading, like Social Security Number. Subject headings are often copied into uncontrolled mail tracking logs or reports and should not contain sensitive information.

Once IT designers get the hang of what can be done, some of the solutions that result from clever policy design can provide some awesome features and protection!