By Edward Amoroso, CEO of TAG Cyber LLC
Back when Nixon was telling us all that our President was no crook, the fathers of the Internet decided that it would be just fine for computers to lie.
Before this vastly consequential decision by Kahn and Cerf, just about all technology worked on the idea that communicating devices, also known as telephones, should connect across a circuit and should most definitely not lie. So-called point codes designed in the Bell System could be reasonably trusted to reveal the calling party, and this was a handy feature in circuit switching.
But with TCP/IP, Kahn and Cerf decided that it would be fine for you, the sending party, to make your own decision about what to write down as a “from” source address. And they also based their network on packets, which could be scattered in such a manner as to survive nuclear holocausts – perhaps the most awesome example of an original design feature that we’re all glad turned out to have been somewhat extraneous.
Look, this telling-lies and using-packets stuff was obviously a good call, as evidenced by everything that ensued after their design . . . what with their protocol and Internet, like, changing Planet Earth and all . . . but if I could time-travel, I might bop back to 1973 and ask whether it might be possible to reconsider that design decision. I doubt they’d have listened.
Nevertheless, until someone can find a DeLorean, we must all try to do what we can to improve the robustness of source deception at the protocol and application levels. Email, in particular, has been a bit of a mess recently, with senders figuring out that they can send email from “Your Trusted Bank,” without actually being “Your Trusted Bank.” This is a real bummer when the email looks like it most definitely came from “Your Trusted Bank.” It can get really confusing, and we call the result phishing.
Two super geeky standards with the acronyms SPF and DKIM were designed to try to help fix the problem at the infrastructure level. What they do is help email providers connect “from” addresses in email to the actual domain they claim to be from, as well as some other checks to improve the integrity of email content. A newer standard called DMARC was created recently to combine and integrate SPF and DKIM into something more usable with reporting and other good stuff for domain owners.
The whole thing is a really great idea that solves a really tough problem and has solutions from some really great companies – like Agari. So it is perhaps a bit confusing that this control is rarely included in audit reports, compliance standards, regulatory frameworks, and on and on. Such omission might be because, admittedly, understanding DMARC requires that you be a bit of a techie. I cover the standard to some degree in my new report 2017 TAG Cyber Security Annual, available for free download on the Agari website and the TAG Cyber website.
But here is my request: Even if you are not a techie, you probably know how to complain and whine – right? And this is exactly what you should do with the group managing your business domain if they are not presently using DMARC to reduce the risk of phishing. So why don’t you take a moment and send them a note asking if DMARC is in place to reduce security risk in email . . . and if they are not, then you have my permission to complain.