02:30 PM
Jose Nazario
Jose Nazario
Connect Directly
E-Mail vvv

Tunneling Through The "Walls" Of IoT In The Enterprise

The movie "Die Hard" has a thing or two to teach us about the pitfalls of the Internet of Things.

Much has already been written about the threat that Internet of Things (IoT) devices pose to the larger Internet. Think about the October 2016 Mirai botnet attacks and the discussions since then. But this column isn't about that. It's about the specific threat that Internet-connected devices pose to an enterprise network, and how we can intelligently apply network architecture to achieve security aims.

For an intranet, IoT devices create an overlay network comparable to the vast high-rise Los Angeles commercial building in Die Hard, where most of the 1988 movie takes place. In the film, Bruce Willis plays the role of New York City cop John McClane, who visits his estranged wife at her office Christmas party in Nakatomi Plaza in L.A. The party gets attacked by terrorists, and McClane saves the day with some ingenuity, firepower, and brawn.

L.A.'s Fox Plaza, location for Die Hard's fictional Nakatomi Place  
Image Source: Capture Light via Shutterstock

L.A.'s Fox Plaza, location for Die Hard's fictional Nakatomi Place
Image Source: Capture Light via Shutterstock

In a recent blog post entitled "Nakatomi Space," Geoff Manaugh (author of the BLDGBlog architecture blog and the book The Burglar’s Guide to the City, both of which I recommend for any cybersecurity professional) describes the movie as a great study in the unintended effects of architecture. He writes:

Over the course of the film, McClane blows up whole sections of the building; he stops elevators between floors; and he otherwise explores the internal spaces of Nakatomi Plaza in acts of virtuoso navigation that were neither imagined nor physically planned for by the architects.

His is an infrastructure of nearly uninhibited movement within the material structure of the building.

The parallels to cybersecurity are striking: network and security architects typically design networks to meet the obvious business needs of connectivity and speed. But this approach creates unintended consequences. Look around your office now and you’ll probably see network-connected printers (quite common for about two decades), VoIP phones (standard for a decade now), and probably IP-enabled cameras and building controls such as HVAC, and door and building access mechanisms such as proximity card readers (increasingly common in the past decade). In both network security and Nakatomi Space, the infrastructure was created to enable occupants to use and traverse the space, or systems, as the case may be.

Without this out-of-sight support infrastructure, the usability of the main space dramatically drops. An additional challenge is that both types of infrastructures are typically invisible from a defense standpoint. We all tend to overlook the real and digital equivalent to air ducts and windows. The attack surface  this creates for enterprises was demonstrated by Ang Cui in his Stepping Pwns talk. He and his team at Red Balloon were able to compromise a network without touching a standard computer. This avoids the bulk of the defenses installed: antivirus, logging, file, and process integrity checks, for example, undermining the majority of an enterprise's security efforts.

Applying the lessons of physical space security to network defense has been on my mind for many years. Since I first visited Halifax, Nova Scotia, about a decade ago, I've been eager to try and apply fortification lessons to network security. The fort at Citadel Hill, for example, "connects" via a network of flags and signals to a network of towers in the harbor waterway leading to the city. This enables defenders to signal the approach of enemy ships, giving the city hours to raise their defenses. However, in the years since I began reading Manaugh, I’ve instead begun to focus my thinking on how intelligent building designers utilize architecture and landscape features to actively defend their inhabitants.

I’m reminded of the writings of Major Gen. Sir Ernest Dunlop Swinton’s Defence of Duffer's Drift, a 1904 novel about lessons learned in the defense of a river during the Boer War. In the story, the protagonist reveals the strengths and weaknesses of various fortification positions. A combination of natural and manufactured structures alerted defenders to attackers as they approached, and forced them to attack from a weaker position. These types of insights have gone largely ignored in network security lessons. When designing networks, the castle wall narrative has been prevalent for too long - at the expense of designs that parallel security features of well-defended cities.

