Working around email security

One of the common things I see as a delivery consultant is that companies do their best to set effective policies about email, but make it difficult to comply with those policies. It happens all the time. It’s one of the reasons that the tweets Steve shared about Sec. Clinton’s email server rang so true to me.
Security.
One of the commenters on that post disagrees, and uses banks and health care as an example.
Erik says:

Disagree. I work for a bank – highly regulated, just like health care and the government itself.
We go through quarterly compliance training – yes every three months. I can assure you anyone working on department of state information systems also has security clearance and goes through compliance training.
They knew what they were doing and did it anyway, my theory is that some higher up (Clinton or direct report) asked for it and someone was afraid to say no.

Banks and health care companies are notorious for registering new domains and creating infrastructure because they can’t do what they want through normal IT channels. I’ve had both industries as clients and I’m a consumer of mail from both. I’ve had conversations with folks in their security and their marketing departments. If anything, banks and health care are prime examples of how companies will work around things.
Generally the work around involves registering an entirely new domain and then authenticating that domain through their ESP. It’s mail that’s sent to customers by the bank, but it’s not the primary bank domain. This can be done for all sorts of reasons.
In at least two cases a bank registered a new domain to use for alerts of a security breach. In one case it was my credit card company, sending to the tagged address only the company had. I called the bank and they told me it was a phish and not to answer it. Except if that was true, there was a much bigger breach as only the bank had that address of mine.
In another case a bank sent us an alert that a system one of our customer uses for invoicing and payments was compromised. Again, the bank sent out an alert. That alert failed DKIM checking and was unauthenticated email. I’d believe this was a phish / spoof, except I used tagged addresses and I know that only the supplier portal had that address. If it was a phish, it was a phish using data stolen from the company.
To be fair, things are getting better. Banks are working to consolidate domains and stop with the using so many different domains. I even had a discussion with on bank employee earlier this year at CNX16 about the delivery implications of the consolidation they’re undergoing. Seems a different division was having problems with a blocklist and she was concerned those problems would spread to her mail when they consolidated the domains.
As I was writing this post I discovered that our health insurance company has finally started DMARC protecting the cousin domain they use to send billing notices. Last year they weren’t and I used them as an example during one of my talks to a health care audience. Many of the DMARC advocates were loudly trumpeting that this company was protecting all their mail with DMARC, but they weren’t they were only protecting part of it. So things are improving.
The point is that this isn’t unusual at all. IT can’t do what part of the company needs, whether for policy or budget reasons, and so options are explored. Those options are often registering a new domain and handling the mail on external hardware. It is common business practice, even in highly regulated industries like health care and banking. It does seem to be becoming less common, which is great! But let’s not pretend that email is some perfect bastion of security and policy compliance in regulated industries.

Related Posts

Security vendors and trust.

A big part of my predictions for 2016, that I’ll publish shortly, is that security is going to be a huge issue. I think we’re really going to see receivers expecting senders to have their houses in order when it comes to sending mail.
Of course, some filter companies need to get their houses in order to. Yesterday, a security researcher went public with problems in the TrendMicro anti-virus appliance. These vulnerabilities would let any email sender remotely execute code on the recipients machine with no interaction of the user. They also exposed all the passwords on the machine to the outside world.
Even worse, Trend doesn’t seem to understand the urgency to fix this. They have started releasing patches for the exploits, but there are significant problems with the patched versions as well.
If you’re a Trend user, you may want to consider other vendors for desktop security. I know that no security is perfect and that other vendors have problems, too. But shipping a password manager that exposes all passwords is just incompetence. It seems like a corporate lack of understanding of what their business is and how to actually create security software.
Even worse is that lack of urgency from the Trend folks as the security researchers are explaining the problem. I don’t care if the person receiving the report was the janitor, anything that says security exploit should be escalated to someone who can determine if the report is valid.
Compare Trend’s reaction to this to Juniper’s reaction to discovering a backdoor in their code in December. First off, Juniper found the exploit during a routine code review. That alone tells you Juiper is continually monitoring their code security. Second, Juniper was reasonably open about the issue, with executives posting blogs and security posting advisories talking about the issue. More importantly, they shared how they were going to fix it and prevent it from happening again.
Security is such a large issue right now. We have to be able to trust our vendors to do what they’re selling us. Every vendor is going to make mistakes and have vulnerabilities. No code and no developer is perfect. I do expect, though, that vendors will take exploits seriously and act fast in order to correct the problem. I’m not seeing that sense of urgency with Trend.
 

Read More

January 2016: The Month in Email

Jan2016_blogHappy 2016! We started off the year with a few different “predictions” posts. As always, I don’t expect to be right about everything, but it’s a useful exercise for us to look forward and think about where things are headed.
I joined nine other email experts for a Sparkpost webinar on 2016 predictions, which was a lot of fun (see my wrap up post here), and then I wrote a long post about security and authentication, which I think will be THE major topic in email this year both in policy and in practice (see my post about an exploit involving Trend Micro and another about hijacked Verizon addresses). Expect to hear more about this 2016 continues.
My other exciting January project was the launch of my “Ask Laura” column, which I hope will prove a great resource for people with questions about email. Please let me know if you have any questions you’d like to see me answer for your company or your clients — I’ll obscure any identifying information and generalize the answers to be most widely applicable for our readers.
In other industry news, it’s worth noting that Germany has ruled it illegal to harvest users’ address books (as Facebook and other services do). Why does that make sense? Because we’re seeing more and more phishing and scams that rely on social engineering.
In best practices, I wrote about triggered and transactional emails, how they differ, and what to consider when implementing them as part of your email program. Steve describes an easy-to-implement best practice that marketers often ignore: craft your mails so the most important information is shown as text.
I re-published an older post about SMTP rules that has a configuration checklist you might find useful as you troubleshoot any issues. And a newer issue you might be seeing is port25 blocking, which is important if you are hosting your own email senders or using SMTP to send to your ESP.
Finally, I put together some thoughts about reporting abuse. We work closely with high-volume abuse desks who use our Abacus software, and we know that it’s often not worth the time for an individual to report an incident – but I still think it’s worthwhile to have the infrastructure in place, and I wrote about why that is.

Read More

Email nightmare for some FSU students

shieldI mentioned yesterday that sometimes people and software screw up in ways that cause problems. Today I saw an article demonstrating just how bad these issues can be. Florida State University Housing Department sent detailed and confidential violation reports to tens of thousands of students.

Read More