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.
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.
Saturday, February 26, 2011
How about password security?
Password security may look like yet another oxymoron, as two intrinsically contradictory terms. If it is a password, how can it be secure?
Indeed, there are many and valid security arguments not to use passwords. You can find a summary in the paper Take Five In Internet Security where, in a five-minute appraisal, we present and discuss a typical dialogue with someone claiming that they have a secure server while using username/password authentication.
However, not all passwords are created equal. ZSentry, for example, uses two-factor, strong authentication without passwords -- even though, for familiarity, the second-factor is called ZSentry Password.
This is important for usability, as passwords are easy to use.
The security difference is that ZSentry does not store your Usercode or Password, not even encrypted. This technology, called ZSentry Sans-Target, solves the vulnerability problems of common passwords, including dictionary attacks and password files, as described in the study Take Five In Internet Security.
The ZSentry technology eliminates common online targets such as username/password lists, names, email addresses, plain text user data, meta-data, and even the encryption/decryption keys themselves, while adding two-factor mutual authentication, adaptive security, and password-hardening.
The critical point is that ZSentry Sans-Target provides the best defense possible against data theft -- the best defense against data theft is to not have the data in the first place.
Another important point is that ZSentry is not as dependent on password quality for security, as conventional systems are. With ZSentry technology, passwords are paired with an unpredictable ZSentry Usercode, and both are not at risk anywhere.
Nonetheless, it is recommended that ZSentry passwords should include at least one control or punctuation character. All of the characters !@#$%^&*()_-+=[]|\;:"?/,.< >`~' and space can be used in ZSentry passwords (space cannot be used at the beginning or end of a password).
For advanced password use, for maximum protection, you can use ANSI codes from #32 to #255 (keyboard ALT-number, no space at the start or end of a password). This simple strategy enables more than 132 bits of entropy with just 13 ZSentry Password characters (and the Usercode).
The conventional difficulty for using ANSI codes in passwords is solved by the ZSentry function Password Peek (during signup and login). You can easily see and verify what you typed before you submit, even for ANSI CODES such as ALT-0159 for Ÿ (Latin Capital Letter Y With Diaeresis).
With ZSentry, you can now use passwords as securely as you want.
Indeed, there are many and valid security arguments not to use passwords. You can find a summary in the paper Take Five In Internet Security where, in a five-minute appraisal, we present and discuss a typical dialogue with someone claiming that they have a secure server while using username/password authentication.
However, not all passwords are created equal. ZSentry, for example, uses two-factor, strong authentication without passwords -- even though, for familiarity, the second-factor is called ZSentry Password.
This is important for usability, as passwords are easy to use.
The security difference is that ZSentry does not store your Usercode or Password, not even encrypted. This technology, called ZSentry Sans-Target, solves the vulnerability problems of common passwords, including dictionary attacks and password files, as described in the study Take Five In Internet Security.
The ZSentry technology eliminates common online targets such as username/password lists, names, email addresses, plain text user data, meta-data, and even the encryption/decryption keys themselves, while adding two-factor mutual authentication, adaptive security, and password-hardening.
The critical point is that ZSentry Sans-Target provides the best defense possible against data theft -- the best defense against data theft is to not have the data in the first place.
Another important point is that ZSentry is not as dependent on password quality for security, as conventional systems are. With ZSentry technology, passwords are paired with an unpredictable ZSentry Usercode, and both are not at risk anywhere.
Nonetheless, it is recommended that ZSentry passwords should include at least one control or punctuation character. All of the characters !@#$%^&*()_-+=[]|\;:"?/,.< >`~' and space can be used in ZSentry passwords (space cannot be used at the beginning or end of a password).
For advanced password use, for maximum protection, you can use ANSI codes from #32 to #255 (keyboard ALT-number, no space at the start or end of a password). This simple strategy enables more than 132 bits of entropy with just 13 ZSentry Password characters (and the Usercode).
The conventional difficulty for using ANSI codes in passwords is solved by the ZSentry function Password Peek (during signup and login). You can easily see and verify what you typed before you submit, even for ANSI CODES such as ALT-0159 for Ÿ (Latin Capital Letter Y With Diaeresis).
With ZSentry, you can now use passwords as securely as you want.
Sunday, January 30, 2011
The Technical Problem of Information Security
This article provides an in-depth look into Information Security and End-to-End Security. What is the problem, what can we do about it, and how effectively?
This discussion presents the technical requirements for an End-to-End IT security solution, summarized in four points:
The technical problem of information security can be stated, quite simply, as "to avoid too much concentration of information and power, while allowing enough information and power so as to make a task possible to execute."
For example, an all-knowing, all-powerful entity would be the perfect attacker and could break any security measure.
That is why we oftentimes talk about "need to know" and "separation of powers." We name these principles, respectively, information granularity and power granularity.
Such principles mean that information should not be provided in its entirety to a single entity and one should also avoid the scenario where any entity is, at the same time, user, administrator and auditor. That is why business information and power should be carefully divided, for example, among local employees, the office management, the enterprise management and the customer.
Also, contrary to what is oftentimes advocated in regard to IT security solutions, there should be no single point of control in an IT security system, which point must be recognized as a single point of failure -- i.e., no matter how trustworthy that single point of control is, it may fail or be compromised and there is no recourse available because it is the single point of control.
One of the earliest references to this principle can be found some five hundred years ago in the Hindu governments of the Mogul period, who are known to have used at least three parallel reporting channels to survey their provinces with some degree of reliability, notwithstanding the additional efforts.
Tools such as authentication and authorization can help define information and power granularity. However, at its most basic level, a secure IT system needs to do much more than just control authentication and authorization.
No matter how much assurance is provided that each component of a secure system is correct, when operational factors such as collusion, internal attacks, hackers, bugs, viruses, worms or errors are taken into account, the system may fail to be effective -- i.e., may fail to be secure in the context of its operational use.
In addition, underlying assurance problems such as insecure operating systems and reoccurring buffer overflow vulnerabilities are not likely to improve over the coming years.
There is a real need, thus, to bring together policy, management and implementation considerations that could influence effectiveness assurances for each particular IT security solution.
Other security principles such as redundancy, diversity, and least privilege also need to be used in defining the specific requirements for a secure IT system. In addition to being specific, such requirements need to be clearly formulated, decidable and, as much as possible, complete.
Additionally, an end-to-end design is important to assure effectiveness, because attacks and errors are hard to detect and prevent at the interface points. End-to-End (E2E) security is defined as safeguarding information in a secure telecommunication system by cryptographic or protected distribution system means, from point of origin to point of destination
For lack of paper trails or other material proof, non-repudiation is also often essential for Internet and IT security systems. A common definition states that non-repudiation is about providing proof that a particular act was actually performed, for example as demonstrated by a trusted time-stamp. However, this definition is etymologically incorrect and, thus, should be repudiated. It also misses the point. We and other authors prefer to define non-repudiation as "preventing the false denial of an act". In other words, it is not enough to provide proof of an act, as a denial may be presented and create a tie. While a correct denial should win the tie, a false denial should not.
To be effective, non-repudiation needs to take into account technical and business considerations. For example, bank checks are non-repudiable in the sense that a check is paid if (1) you did not tell the bank beforehand that the check should not be paid and (2) the signature does not look like a signature you did not make. The reader should note the double-negative, which provides less room for customer repudiation -- the signature does not have to look like a signature that you made, it just has to not look like a forgery.
Commonly, IT secure systems also must satisfy security standards such as the Controlled Access Protection (C2) level of security as defined in DoD 5200.28-STD (the Department of Defense Trusted Computer System Evaluation Criteria), the ITSEC Level 3 as defined in the Common Criteria for Information Technology Security Evaluation, or the Code of Practice for Information Security Management BS 7799 (a British Standard that is the basis of the ISO/IEC 17799-1 Standard).
To meet these objectives, an effective IT security solution should be based on two points:
The first point defines the component quality used in the IT system, where a weak component may compromise the whole system. For example, a system that relies on conventional username/passwords for authentication is likely already broken.
The second point focuses on the need to continuously evaluate all potential and existing threats, and verify any additional security design features that might be necessary to mitigate the risks stemming from the most likely and/or most damaging threats associated with the customer environment, and eventual changes in that environment.
The ZSentry security solution satisfies both points. ZSentry uses standard encryption technology with the unique Sans Target method to keep it safe and HITECH Safe Harbor compliant to send data between parties as regular email. It does not require installation of any software, which is great for both security and usability, and it even adds functionality such as self-destruct, with message level access control. This is also good news for Novell users who have become used to this type of functionality.
For example, using ZSentry renders your private health data unreadable to any third party who might come across it, and takes the issue of HIPAA breaches and fines off the table.
Read more about Why Not Passwords?
Read more about End-to-End IT Security
This discussion presents the technical requirements for an End-to-End IT security solution, summarized in four points:
- integrate core security services;
- eliminate known weak or costly links such as password lists, access control databases, shared secrets, and client-side PKI;
- avoid the seemingly desirable scenario of a single point of control, which is recognized as a single point of failure;
- bind a coherent system of trust to the solution and to its users.
The technical problem of information security can be stated, quite simply, as "to avoid too much concentration of information and power, while allowing enough information and power so as to make a task possible to execute."
For example, an all-knowing, all-powerful entity would be the perfect attacker and could break any security measure.
That is why we oftentimes talk about "need to know" and "separation of powers." We name these principles, respectively, information granularity and power granularity.
Such principles mean that information should not be provided in its entirety to a single entity and one should also avoid the scenario where any entity is, at the same time, user, administrator and auditor. That is why business information and power should be carefully divided, for example, among local employees, the office management, the enterprise management and the customer.
Also, contrary to what is oftentimes advocated in regard to IT security solutions, there should be no single point of control in an IT security system, which point must be recognized as a single point of failure -- i.e., no matter how trustworthy that single point of control is, it may fail or be compromised and there is no recourse available because it is the single point of control.
One of the earliest references to this principle can be found some five hundred years ago in the Hindu governments of the Mogul period, who are known to have used at least three parallel reporting channels to survey their provinces with some degree of reliability, notwithstanding the additional efforts.
Tools such as authentication and authorization can help define information and power granularity. However, at its most basic level, a secure IT system needs to do much more than just control authentication and authorization.
No matter how much assurance is provided that each component of a secure system is correct, when operational factors such as collusion, internal attacks, hackers, bugs, viruses, worms or errors are taken into account, the system may fail to be effective -- i.e., may fail to be secure in the context of its operational use.
In addition, underlying assurance problems such as insecure operating systems and reoccurring buffer overflow vulnerabilities are not likely to improve over the coming years.
There is a real need, thus, to bring together policy, management and implementation considerations that could influence effectiveness assurances for each particular IT security solution.
Other security principles such as redundancy, diversity, and least privilege also need to be used in defining the specific requirements for a secure IT system. In addition to being specific, such requirements need to be clearly formulated, decidable and, as much as possible, complete.
Additionally, an end-to-end design is important to assure effectiveness, because attacks and errors are hard to detect and prevent at the interface points. End-to-End (E2E) security is defined as safeguarding information in a secure telecommunication system by cryptographic or protected distribution system means, from point of origin to point of destination
For lack of paper trails or other material proof, non-repudiation is also often essential for Internet and IT security systems. A common definition states that non-repudiation is about providing proof that a particular act was actually performed, for example as demonstrated by a trusted time-stamp. However, this definition is etymologically incorrect and, thus, should be repudiated. It also misses the point. We and other authors prefer to define non-repudiation as "preventing the false denial of an act". In other words, it is not enough to provide proof of an act, as a denial may be presented and create a tie. While a correct denial should win the tie, a false denial should not.
To be effective, non-repudiation needs to take into account technical and business considerations. For example, bank checks are non-repudiable in the sense that a check is paid if (1) you did not tell the bank beforehand that the check should not be paid and (2) the signature does not look like a signature you did not make. The reader should note the double-negative, which provides less room for customer repudiation -- the signature does not have to look like a signature that you made, it just has to not look like a forgery.
Commonly, IT secure systems also must satisfy security standards such as the Controlled Access Protection (C2) level of security as defined in DoD 5200.28-STD (the Department of Defense Trusted Computer System Evaluation Criteria), the ITSEC Level 3 as defined in the Common Criteria for Information Technology Security Evaluation, or the Code of Practice for Information Security Management BS 7799 (a British Standard that is the basis of the ISO/IEC 17799-1 Standard).
To meet these objectives, an effective IT security solution should be based on two points:
- Clear security principles, algorithms and products based on time-proven designs; and
- Independent, permanent verification and validation of the systems’ security features.
The first point defines the component quality used in the IT system, where a weak component may compromise the whole system. For example, a system that relies on conventional username/passwords for authentication is likely already broken.
The second point focuses on the need to continuously evaluate all potential and existing threats, and verify any additional security design features that might be necessary to mitigate the risks stemming from the most likely and/or most damaging threats associated with the customer environment, and eventual changes in that environment.
The ZSentry security solution satisfies both points. ZSentry uses standard encryption technology with the unique Sans Target method to keep it safe and HITECH Safe Harbor compliant to send data between parties as regular email. It does not require installation of any software, which is great for both security and usability, and it even adds functionality such as self-destruct, with message level access control. This is also good news for Novell users who have become used to this type of functionality.
For example, using ZSentry renders your private health data unreadable to any third party who might come across it, and takes the issue of HIPAA breaches and fines off the table.
Read more about Why Not Passwords?
Read more about End-to-End IT Security
Subscribe to:
Posts (Atom)