Network security architecture can, and should, learn a lot from building and city architecture. The lessons can be abstracted to achieve the same goals, namely spotting intruders as they approach, and confusing them should they gain entry, or at least slowing their progress. Historically, we architected networks with a distinct management network and a separate data network. The management network requires combinations of physical and logical controls to limit access to a small set of administrators. With an increasing number of IoT devices, some administrators have advocated building a similar separate network for control devices to keep them away from the data that comprises corporate assets. This would, at the least, prevent the "Stepping Pwns" attack whereby attackers bounce around between computers and data once inside the network.

If the above discussion suggests anything, it's that corporations shouldn't be passive in their IoT network security. Instead, admins should ensure that they not only have visibility into what's going on in the Internet-connected device network, but also guarantee that visibility through the entire structure of the network. Anyone who moves through the infrastructure must leave an indelible trail and be thwarted at every turn, lest they treat it as an unobstructed air duct through Nakatomi Plaza. I urge companies to turn those (virtual) air ducts into a confusing set of passages, perhaps even traps, and prevent thermostats from becoming stepping stones.

Related Content:

Dr. Jose Nazario is the Director of Security Research at Fastly, and is a recognized expert on cyberthreats to ISPs, network subscribers, and enterprises from cybercrime and malware. He was previously the Research Director for Malware Analysis at Invincea Labs. Before his ... View Full Bio
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
2/23/2017 | 9:00:24 AM
This is">tactical info
Love The Internet Of Things & Really Great Article Thanks :) 
New Free Tool Scans for Chrome Extension Safety
Dark Reading Staff 2/21/2019
Making the Case for a Cybersecurity Moon Shot
Adam Shostack, Consultant, Entrepreneur, Technologist, Game Designer,  2/19/2019
Register for Dark Reading Newsletters
White Papers
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
How Enterprises Are Attacking the Cybersecurity Problem
How Enterprises Are Attacking the Cybersecurity Problem
Data breach fears and the need to comply with regulations such as GDPR are two major drivers increased spending on security products and technologies. But other factors are contributing to the trend as well. Find out more about how enterprises are attacking the cybersecurity problem by reading our report today.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2019-02-22
Citrix NetScaler Gateway 12.1 before build 50.31, 12.0 before build 60.9, 11.1 before build 60.14, 11.0 before build 72.17, and 10.5 before build 69.5 and Application Delivery Controller (ADC) 12.1 before build 50.31, 12.0 before build 60.9, 11.1 before build 60.14, 11.0 before build 72.17, and 10.5...
PUBLISHED: 2019-02-22
An issue was discovered in PHP before 5.6.40, 7.x before 7.1.26, 7.2.x before 7.2.14, and 7.3.x before 7.3.1. Invalid input to the function xmlrpc_decode() can lead to an invalid memory access (heap out of bounds read or read after free). This is related to xml_elem_parse_buf in ext/xmlrpc/libxmlrpc...
PUBLISHED: 2019-02-22
An issue was discovered in PHP before 5.6.40, 7.x before 7.1.26, 7.2.x before 7.2.14, and 7.3.x before 7.3.1. A heap-based buffer over-read in PHAR reading functions in the PHAR extension may allow an attacker to read allocated or unallocated memory past the actual data when trying to parse the file...
PUBLISHED: 2019-02-22
An issue was discovered in PHP 7.x before 7.1.26, 7.2.x before 7.2.14, and 7.3.x before 7.3.2. dns_get_record misparses a DNS response, which can allow a hostile DNS server to cause PHP to misuse memcpy, leading to read operations going past the buffer allocated for DNS data. This affects php_parser...
PUBLISHED: 2019-02-22
An issue was discovered in PHP before 5.6.40, 7.x before 7.1.26, 7.2.x before 7.2.14, and 7.3.x before 7.3.1. A number of heap-based buffer over-read instances are present in mbstring regular expression functions when supplied with invalid multibyte data. These occur in ext/mbstring/oniguruma/regcom...