In his book, The Hitchhiker’s Guide to the Galaxy, Douglas Adams suggests that the secret to invisibility is to be somebody else’s problem. While a work of comedic science fiction, it’s a very profound and relevant observation. Consider the myriad of dependencies required to allow you to receive and read this blog. The power to run your computer. The fibre/cables that carry your request. The DNS servers that provide a machine-friendly destination IP address. The routing protocols that shuttle the bits between the web server and your computer. It’s a complex ecosystem of interdependent systems often simply referred to as a ‘network of networks’.
Consider Rose George’s most excellent and informative book on the shipping industry entitled: ‘Ninety Percent of Everything: Inside Shipping, the Invisible Industry That Puts Clothes on Your Back, Gas in Your Car, and Food on Your Plate’. Very different to Douglas Adams’ iconic masterpiece, Rose George’s book is non-fiction, and filled with compelling facts. She shines a light on a complex global eco-system (a supply chain) that nearly every human on the planet depends on, but few even know exists.
It is these ‘invisible’ dependencies that we have developed (and continue to develop), that safety, security and privacy professionals must consider if we are to survive the future which is already being thrust upon us.
By now, almost everyone is starting to understand the dangers associated with domain overlap, exemplified by cyber-physical systems like connected cars, implanted medical devices and household IoT. These systems of systems live in two very different worlds; the world of cyber is bits and bytes, while the physical world is made up of atoms and molecules. Most professionals in these domains are approaching the problem from a purely technical perspective. Some see it as a social issue, and others believe legislation will sort it out. While all components of a reasonable response, each on its own is destined to fail because of the invisible forces driving system interaction, and the resulting dependencies introduced that have no custodians. It’s somebody else’s problem.
Case in point, someone decides to launch a DDoS attack on Brian Krebs’ website — Twitter, PayPal, Spotify, Netflix and others are impacted. These entities are what we call ‘collateral damage’. While not the intended target, these entities, and others, were impacted in negative ways because of a dependency they all shared related to Dyn DNS services. Is a scenario like this in your threat catalogue? Do you have a dependency on shared services? Have you experienced such an incident? Do you model system failure related to your organisation’s dependencies? It’s somebody else’s problem until it’s yours.
In late September, I presented a talk about my research entitled ‘Subs, Ships and Satellites: The Internet of Invisible Things’. The intention of the work is to build practical modelling tools that allow human analysts to identify ‘invisible’ dependencies across stakeholders’ communities, domains and complex ecosystems/supply chains. We decided that maritime port operations were the perfect candidate, given the socio-economic impact of propagating disruptions to these eco-systems, the number of external dependencies, and the evolving cyber-physical nature associated with port-automation initiatives. There is a companion white paper that describes our approach, which will be released later this month, but you don’t have to wait for that to start having these discussions in your own organisation.
In its simplest form, we are really talking about threat modelling. This is a common practice that most security professionals employ, regardless of their maturity level. As systems grow more complex, and eco-systems expand, we must get better at threat modelling. We need to not only model common industry threat catalogues, but also consider theoretical threats, specifically ones related to interdependencies across stakeholder communities.
Consider this a call to action. We must institutionalise and operationalise these practices now, in preparation for automating these capabilities. It’ll be the only way to survive the coming swarms of IoT and invisible dependencies we are building — because humans matter and what you don’t see can hurt you.