Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IoT
2/22/2017
02:30 PM
Jose Nazario
Jose Nazario
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

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.

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
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
Survivalindeed
50%
50%
Survivalindeed,
User Rank: Apprentice
2/23/2017 | 9:00:24 AM
This is http://www.survivalindeed.com/">tactical info
Love The Internet Of Things & Really Great Article Thanks :) 
Manchester United Suffers Cyberattack
Dark Reading Staff 11/23/2020
As 'Anywhere Work' Evolves, Security Will Be Key Challenge
Robert Lemos, Contributing Writer,  11/23/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: He hits the gong anytime he sees someone click on an email link.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-12262
PUBLISHED: 2020-11-27
Intelbras TIP200 60.61.75.15, TIP200LITE 60.61.75.15, and TIP300 65.61.75.15 devices allow /cgi-bin/cgiServer.exx?page= XSS.
CVE-2020-29129
PUBLISHED: 2020-11-26
ncsi.c in libslirp through 4.3.1 has a buffer over-read because it tries to read a certain amount of header data even if that exceeds the total packet length.
CVE-2020-29130
PUBLISHED: 2020-11-26
slirp.c in libslirp through 4.3.1 has a buffer over-read because it tries to read a certain amount of header data even if that exceeds the total packet length.
CVE-2020-26936
PUBLISHED: 2020-11-26
Cloudera Data Engineering (CDE) before 1.1 was vulnerable to a CSRF attack.
CVE-2020-29042
PUBLISHED: 2020-11-26
An issue was discovered in BigBlueButton through 2.2.29. A brute-force attack may occur because an unlimited number of codes can be entered for a meeting that is protected by an access code.