As everybody noticed, the delivery vector for these phishings is email. So an email filtering engine that is capable of detecting phishing attacks, either by recurrent pattern detection (like Cyren), or via URL extraction and checks (like Kaspersky or BitDefender), when in place, will keep your users safe. These phishing emails are also caught by open source engines like the veteran SpamAssassin or the new kid on the block OrangeAssassin (from SpamExperts).

A detailed analysis from Cyren:
https://blog.cyren.com/articles/locky-2-jaff-ransomware-launched-from-necurs-botnet.html

Yet again the delivery vector is email. If you are managing on-prem email servers, make sure your filters are active and properly configured.

@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.

@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.

Stumbled upon this article today: https://itsm.tools/2017/05/18/power-chat-support/

I am curios as to how many of you provide chat support and what is the user adoption on it?

@scottalanmiller we are looking at it to integrate it with @axigen. Good product indeed!

@Tim_G OK, got your point and see its validity. But what about when you are servicing multiple, remote SMB customers with a team of 3+ support guys?

@Carnival-Boy educating customers pays dividends on the long term, right?

@Minion-Queen Thanks! Interesting... I see they also have a free tier to give it a try...

Stumbled upon this article today: https://itsm.tools/2017/05/18/power-chat-support/

I am curios as to how many of you provide chat support and what is the user adoption on it?

A detailed analysis from Cyren:
https://blog.cyren.com/articles/locky-2-jaff-ransomware-launched-from-necurs-botnet.html

Yet again the delivery vector is email. If you are managing on-prem email servers, make sure your filters are active and properly configured.

As everybody noticed, the delivery vector for these phishings is email. So an email filtering engine that is capable of detecting phishing attacks, either by recurrent pattern detection (like Cyren), or via URL extraction and checks (like Kaspersky or BitDefender), when in place, will keep your users safe. These phishing emails are also caught by open source engines like the veteran SpamAssassin or the new kid on the block OrangeAssassin (from SpamExperts).

@scottalanmiller Thanks!

@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.

@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.