ZSentry means less work with IT and users. Encrypt and decrypt with one click, including two-factor user authentication. Your ZSentry-secured solutions will feel exactly like what you use today on the desktop and phone, and your recipients' solutions will also benefit from your use of ZSentry and yet feel exactly like what they use today, with no changes.
HOW IT WORKS
Security Red Flags
It often makes more sense to evaluate security products from their potential business impact rather than from their product claims or technological side. Here, we take the business impact approach and talk about some of the common warning signs, Red Flags, and how you can use them to guide your choices.
1. Red Flags
Red Flag #1: Sign a HIPAA Business Associate Agreement. This usually means that the security solution is exposing you to unnecessary technical, business, and legal risks.
ZSentry Premium operates in full HIPAA compliance without requiring users to sign a Business Associate Agreement (BAA), although a BAA can be signed if desired.
Red Flag #2: Centralized directory for encryption. Someone other than yourself has your business partners' and customer's contact information, with names, email addresses and other data.
In addition to being a single point of failure, this means that your data may become available or be sold to solution providers and other businesses. This also means that in the event data is lost or stolen, it is linkable to a particular person, at risk of violating HIPAA, HITECH, and other regulations.
Red Flag #3: It Just Works. This is fine but beware of hidden liabilities. For example, make sure that your keys are not escrowed in the servers providing the solution, as with IBE (Voltage). Nothing is safe in servers, not only from attackers but also from service providers and employees.
Red Flag #4: Key Management "in the cloud". Beware that nothing is safe "in the cloud".
Customer data storage, including keys, can only be securely maintained in the "cloud" with encrypted, de-identified numbers, where the access keys should be provided and secured by yourself. See also comments to Red Flag #16.
Red Flag #5: Service automatically detects and encrypts messages that contain personally identifiable information. This means that your service provider actively stores and scans all your communications.
Also sometimes mentioned as:
Red Flag #6: Ensure Business Associates understand HIPAA implications. This means that your business risk and reputation depends on others, who you cannot control. Instead, your security solution should limit the risk posed by others.
Red Flag #7: Keys provided by "Web-of-Trust". This means that there is no entity responsible for revocation of keys, or for assuring that the keys are up-to-date, or valid for the intended purpose. This may work with a group of friends, but not when your risk and reputation depend on it.
Red Flag #8: Require Users to Buy a X.509/PKI or S/MIME Certificate. For a variety of reasons, and not just cost, this has not worked since it was first proposed more than twenty years ago.
Even though conventional PGP and PKI/X.509 solutions are notoriously far too difficult to use, a number of providers use servers to automate some of the tasks that were previously done manually. While this does improve ease-of-use, it may compromise HIPAA/HITECH Safe Harbor conformance, and still has to deal with several limitations of the underlying technologies PGP and X.509/PKI.
Red Flag #9: Protected with passwords. Passwords are notoriously insecure and their management is a nightmare even for a few dozen users.
Passwords are not considered secure by HIPAA, HITECH, the Federal Financial Institutions Examination Council (FFIEC), and other regulatory regimes. Compliant authentication solutions should use two-factor authentication, present familiar user interfaces (to prevent user errors), prevent dictionary attacks, and not store authentication credentials (such as passwords and usernames) online or, more desirably, anywhere.
Red Flag #10: Use the fax. It is possible for health care providers to use fax, voice mail, or even regular email and avoid a HIPAA violation. However, the cost, burden and liability to do so can be substantial under HIPAA, HITECH, and state privacy rules, including mandatory breach notification. Thus, using a fax makes it difficult to ensure privacy and implies added liability. Read more >>
Red Flag #11: Our employees are trusted. Your business data security should not depend on trusting the service provider's employees ("we promise we won't look"), who you cannot select, verify or control. It is known that more than 70% of all security breaches are due to internal causes. Not even the FBI can prevent having a national security traitor for many years among their own directors.
Red Flag #12: We train your employees. This means that your employees will need to be trusted to follow security procedures, which failure will fall on your business and is at the root of more than 70% of all breaches. See Red Flag #11.
Red Flag #13: Just install a plugin for your Mail client or Web browser. Also mentioned as "downloaded and installed in minutes". This means that you have to download an untrusted new component, that opens your system to new zero-day exploits, will need to be always updated, and may cease to work when you update your application or other plugins.
Red Flag #14: Delivered using a secure SSL/TLS encrypted connection. This delivery process falls short of basic security requirements for email messages (see below). See also Red Flags #1 and #5.
Red Flag #15: If the recipient is not registered, the message is sent to a secure portal. This actually means that the recipient must register anyway, and reduces usability.
Red Flag #16: We can use your information for purposes including... This statement may sound assuring but it is open-ended and does not exclude any purpose or person.
This Red Flag is actually worse than the notorious "opt-out" policy, where sharing your protected information is the default mode, as there is no limit that you can request (by opting-out) regarding the use of your protected information.
Red Flag #17: Beware of conflicts of interest between the distinct roles that may be played by the same service provider, which may increase both your risk and liability. Also called the "fox taking care of the hens" scenario.
For example, if (1) a service provider for secure email is also (2) a provider of anti-virus scanning service, then the service is potentially made aware of protected information and the "Safe Harbor" provision may not apply (see Red Flag #1).
Red Flag #18: Impossible to break. Our servers are in a secure facility. It is not a matter of if, but when.
Regardless of how safe and secure people claim something online is, there always seem to be someone who can eventually crack access to it. Not even US Department of Defense and Pentagon servers are secure.
2. Regulatory Compliance and Fines
These and other Red Flags are important because online security and encryption are gaining importance, for some very clear reasons:
For example, if you are in the health-sector, then you probably must comply with the US HIPAA (Health Insurance Portability and Accountability Act) and HITECH Act (Health Information Technology for Economic and Clinical Health Act of 2009) and other regulations.
However, a solution may be 100% HIPAA-compliant and yet expose your organization to hefty fines in case of a fault or breach, while another solution may present a HITECH Safe Harbor with no fines even if there is a breach. And any security solution must be, first and foremost, usable — otherwise, users will not adopt it, or use it poorly.
3. Security Technologies
For further consideration, and as summarized here, we also analyze the various technologies used in security products, using peer-reviewed metrics and considering usability as well as security.
There are five known security technology players: X.509/PKI, PGP, SSL/TLS, IBE (Voltage), and ZSentry. Even though there are many providers of security solutions, these are the only five known security technologies that can power any security solution of interest, excluding passwords as notoriously insecure.
Of the five players, PKI X.509 was released in 1988 and followed by the S/MIME extension for email encryption, PGP in 1991 (also later followed by an S/MIME extension), and the first practical IBE system was developed in 2000. SSL/TLS was first developed ca. 1996. ZSentry was first used in 2000, was applied to secure email in 2004, and became available to other online protocols starting in 2009. ZSentry also supports PKI/X.509 and PGP, and extends these standards in significant ways.
X.509, PKI, PGP, S/MIME
With PKI and PGP (with or without S/MIME), while their key management solutions are secure, they are notoriously at fault in terms of usability (due to complexity, certificate revocation, public-key signing and other issues reviewed in the references [*]). This, in turn, creates security problems because users are not able to correctly apply expected procedures.
For example, in the work of Alma Whitten and J. D. Tygar [*], the authors report on a user test demonstrating that when the test participants were given even 90 minutes in which to sign and encrypt a message, the majority of them were unable to do so successfully.
How about newer versions? User interfaces get flashier, help files get longer but the usability problems remain. After almost 20 years of development, improving the graphical user interface and the help dialogue in IT security products seems to have reached a point of diminishing returns.
Users find PKI or PGP public-key management hard to understand, hard to use, and counter-intuitive. When you send a postal mail, for example, you do not ask the recipient to first send you an envelope. And you do not ask who they trust. But that is what happens when you send a PKI or PGP message — you need to first ask the recipient for her public-key. Which must be digitally signed by someone that is trusted by someone you both must trust.
With IBE (Voltage, MessageGuard), while it is usable it is not secure (mandatory key-escrow, no key revocation, and other issues).
In IBE, the recipient's private key (which allows received messages to be decrypted) is provided by and is available at a server, the PKG (the Private Key Generator). In the IBE design, both the recipient and the sender must trust the PKG. But, for example, if the PKG provides the recipient's private key to other parties in addition to the recipient, this breaks the sender's message confidentiality. There is nothing that you, the sender, can do about it. You do not even know about it. There is a false sense of security. Oblivious to what is happening you may continue to send what, you think, are secure messages. This can happen without the recipient's cooperation or knowledge, in spite of assurances by the PKG and best efforts by the recipient to safeguard her private-key.
Because IBE has no key revocation, a compromised private-key cannot be terminated when desired. IBE has a built-in revocation delay that is equal to the time remaining for key expiration. This implies a very large or even undefined delay for key revocation.
Further, think about whether you want a hacker, a bug, a virus, or even someone working with the PKG server providing your "secure email" service, to have access to your private-key — the same private-key that can decrypt any email you send. You don't.
Due to its success in online sales transactions and online banking, SSL/TLS has been tried to provide email security functionality — for example, in one of the email-security solutions by Postini. However, SSL/TLS falls short of basic security requirements for email. For example, because SSL/TLS messages are only encrypted in-between servers, third parties can compromise message security and integrity at the security-gaps created at each end-point (i.e., not only at Postini but also at the user's ISP, DSL provider, and any other intervening server or cache system), and at the user's machine. This falls within the Red Flags #1 and #5.
Relying on SSL/TLS as the encryption mechanism for protecting the delivery of email messages also creates a single point of failure for all messages, which vulnerability can be remotely and anonymously exploited.
ZSentry avoids all the Red Flags above, is HIPAA compliant, and provides a HITECH Safe Harbor. ZSentry also overcomes the security and usability limitations of the conventional technologies PKI, PGP, IBE, and SSL/TLS, while supporting PKI/X.509 and PGP, and extending these standards in significant ways. ZSentry further supports SAML and SSO, so that it can be part of a federated-identity ecosystem.
The ZSentry technology operates with the "Sans Target" principle:
the ultimate and fail-safe defense against data theft is to not have the data in the first place. ZSentry mathematically
eliminates references used in conventional security systems — which references are themselves tar gets — and also sufficiently hardens passwords against dictionary or brute-force attacks. This is leveraged to protect other
data, by encryption using the "Sans Target" keys. Consequently, the main risk issues such as those
caused by key or password file breach are actually eliminated [1-2], so that the ZSentry solution can offer
a HITECH Safe Harbor with no fines even if there is a breach.
Usability is also increased with ZSentry.
In two security versus usability comparative analyses [1-2] of email authentication and encryption
solutions using the technologies PKI, PGP, IBE, and ZSentry, the latter shows a marked synergy between
security and usability. with ZSentry, increased usability increases security.
References Gerck, E. (2007). Secure email technologies X.509/PKI, PGP, IBE and Zmail. In Corporate Email Management, Chapter 12, Edited by Krishna SJ, Raju E., pp.171-196, Hyderabad, India, ICFAI University Press. Available online at http://email-security.net/papers/pki-pgp-ibe-zmail.pdf.
 Neppe, V. M. (2008). The email security-usability dichotomy: Necessary antinomy or potential synergism?. In Telicom, 21:3, May-June, pp.15-31. Available online at http://email-security.net/papers/usable-secure-email.pdf.
 Whitten, A. and Tygar, J. D. (1999). Why Johnny can't encrypt: A usability evaluation of PGP 5.0. In Proceedings of the 8th USENIX Security Symposium. Available online at http://www.gaudior.net/alma/johnny.pdf
 Feghhi, J., Feghhi J., and Williams, P. (1998). In Digital Certificates: Applied Internet Security. Addison-Wesley, ISBN 0-20-130980-7. More on this topic: Comparisons and Technical Review »
|Main Technical Notes|