O365 and encrypted mail to other email systems
-
@Dashrender said in O365 and encrypted mail to other email systems:
@bogdan.moldovan said in O365 and encrypted mail to other email systems:
@Dashrender I think that the gold standard here is S/MIME.
It requires that you (as a sender) have an S/MIME Private Key and signed Certificate and know your recipient's Public Key/Certificate.
It requires that the receiver has matching S/MIME Private Key and signed Certificate to the Public Key/Certificate that the sender had when sending the email.The S/MIME Private Keys / Certificates have to be configured on each device where the senders and receivers are sending / receiving email from/to.
Everything else, IMHO, is non-secure!
The S/MIME Certificates and Private Keys and be acquired individually by users or distributed to users from your own managed PKI.
Thanks for playing, this is not part of a viable solution.
You're welcome! I understand the hint ;)!
-
@Dashrender said in O365 and encrypted mail to other email systems:
Mail isn't covered by the HIPAA as fair as digital data goes, so it's not my concern..
Depends, do you have an account number on the paper? That would be digital data.
-
@scottalanmiller said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
@scottalanmiller said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
@scottalanmiller said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
Disagree Zix does have one Pro: able to send notice of desire to communicate, but TLS isn't available, so you must use another more painful means.
Nope, you can make rules for TLS that allow you to send notification but not the payload.
You just repeated what I said. Now, since Zix doesn't give a shit about TLS, it only ever uses it's secure portal (to the best of my knowledge) all secure messages are sent using their painful method, but a notice about that message is sent via to the client over whatever, TLS or not is available to the server.
But you can do that with Exchange, too. But never have the uselessly painful portion.
That's interesting - so you know that exchange can have a second transport option created that will send a generic notice to a NON TLS recipient and not send the original email? That would be cool. Still need a solution for the actual message content at that point, but that's for another discussion.
I know that it has "TLS Transport Rules" so that it only requires TLS in certain circumstances.
Eh? you mean every circumstance?
I suppose, IF, and only IF Exchange's transport rules can act upon things within the message itself, then a rule could be made - when a message subject line contains secure that the message can only be sent via TLS otherwise fail it. But I haven't seen that type of option available to the Rules.
-
@bogdan.moldovan said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
@bogdan.moldovan said in O365 and encrypted mail to other email systems:
@Dashrender I think that the gold standard here is S/MIME.
It requires that you (as a sender) have an S/MIME Private Key and signed Certificate and know your recipient's Public Key/Certificate.
It requires that the receiver has matching S/MIME Private Key and signed Certificate to the Public Key/Certificate that the sender had when sending the email.The S/MIME Private Keys / Certificates have to be configured on each device where the senders and receivers are sending / receiving email from/to.
Everything else, IMHO, is non-secure!
The S/MIME Certificates and Private Keys and be acquired individually by users or distributed to users from your own managed PKI.
Thanks for playing, this is not part of a viable solution.
You're welcome! I understand the hint ;)!
Sorry I'm a bit pissed off right now because of the Faxing things. it's nothing against you. While the idea in and of itself is sound, it's completely not usable in a normal corporate environment. I can't get my wife to use a new chat client, let alone expect my front desk person to know how to find someone's Public Key, download/install it into their email client (which is local only, so when they sit a new machine, they have to do it again and again), then use that key to send via s/mime.
-
@Dashrender said in O365 and encrypted mail to other email systems:
@bogdan.moldovan said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
@bogdan.moldovan said in O365 and encrypted mail to other email systems:
@Dashrender I think that the gold standard here is S/MIME.
It requires that you (as a sender) have an S/MIME Private Key and signed Certificate and know your recipient's Public Key/Certificate.
It requires that the receiver has matching S/MIME Private Key and signed Certificate to the Public Key/Certificate that the sender had when sending the email.The S/MIME Private Keys / Certificates have to be configured on each device where the senders and receivers are sending / receiving email from/to.
Everything else, IMHO, is non-secure!
The S/MIME Certificates and Private Keys and be acquired individually by users or distributed to users from your own managed PKI.
Thanks for playing, this is not part of a viable solution.
You're welcome! I understand the hint ;)!
Sorry I'm a bit pissed off right now because of the Faxing things. it's nothing against you. While the idea in and of itself is sound, it's completely not usable in a normal corporate environment. I can't get my wife to use a new chat client, let alone expect my front desk person to know how to find someone's Public Key, download/install it into their email client (which is local only, so when they sit a new machine, they have to do it again and again), then use that key to send via s/mime.
That's OK. Whenever you would like to deep-dive into this, let me know. True end to end security is not for the average front desk person, I agree. Nor should they need it! On the other hand, in my experience, when true end-to-end security is required, the overhead of properly setting things up becomes an acceptable issue, if not a non-issue.
-
@bogdan.moldovan said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
@bogdan.moldovan said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
@bogdan.moldovan said in O365 and encrypted mail to other email systems:
@Dashrender I think that the gold standard here is S/MIME.
It requires that you (as a sender) have an S/MIME Private Key and signed Certificate and know your recipient's Public Key/Certificate.
It requires that the receiver has matching S/MIME Private Key and signed Certificate to the Public Key/Certificate that the sender had when sending the email.The S/MIME Private Keys / Certificates have to be configured on each device where the senders and receivers are sending / receiving email from/to.
Everything else, IMHO, is non-secure!
The S/MIME Certificates and Private Keys and be acquired individually by users or distributed to users from your own managed PKI.
Thanks for playing, this is not part of a viable solution.
You're welcome! I understand the hint ;)!
Sorry I'm a bit pissed off right now because of the Faxing things. it's nothing against you. While the idea in and of itself is sound, it's completely not usable in a normal corporate environment. I can't get my wife to use a new chat client, let alone expect my front desk person to know how to find someone's Public Key, download/install it into their email client (which is local only, so when they sit a new machine, they have to do it again and again), then use that key to send via s/mime.
That's OK. Whenever you would like to deep-dive into this, let me know. True end to end security is not for the average front desk person, I agree. Nor should they need it! On the other hand, in my experience, when true end-to-end security is required, the overhead of properly setting things up becomes an acceptable issue, if not a non-issue.
It's for HIPAA, not for security.
-
@bogdan.moldovan said in O365 and encrypted mail to other email systems:
That's OK. Whenever you would like to deep-dive into this, let me know. True end to end security is not for the average front desk person, I agree. Nor should they need it! On the other hand, in my experience, when true end-to-end security is required, the overhead of properly setting things up becomes an acceptable issue, if not a non-issue.
it's debatable if HIPAA requires this for PHI transmission or not.
Currently, this lot believes that it is not, but only transmission from your email server to their email server, after that it's on them to secure the data.
But, when looking at Opportunistic TLS vs Forced TLS - currently I don't know of a way to make Exchange do this on the fly, say based on content in a message. There are add-ons to Exchange that enable this functionality, but the discussion here is if TLS along would solve the problem.
Scott's now claiming (I think at least) that sending emails over non TLS, non encrypted connections over the internet is completely fine, and does not put you at any legal risk from HIPAA - he believe this because faxing does not require any type of encryption. And While I understand his argument, I simply don't agree - and personally can't wait for a court case to see the fireworks - Scott's lawyer would claim faxing has no security, therefore email doesn't require any.
-
@Dashrender said in O365 and encrypted mail to other email systems:
@bogdan.moldovan said in O365 and encrypted mail to other email systems:
That's OK. Whenever you would like to deep-dive into this, let me know. True end to end security is not for the average front desk person, I agree. Nor should they need it! On the other hand, in my experience, when true end-to-end security is required, the overhead of properly setting things up becomes an acceptable issue, if not a non-issue.
it's debatable if HIPAA requires this for PHI transmission or not.
Currently, this lot believes that it is not, but only transmission from your email server to their email server, after that it's on them to secure the data.
But, when looking at Opportunistic TLS vs Forced TLS - currently I don't know of a way to make Exchange do this on the fly, say based on content in a message. There are add-ons to Exchange that enable this functionality, but the discussion here is if TLS along would solve the problem.
Scott's now claiming (I think at least) that sending emails over non TLS, non encrypted connections over the internet is completely fine, and does not put you at any legal risk from HIPAA - he believe this because faxing does not require any type of encryption. And While I understand his argument, I simply don't agree - and personally can't wait for a court case to see the fireworks - Scott's lawyer would claim faxing has no security, therefore email doesn't require any.
What you need to do is stop conflating everything. You are trying to mix all the pieces up when they are all different issues.
All you end up with is a big heaping pile of steaming shit.
No matter what @scottalanmiller's opinions are of faxing and email they have nothing to do with the topic at hand. He thankfully started a separate topic to handle that discussion.
You want to send PHI via email. HIPAA auditors state that it must be encrypted. Your only concern is that you require encryption for delivery. Once delivered the PHI is not under your control and is not something you need have any concern over.
The easiest and most cost effective way to do this is to require TLS at your MTA.
As with any solution, there will be people that are unable to get the message. Unlike other services where they have to try and deal with 3rd party issues, your users will know immediately that the PHI was unable to be sent because you will receive a failure notice from your MTA.
At this point you have many options to handle the failure. You can call, email non PHI information on a non TLS connection, send a letter, or go to their home/office and tell them in person that they have PHI data that you are unable to send to them.
That is all there is to it.
-
Read what I just wrote and do not add anything into it.
In one of the prior posts you jumped from required TLS and a backup MTA to saying it was all not going to work because you cannot figure out some method to automagically route messages.
That is conflating two completely different topics. You need to stop doing that.
-
@JaredBusch said in O365 and encrypted mail to other email systems:
Read what I just wrote and do not add anything into it.
In one of the prior posts you jumped from required TLS and a backup MTA to saying it was all not going to work because you cannot figure out some method to automagically route messages.
That is conflating two completely different topics. You need to stop doing that.
I don't believe I was conflating anything, as you like to say - but I definitely agree that there are multiple issues that need to be resolved.
I never wrote, but had considered the solutions to the FORCE TLS option that you presented.
-
@Dashrender said in O365 and encrypted mail to other email systems:
@JaredBusch said in O365 and encrypted mail to other email systems:
Read what I just wrote and do not add anything into it.
In one of the prior posts you jumped from required TLS and a backup MTA to saying it was all not going to work because you cannot figure out some method to automagically route messages.
That is conflating two completely different topics. You need to stop doing that.
I don't believe I was conflating anything, as you like to say - but I definitely agree that there are multiple issues that need to be resolved.
I never wrote, but had considered the solutions to the FORCE TLS option that you presented.
You know the really cool thing? You can turn on TLS for sending right now and just see how many bounces you get. Users do not need to be involved.
If you suddenly get a bunch, tell, the users, "hmm something is weird let me check the server" and then turn it back off and have them resend.
-
Good point. Dollars to donuts you get very, very few.
-
@Dashrender Another idea might be to have separate delivery MTAs. Use one for ePHI and another for anything else.
On the ePHI-assigned MTA gateway, configure Force TLS, DNSSEC, DKIM signing, SPF, etc..
Route to the ePHI MTA gateway either by rule or by configuration (e.g. if ePHI info is only sent from a known number of systems, configure those to use the MTA gateway that has Force TLS configured on it).
Note that the data at rest that you keep on your side also has to be encrypted, if I interpret correctly the requirements.
On the other hand, you should really consider hiring a Certified HIPAA Security Expert and get a professional audit on the as-is, recommendation, implementation followed by an audit on the new implementation. -
@JaredBusch said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
@JaredBusch said in O365 and encrypted mail to other email systems:
Read what I just wrote and do not add anything into it.
In one of the prior posts you jumped from required TLS and a backup MTA to saying it was all not going to work because you cannot figure out some method to automagically route messages.
That is conflating two completely different topics. You need to stop doing that.
I don't believe I was conflating anything, as you like to say - but I definitely agree that there are multiple issues that need to be resolved.
I never wrote, but had considered the solutions to the FORCE TLS option that you presented.
You know the really cool thing? You can turn on TLS for sending right now and just see how many bounces you get. Users do not need to be involved.
If you suddenly get a bunch, tell, the users, "hmm something is weird let me check the server" and then turn it back off and have them resend.
Yep, this I know - but because of the rejection notices, my boss would know something funny was happening.. but you are absolutely correct.
-
@bogdan.moldovan said in O365 and encrypted mail to other email systems:
@Dashrender Another idea might be to have separate delivery MTAs. Use one for ePHI and another for anything else.
On the ePHI-assigned MTA gateway, configure Force TLS, DNSSEC, DKIM signing, SPF, etc..
Route to the ePHI MTA gateway either by rule or by configuration (e.g. if ePHI info is only sent from a known number of systems, configure those to use the MTA gateway that has Force TLS configured on it).
Note that the data at rest that you keep on your side also has to be encrypted, if I interpret correctly the requirements.
On the other hand, you should really consider hiring a Certified HIPAA Security Expert and get a professional audit on the as-is, recommendation, implementation followed by an audit on the new implementation.At rest encryption is not required.
As for the split MTAs it's a though, but nearly everyone in the company deals with PHI, and needs to be able to send and receive PHI, so there would be so few people on the non PHI side as it make the effort not worth making.
-
@Dashrender said in O365 and encrypted mail to other email systems:
@JaredBusch said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
@JaredBusch said in O365 and encrypted mail to other email systems:
Read what I just wrote and do not add anything into it.
In one of the prior posts you jumped from required TLS and a backup MTA to saying it was all not going to work because you cannot figure out some method to automagically route messages.
That is conflating two completely different topics. You need to stop doing that.
I don't believe I was conflating anything, as you like to say - but I definitely agree that there are multiple issues that need to be resolved.
I never wrote, but had considered the solutions to the FORCE TLS option that you presented.
You know the really cool thing? You can turn on TLS for sending right now and just see how many bounces you get. Users do not need to be involved.
If you suddenly get a bunch, tell, the users, "hmm something is weird let me check the server" and then turn it back off and have them resend.
Yep, this I know - but because of the rejection notices, my boss would know something funny was happening.. but you are absolutely correct.
The other cool thing. These two technologies aren't mutually exclusive. You can try one, with minimal work, and see if that meets your needs. If it doesn't, backtrack and deploy the second solution.
Again, you will probably find that the first solution will have such a low bounce rate as to be unnoticeable.
-
@coliver said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
@JaredBusch said in O365 and encrypted mail to other email systems:
@Dashrender said in O365 and encrypted mail to other email systems:
@JaredBusch said in O365 and encrypted mail to other email systems:
Read what I just wrote and do not add anything into it.
In one of the prior posts you jumped from required TLS and a backup MTA to saying it was all not going to work because you cannot figure out some method to automagically route messages.
That is conflating two completely different topics. You need to stop doing that.
I don't believe I was conflating anything, as you like to say - but I definitely agree that there are multiple issues that need to be resolved.
I never wrote, but had considered the solutions to the FORCE TLS option that you presented.
You know the really cool thing? You can turn on TLS for sending right now and just see how many bounces you get. Users do not need to be involved.
If you suddenly get a bunch, tell, the users, "hmm something is weird let me check the server" and then turn it back off and have them resend.
Yep, this I know - but because of the rejection notices, my boss would know something funny was happening.. but you are absolutely correct.
The other cool thing. These two technologies aren't mutually exclusive. You can try one, with minimal work, and see if that meets your needs. If it doesn't, backtrack and deploy the second solution.
Again, you will probably find that the first solution will have such a low bounce rate as to be unnoticeable.
I agree - it's just getting the boss to accept that a few failures will happen and then an acceptable resolution solution for those failures.
-
Tangential question: will the TLS to TLS connection work if the remote server does not have a trusted certificate?
I'm trying to figure out how to get a handle on all of our communication and what we actually need to do to be compliant and secure in our communications with customers. Unfortunately the DoD and related subagencies do not use certificates trusted by any other authority. Therefore, O365 will not trust the certificate of the remote server.
-
@Kelly said in O365 and encrypted mail to other email systems:
Tangential question: will the TLS to TLS connection work if the remote server does not have a trusted certificate?
I'm trying to figure out how to get a handle on all of our communication and what we actually need to do to be compliant and secure in our communications with customers. Unfortunately the DoD and related subagencies do not use certificates trusted by any other authority. Therefore, O365 will not trust the certificate of the remote server.
By default, yes. Can you require that it be trusted? Yes you can.
-
@Dashrender said in O365 and encrypted mail to other email systems:
I agree - it's just getting the boss to accept that a few failures will happen and then an acceptable resolution solution for those failures.
I would just explain that the alternative, the Zix method, is a failure "every" time. And not a failure to you, but a failure to the other end. Instead of you getting notified that things didn't work once in a while (or maybe never), your recipient gets notified that things didn't work through email every, single, time.
So it is a huge win in two ways:
- Failures are uncommon and unexpected instead of common and expected
- Failures are invisible to customers instead of invisible to you
