Skip to main content

Healthcare Best Practices for Securing Email

Written by website@neigerdesign.com on . Posted in Health-ISAC.

From training / testing staff to implementing DMARC

Special thanks to Justin Armstrong, CISSP, MEDITECH Product Security, for sharing this article in the spirit of helping other H-ISAC member organizations implement DMARC. MEDITECH has been doing DMARC in reject mode for some time.

Email continues to be a major vector of attack. Frequently InfoSec professionals use the analogy that an organization and its defenses are like a castle. It has multiple walls, and perhaps a moat, and this represents the various defenses that are in place. Defense in depth — multiple layers of defenses which overlap — is an important approach to security since security controls can fail, and individual security controls do not protect against every attack.

There is a serious issue that we sometimes leave out of this picture. In our mind, we’re picturing the castle with its looming walls, massive gates, portcullis, and heavily armored soldiers who challenge everyone who approaches. In reality, the cyber defenses may be as impressive as this ancient castle with one exception — the “guards” are easily tricked and frequently let attackers in — right through the front gate! In today’s world, every employee has the power to allow attackers into the castle. They “open the gates” to attackers whenever they download malware attachments, give up their credentials to a phishing site, or visit a malicious website.

Three components of email security to be considered:

  1. Training and testing staff
  2. Improving the trustworthiness of email
  3. Securing the email infrastructure

Training Staff

Train your staff about phishing and social engineering in general. This includes educating them about techniques criminals will use over the phone or in person to gain access. Include real life experiences about phishing. Share best practices for email security. Provide education that will also help them outside of work. The hope is that once they begin practicing good security in their personal life, they will keep those habits with them in the workplace.

It is important to help non-InfoSec staff appreciate just how serious an issue this is. These people would never dream of handing the key to the pharmaceutical cabinet to a complete stranger, but may not understand that they are doing just that when they click on links and give up their credentials. Help them to make the connection that downloading a suspicious attachment can be just as destructive as letting a criminal into a secure area unsupervised.

Test Your Staff

Send out test phishing emails. The goal is not to trick staff and make them feel bad. The goal is to help them develop “muscle memory.” Staff will have been trained on identifying phishing emails, and will understand the importance of being cautious about clicking any link or downloading attachments. But unless they put it into practice, they will eventually forget. Phishing tests will serve as constant reminders, and will also help the security team discern who needs further education.

This works best if you can:

    • Track who clicks the link or downloads an attachment
    • Track who actually enters their credentials after clicking
    • Give staff a way to report phishing
    • Educate staff on demand when they fail a phishing test

Metasploit and other freely available tools enable one to perform phishing tests without a great expenditure of time or money. Companies PhishMe and KnowBe4 have comprehensive phishing and education products that have received wide acclaim.

Improving Email Trustworthiness

Perhaps you have already experienced this – after training and phishing your staff, they no longer trust anything. Staff may send you repeated messages asking “is this email legitimate?” While this is good that you have raised their awareness level, we really need to consider what we can do to help them quickly identify trustworthy emails.

First of all, consider creating a set of standards for corporate emails. Every time we send out an email that says “click on this link for more details” we are undoing all of our work in educating them to hesitate before clicking. But we don’t want them to also suspect every email from us. We could provide a brief explanation about how to identify the current email as legitimate (hover over the link, examine the “from” field) or we could forego links altogether. Rather than sending them a link, ask them to navigate to your intranet page and tell them how to locate the page you would like them to read.

Secondly, work with your email solution to implement the following:

  1. Spam Filtering– use spam filtering. Many email products come with this.
  2. Scan Email Attachments– scan all email attachments as this is a major vector for malware.
  3. Add a warningto emails that are from outside the organization.

Prevent Spoofing – SPF, DKIM, DMARC

We also want to prevent spoofing of our domain. Not only does this benefit our internal staff, but it can prevent spammers from using our domain in attacks on other organizations. This can be accomplished through the use of SPF and DKIM. We can then move to implement DMARC once we have put these two in place.

  • SPF (Sender Policy Framework)– [4] – SPF protects your domain from spoofing. Spammers and phishers will be less likely to send emails pretending to be from your domain if you have SPF in place. Ultimately this means that your legitimate emails are more likely to get through the spam filters at receiving organizations. OpenSPF has some useful resources [5].
  • DKIM (DomainKeys Identified Mail)[6] – DKIM utilizes a digital signature which allows others to validate the origins of the email and that it has not been tampered with by an unauthorized party.

SPF and DKIM benefit those who receive emails from your organization. In a sense, this benefits your organization as well. If an important email from your organization does not get through, that can impact how your organization is perceived. How, though, can you find out if your email authentication methods are actually working? How can you receive reports that indicate others are trying to spoof your emails? This is where DMARC comes in.

NIST Special Publication 800-77 (page vi) does a great job of explaining the role of SPF, DKIM, and DMARC:

“Sender Policy Framework (SPF) is the standardized way for a sending domain to identify and assert the authorized mail senders for a given domain. Domain Keys Identified Mail (DKIM) is the mechanism for eliminating the vulnerability of man-in-the-middle content modification by using digital signatures generated from the sending mail server.

…

Standardized handling of SPF and DKIM removes guesswork about whether a given message is authentic, benefitting receivers by allowing more certainty in quarantining and rejecting unauthorized mail. In particular, receivers compare the “From” address in the message to the SPF and DKIM results, if present, and the DMARC policy in the DNS. The results are used to determine how the mail should be handled. The receiver sends reports to the domain owner about mail claiming to originate from their domain. These reports should illuminate the extent to which unauthorized users are using the domain, and the proportion of mail received that is “good.” ”

