Architecting IoT for Emergencies and Disasters

disasters
What was envisioned, and has been discussed and speculated for a long time, has now happened. On or about October 21, 2016, beginning about 7:00AM US ET, a massive DDoS (Distributed Denial of Services) attack was executed by millions IoT Bots. Unprecedented in its intensity, number of devices engaged, and identified as hacked web cameras, DVDs and routers this attack demonstrated that forthcoming IoT ecosystems have important security weaknesses. Therefore, in this blog we point to the necessity of architecting IoT for security and resilience and discuss some possible approaches.

How the IoT Bots Attack Was Executed

Domain Name Services (DNS) accepts URLs (aka Domain Names, AKA site names) and translates them into IP addresses to enable direction and routing of internet traffic. As a such, these servers represent the weak under-belly of the internet and are a typical target of DDoS attacks. Large numbers of computers are infected with malware and made ready for coordinated attack on infrastructural service intending to overload CPUs, saturate network traffic, and fill up server disks. The recent DNS DDoS attack primarily made use of compromised devices, turning devices like smart kitchen appliances, routers, and even IP camera security systems into ‘bots’ for an attack. This attack has again reminded us all that any chain is only as strong as its weakest link(s).  Clearly, the internet today is connected to a lot of weak links.

figure-1

This time, the attack was huge in scope and intensity (several million devices and intensity (620 – 1200 Gbps), and shifted from one to another geographical region.

The key component of Internet traffic routing is DNS system consisting of many thousand servers which can be marked as CRITICAL. On the edge of the internet, trillions of devices will be actively connected. Therefore, size, scope and dynamics of security will range from critical (DNS) to vulnerable (all Edge devices), requiring a Herculean effort to manage and keep resilient, indeed.

Architecting for Resilience – Today/Tomorrow

Current DNS infrastructure is architected for DDoS attacks, but as we are witnessing the rapid rise of IoT devices deployed, both DNS and IoT should be carefully reconsidered in the context of the need for rebuilding infrastructure for trillions of devices and IoT things, gadgets and objects radically hardened for unbreakable security.  Witnessing deployment of IoT in transportation and industry, this will bring yet another dimension in focus: safety. In short, entire IoT eco-system should be architected for resilience[1] designed for security, safety and privacy protection. Without that, IoT may face the destiny of an interesting but dangerous technology.

Architecture, regardless of scope, when properly performed considers multiple perspectives or views in the precise context of the scope. Along the path from Architecture to Design to Implementation to Operations, one key aspect to be considered carefully is granularity. Properly implemented granularity can facilitate efficient (and cost efficient) scaling, but can also equip and enable fault tolerance and/or rapid business continuity, minimizing and managing disruptions to business. In considering the cost of establishing resilience through fault tolerance at some level to maintain business continuity of any particular grain, it is of equal importance to consider the cost of a potential disruption if no action is taken, and a failure occurs.

Our collective dependence today on the Internet to conduct most day-to-day business makes consideration of the pervasive attribute of ‘resilience’ even more important.  For these reasons, in our opinion, “resilience awareness” is the responsibility of every member of the internet community.

One example of the need for pervasive ‘resilience awareness’ is that many business Enterprises (and Extended Enterprises) were seriously impacted by the DNS DDoS attack.  Many Enterprises and Extended Enterprises realize the need to re-evaluate the cost/benefit of hosting local (Enterprise/Extended Enterprise) DNS servers, and to establish a protocol standard within their scope that determines when their local DNS servers effectively temporarily become the primary or exclusive DNS servers to minimize their business disruption.

IoT Intelligence: Malware Mapping

Beyond architecting, designing and engineering IoT ecosystems for resilience, one can envision the necessity of attentive patrolling/scanning of entire system, so on a positive note, it is good that this IoT bots attack happened to make us aware of the problem. On the other hand, we see that a huge number of IoT devices are being used in real-world environments effectively without any security shield.

There is also a de facto acute need for some global security standards, and automated enforcement, for smart networked devices, such as the need to enforce changing the default (out of the box) passwords.  Most home and SOHO routers, NAS/private cloud appliances, IP cameras, and even residential networked kitchen appliances have default passwords available online in a .pdf User Manual. Studies indicate that a significant percentage of these devices are connected to the internet with these default UserIDs and Passwords unchanged or are otherwise compromised rather easily[2]. Basic enforcement could be as simple as some basic form of verification that no ‘out of the box’ password is permitted on any device connected to any WAN.

Of course, most security related resiliency approaches are analogous to using devices to prevent auto theft.  All of the auto theft prevention devices can be eventually defeated, so auto theft prevention devices are simply a matter of influencing thieves to choose a different auto.  Similarly, any security related resiliency approach can eventually be defeated, but at the very least these approaches can be utilized to influence hackers to look for a different network to attack.

Architecting means envisioning entire ecosystem with all possible uses and (especially) misuses, driving the need to architect the entire system for resilience.  Designing implies deciding about compartments cleverly chosen with appropriate technologies, so that the system can resist challenges as long as feasible. Engineering suggest that wisely configured components and their links will be chosen so that single points of failure are all eliminated.

To see IoT making the Third Wave of Internet, we need not only apply novel architectural approaches, and efficient technology solutions, but also regulation and legislation adjusted to the newly created circumstances, not to mention likely military uses of IoT bots aiming to create global havoc and provoke huge disasters. Even governments are beginning to understand the need to address this more aggressively.  Our position is that we must collectively begin this as a key component of decision governance in all systems, process, and people, and we’d better start yesterday.

Related Links:

  1. Previous blogs by Kemal A. Delic
  2. On Resilience of IoT Systems – Delic, ACM Ubiquity, February 2016.
  3. Sirens’ Song of the IoT – Delic, ACM Ubiquity, December 2015.
  4. Resilience of IoT Systems – Delic, Berlin, 25-26 June, 2014.

 

[1] In this context, we define “resilience” as the ability to avoid, and if/when needed, recover readily from disruption of any kind, malicious or otherwise.

[2] http://www.itworld.com/article/2716804/security/if-your-router-is-still-using-the-default-password--change-it-now-.htmlhttps://www.cnet.com/news/top-wi-fi-routers-easy-to-hack-says-study/http://www.phenoelit.org/dpl/dpl.html, and http://www.securityevaluators.com/knowledge/case_studies/routers/soho_router_hacks.php (note they found that "11 of 13 routers evaluated can be taken over from the WAN")

 

Kemal A. Delic

Author: Kemal A. Delic

Kemal is a senior technologist with Hewlett-Packard Co. He is also an Adjunct Professor at PMF University in Grenoble, Advisor to the European Commission FET 2007-2013 Programme and Expert Evaluator for Horizon 2020. He can be found on Twitter @OneDelic.

Tony Tolleson

Author: Tony Tolleson

Tony is an Account Chief Technologist and a former Leader of HPE’s Architecture Profession Office. Tony remains a frequent HPE architecture methodology instructor and an occasional speaker in the HPE Architecture community. He can be found at tony@tonytolleson.com.