The who and what of email security
In the days of circuit-switched telephony, when Grandma dialed Grandpa, the phone company could easily determine that the caller’s identity was, in fact, Grandma. Such confidence melted away, however, with TCP/IP and the Internet. That is, when Kahn and Cerf decided to allow senders, instead of the network, to specify their identity, they created a flexible Internet protocol – but also one that required add-on overlays for authentication.
One casualty of this non-assurance has been email security. Because identities are untrusted, virtually every enterprise security solution today must sift through the contents of inbound payloads. While such filtering is an important advance and a necessary control, it sure seems unfortunate that sender names, domains, and services play such a relatively minor role in making real-time security decisions about email.
At least that was the case for many years – but the situation is now definitely improving. I spent some quality time with the team from Valimail this past week and they took me through a well-conceived methodology for improving the security of inbound messaging, including email. Their concept is that two fundamental questions must be addressed in assigning trust to a message: (1) What’s in it? and (2) Who sent it? Let’s examine each:
As suggested above, the what’s-in-it part is generally attended to by security teams through a complex gauntlet of content filters. This has progressed from simple anti-virus scans to advanced machine-learning-assisted rendering of judgment on content. This done in safe, virtualized enclosures designed to simulate realistic environments. So, our community has gotten good at determining what stuff is included in an email message.
Sender identity validation
The who-sent-it part, however, has been tougher to solve, because traditional email security defensive tools do not protect against fake senders. The over-arching protection goal, of course, is to support a determination as to whether a sender can be trusted, and whether that sender really is who they say they are. So, developing effective means for answering these questions is in everyone’s interest.
Valimail’s Trust Layer
Valimail described to me a concept called a trust layer that can be established between external senders and internal email gateways. The idea is to pre-process sender identities to defend against fake information, and to block inbound email before it hits the traditional secure email gateway. Thus, if the sender of an email is lying, then the emails can be blocked. I like the concept, especially because functionality is available to implement this layer.
Specifically, the trust layer would focus on the who-sent-it part of the equation through authentication controls such as Domain Message Authentication Reporting & Conformance (DMARC) and Brand Indicators for Message Identification (BIMI). Both of these bind reported identities to more concrete sender information and policies maintained at the infrastructure level by email service owners. In addition, Valimail assesses sender trustworthiness based on its analysis of millions of email-sending domains. It then uses that data to inform an additional dimension of identity protection on inbound email for enterprises.
Here’s my advice: Sit down and redraw your email security infrastructure, which probably includes external senders, a secure email gateway (SEG), and inbound email sorting, processing, and routing to inboxes. Your new drawing should include a trust layer between the Internet and your SEG, and it should be expected to use available authentication-related information to filter messages, if the “who” portion so-warrants.
As always, let me know your thoughts on this – and I’d sure like to see some of those new email infrastructure drawings!