DMARC

Domain based Message Authentication, Reporting and Conformance (DMARC [7]) builds upon SPF and DKIM. Preferably you will have implemented both SPF and DKIM, though you could just implement one of them and still implement DMARC.

DMARC allows those domain owners who send email to specify how those who receive emails can validate the authenticity of those emails. The sending organization can even specify what the receiver should do with emails that fail validation, and how reports should be sent back to the sender. This benefits those on the receiving end of your organization’s emails, and it benefits you by providing you with feedback. For example, you may note that there is a sudden rise in unauthorized users sending email from your domain. This could be a prelude to a cyberattack, and you could share this information with the FBI via IC3.gov.

DMARC.org [7] provides some excellent explanations about how DMARC works, and the benefits of using DMARC. Typically, you will roll out DMARC in stages.

  1. Monitor– First, monitor the alerts about spoofed emails.
  2. Quarantine– Begin quarantining any of these suspicious emails.
  3. Reject– Once you have reached the point where legitimate emails are rarely filtered out, move to automatically reject these emails.

The DMARC reports can be useful threat intelligence as well. You may see trends or patterns in rejected emails, and it could give you an early warning that someone is targeting your organization.

Rolling Out DMARC

There is more than one way to proceed with rolling out DMARC. If you review the links on the NH-ISAC challenge page, there is this set of pages from DHS [2] which explain the steps that federal institutions are taking to improve the security of their web sites and email systems. The NIST Special Publication 800-177 entitled “Trustworthy Email” [3] also provides extensive information about SPF, DKIM, and DMARC.

If SPF and DKIM have not already been implemented, you might develop a plan like this:

  1. Add DKIM to all known email sources/streams
  2. Add an SPF record that covers all known email sources/streams. It would be best to use the soft fail (~all) until you are absolutely sure you have identified all of the sources/streams.
  3. Enable DMARC in reporting only mode.
  4. Review the DMARC reports. The goal at this stage is to identify any email sources/streams that are not being authenticated properly by SPF and DKIM. These problems should be corrected before moving on to the next steps.
  5. As an interim step, you may change the DMARC policy to quarantine emails that do not pass at least one check.
  6. Once you are confident that all email sources/streams are properly authenticated by SPF or DKIM, change the DMARC policy to reject emails that do not pass at least one of these checks.

Some useful tools for this are listed in the reference section, such as the OpenSPF page [5] and a few tools from commercial entities [7,8.] When implementing these changes, you will also need to work with any vendors that may be sending emails on your behalf.

Email Account Takeover

However, this does not mean that all email that staff receive will be legitimate. Even with all of this in place, some malicious emails will make it through. One scenario that is particularly effective for attackers is email account takeover. If the attacker is able to steal the credentials of an employee and log into their email account, they are now able to masquerade as that staff member. They can read through past emails to see what subjects are discussed and then craft a customized spear phishing email which references past conversations and includes an attached pdf or word document with malware.

Check out Barkly’s blog about the Ursnif spear phishing attacks – these were particularly worrisome because the attackers would reply to existing email threads!

Securing the Email Infrastructure

Last, but certainly not least, we want to make sure that our email infrastructure is secure. The following NIST publications cover different aspects of email security in great detail:

NIST SP 800-45 – Guidelines on Electronic Mail Security

  • Message Signing
  • Encryption Standards (PGP, etc.)
  • Mail Servers

NIST SP 800-177 – Trustworthy Email

  • SPF, DKIM, DMARC
  • Encryption in Transit
  • Mail Clients

Conclusion

Email is involved in the majority of security incidents today. Email security deserves special attention. Besides securing email itself and doing our best to make email trustworthy again, staff awareness and education will always be important. Make sure that everyone in the organization understands just how serious an issue this is.

References:

  1. NH-ISAC: “Fall Summit Recap and DMARC” – https://nhisac.org/nh-isac-fall-summit-recap-dmarc/
  2. DHS: “Binding Operational Directive 18-01: Enhance Email and Web Security” – https://cyber.dhs.gov/
  3. NIST Special Publication 800-177: “Trustworthy Email” – http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-177.pdf
  4. Wikipedia: “Sender Policy Framework” – https://en.wikipedia.org/wiki/Sender_Policy_Framework

“If a domain publishes an SPF record, spammers and phishers are less likely to forge e-mails pretending to be from that domain, because the forged e-mails are more likely to be caught in spam filters which check the SPF record. Therefore, an SPF-protected domain is less attractive to spammers and phishers. Because an SPF-protected domain is less attractive as a spoofed address, it is less likely to be blacklisted by spam filters and so ultimately the legitimate e-mail from the domain is more likely to get through.[9]” –https://web.archive.org/web/20100129195805/http://www.emailmanual.co.uk/index.php/2009/05/why-should-i-implement-a-spf-record-on-my-domain

  1. Open SPF Organization – http://www.openspf.org/
  2. DKIM Organization – http://www.dkim.org/index.html
  3. DMARC Organization – https://dmarc.org/
  4. Kitterman Testing Services: “SPF Record Testing Tools” – http://www.kitterman.com/spf/validate.html
  5. Dmarcian.com: “DMARC Inspector” – https://cauldron.dmarcian.com/dmarc-inspector/

Phishing

This site is registered on Toolset.com as a development site.