encrypted email options?
-
@Dashrender said in encrypted email options?:
@Pete-S said in encrypted email options?:
@Dashrender said in encrypted email options?:
@scottalanmiller said in encrypted email options?:
With Zix, for example, they have your key.
yep
PGP/GPG options are definitely way, way more secure. And they use real email to do it. But no one likes them.
Right, normal users, a cashier at the grocery store, will likely never setup a GPG key, support it, etc to get medical records via email from their doctor. that's to much work.
But they will create a logon to an EMR portal and a "secure email portal" to access/retrieve messages from their doctors. Of course, generally, they will use the same password they use everywhere else, but that's not my problem.
I know cases where communication between health care professionals and patients is done through a website that requires 2FA for the patients. It has absolutely nothing to do at all with email except that patients can get email and sms notifications. Patients can view their journals as well. I'm sure it's custom built but maybe there are COTS systems that are made for exactly this.
COTS?
"Commercial, Off The Shelf"
-
It's generally used as COTS vs Bespoke.
In between the two are things like SAP where it's premade, but can't be used until customized.
-
I posted this question to my supervisors this morning:
When you hear secure or encrypted email what do you envision? How do you envision that working?
answer 1
Secure or encrypted to me means that the content of the email is protected by a password and is not able to be opened by just anyone. I have several vendors that send me secure mail, so I am used to using it.
answer 2
I think of secure email as a means to send PHI or personal information without worrying that someone who shouldn’t see the information will be able to view it. Encrypted to me means that you need to sign in or have some sort of password to get into the email to view the contents. I may be way off base but….
-
answer 2
I think of secure email as a means to send PHI or personal information without worrying that someone who shouldn’t see the information will be able to view it. Encrypted to me means that you need to sign in or have some sort of password to get into the email to view the contents. I may be way off base but….
Interesting to see that someone considers secure and encrypted two different things.
-
@Dashrender said in encrypted email options?:
I posted this question to my supervisors this morning:
When you hear secure or encrypted email what do you envision? How do you envision that working?
answer 1
Secure or encrypted to me means that the content of the email is protected by a password and is not able to be opened by just anyone. I have several vendors that send me secure mail, so I am used to using it.
answer 2
I think of secure email as a means to send PHI or personal information without worrying that someone who shouldn’t see the information will be able to view it. Encrypted to me means that you need to sign in or have some sort of password to get into the email to view the contents. I may be way off base but….
Why does it matter what your non-IT supervisors think about the definition of encrypted email?
I would say they have a decent grasp of the concept, and who cares if they know the exact definition. It's not their job to know it.
-
I asked a followup question:
Could you be a little more in depth on how you envision it working – for say a patient, make a step by step list if you can.
answer 1
The secure mail would need to be initiated by TUC staff to send an email to patient, stating they have a secure message from TUC. Upon opening the message for the first time, they would be directed to create a password with whatever requirements we set up (number of characters, any special characters, Upper and lower case, etc.) Once password is approved by meeting criteria, the true message can be opened and responded to as needed. Future messages could be sent and opened by using the established password.
-
@IRJ said in encrypted email options?:
@Dashrender said in encrypted email options?:
I posted this question to my supervisors this morning:
When you hear secure or encrypted email what do you envision? How do you envision that working?
answer 1
Secure or encrypted to me means that the content of the email is protected by a password and is not able to be opened by just anyone. I have several vendors that send me secure mail, so I am used to using it.
answer 2
I think of secure email as a means to send PHI or personal information without worrying that someone who shouldn’t see the information will be able to view it. Encrypted to me means that you need to sign in or have some sort of password to get into the email to view the contents. I may be way off base but….
Why does it matter what your non-IT supervisors think about the definition of encrypted email?
I would say they have a decent grasp of the concept, and who cares if they know the exact definition. It's not their job to know it.
Because one of the things this thread is showing is that different people have different expectations.
The first two posts where talking about S/MIME, and while of course this could be the most original classic definition of secure/encrypted email, it's not what I, me - Dashrender - was really leaning towards.
Then Scott posts that real secure/encrypted email is basically nothing more more than TLS based transit encrypted delivery.
Now - none of that might matter at all - really, the only opinion that matters is that of the stakeholders, though frankly, I have no idea who those people are at this point. I could see an argument for me (the IT person) to be the stakeholder, but I could also see my boss, or those asking for it, but I could also see it being the BOD (the ones who will ultimately approve the spend - yeah because we don't have spending permissions on much that doesn't flow through them these days). yep, pretty terrible situation to be in.
-
Also - getting buy-in as I assume you know, it extremely helpful in getting things implemented. And even if we don't go with what they believe to be a product/process, at least I know I have to do education with them first to help sell it to the rest.
-
@Dashrender said in encrypted email options?:
Then Scott posts that real secure/encrypted email is basically nothing more more than TLS based transit encrypted delivery.
I wouldn't worry about Scott's definition of things. OME is well accepted as email encryption, even though Scott will argue that it technically isn't. We could get into the weeds about things technically and start an argument that doesnt matter or we could ask ourselves a few important questions.
1.) Is the data actually encrypted?
2.) Is authentication required to access the data?
3.) Is this an accepted industry standard?
4.) Can I bring my own key to ensure no one else can read the data, if I dont trust Microsoft?
5.) Will it easily integrate with my current solution?The answer to all those is Yes from OME. Why would you setup a more complicated solution just so it can be technically encrypted email? Who gives a shit about the email itself? It is the data you are trying to protect.
No IT department that I have ever seen functions as Scott claims. I have known a few IT people that like to argue about things like this, but in the end they end up wasting time and actually hurting the business. Bringing a more complicated solution in this case solves nothing and only creates issues.
-
@Dashrender said in encrypted email options?:
I posted this question to my supervisors this morning:
When you hear secure or encrypted email what do you envision? How do you envision that working?
answer 1
Secure or encrypted to me means that the content of the email is protected by a password and is not able to be opened by just anyone. I have several vendors that send me secure mail, so I am used to using it.
answer 2
I think of secure email as a means to send PHI or personal information without worrying that someone who shouldn’t see the information will be able to view it. Encrypted to me means that you need to sign in or have some sort of password to get into the email to view the contents. I may be way off base but….
Okay, so now we are back to what I was saying originally. Their goal is to ensure a given email is not able to be read by someone else (an attacker, admin, etc.) who could obtain access to the user's email.
You're back to a separate system controlling access like OME. If this is between the health place and patients, S/MIME is out of the question.
That said, I do remember you mentioning that doesn't matter because in the end they want to do the absolute minimum to obtain compliance, which may be nothing. That I don't know.
-
Believe me - I'm not in the weeds over Scott's post.
But it's likely that my only requirement is HIPAA, not encryption of data at rest, especially on the patient side, etc.
HIPAA doesn't require encryption at rest, even though I have it on my side with O365.
HIPAA doesn't require encryption at rest on the client side - it makes no mention of it.You mention authentication to access - does having access to their own email account count? I think it does, so I believe this is checked off.
Is TLS delivery an industry accepted standard - yes, check
Can I bring my own key - not a HIPAA requirement
Will it integrate into my current solution - well, TLS only itself will integrate seamlessly, but domains that don't support it won't fail for 24 hours, leading to complaints of delivery failure and extreme time for notice.Now I completely agree with your that OME is likely the solution we will employ, if for no other reason that it's what the novice world has come to know as secure/encrypted email.
Actually, one of the things I considering, is - Will management accept the 24 hour delay in notice on failed TLS connections AND do they consider TLS enough to sign off on the HIPAA requirement for secure/encrypted email?
In the past they rescinded the sign off because their family used accounts that didn't support it. Cox has finally moved to a solution that does support it, so that hurdle is removed. -
@Dashrender said in encrypted email options?:
HIPAA doesn't require encryption at rest, even though I have it on my side with O365.
I'd rethink that.
https://thehcbiz.com/is-encryption-required-by-hipaa-yes/
So… it’s not required. But HHS goes on:
“The covered entity must decide whether a given addressable implementation specification is a reasonable and appropriate security measure to apply within its particular security framework. For example, a covered entity must implement an addressable implementation specification if it is reasonable and appropriate to do so, and must implement an equivalent alternative if the addressable implementation specification is unreasonable and inappropriate, and there is a reasonable and appropriate alternative.”
The key phrase here is “reasonable and appropriate.” As in, encryption IS required if it’s reasonable and appropriate to encrypt. This is really important and we’ll come back to it later. HHS continues:
“This decision will depend on a variety of factors, such as, among others, the entity’s risk analysis, risk mitigation strategy, what security measures are already in place, and the cost of implementation. The decisions that a covered entity makes regarding addressable specifications must be documented in writing. The written documentation should include the factors considered as well as the results of the risk assessment on which the decision was based.”
Basically what they’re saying is that you don’t “have to” encrypt, but if you choose not to you’d better be prepared to demonstrate, in writing, why you believe that. Then, in the event of an audit, The Office for Civil Rights (OCR) will review your documentation and determine whether or not they agree with you.
-
@stacksofplates said in encrypted email options?:
@Dashrender said in encrypted email options?:
HIPAA doesn't require encryption at rest, even though I have it on my side with O365.
I'd rethink that.
https://thehcbiz.com/is-encryption-required-by-hipaa-yes/
So… it’s not required. But HHS goes on:
“The covered entity must decide whether a given addressable implementation specification is a reasonable and appropriate security measure to apply within its particular security framework. For example, a covered entity must implement an addressable implementation specification if it is reasonable and appropriate to do so, and must implement an equivalent alternative if the addressable implementation specification is unreasonable and inappropriate, and there is a reasonable and appropriate alternative.”
The key phrase here is “reasonable and appropriate.” As in, encryption IS required if it’s reasonable and appropriate to encrypt. This is really important and we’ll come back to it later. HHS continues:
“This decision will depend on a variety of factors, such as, among others, the entity’s risk analysis, risk mitigation strategy, what security measures are already in place, and the cost of implementation. The decisions that a covered entity makes regarding addressable specifications must be documented in writing. The written documentation should include the factors considered as well as the results of the risk assessment on which the decision was based.”
Basically what they’re saying is that you don’t “have to” encrypt, but if you choose not to you’d better be prepared to demonstrate, in writing, why you believe that. Then, in the event of an audit, The Office for Civil Rights (OCR) will review your documentation and determine whether or not they agree with you.
IMO, it IS reasonable and appropriate to keep unauthorized people from accessing the data you are sending, which means OME.
-
@Obsolesce said in encrypted email options?:
@stacksofplates said in encrypted email options?:
@Dashrender said in encrypted email options?:
HIPAA doesn't require encryption at rest, even though I have it on my side with O365.
I'd rethink that.
https://thehcbiz.com/is-encryption-required-by-hipaa-yes/
So… it’s not required. But HHS goes on:
“The covered entity must decide whether a given addressable implementation specification is a reasonable and appropriate security measure to apply within its particular security framework. For example, a covered entity must implement an addressable implementation specification if it is reasonable and appropriate to do so, and must implement an equivalent alternative if the addressable implementation specification is unreasonable and inappropriate, and there is a reasonable and appropriate alternative.”
The key phrase here is “reasonable and appropriate.” As in, encryption IS required if it’s reasonable and appropriate to encrypt. This is really important and we’ll come back to it later. HHS continues:
“This decision will depend on a variety of factors, such as, among others, the entity’s risk analysis, risk mitigation strategy, what security measures are already in place, and the cost of implementation. The decisions that a covered entity makes regarding addressable specifications must be documented in writing. The written documentation should include the factors considered as well as the results of the risk assessment on which the decision was based.”
Basically what they’re saying is that you don’t “have to” encrypt, but if you choose not to you’d better be prepared to demonstrate, in writing, why you believe that. Then, in the event of an audit, The Office for Civil Rights (OCR) will review your documentation and determine whether or not they agree with you.
IMO, it IS reasonable and appropriate to keep unauthorized people from accessing the data you are sending, which means OME.
Yeah I'm not arguing that. They already have encryption at rest with O365 anyway, I'm saying more everything else. Saying HIPAA doesn't require encryption at rest is I guess technically true, but hopefully you document why it isn't in whatever use case.
-
@Dashrender said in encrypted email options?:
Believe me - I'm not in the weeds over Scott's post.
But it's likely that my only requirement is HIPAA, not encryption of data at rest, especially on the patient side, etc.
HIPAA doesn't require encryption at rest, even though I have it on my side with O365.
HIPAA doesn't require encryption at rest on the client side - it makes no mention of it.You mention authentication to access - does having access to their own email account count? I think it does, so I believe this is checked off.
Is TLS delivery an industry accepted standard - yes, check
Can I bring my own key - not a HIPAA requirement
Will it integrate into my current solution - well, TLS only itself will integrate seamlessly, but domains that don't support it won't fail for 24 hours, leading to complaints of delivery failure and extreme time for notice.Now I completely agree with your that OME is likely the solution we will employ, if for no other reason that it's what the novice world has come to know as secure/encrypted email.
Actually, one of the things I considering, is - Will management accept the 24 hour delay in notice on failed TLS connections AND do they consider TLS enough to sign off on the HIPAA requirement for secure/encrypted email?
In the past they rescinded the sign off because their family used accounts that didn't support it. Cox has finally moved to a solution that does support it, so that hurdle is removed.You are all over the place, dude.
If you can get away with doing nothing, should you? Doing the bare minimum is pretty bad, when you know its insecure. You as a customer wouldnt want your PHI handled like that would you?
In your next train of thought you say oh I wonder if OME is even good enough... Of course it is good enough. You have very large organizations with huge compliance departments using it. These organizations get regular audits to ensure compliance.
Your bosses walk all over you, because you bring them stuff like this. You are the IT guy, choose your solution and tell them THIS is what we are doing. You have been in IT a long time man. You should be the one making IT decisions for your organization. Very rarely should your supervisors make these type of technical decisions.
-
@stacksofplates said in encrypted email options?:
@Obsolesce said in encrypted email options?:
@stacksofplates said in encrypted email options?:
@Dashrender said in encrypted email options?:
HIPAA doesn't require encryption at rest, even though I have it on my side with O365.
I'd rethink that.
https://thehcbiz.com/is-encryption-required-by-hipaa-yes/
So… it’s not required. But HHS goes on:
“The covered entity must decide whether a given addressable implementation specification is a reasonable and appropriate security measure to apply within its particular security framework. For example, a covered entity must implement an addressable implementation specification if it is reasonable and appropriate to do so, and must implement an equivalent alternative if the addressable implementation specification is unreasonable and inappropriate, and there is a reasonable and appropriate alternative.”
The key phrase here is “reasonable and appropriate.” As in, encryption IS required if it’s reasonable and appropriate to encrypt. This is really important and we’ll come back to it later. HHS continues:
“This decision will depend on a variety of factors, such as, among others, the entity’s risk analysis, risk mitigation strategy, what security measures are already in place, and the cost of implementation. The decisions that a covered entity makes regarding addressable specifications must be documented in writing. The written documentation should include the factors considered as well as the results of the risk assessment on which the decision was based.”
Basically what they’re saying is that you don’t “have to” encrypt, but if you choose not to you’d better be prepared to demonstrate, in writing, why you believe that. Then, in the event of an audit, The Office for Civil Rights (OCR) will review your documentation and determine whether or not they agree with you.
IMO, it IS reasonable and appropriate to keep unauthorized people from accessing the data you are sending, which means OME.
Yeah I'm not arguing that. They already have encryption at rest with O365 anyway, I'm saying more everything else. Saying HIPAA doesn't require encryption at rest is I guess technically true, but hopefully you document why it isn't in whatever use case.
It's kinda in the same vein, that you can build a house that meets code, but is still a piece of shit, just because it's the minimum that you have to do by law, doesn't mean that's all you should do, nor does it mean you can't meet the code and still get sued for something you did that met code but done in a negligent way to cause damage later on.
-
@thecreaitvone91 said in encrypted email options?:
@stacksofplates said in encrypted email options?:
@Obsolesce said in encrypted email options?:
@stacksofplates said in encrypted email options?:
@Dashrender said in encrypted email options?:
HIPAA doesn't require encryption at rest, even though I have it on my side with O365.
I'd rethink that.
https://thehcbiz.com/is-encryption-required-by-hipaa-yes/
So… it’s not required. But HHS goes on:
“The covered entity must decide whether a given addressable implementation specification is a reasonable and appropriate security measure to apply within its particular security framework. For example, a covered entity must implement an addressable implementation specification if it is reasonable and appropriate to do so, and must implement an equivalent alternative if the addressable implementation specification is unreasonable and inappropriate, and there is a reasonable and appropriate alternative.”
The key phrase here is “reasonable and appropriate.” As in, encryption IS required if it’s reasonable and appropriate to encrypt. This is really important and we’ll come back to it later. HHS continues:
“This decision will depend on a variety of factors, such as, among others, the entity’s risk analysis, risk mitigation strategy, what security measures are already in place, and the cost of implementation. The decisions that a covered entity makes regarding addressable specifications must be documented in writing. The written documentation should include the factors considered as well as the results of the risk assessment on which the decision was based.”
Basically what they’re saying is that you don’t “have to” encrypt, but if you choose not to you’d better be prepared to demonstrate, in writing, why you believe that. Then, in the event of an audit, The Office for Civil Rights (OCR) will review your documentation and determine whether or not they agree with you.
IMO, it IS reasonable and appropriate to keep unauthorized people from accessing the data you are sending, which means OME.
Yeah I'm not arguing that. They already have encryption at rest with O365 anyway, I'm saying more everything else. Saying HIPAA doesn't require encryption at rest is I guess technically true, but hopefully you document why it isn't in whatever use case.
It's kinda in the same vein, that you can build a house that meets code, but is still a piece of shit, just because it's the minimum that you have to do by law, doesn't mean that's all you should do, nor does it mean you can't meet the code and still get sued for something you did that met code but done in a negligent way to cause damage later on.
That is a good point. There are set rules you have to follow, but you can also be fired, sued, and in some cases jailed for not doing your due diligence to keep things secure.
This is actually a good example of that, and if you were to say we did the bare minimum because it was slightly easier and less work then you could be liable. Will anything happen other than you being fired, probably not. If you worked for a large organization and you had documented proof of negligence then maybe.
-
@IRJ said in encrypted email options?:
@Dashrender said in encrypted email options?:
Believe me - I'm not in the weeds over Scott's post.
But it's likely that my only requirement is HIPAA, not encryption of data at rest, especially on the patient side, etc.
HIPAA doesn't require encryption at rest, even though I have it on my side with O365.
HIPAA doesn't require encryption at rest on the client side - it makes no mention of it.You mention authentication to access - does having access to their own email account count? I think it does, so I believe this is checked off.
Is TLS delivery an industry accepted standard - yes, check
Can I bring my own key - not a HIPAA requirement
Will it integrate into my current solution - well, TLS only itself will integrate seamlessly, but domains that don't support it won't fail for 24 hours, leading to complaints of delivery failure and extreme time for notice.Now I completely agree with your that OME is likely the solution we will employ, if for no other reason that it's what the novice world has come to know as secure/encrypted email.
Actually, one of the things I considering, is - Will management accept the 24 hour delay in notice on failed TLS connections AND do they consider TLS enough to sign off on the HIPAA requirement for secure/encrypted email?
In the past they rescinded the sign off because their family used accounts that didn't support it. Cox has finally moved to a solution that does support it, so that hurdle is removed.You are all over the place, dude.
If you can get away with doing nothing, should you? Doing the bare minimum is pretty bad, when you know its insecure. You as a customer wouldnt want your PHI handled like that would you?
You're not happy with TLS based delivery of your PHI to gmail? So you don't trust gmail security to keep your email secure? it's encrypted on my side at rest (O365) it's encrypted during transit (TLS) and on your side - that's your problem.
Really, once the patient accesses the data via OME, they're likely downloading it in a non encrypted PDF and saving it to their computer where they're just likely emailing it to someone else.
So I'm asking - what benefit does OME bring to the normal user in this environment?
But let's bump this up to something between you and your lawyer - you trust your email system, you assume they trust theirs, and you're using TLS between them - do you need something more? Are you that worried about the IT person reading the emails? If so, should they be working for you? Or is there a requirement to make it impossible for them to access them?
Believe me guys, I totally get where you guys are going with this stuff. But it sounds like you're saying that TLS alone would never be an option for you, and my question is - why not?
And does that outweigh the onus on the end user when accessing attachments on email?
-
@IRJ said in encrypted email options?:
In your next train of thought you say oh I wonder if OME is even good enough... Of course it is good enough. You have very large organizations with huge compliance departments using it. These organizations get regular audits to ensure compliance.
Where did I ask if OME is good enough? I know tons of companies use it, Zix's solution is basically the same - I definitely consider it more than good enough for HIPAA.
-
@IRJ said in encrypted email options?:
@thecreaitvone91 said in encrypted email options?:
@stacksofplates said in encrypted email options?:
@Obsolesce said in encrypted email options?:
@stacksofplates said in encrypted email options?:
@Dashrender said in encrypted email options?:
HIPAA doesn't require encryption at rest, even though I have it on my side with O365.
I'd rethink that.
https://thehcbiz.com/is-encryption-required-by-hipaa-yes/
So… it’s not required. But HHS goes on:
“The covered entity must decide whether a given addressable implementation specification is a reasonable and appropriate security measure to apply within its particular security framework. For example, a covered entity must implement an addressable implementation specification if it is reasonable and appropriate to do so, and must implement an equivalent alternative if the addressable implementation specification is unreasonable and inappropriate, and there is a reasonable and appropriate alternative.”
The key phrase here is “reasonable and appropriate.” As in, encryption IS required if it’s reasonable and appropriate to encrypt. This is really important and we’ll come back to it later. HHS continues:
“This decision will depend on a variety of factors, such as, among others, the entity’s risk analysis, risk mitigation strategy, what security measures are already in place, and the cost of implementation. The decisions that a covered entity makes regarding addressable specifications must be documented in writing. The written documentation should include the factors considered as well as the results of the risk assessment on which the decision was based.”
Basically what they’re saying is that you don’t “have to” encrypt, but if you choose not to you’d better be prepared to demonstrate, in writing, why you believe that. Then, in the event of an audit, The Office for Civil Rights (OCR) will review your documentation and determine whether or not they agree with you.
IMO, it IS reasonable and appropriate to keep unauthorized people from accessing the data you are sending, which means OME.
Yeah I'm not arguing that. They already have encryption at rest with O365 anyway, I'm saying more everything else. Saying HIPAA doesn't require encryption at rest is I guess technically true, but hopefully you document why it isn't in whatever use case.
It's kinda in the same vein, that you can build a house that meets code, but is still a piece of shit, just because it's the minimum that you have to do by law, doesn't mean that's all you should do, nor does it mean you can't meet the code and still get sued for something you did that met code but done in a negligent way to cause damage later on.
That is a good point. There are set rules you have to follow, but you can also be fired, sued, and in some cases jailed for not doing your due diligence to keep things secure.
This is actually a good example of that, and if you were to say we did the bare minimum because it was slightly easier and less work then you could be liable. Will anything happen other than you being fired, probably not. If you worked for a large organization and you had documented proof of negligence then maybe.
if you have documented proof of negligence, then I'd say you didn't meet some requirement, or the negligence has no baring on the requirements, and as Scott would say - the requirement in that case would be a red herring.
