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.
-
@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.
-
@Dashrender said in encrypted email options?:
@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.
requirements in IT have to be somewhat open-ended because at the rate things are changing. Due Diligence being one of the requirements means you should do what is reasonably required to keep things secure. If there is a large cost involved, then it may be understandable not to pursue more security in a specific area, but if the cost and effort is minimal it is something you should do.
-
@Dashrender said in encrypted email options?:
@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?
Phishing. Your work has had email addresses leaked before and an attacker could use this as way to target your patients. An attacker would not use a service that is actively scanning for malware, he would send them via email.
Another advantage is that you control the data until they download. Which means you can set links that expire or remove content at anytime. Could the user have downloaded it, sure. However, you control the full delivery process and can actually remove access at anytime. An email will sit in their inbox forever.
-
@IRJ said in encrypted email options?:
An email will sit in their inbox forever.
That is not my problem and nowhere near a requirement of any system
-
@IRJ said in encrypted email options?:
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?
The entire point of HIPAA is to reduce what the "minimum" is.
But honestly, from dealing with some of these companies, I think doing "more" is actually less secure. Letting some of those vendors who have really bad track records be third party holders of that data is worse than doing what people like to call "minimum" security.
The minimum is more security than most of the alternatives that people push for. It's just not as invasive, so people don't feel as secure.
-
@scottalanmiller said in encrypted email options?:
It's just not as invasive, so people don't feel as secure.
This is definitely true.
-
@IRJ said in encrypted email options?:
@Dashrender said in encrypted email options?:
@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?
Phishing. Your work has had email addresses leaked before and an attacker could use this as way to target your patients. An attacker would not use a service that is actively scanning for malware, he would send them via email.
Another advantage is that you control the data until they download. Which means you can set links that expire or remove content at anytime. Could the user have downloaded it, sure. However, you control the full delivery process and can actually remove access at anytime. An email will sit in their inbox forever.
LOL - OK that's good for email, but patients also have access to their patient portal - you know.. all that HIPAA data we're trying to protect. We can't set expiration dates on access to those. So if the end user's computer is compromised, there is nothing we can do about that.
-
@IRJ said in encrypted email options?:
Another advantage is that you control the data until they download. Which means you can set links that expire or remove content at anytime. Could the user have downloaded it, sure. However, you control the full delivery process and can actually remove access at anytime. An email will sit in their inbox forever.
Well, think of the email as having been downloaded and now they are the same. In either case, if the patient automatically downloads everything and just leaves it somewhere, it's just there forever. In both cases, you don't care.
