Like everyone else, I caught the new trailer for the next Star Wars movie on Monday and “saw raw, untamed power … and beyond that, something truly special.” I’m now spotting Lucasfilm metaphors everywhere. Since IoT is my personal and professional obsession, botnet foes like Persirai and Mirai and LinuxProxyM naturally equate to the dark side of the Force — the evil empire spreading its influence insidiously through thousands upon thousands of weak devices. Then there are the light-bearers: quiet Jedi masters valiantly using the same Force (say, via Wifatch and Hajimi) in a noble bid to prevent further infection and exploitation. And of course, there is BrickerBot, the permanent denial-of-service (PDoS) botnet that effectively destroys or “bricks” unsecured and susceptible internet-connected devices. It’s harsh but effective. Not entirely light. Not entirely dark. As with Qui-Gon Jinn, and maybe even Luke Skywalker and Rey, it’s kind of gray.
For those who’ve never fallen down the Star Wars rabbit hole, here’s a little Lucasification 101: In Star Wars canon, midi-chlorians (MC) are a lifeform that share a symbiotic relationship with every cell in living bodies (including bacterium found in and on inanimate objects). MC are connected and networked throughout the Star Wars universe, creating a universal zoetic field — commonly called “the Force.” In this analogy, all our IP devices (including 1st and 2nd generation IoT, such as personal computers and mobile devices) would be MC. They connect and interconnect to create the larger “animate” field (our Internet).
The Force is wielded by those initiated in the art of its use and by those with deep personal ties to it — aka Jedi. Hackers that can manipulate the Force for their own purposes, be they light or dark, are Jedi. Indeed, botnets comprise a collection of IoT devices (our version of MC) that are manipulated at will for various purposes; and the humans who control them are our version of Jedi. As in the Star Wars universe, some Jedi are much more powerful than others: whoever controls the most MC — and is the most adept and quick to adapt their use — wins.
Force in the real world
In our universe, BrickerBot stems from a Jedi who got fed up with the growing strength of those bending the Force to the dark side. It is an answer to their attacks that, itself, causes collateral damage for the “greater” purpose of preventing further attacks. Some have cheered the repeated iterations of this vigilante malware for its no nonsense response to lax IP security. In a communique with BleepingComputer, the hacker Janit0r came forward to explain why he/she unleased BrickerBot:
Like so many others I was dismayed by the indiscriminate DDoS attacks by IoT botnets in 2016. I thought for sure that the large attacks would force the industry to finally get its act together, but after a few months of record-breaking attacks it became obvious that in spite of all the sincere efforts the problem couldn’t be solved quickly enough by conventional means. The IoT security mess is a result of companies with insufficient security knowledge developing powerful Internet-connected devices for users with no security knowledge … I hope the unconventional actions by ‘BrickerBot’ have helped in buying another year of time for governments, vendors and the industry in general to get the current IoT security nightmare under control … I consider my project a form of ‘Internet Chemotherapy’ … [and] can only hope that when the IoT relapse comes we’ll have better ways to deal with it. Besides getting the number of IoT DDoS bots to a manageable level my other key goal has been to raise awareness. The IoT problem is much worse than most people think, and I have some alarming stories to tell.
If you’re the poor shmoe who happens to rely on a vulnerable “smart” insulin pump that gets bricked by this bot, you are collateral damage (and raising IoT security awareness is going to be the least of your concerns). But Janit0r isn’t exaggerating about the scope of the problem and the ineffectual measures to counter the dark side thus far. The Ponemon Institute’s recent application security study reports that, on average, 80 percent of IoT apps are not even tested for vulnerabilities, with rush-to-release pressures topping the reasons cited for ultimately vulnerable code. The study further noted a pervasive “lack of urgency” and a lack of funding for general prevention efforts. Alarming stories, indeed.
On the “light” side, a Harvard Business Review article advocates for an IoT equivalent of the National Institute of Standards and Technology (NIST) Cybersecurity Framework, as well as immediate independent industry response (baking security into development, enabling all devices to receive software updates for their entire life span, and improving transparency to consumers). And Wired recently explored defenses like Cloudflare’s Orbit, a new security service for IoT vendors featuring “multiple data security options (from IP verification up to full cryptographic connection signing) to ensure that data moving through the security layer is protected” — albeit with cautious optimism (considering Cloudflare’s own past security issues).
This type of advocacy and service development is all well and good but can be viewed as exactly the type of “moderate” response that drives Jedi like Janit0r to vigilantism: Improved transparency? Another security layer as a service? Really? This is standard best practice territory, and still we find ourselves beholden to hackers for decisive action.
It’s not that we don’t know how to address the IoT vulnerability problem, it’s that we are not speedily addressing the problem at a scale sufficient to stem the dark botnet tide. Time and again, the collective response to obvious signs of danger seems far too measured. Then Anakin lays waste to the Jedi Temple, Order 66 is executed, and it’s too late to mount any strong defense at all.
A different approach
A bigger, bolder stance is required of industry if IoT hopes to escape the Star Wars meme. In casting about for a more effective defense, I’ve found an unlikely source of inspiration in recent news about digital advertising.
That’s right. Perhaps we can better fight the evil empire of botnets by taking a page from the fight against annoying pop-up ads.
Back in March, AdAge reported that the Coalition for Better Ads (CAB) “released research … that will likely surprise no one: Consumers do not like autoplay video ads with sound, pop-up ads, and ads that quickly flash [and/or] change colors.” Members of the CAB include Facebook and Google, but also News Corp., Proctor & Gamble, and Unilever among others. A list of least preferred ad experiences is posted on CAB’s website, and judging by the familiarity of all these types of digital blights, it’s no wonder that consumer ad blocker usage surged 30 percent last year alone. The trending installation of third-party blockers is a serious concern to those leveraging digital advertising to support their business models (ahem, Facebook, Google, News Corp., …).
Now the most-recent scuttlebutt is that Google’s Chrome, our world’s favorite web browser, will soon be imbued with its own default ad blocker. The purported logic being that by blocking the most annoying types of ads natively, Chrome will remove the motivation for consumers to install third-party ad blockers — rescuing a revenue stream and curbing annoying ad proliferation in one fell swoop.
Ignoring the possible antitrust issues with this scheme for a minute, there is a larger model at play here that may help with IoT security.
Since Chrome claims a 44.5 percent marketshare, and assuming it employs the thresholds outlined in the Coalition’s initial better ads standards, this “native blocking” concept effectively starts a whitelist for the types of digital advertising that will be allowed to circulate in the future — eliminating all opportunity for the most egregious types of ads to continue to thrive. Bloomberg coverage noted that “Google alone cannot solve for the incentives users have to install ad blockers,” but if nearly half the browsers in the world preemptively block certain types of ads, and a whole host of industry partners agree to stop paying for those types of ads, then those types of ads are probably going to stop getting made quickfast.
Similarly, if IoT providers could agree on some baseline security threshold (say, a forcing mechanism for strong password protection before activation or a blockchain identifying manufacturer provenance and secure development verification), we’re getting somewhere. And if a couple of important providers (say, Cisco and Netgear) decided their routers would no longer support a connection to any service or device that did not meet that threshold, then real IoT security progress might get made quickfast as well.
I’m not suggesting that Cisco and Netgear can or should shoulder the industry responsibility for bold IoT security changes. The point is merely that we need a real threshold and a brave entity representing a weighty market segment to draw a line and say, “Only those meeting these minimum requirements will play in our network.” If that network is big enough, change will come. Wield enough midi-chlorians and balance can be restored.
There are many entities trying to accumulate that necessary weight: the IoT Security Foundation, OPSWAT, BITAG, and the Internet of Things Consortium (where I co-chair the Privacy and Security task force) are all working to produce that security-first saturation point. But none of us, alone or together, has yet managed to get the IoT security nightmare under control. Perhaps Janit0r’s vigilantism will generate the required awakening. After all, as a certain someone once said, “Do. Or do not. There is no try.”
Jim Hunter is Chief Scientist & Technology Evangelist for Greenwave Systems, a provider of IoT software and services. He co-chairs the Internet of Things Consortium’s Privacy and Security task force and is an IoT educator and inventor, having created and patented several technologies. Prior to Greenwave Systems, Jim joined Motorola Mobility (a division of Google) through the acquisition of 4Home, a company he founded and served as CTO and Chief Architect.