Challenges Implementing Email Security
I’ve just about reached the end of a Proof Of Concept with the FortiMail Secure Email Gateway. It’s a fine product and one I’ll be hoping to get funding for to deploy permanently in our environment in the next couple of weeks.
I’ve never got deep into email security prior to this, and I know I’ve only scratched the surface these past couple of months with the POC, but it’s highlighted some of the many challenges that comes with keeping scammers, spammers and hackers at bay.
I thought I’d list a few of the challenges I’ve come across, as they apply to anybody looking to implement greater email security, not just as part of deploying a FortiMail unit. At this moment in time I don’t have adequate solutions for most of these! But hopefully in the near future I can revisit this article having addressed the majority of them.
SPF
In an ideal world, every domain would maintain an accurate and up-to-date SPF record, and we could rely on SPF to be the champion of email spam defense.
In reality, a huge number of domains either don’t realise their SPF record is inaccurate, don’t know what an SPF record is, or just don’t care. For the past few months I’ve been receiving notifications on hard and soft SPF fails coming into my domain, in the hope that the amount of legitimate business emails would be small and manageable enough to warrant putting restrictions on incoming SPF fails, and notify those companies failing SPF to update their records.
A utopian future where all companies we deal with have valid SPF records…but that was very naive and wishful thinking!
The amount of incorrect SPF records is just staggering, from the smallest of “mom-and-pop” shops we deal with to multinational organisations.
While I do intend to heavily tag and quarantine hard fails, I think soft fails are already a lost cause. The time and effort it would take to follow up with each and every company, asking them to update their SPF, would be a full-time job in itself.
And as much as I would love to take a hard-line stance on this, all it takes is for one revenue-impacting blocked mail and a disgruntled colleague making noise to bring the whole thing to a grinding halt, potentially impacting other security measures I would like to implement.
Sender Policy Framework, you came with such great intentions, but we just weren’t ready for you! So long…
FortiGuard/SURBL/DNSBL Blacklists
Similar to SPF, I would only love to outright block all emails that fail a check to FortiGuard/SURBL/DNSBL, and be able to quip back to anybody complaining that it’s the sender’s responsibility to ensure their IP and domain reputation is in good standing with the many IP/URI lookup services that are available. But the reality is, again, that a heavy-handed approach will upset people and ultimately result in the system being suppressed in other ways.
However, I do think there is more scope to work with here than with SPF. During the FortiMail POC, an insurance company that dealt with our hospital on a daily basis was having their emails blocked due to the FortiGuard URI check categorising a link in their email signature as spam. Initially I thought “Here we go, back to the inevitable white-listing”, which I’m desperately trying to avoid at all costs. The ideal solution would be for FortiGuard to reclassify this URL, as it was clearly harmless (it was a link to the insurance company’s mobile app).
And so I filled in the 2-minute form on the FortiGuard site, and lo and behold, to my surprise, 15 minutes later I got confirmation that this URL had been reclassified to “Banking/Insurance”, which of course we are not blocking as part of our FortiGuard URI filtering.
So the above is a very acceptable result to me. I can continue to enforce restrictions on mails that fail FortiGuard lookups, heavily if need be, in the knowledge that I can relatively quickly have a URL globally reclassified rather than compromising on security with an all-encompassing white-list. It will undoubtedly create a bit of administrative overhead at first, but will be worth it in the long run I think.
Quarantine
I’ve always considered email quarantine to be a very standard business feature, and having never deployed a SEG before, I always took it for granted that somebody had to roll out the quarantine process to hundreds or thousands of users who potentially had never used this kind of feature before.
Some people just find the idea of quarantine difficult to grasp, and it can potentially cause more problems than it solves!
“Hey, this quarantine blocked legitimate mail, and delayed me replying for 30 minutes. I want to be exempt from it!”
“But your quarantine has blocked 205 other spam emails that would otherwise have made it to your inbox…”
“I don’t care, every day I get multiple quarantime reports, they’re almost as annoying as the spam itself!”
And…in fairness, that’s actually a fair and legitimate complaint! So far I’ve only deployed the Quarantine feature of FortiMail to about 30 people. Once finance approves purchase, the roll-out will be to 1,200. In phases of course, but I know we’re going to come across complaints like the above in the process. On the opposite end of the spectrum, we’ll no doubt receive complains about “lewd” spam that managed to get through the anti-spam measures.
Communication will be key, as will not overwhelming users with information. The Quarantine report, the quarantine web portal, how to release mail, how to maintain your own safe sender list, what the various subject line tags mean…it all needs to come in manageable chunks, and at an angle that shows this product is there to ultimately protect the user and hospital, even though it may at first cause some confusion and annoyance.
IP and Domain Reputation
We elected to change our outbound mail IP address when moving to the FortiMail. Our existing outbound mail address had perfectly good reputation, but the old email gateway is also acting as a reverse proxy for another inbound service, and so it had to maintain the IP.
To anybody contemplating moving their outbound IP, I’d recommend against it if at all possible. It will take a few days of decent mail flow to get your new IP address in good standing, and you’ll have trouble in the meantime with some recipients accepting from your new address.
You may, like us, even come across some tin-foil hat security-conscious partner companies who have in the past blocked all incoming SMTP connections except for those on a white-list. Of course, nobody in our company remembers who these recipients are and there sure isn’t any documentation on it! It’s a frustrating process contacting companies, particularly public health institutions, and getting hold of somebody who can make the necessary changes on their side.
Along with the whole process of getting a reverse DNS entry set up for your new IP, which for us was painful (no less than 6 emails back and forth between our ISP and DNS provider insisting it was the other who managed this), changing your IP is one extra headache you could probably do without.
Deciding on Rate Limits
During the POC, despite all the extra measures we had in place, we still got hit by a small phishing campaign trying to trick users into logging into a “Physicians” web portal with their domain credentials. It was a bit of a smack in the face to be honest…a few days before going for funding too!
In defense of the FortiMail, this phish came from a (freshly hacked) legitimate Canadian Government email address, passed SPF checks, and didn’t have any malicious content, with the link going to a (presumably also hacked) technology site.
One way we could have at least slowed the 300 or so emails sent would have been to have to rate limits in place for inbound mail. There’s a few options here: maximum SMTP connections in 30 minutes per client, maximum recipient address in 30 minutes per client, maximum recipient addresses in a single session etc.
It’s something I never thought about before; what’s a reasonable number of simultaneous recipients in an email message from an external source before blocking or limiting in some way? Obviously internally you would expect some huge CC’s, but externally? We employ an external company to do some “hospital newsletter” type campaigns to our users (a marketing decision of course, not IT!), but I’ve found in the logs that these actually make a single SMTP connection per recipient.
So I went with 20 as being a reasonable number of recipients in a single email. I don’t recall ever CC’ing more than 20 people externally, so we’ll see how that plays out, and if it helps in another situation similar to the Canadian Government phishing attempt.