Solutions for email security are often plagued by hidden costs, hidden liability, and lack of both security and usability. Even though the choice of a security solution involves many aspects, what is clear is that a selection process should not overlook some obvious red flags.
Red Flag #1: Sign a HIPAA Business Associate Agreement. This means that the security solution is exposing you to unnecessary technical, business, and legal risks.
Signing a HIPAA Business Associate Agreement is mandatory if the solution does NOT take advantage of the HIPAA "Safe Harbor", which requires encrypted and de-identified data. In addition to legal model and harmonization problems for you in signing another contract, absence of the "Safe Harbor" means that if a breach of unsecured protected health information (PHI) is discovered, fines may be levied and notices to each person affected are required. In addition, contracts with a "Covered Entity" may be at risk and the reputation of all business involved will almost certainly be harmed.
Red Flag #2: Centralized directory for email 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. 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 a "hosted solution that automatically encrypts email based on your policy definitions". This not only falls within the Red Flag #1 and excludes a "Safe Harbor", but potentially exposes your business to covert surveillance as well as to legal loopholes allowing service providers to use and sell your information as it is not "data in motion".
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.
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 a privacy and HIPAA violation to allow faxes with personal information to be available in an office area that can be accessed by anyone other than the intended recipient, which is also notoriously difficult to ensure.
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 plug-in 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 references 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 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.
Security claims should not depend on being "impossible to break" (the Fort Knox approach), but on the impossibility of finding anything of value when that happens. This strong concept of security does not assume any limitation on the attacker, which limitations are often found to be unrealistic but only after an attack succeeds.
Regulatory Compliance and Fines
These and other Red Flags are important because security and email encryption are gaining importance, for some very clear reasons:
- Email phishing, spam, email disclosure, and identity theft are major sources of fraud losses today.
- Protecting consumer privacy is becoming a duty for organizations worldwide.
- Organizations in regulatory privacy and security compliance regimes (e.g., HIPAA and FFIEC) need to communicate in a way that is compliant.
- After 02/2009, fines for non-compliance (HITECH Act) have sharply increased up to $1.5 million.
Conclusions
The choice of a security solution involves many aspects, including not to overlook the 18 red flags we discuss in this article. We also observe that privacy and security compliance is not enough — any security solution must be, first and foremost, usable. Otherwise, it will not be used or used incorrectly, defeating the security objective.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.
No comments:
Post a Comment