The statistics regarding the impact of EMR (Electronic Medical Records) on efficiency seem far less than encouraging. As commented privately to me, in more than one occasion, significant net drops in provider efficiency are the norm, despite the hype.
The push for EMR adoption on the part of the government and payers is about data, not provider productivity (at least not the kind of productivity that improves a provider's bottom line). A 6% penalty on Medicare billing or a $64,000 incentive is small compared to the real cost of EMR adoption for many providers. The gap between what providers are being sold on and reality could hardly be broader in the industry...
So, the reality is that today's EMR is a really hard thing to do well, as also evidenced by the reported high numbers of failed EMR conversions and large number of second EMRs (replacing a first EMR).
Electronic Medical Records -- the new email frontier?
In contrast, using encrypted email can be much easier for adoption and even provide an EMR basis IF it can complement rather than replace an email system. It should require no changes in the user GUI, no learning, no commitment in other areas, no change to any other aspect of the operation, and should have low cost compared to the base system (email).
This is exactly what ZSentry at http://zsentry.com has been providing, as a complement system to Google Apps, Outlook, iPad, and other existing email solutions, enabling HIPAA and HITECH Safe Harbor (the next need after HIPAA) practically "out-of-the-box".
And ZSentry can also be used as part of a local EMR, allowing secure communication in and out of it. One such hybrid ZSentry/EMR system has recently been certified by the DHHS in the US ARRA program.
So, Yes, albeit the statistics on current EMR efficiency are not encouraging, we can start with simpler systems that are, well, simpler to work with.
How about the future?
If we see the statistics of CNC (Computer Numerical Control) adoption in the early 50's in the US, in the 70's for word processors, and other IT application examples, including the Internet itself, we will see the same trend of less efficiency, frustration, followed by exponential, unbelievable at the time, improvements in efficiency, cost, quality, and every other parameter (except when people look at direct employment reduction as a downside, rather than as an opportunity for progress).
Now, ask yourself how much would it cost to run an IT company the way a physician runs his office today?
For example, how many people-hours/day are used faxing in a practice today? And faxes are not even HIPAA-compliant...How long can this waste go on?
It's just natural that the future comes with a shock-wave. But automation-driven efficiency improvements grow fast and are worth the trouble. The U.S. Census Bureau took eight years to complete the 1880 census, but just one year for the 1890 census. The difference then: automatic tabulation with Hollerith cards.
Now, fast-forward to the US health-care sector in 2011. What's happening with the SOHO and SMB health-care markets? They are shrinking fast since ca. 2000, and becoming far more competitive in price. For example, the share of solo practices among members of the American Academy of Family Physicians fell to 18 percent by 2008 from 44 percent in 1986. And US census figures show that in 2007, just 28 percent of doctors described themselves as self-employed, compared with 58 percent in 1970. Many of the provisions of the new health care law are likely to accelerate these trends in the health care sector.
Because efficiency will become even more critical for the survival of solo and small practices, they may be more likely to use simpler, secure email first and move to EMR as possible. I doubt they will continue to use fax, or even dare to ask their patients to run to the pharmacy with a written prescription, or refill by phone. Larger health-care providers may also see faster returns by using simpler systems first. Keep It Simple -- and I see no need for adding a second S at the end.
Ed Gerck
Welcome to Email-Security. This is a technical development forum dedicated to a fresh exploration of the Internet email security issues of today, with website at http://email-security.net. Comments and paper contributions on the theme of email security are welcome. Papers will be peer-reviewed before publication. Product and service listings are also welcome, see website.
Showing posts with label HIPAA. Show all posts
Showing posts with label HIPAA. Show all posts
Sunday, July 17, 2011
Wednesday, June 29, 2011
Email vs Postal Mail Security
"If can send this document by postal mail, why can't I email it?"
Saying that email is like a postcard, that anyone can read and even write on, is usually not enough to highlight the differences. After all, there are so many emails out there, people think, that email is "protected by numbers." And anyone can also open my envelope and read my postal mail.
What's the difference?
To further clarify the difference, it is useful to consider the different roles of an email service provider versus a postal mail or courier service in terms of security of medical records. A health care organization (HCO) must comply with HIPAA (medical records privacy rules) to assure the privacy of a patient's Protected Health Information (PHI). To send PHI, the HCO has a legal obligation to sign a Business Associate Agreement (BAA) with any service provider that may become aware of the PHI, assuring that the PHI will be protected as determined by HIPAA.
The US Post Office and courier services do not need to have a BAA to transfer mail. It is legally understood in HIPAA terms that the usual "sealed envelope" is enough to protect the PHI and deny potential access to it by the service provider -- even though access is clearly possible by the service provider personnel, and would require just opening the envelope.
However, "opening the envelope" would have to be done by someone first going through the physical access controls of the mail provider, is a physical act that can be done only one envelope at a time, takes time and space, can be observed and reported by a co-worker or someone else (including video surveillance). Typically, several people need to be involved and would need to collude in an entire mesh of secret events. Further, "opening the envelope" is still likely to leave traces that the recipient can see.
This is not the case with electronic records, such as electronic PHI (ePHI). A factor that militates against ePHI is the fact that although paper and electronic records are both vulnerable to subversion, it is a lot easier and faster to read what is in an electronic record somewhere, or search for specific information, than it is to read or search what is on paper in a closed envelope.
HIPAA enforcement and patients are also well aware that electronically one can read, search, and even modify a million records with as little as a few keystrokes, for example from a cybercafe in Moldavia or somewhere in China.
These are critical vulnerabilities that need to be addressed when using ePHI - for example, that mass disclosure and potential subversion can be so readily accomplished from the safety of a remote laptop or phone, and that it would be unavoidable or even undetectable.
To answer these concerns, the email provider must demonstrate a number of barriers, including defense in depth. This should be based not only on cryptographic assurances, but how they are distributed, and how ePHI entering the email provider is bound to communication channels in a manner that the ePHI is rendered demonstrably inaccessible to an attacker, both through physical access controls and through cryptographic protocols.
Moreover, the email provider should include a step-by-step description of the process, available for auditing, so that when someone asks, "What if the intruder succeeds in breaking into the system to change X?" this can be clearly answered, for example, by (i) to change X would cause a subsequent binding failure, thus it would be detectable except with parallel access to Y and Z, which are independently inaccessible; or (ii) knowledge of an alternate (and attacker-desirable) value for X is computationally impossible to achieve during the PHI lifetime period, and the effort could not be leveraged to any other X.
In short, the email provider should use not just cryptography but also other techniques to make it is as impossible as desired to tamper with the PHI. This includes server actions to protect each client and to protect the servers from malicious use of the clients.
In addition to the foregoing barriers, "opening the envelope" by the email service provider staff or online attackers would require having the keys to do so. However, where and how to securely keep the keys from insiders, and who watches the watchers?
Looking at NASDAQ, Epsilon, Citibank, and other high-profile "secure service provider" breach cases in 2011, shows a bleak view as not even large organizations could prevent such attacks.
However, these requirements can be easily met by an email service provider using the ZSentry Sans-Target technology, because online servers and personnel simply do not have the keys to do it, there is no copy of the keys anywhere, and the keys are too large for a trial-and-error attack to succeed in practice.
Further, ZSentry treats the email body as a "data blob" and does not scan it. There is also no condition whereby the ZSentry service or personnel could be made aware of the ePHI, providing even stronger protection for an email service provider using ZSentry services for encryption.
Therefore, in addition to assuring that the ePHI is encrypted and de-identified, an email service provider can use the ZSentry technology to technically prevent anyone, including own personnel and online attackers, from breaking the encryption or the de-identification.
More info in answer to the question "Why is ZSentry secure?" in http://zsentry.com/security-email-faq.htm
Saying that email is like a postcard, that anyone can read and even write on, is usually not enough to highlight the differences. After all, there are so many emails out there, people think, that email is "protected by numbers." And anyone can also open my envelope and read my postal mail.
What's the difference?
To further clarify the difference, it is useful to consider the different roles of an email service provider versus a postal mail or courier service in terms of security of medical records. A health care organization (HCO) must comply with HIPAA (medical records privacy rules) to assure the privacy of a patient's Protected Health Information (PHI). To send PHI, the HCO has a legal obligation to sign a Business Associate Agreement (BAA) with any service provider that may become aware of the PHI, assuring that the PHI will be protected as determined by HIPAA.
The US Post Office and courier services do not need to have a BAA to transfer mail. It is legally understood in HIPAA terms that the usual "sealed envelope" is enough to protect the PHI and deny potential access to it by the service provider -- even though access is clearly possible by the service provider personnel, and would require just opening the envelope.
However, "opening the envelope" would have to be done by someone first going through the physical access controls of the mail provider, is a physical act that can be done only one envelope at a time, takes time and space, can be observed and reported by a co-worker or someone else (including video surveillance). Typically, several people need to be involved and would need to collude in an entire mesh of secret events. Further, "opening the envelope" is still likely to leave traces that the recipient can see.
This is not the case with electronic records, such as electronic PHI (ePHI). A factor that militates against ePHI is the fact that although paper and electronic records are both vulnerable to subversion, it is a lot easier and faster to read what is in an electronic record somewhere, or search for specific information, than it is to read or search what is on paper in a closed envelope.
HIPAA enforcement and patients are also well aware that electronically one can read, search, and even modify a million records with as little as a few keystrokes, for example from a cybercafe in Moldavia or somewhere in China.
These are critical vulnerabilities that need to be addressed when using ePHI - for example, that mass disclosure and potential subversion can be so readily accomplished from the safety of a remote laptop or phone, and that it would be unavoidable or even undetectable.
To answer these concerns, the email provider must demonstrate a number of barriers, including defense in depth. This should be based not only on cryptographic assurances, but how they are distributed, and how ePHI entering the email provider is bound to communication channels in a manner that the ePHI is rendered demonstrably inaccessible to an attacker, both through physical access controls and through cryptographic protocols.
Moreover, the email provider should include a step-by-step description of the process, available for auditing, so that when someone asks, "What if the intruder succeeds in breaking into the system to change X?" this can be clearly answered, for example, by (i) to change X would cause a subsequent binding failure, thus it would be detectable except with parallel access to Y and Z, which are independently inaccessible; or (ii) knowledge of an alternate (and attacker-desirable) value for X is computationally impossible to achieve during the PHI lifetime period, and the effort could not be leveraged to any other X.
In short, the email provider should use not just cryptography but also other techniques to make it is as impossible as desired to tamper with the PHI. This includes server actions to protect each client and to protect the servers from malicious use of the clients.
In addition to the foregoing barriers, "opening the envelope" by the email service provider staff or online attackers would require having the keys to do so. However, where and how to securely keep the keys from insiders, and who watches the watchers?
Looking at NASDAQ, Epsilon, Citibank, and other high-profile "secure service provider" breach cases in 2011, shows a bleak view as not even large organizations could prevent such attacks.
However, these requirements can be easily met by an email service provider using the ZSentry Sans-Target technology, because online servers and personnel simply do not have the keys to do it, there is no copy of the keys anywhere, and the keys are too large for a trial-and-error attack to succeed in practice.
Further, ZSentry treats the email body as a "data blob" and does not scan it. There is also no condition whereby the ZSentry service or personnel could be made aware of the ePHI, providing even stronger protection for an email service provider using ZSentry services for encryption.
Therefore, in addition to assuring that the ePHI is encrypted and de-identified, an email service provider can use the ZSentry technology to technically prevent anyone, including own personnel and online attackers, from breaking the encryption or the de-identification.
More info in answer to the question "Why is ZSentry secure?" in http://zsentry.com/security-email-faq.htm
Saturday, May 28, 2011
Silverlight, Flash, PDF and other Online Form Techniques
[Target Audience: Developers and System Administrators]
There seems to be growing interest for an online form service allowing customers to collect input from users and send it back as structured information to organizations, while preserving confidentiality including input, transmission, archive, access, and auditing functions.
The ability to enable customers to style online forms, for different server scenarios including absence of server-SSL input protection, should also be part of the available customer-design process. Further, the online form service should allow customers to use web forms, email forms, SMS forms, storage file forms, and any other communication process.
ZSentry is currently beta-testing such a Secure Online Form service that meets these considerations.
This work has led us to think more deeply about the pros and cons of Silverlight, Flash, PDF and other methods used to provide online form functions, as well as security and usability, which are the motivations for this posting and feedback.
In many cases of interest, the online form service must assure full HIPAA compliance. Safe Harbor compliance (even without HIPAA) is also coming to the foreground given the high profile and costs of recent breaches such as with Epsilon and Sony.
From the security viewpoint, and contrary to ZSentry for Google Apps (where both the need for HIPAA and Safe Harbor compliance can be satisfied by ZSentry), online forms as enabled by Google Docs cannot at this time be used by ZSentry as a basis for such secure service. The recent security breaches caused by phishing attacks against Google Apps and Gmail further highlight the concerns of storing plaintext information in online services such as Google Docs.
Our usability starting point is that online form functions are "critical" and, thus, in principle should be usable without asking the user to download or do anything else.
Usability is also necessary to ensure security, as we mention elsewhere (Usability is a system's #1 Security Property). In short, a secure online form service that is secure but not usable will not be used and, therefore, will actually fail to be secure. If security is too difficult or annoying, users may give up on it altogether.
Therefore, while it is OK for an information or help document to be available in PDF (with all the PDF requirements/problems to be met and solved at the user side), users can either view the PDF using any quick view software/service (including Google) or just move on to something else. Not so with an online form that needs to be entered.
We also see that many users are just that -- users -- and have no admin privilege in their devices. Increasingly, devices are locked (also by manufacturers -- see iPad vs Flash) for installation.
These concerns go against Silverlight. It could be better to use Flash (more widely available) but still many users would be left out as new Flash versions come out quite frequently and many users cannot update or do not like to bothered by yet another update. Silverlight also suffers from frequent updates.
How about JavaScript? It is commonly available. However, even JavaScript should only be used to provide added usability, while the online form itself should be functional without JavaScript. This is important not just because some devices have problems with JavaScript; some networks and services also block JavaScript.
In comparison, even though Silverlight or Flash based online forms may look more usable for corporate intranets and other special subsets of users, for public Internet users they are actually not as usable as HTML/CSS with optional JavaScript.
ADA and accessibility requirements also point to HTML/CSS with optional JavaScript.
In conclusion:
Comments are welcome. ZSentry for secure online forms is currently in beta test. Please submit a Support Ticket if you are interested in participating now or when the service is launched.
Cheers,
Ed Gerck
There seems to be growing interest for an online form service allowing customers to collect input from users and send it back as structured information to organizations, while preserving confidentiality including input, transmission, archive, access, and auditing functions.
The ability to enable customers to style online forms, for different server scenarios including absence of server-SSL input protection, should also be part of the available customer-design process. Further, the online form service should allow customers to use web forms, email forms, SMS forms, storage file forms, and any other communication process.
ZSentry is currently beta-testing such a Secure Online Form service that meets these considerations.
This work has led us to think more deeply about the pros and cons of Silverlight, Flash, PDF and other methods used to provide online form functions, as well as security and usability, which are the motivations for this posting and feedback.
In many cases of interest, the online form service must assure full HIPAA compliance. Safe Harbor compliance (even without HIPAA) is also coming to the foreground given the high profile and costs of recent breaches such as with Epsilon and Sony.
From the security viewpoint, and contrary to ZSentry for Google Apps (where both the need for HIPAA and Safe Harbor compliance can be satisfied by ZSentry), online forms as enabled by Google Docs cannot at this time be used by ZSentry as a basis for such secure service. The recent security breaches caused by phishing attacks against Google Apps and Gmail further highlight the concerns of storing plaintext information in online services such as Google Docs.
Our usability starting point is that online form functions are "critical" and, thus, in principle should be usable without asking the user to download or do anything else.
Usability is also necessary to ensure security, as we mention elsewhere (Usability is a system's #1 Security Property). In short, a secure online form service that is secure but not usable will not be used and, therefore, will actually fail to be secure. If security is too difficult or annoying, users may give up on it altogether.
Therefore, while it is OK for an information or help document to be available in PDF (with all the PDF requirements/problems to be met and solved at the user side), users can either view the PDF using any quick view software/service (including Google) or just move on to something else. Not so with an online form that needs to be entered.
We also see that many users are just that -- users -- and have no admin privilege in their devices. Increasingly, devices are locked (also by manufacturers -- see iPad vs Flash) for installation.
These concerns go against Silverlight. It could be better to use Flash (more widely available) but still many users would be left out as new Flash versions come out quite frequently and many users cannot update or do not like to bothered by yet another update. Silverlight also suffers from frequent updates.
How about JavaScript? It is commonly available. However, even JavaScript should only be used to provide added usability, while the online form itself should be functional without JavaScript. This is important not just because some devices have problems with JavaScript; some networks and services also block JavaScript.
In comparison, even though Silverlight or Flash based online forms may look more usable for corporate intranets and other special subsets of users, for public Internet users they are actually not as usable as HTML/CSS with optional JavaScript.
ADA and accessibility requirements also point to HTML/CSS with optional JavaScript.
In conclusion:
- Knowing the target-user comes first, as it defines how the message needs to be delivered. Silverlight, Flash, PDF forms, and other non-HTML solutions can be used well in an intranet (internal services in a hospital, for example) where the organization can control the server, the network, the filters, all the clients, and what is installed and updated at any moment in those clients. Lacking that inclusive control, it is bound to fail in the public Internet for the same reasons.
- From the user's viewpoint, HTML/CSS with optional JavaScript should be the best practice for online forms using the public Internet, as providing the needed functions while not standing in the way of using the online form -- which is the user's goal.
- The ZSentry API for secure online forms is designed so that it can be used with any desired method, including HTML/CSS with optional JavaScript, Silverlight, Flash, PDF forms, and other interfaces. It is up to the developer to make the best use of it.
Comments are welcome. ZSentry for secure online forms is currently in beta test. Please submit a Support Ticket if you are interested in participating now or when the service is launched.
Cheers,
Ed Gerck
Saturday, April 23, 2011
NMA ZSentry API -- Frequent Questions
[Target Audience: Developers and System Administrators]
The NMA ZSentry API is a secure software service that works in your environment. You can use the API both in a server as well as in a client context. There is no plugin or installation. With the ZSentry API you can readily connect, send, and store information securely, for example as a secure email, enabling secure communications in desktop, cloud, and mobile platforms, anywhere.
What is the NMA ZSentry API?
An SMTPS (SMTP over SSL, also called implicit SSL) service. You use the ZSentry API to connect your system to the ZSentry engine using TCP port 465 for encryption and decryption directly or through a message service or application. The resulting secure emails are encrypted per message and can be sent using ZSentry's own SMTP server, without requiring SSL, or can use another resource as a mail relay with or without SSL.
Why port 465?
With port 465 there is no ZSentry data exchange without SSL, including the ZSentry Usercode and Password data. Contrary to the submission port 587 with STARTTLS where the connection changes from non-SSL into SSL, port 465 has SSL-at-connect required. We prefer port 465 because every connection is encrypted from the start, preventing problems such as the SSL bridge attack (a well-known problem also for web browsers).
What server-side applications and servers are compatible?
The ZSentry API complies with IETF standards. ZSentry tested the API using servers with the dovecot/postfix Debian implementation and other Linux flavors. Customers have tested the API with a variety of Linux and Windows technology, including System.Net.Mail, CDOSYS (Collaborative Data Objects, Cdosys.dll), VB6, PHP, Java, and Sybase PowerBuilder.
Do users need to use ZSentry App (the web interface)?
No, not necessarily. The ZSentry API sends secure email that can be read and decrypted using the ZSentry App as well as leading Mail clients without any plug-in. This means that with the ZSentry API there is no web browser security and usability limitation for users, and users do not need to use the ZSentry App for reading, sending and saving secure messages. However, the ZSentry App can be used in a webmail environment.
How about Google Apps and Gmail?
Web mail services including Google Apps and Gmail can be set up to send HIPAA-compliant secure email using the ZSentry API directly, as a cloud Mail client with Single-Sign-On. This can be done by users, without an add-on or installation. Reading and saving secure email can also be done through Google Apps and Gmail,
using ZSentry App in the webmail environment or a Mail client.
How are Mail clients used?
Mail clients can be set up to send, read, and save HIPAA-compliant secure email using the ZSentry API directly, with Single-Sign-On. The user only sees the Mail client GUI for sending, reading and saving messages. This can be setup by users, without a plug-in or installation. A web browser is still used on the client side, but it is used transparently as a middleware and not as a GUI.
What clients are compatible?
The ZSentry API complies with IETF standards. Compatible clients include any major web browser, Outlook, Outlook Express, Windows Mail, Apple Mail, Entourage, Thunderbird, iPhone, Android, and iPad, on Windows XP, Vista, Windows 7, Linux, Mac OS X and iOS.
What applications can be used at the client side?
Clients can use several applications including webmail, email, IM, SMS, and file storage services.
Can I debug the SSL/SMTP flow?
Yes. This is a typical SSL/SMTP trace enabled by the API and which you can also capture in normal use to log delivery evidence for your service:
--------------
SMTP -> FROM SERVER:220 mail.example.com ESMTP Postfix
SMTP -> FROM SERVER: 250-mail.example.com 250-PIPELINING 250-SIZE 20480000 250-VRFY 250-ETRN 250-
AUTH PLAIN LOGIN 250-AUTH=PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN
SMTP -> FROM SERVER:250 2.1.0 Ok
SMTP -> FROM SERVER:250 2.1.5 Ok
SMTP -> FROM SERVER:354 End data with .
SMTP -> FROM SERVER:250 2.0.0 Ok: queued as E519A5801F4
-------------------------
More Information:
http://zsentry.com/zapi.htm
The NMA ZSentry API is a secure software service that works in your environment. You can use the API both in a server as well as in a client context. There is no plugin or installation. With the ZSentry API you can readily connect, send, and store information securely, for example as a secure email, enabling secure communications in desktop, cloud, and mobile platforms, anywhere.
What is the NMA ZSentry API?
An SMTPS (SMTP over SSL, also called implicit SSL) service. You use the ZSentry API to connect your system to the ZSentry engine using TCP port 465 for encryption and decryption directly or through a message service or application. The resulting secure emails are encrypted per message and can be sent using ZSentry's own SMTP server, without requiring SSL, or can use another resource as a mail relay with or without SSL.
Why port 465?
With port 465 there is no ZSentry data exchange without SSL, including the ZSentry Usercode and Password data. Contrary to the submission port 587 with STARTTLS where the connection changes from non-SSL into SSL, port 465 has SSL-at-connect required. We prefer port 465 because every connection is encrypted from the start, preventing problems such as the SSL bridge attack (a well-known problem also for web browsers).
What server-side applications and servers are compatible?
The ZSentry API complies with IETF standards. ZSentry tested the API using servers with the dovecot/postfix Debian implementation and other Linux flavors. Customers have tested the API with a variety of Linux and Windows technology, including System.Net.Mail, CDOSYS (Collaborative Data Objects, Cdosys.dll), VB6, PHP, Java, and Sybase PowerBuilder.
Do users need to use ZSentry App (the web interface)?
No, not necessarily. The ZSentry API sends secure email that can be read and decrypted using the ZSentry App as well as leading Mail clients without any plug-in. This means that with the ZSentry API there is no web browser security and usability limitation for users, and users do not need to use the ZSentry App for reading, sending and saving secure messages. However, the ZSentry App can be used in a webmail environment.
How about Google Apps and Gmail?
Web mail services including Google Apps and Gmail can be set up to send HIPAA-compliant secure email using the ZSentry API directly, as a cloud Mail client with Single-Sign-On. This can be done by users, without an add-on or installation. Reading and saving secure email can also be done through Google Apps and Gmail,
using ZSentry App in the webmail environment or a Mail client.
How are Mail clients used?
Mail clients can be set up to send, read, and save HIPAA-compliant secure email using the ZSentry API directly, with Single-Sign-On. The user only sees the Mail client GUI for sending, reading and saving messages. This can be setup by users, without a plug-in or installation. A web browser is still used on the client side, but it is used transparently as a middleware and not as a GUI.
What clients are compatible?
The ZSentry API complies with IETF standards. Compatible clients include any major web browser, Outlook, Outlook Express, Windows Mail, Apple Mail, Entourage, Thunderbird, iPhone, Android, and iPad, on Windows XP, Vista, Windows 7, Linux, Mac OS X and iOS.
What applications can be used at the client side?
Clients can use several applications including webmail, email, IM, SMS, and file storage services.
Can I debug the SSL/SMTP flow?
Yes. This is a typical SSL/SMTP trace enabled by the API and which you can also capture in normal use to log delivery evidence for your service:
--------------
SMTP -> FROM SERVER:220 mail.example.com ESMTP Postfix
SMTP -> FROM SERVER: 250-mail.example.com 250-PIPELINING 250-SIZE 20480000 250-VRFY 250-ETRN 250-
AUTH PLAIN LOGIN 250-AUTH=PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN
SMTP -> FROM SERVER:250 2.1.0 Ok
SMTP -> FROM SERVER:250 2.1.5 Ok
SMTP -> FROM SERVER:354 End data with .
SMTP -> FROM SERVER:250 2.0.0 Ok: queued as E519A5801F4
-------------------------
More Information:
http://zsentry.com/zapi.htm
Tuesday, March 22, 2011
Sender-Defined Security
When you send an email to a recipient, who bears the highest risk?
Usually, you. Because the information is transferred from sender to recipient, the sender likely has the highest risk. The information may be valuable to both, but the sender is the party that can be found liable for (even if inadvertently) disclosing it to others. Email is risk-asymmetric.
For example, patients may initiate communications with a health care provider using unencrypted email, according to HIPAA. This is done at the patient's risk. However, providers may have concerns when replying to the patient using unencrypted email. Providers are subject to potential liability under the HIPAA Privacy Rule [see 45 C.F.R. § 164.530(c)], including their determination whether a patient is aware of the possible risks of using unencrypted email.
Since the sender is the party at risk, the sender needs to be able to define the security conditions, for example, for confidentiality, delivery, and tracking of the message.
Let's see how certified postal mail works. The sender chooses the service and the type of envelope to protect the message. The sender also chooses the instructions
that must be followed before the envelope can be opened by the recipient. The recipient has no charge to pay for, or burden, in order to receive the envelope, and does not have to do anything before the envelope is sent. The recipient is able to verify the identity of the sender and, if so desired, refuse the envelope. The recipient can open the envelope if and only if the recipient is willing to follow the sender's instructions (e.g., providing name, address, date, signature).
The same should be available for sender-defined security modes of operation for email.
Using IBE encryption (Identity-Based Encryption, Voltage, MessageGuard) does not work because IBE requires sender key-escrow, so that the sender is always at risk that her messages can be read by someone else.
Clearly, a conventional public-key model (PKI, X.509, PGP) cannot provide this functionality either. The security model for protecting email with public-key cryptography is backwards, technically and business wise. The sender, who is the party at risk, has to trust a lock provided by the recipient (his public-key) to protect her secrets (the message).
If certified postal mail would provide message security a la PGP, PGP/MIME or S/MIME email, the sender would have to convince the recipient to pay and send in advance an envelope for the sender to use. The sender, however, would never know whether the envelope indeed prevented others from prying into its contents. Moreover, the recipient is not the business driver who needs to provide, pay for and protect the lock. The sender is the party who has the motivation to spend money to provide and protect the lock.
These are well-known and recognized standards for encryption of email. However, their security and usability problems noted above cannot be solved by improvements in usability, better pricing or user education regarding how IBE, PKI, X.509, or PGP work. It simply does not work as it should work. That's also why conventional secure email has been difficult to use. It has the wrong logic for the problem.
ZSentry is a security technology that was developed after these standards and improves upon them in both usability and security. ZSentry provides per-message encryption, authentication, message control, and auditing, protecting information in motion and at rest. ZSentry reduces the trust and control requirements in several critical areas, making it easier to attain and demonstrate a higher level of security while increasing usability.
Most importantly, ZSentry enables a secure email system that works closer to how postal mail, including courier and certified postal mail, works.
Because ZSentry mail can be delivered securely to both registered and also to unregistered users, the sender is able to define the delivery conditions that must be satisfied by the recipient before the message can be decrypted (delivered) in each case.
For example, based on what is at stake and what threats may apply, versus the usability requirements, the sender can select from the following delivery conditions:
Require Registration: (For higher security: use this option) The recipient must register before reading the message. After the recipient registers, delivery is further controlled by the Delivery option specified by you for registered users (see next items).
Require Login: (For higher security: use this option) The recipient must be registered and login before reading the message. To reduce risk, this process includes mailbox authentication, login monitoring, message expiration, and other control features.
Read Until Expiration: (For higher usability: use this option) Available for both registered and unregistered users. The recipient is allowed to decrypt the Zmail, including attachments (if any), as many times as desired until the message expires. The security of the Read Until Expiration mode is based on mailbox authentication, login monitoring, and expiration control. The sender can choose when to expire, where the sooner the better for security.
Reply to Sender: (available in all options, including without registration or login) This is a very useful choice to receive a secure reply, as the recipient has no burden to reply securely (can reply securely just with one-click).
The security of these Delivery choices is further enhanced by other choices, including for Control and Tracking, for example allowing the sender to choose a message self-destruct time and real-time audit reporting with a Return Receipt.
The Return Receipt is sent back to you with information on When, Where, How, and by Whom your message was read.
You can also compare the Return Receipt with the corresponding Send Receipt (available from the server, upon sending), closing the loop with potentially more comprehensive delivery and notary evidence than using courier or certified postal mail, with less cost and immediate delivery.
In summary, ZSentry puts the sender in the driver's seat of secure email, with more and more effective options than any other system including IBE, PKI, X.509, PGP, courier and certified postal mail.
Usually, you. Because the information is transferred from sender to recipient, the sender likely has the highest risk. The information may be valuable to both, but the sender is the party that can be found liable for (even if inadvertently) disclosing it to others. Email is risk-asymmetric.
For example, patients may initiate communications with a health care provider using unencrypted email, according to HIPAA. This is done at the patient's risk. However, providers may have concerns when replying to the patient using unencrypted email. Providers are subject to potential liability under the HIPAA Privacy Rule [see 45 C.F.R. § 164.530(c)], including their determination whether a patient is aware of the possible risks of using unencrypted email.
Since the sender is the party at risk, the sender needs to be able to define the security conditions, for example, for confidentiality, delivery, and tracking of the message.
Let's see how certified postal mail works. The sender chooses the service and the type of envelope to protect the message. The sender also chooses the instructions
that must be followed before the envelope can be opened by the recipient. The recipient has no charge to pay for, or burden, in order to receive the envelope, and does not have to do anything before the envelope is sent. The recipient is able to verify the identity of the sender and, if so desired, refuse the envelope. The recipient can open the envelope if and only if the recipient is willing to follow the sender's instructions (e.g., providing name, address, date, signature).
The same should be available for sender-defined security modes of operation for email.
Using IBE encryption (Identity-Based Encryption, Voltage, MessageGuard) does not work because IBE requires sender key-escrow, so that the sender is always at risk that her messages can be read by someone else.
Clearly, a conventional public-key model (PKI, X.509, PGP) cannot provide this functionality either. The security model for protecting email with public-key cryptography is backwards, technically and business wise. The sender, who is the party at risk, has to trust a lock provided by the recipient (his public-key) to protect her secrets (the message).
If certified postal mail would provide message security a la PGP, PGP/MIME or S/MIME email, the sender would have to convince the recipient to pay and send in advance an envelope for the sender to use. The sender, however, would never know whether the envelope indeed prevented others from prying into its contents. Moreover, the recipient is not the business driver who needs to provide, pay for and protect the lock. The sender is the party who has the motivation to spend money to provide and protect the lock.
These are well-known and recognized standards for encryption of email. However, their security and usability problems noted above cannot be solved by improvements in usability, better pricing or user education regarding how IBE, PKI, X.509, or PGP work. It simply does not work as it should work. That's also why conventional secure email has been difficult to use. It has the wrong logic for the problem.
ZSentry is a security technology that was developed after these standards and improves upon them in both usability and security. ZSentry provides per-message encryption, authentication, message control, and auditing, protecting information in motion and at rest. ZSentry reduces the trust and control requirements in several critical areas, making it easier to attain and demonstrate a higher level of security while increasing usability.
Most importantly, ZSentry enables a secure email system that works closer to how postal mail, including courier and certified postal mail, works.
Because ZSentry mail can be delivered securely to both registered and also to unregistered users, the sender is able to define the delivery conditions that must be satisfied by the recipient before the message can be decrypted (delivered) in each case.
For example, based on what is at stake and what threats may apply, versus the usability requirements, the sender can select from the following delivery conditions:
Require Registration: (For higher security: use this option) The recipient must register before reading the message. After the recipient registers, delivery is further controlled by the Delivery option specified by you for registered users (see next items).
Require Login: (For higher security: use this option) The recipient must be registered and login before reading the message. To reduce risk, this process includes mailbox authentication, login monitoring, message expiration, and other control features.
Read Until Expiration: (For higher usability: use this option) Available for both registered and unregistered users. The recipient is allowed to decrypt the Zmail, including attachments (if any), as many times as desired until the message expires. The security of the Read Until Expiration mode is based on mailbox authentication, login monitoring, and expiration control. The sender can choose when to expire, where the sooner the better for security.
Reply to Sender: (available in all options, including without registration or login) This is a very useful choice to receive a secure reply, as the recipient has no burden to reply securely (can reply securely just with one-click).
The security of these Delivery choices is further enhanced by other choices, including for Control and Tracking, for example allowing the sender to choose a message self-destruct time and real-time audit reporting with a Return Receipt.
The Return Receipt is sent back to you with information on When, Where, How, and by Whom your message was read.
You can also compare the Return Receipt with the corresponding Send Receipt (available from the server, upon sending), closing the loop with potentially more comprehensive delivery and notary evidence than using courier or certified postal mail, with less cost and immediate delivery.
In summary, ZSentry puts the sender in the driver's seat of secure email, with more and more effective options than any other system including IBE, PKI, X.509, PGP, courier and certified postal mail.
Wednesday, February 24, 2010
Large EMR privacy breach notification, two years later -- an exception or a symptom?
NOTE: A colleague and I are working on a paper discussing a number of privacy and security red flags that can help call attention to these and other issues, especially in the context of secure email. A draft is gladly available to those who are interested, by private email request, for comments before publication.
Electronic medical records (EMRs) are at the heart of health care reform, and there is both a personal as well as a legal expectation of privacy for EMRs.
Promptly notifying users of privacy breaches can help bring accountability to the system, and help users.
In February 2010, RelayHealth (also known as NDCHealth Corporation) acting as a claims processing company, notified prescription holders that EMRs of two years ago, dating between February 2008 and December 2008, with full name, date of birth, prescription number, insurance cardholder ID, and drug name, that were dispensed at Rite Aid as well as other retail chain pharmacies and independent pharmacies in the State of California, were sent to an unauthorized pharmacy.
After I mentioned this case online, RelayHealth has contacted us in March 2010 and stated that the data was sent in error only in November 2009, so the delay in informing consumers was not two years but three months.
However, we note that this information was not provided to RelayHealth's consumers when the privacy breach was disclosed in February 2010. RelayHealth may want to look into that communication and verify why they did not disclose a delay of three months.
Further, what matters to our analysis here is the consumer privacy risk, which includes the two-year delay. If, for example, three-year old files are wrongly disclosed today and the EMR processor informs the patient tomorrow, this is not a lesser problem for the patient (as the next mentioned Fortis case exemplifies).
The 2010 breach notification did not disclose why the information was sent (Who requested it? Under what authorization? Who approved it?), who incorrectly received the EMR, and who was responsible for the breach, neither what compensation or recourse users may have.
In a recent court case, Fortis (a US health insurance company) was found to have a practice of targeting policyholders with HIV. A computer program and algorithm targeted every policyholder recently diagnosed with HIV for an automatic fraud investigation, as the company searched for any pretext to revoke their policy.
Companies such as Fortis can find out about anyone's diagnosed HIV, or other illness, through pharmacies and claim processors, for example.
This situation underscores the underlying conflicts of interest between at least three distinct roles that RelayHealth plays. They are:
"Your Provider, a Provider-Designated User [pretty much anyone] or authorized member of a Provider Group [anyone] can use contact and/or health information about you stored by RelayHealth for many purposes including [ie, this says that it does not exclude anyone or anything]:
..."
and
"RelayHealth may use the contact, billing and/or health information [EMR] provided by you in our service to provide your physician or other healthcare provider [ie, anyone they want] with updated and/or supplemental information for their files or systems."
A pattern that seems to emerge here is that because EMRs also have a market value (for example, to insurance companies, pharmacies, etc.), health care service companies can build automated information exchanges where they can make collected EMR available to other entities, and build a business on this activity.
That the same health care service companies (with different hats) also serve on behalf of the patients to protect the EMR from disclosure, is where the fox is taking care of the hens, and where the conflicts in 1-2-3 may play a role.
What this means is that the expansion of health care into larger use of EMRs ought to call for a much broader review of procedures and conflicts of interest than what is currently available. And, obviously, it should also include stricter rules for information security and handling of EMRs than what's currently used.
Your comments are welcome.
Best regards,
Ed Gerck
Electronic medical records (EMRs) are at the heart of health care reform, and there is both a personal as well as a legal expectation of privacy for EMRs.
Promptly notifying users of privacy breaches can help bring accountability to the system, and help users.
In February 2010, RelayHealth (also known as NDCHealth Corporation) acting as a claims processing company, notified prescription holders that EMRs of two years ago, dating between February 2008 and December 2008, with full name, date of birth, prescription number, insurance cardholder ID, and drug name, that were dispensed at Rite Aid as well as other retail chain pharmacies and independent pharmacies in the State of California, were sent to an unauthorized pharmacy.
After I mentioned this case online, RelayHealth has contacted us in March 2010 and stated that the data was sent in error only in November 2009, so the delay in informing consumers was not two years but three months.
However, we note that this information was not provided to RelayHealth's consumers when the privacy breach was disclosed in February 2010. RelayHealth may want to look into that communication and verify why they did not disclose a delay of three months.
Further, what matters to our analysis here is the consumer privacy risk, which includes the two-year delay. If, for example, three-year old files are wrongly disclosed today and the EMR processor informs the patient tomorrow, this is not a lesser problem for the patient (as the next mentioned Fortis case exemplifies).
The 2010 breach notification did not disclose why the information was sent (Who requested it? Under what authorization? Who approved it?), who incorrectly received the EMR, and who was responsible for the breach, neither what compensation or recourse users may have.
In a recent court case, Fortis (a US health insurance company) was found to have a practice of targeting policyholders with HIV. A computer program and algorithm targeted every policyholder recently diagnosed with HIV for an automatic fraud investigation, as the company searched for any pretext to revoke their policy.
Companies such as Fortis can find out about anyone's diagnosed HIV, or other illness, through pharmacies and claim processors, for example.
This situation underscores the underlying conflicts of interest between at least three distinct roles that RelayHealth plays. They are:
- claims processor;
- provider of patient EMR to their pharmacies and doctors;
- provider/seller of EMR to providers other than the patient's.
"Your Provider, a Provider-Designated User [pretty much anyone] or authorized member of a Provider Group [anyone] can use contact and/or health information about you stored by RelayHealth for many purposes including [ie, this says that it does not exclude anyone or anything]:
..."
and
"RelayHealth may use the contact, billing and/or health information [EMR] provided by you in our service to provide your physician or other healthcare provider [ie, anyone they want] with updated and/or supplemental information for their files or systems."
A pattern that seems to emerge here is that because EMRs also have a market value (for example, to insurance companies, pharmacies, etc.), health care service companies can build automated information exchanges where they can make collected EMR available to other entities, and build a business on this activity.
That the same health care service companies (with different hats) also serve on behalf of the patients to protect the EMR from disclosure, is where the fox is taking care of the hens, and where the conflicts in 1-2-3 may play a role.
What this means is that the expansion of health care into larger use of EMRs ought to call for a much broader review of procedures and conflicts of interest than what is currently available. And, obviously, it should also include stricter rules for information security and handling of EMRs than what's currently used.
Your comments are welcome.
Best regards,
Ed Gerck
Subscribe to:
Posts (Atom)