I was reading through project writeups now at the end of the semester. Two were particularly interesting and fed on each other as I read them.
One project writeup was a review of the sorry state of email security. The student reviewed current technology and came to the conclusion that it isn’t just technology that is preventing encrypted and authenticated email from being used pervasively. The technology enabling both has been around for over ten years. In my view there are a couple issues. Multiple flavors of similar technology (e.g., GPG and SMIME) that have interoperability issues. And lack of motivation on the part of the providers and the end users to insist on it. The student suggested maybe legislation needs to be passed to force people to use secure email. I agree that some motivation is needed but perhaps a legislative motivation is not the most effective.
Several years back (3 or 4?) there was a big transition with the service providers to require end user clients to authenticate to the SMTP server before it would accept mail to send. I’m sure this was a hassle for the service providers and required a lot of user support to make the transition, but it quickly became essential for them to do this. Without this authentication, the service provider was an easy target to source span. As a known spam source, the services providers addresses were blocked throughout the network, making their customers complain even louder. Perhaps some other maltechnology will effectively force the adoption of secured email.
One might argue that the pressure to have secured email is reduced because spam is perceived as less of a hassle due to the improvements in spam filtering technology. However, I would argue that spam filtering technology has just changed email into an unreliable transport. Joe doesn’t respond to my mail. Does that mean Joe doesn’t like me any more? Joe is to busy? Or Joe didn’t see my mail thanks to some intervening spam blocker? For me the later case is often true.
Another student wrote a review and some simulation results of the Internet Storm Bot, the first P2P bot net. Originally bots had a hierarchical command and control structure. If you found the head, you could pretty easily disable large bot nets. It sounds like the software malengineers have learned a lot and have adopted a lot of distributed processing techniques. No longer is there a fixed hierarchy. Each node has a set of neighbors it communicates with. The set can change over time, so if one bot is destroyed, the remaining bots can adapt. This is denser communication graph, so it is more resilient. You can find more detils on the bot net from the following workshop paper , “Peer to peer botnets: overview and case study”.
The bot engineers also frequently change their communication protocols and add encryption. With encryption, they can frequently rekey. All of this makes it more difficult for the outside observer to understand what is going on. All this change potentially also makes it more difficult to keep your bots in sync. If a bot was off the net for a while, it would miss some protocol updates. When it returns, would the bot software try to bring it up to date? How long does the bot have to be down to turn stale?
This is all bad new for a interposing bot traffic detector that I’ve been thinking about. The likelihood that a deployment could stay up to date is pretty low. When operating at the border, perhaps detecting and reacting to odd behavior is your best bet. Though if the bot nets are indeed so massive (100,000’s or 1,000,000’s of devices), the amount of malignant behavior generated by each bot might not rise above the noise. The dark address space work is one approach to making malignant behavior more apparent.
The bot paper relates to the email study because the mail means of distributing the initial infection was by getting folks to click on exe’s attached to emails. One would think after all of this time, no one would click on a weird exe. But then again, if we had some sort of proper identity authentication, I would really know the attachment was from my trustworthy friend. Thus, we lead back to having secure expectations for email that are not currently based in reality.