The UK Government report on Smart Cities in October 2013 observed that
“Urbanisation and economic development are two sides of the same coin.”
According to the McKinsey Global Institute’s study of global cities:
80% of global GDP is generated in cities with 50% in the 380 major cities of the developed world and 10% in the largest 220 cities of the developing world. In 2025, the same report expects these top 600 cities will still be generating 60% of the growth in GDP but their membership will have shifted East with an estimated 100 new cities entering the rankings from China alone.
Assuming these observations are true, then urbanisation and the evolution of mega-cities and SMART cities is inevitable and inexorable. What is more, this is an evolution that increasingly will be stimulated and enabled by ever-increasing digitisation, much as electricity did in the last century. However, as night follows day, digital enablement leads to incremental cyber security vulnerabilities.
Digitised enablement of city growth is a complex beast with many moving parts and can also be seen as a paradox, bringing into conflict the goals of top-down assumed need for citywide planning and control, versus the bottom-up access to data that lets citizens make their own decisions.
Greater Dependence on Technology Leads to Greater Vulnerability
However, with technology driving much of the thinking, perhaps with insufficient reflection upon human needs, we face a simple reality: Cyber vulnerabilities are already outstripping user community awareness of how those vulnerabilities manifest themselves nor just how pervasive they are.
The use of smart mobile devices in a city on a free public hotspot is massively convenient but fraught with danger. They are terrific device hacking grounds for cyber botmasters (someone who co-ordinates criminal cyber-attacks using sophisticated malware like the CITADEL trojan), where they can scrape hundreds of user credentials in a short space of time and deploy sophisticated smishing attacks (SMS phishing) that even have the ability of intercepting one-time security codes to hijack legitimate internet banking transaction sessions.
Imagine an environment where contactless payments, Uber taxi pick-up, social media community location, public hotspots, bring your own device (BYOD), smart cars, and the developing roadside smart infrastructure are all doing their best to connect us—when none of those have really bothered to consider the vulnerabilities at the boundaries of each area of functionality working together simultaneously. I haven’t even considered, here, the implications for Social Security, health care, waste management and so on.
Let’s look at just two areas of fundamental concern, in our digitally enabled cities: Smart Meters and Smart Motor cars.
Smart Meters – Shark Meters
Smart meters for the first time deliberately connect the enterprise technologies (business systems, billing systems customer data records and so on) with operational technology (things that control pumps, sensors, distribution grids at one level, a supervisory control and data acquisition (SCADA) systems at the aggregation of these)—the things that make stuff work. Think water: Somewhere there is an impellor in a pipe counting the amount of water flowing through that pipe. This is going to a SCADA system somewhere and then to a billing system. It is going to a control room to be aggregated, and it is going into a big data analytics engine in the cloud to establish usage trends.
Problem is the boundary between information technology (IT) and operational technology (OT) is probably the most worrisome boundary for cyber vulnerabilities. Historically we have kept the two worlds apart; now we are deliberately joining them. But really, we haven’t worked hard enough on the broader connectivity security to really reflect multiple vulnerabilities—not just whether your smart meter is secure, which, at the moment, most likely it isn’t anyway.
Smart Cars – Dumb and Dumber
The first introduction vehicle electronics was in the late 1970s when engine electronic control units sought to respond to engine efficiency and reduction in pollution embedded in the California Clean Air Act. Since then, on-board electronics for cars we know have become ubiquitous. The on-board software for our vehicles control anti-lock brakes, roll stability programmes active cruise control systems and other safety or power-train related software.
These safety software systems run on one of two data buses running controller area network (CAN) network protocol:
- safety systems run on the high-speed bus
- other less critical systems (like central locking) run on the slow-speed bus
However, over time, these systems have started to talk to each other, so in the event of a roll, the door locks automatically release because there is a bridge between the two buses. This means that if a hacker gains access to one bus, he can interact with any on-board system.
Sounds scary, but until now this has been of modest concern because, by and large, in order to interact with the vehicle I had to be able to touch it, which usually means you’re not moving.
However, car makers’ continuous pursuit of improved user experience have seen them driving hard toward greater remote connectivity. Consequently, many cars today have some level of on-board connectivity:
- OnStar, GMs connectivity, is one of those at the forefront for connectivity and is now offering connectivity to Twitter.
- BMW’s ConnectedDrive allows Internet browsing and remote fault monitoring
- Chrysler’s UConnect
- Lexus’ Enform
- Ford’s Sync
Indeed all the premium manufacturers offer equivalents. Now I can access your on-board systems remotely – yeehaa! Just in time too: right now, smart city considerations have led to the widespread development and impending deployment of vehicle ad hoc networks (VANETS). These utilise an on-board unit (OBU) talking to roadside units (RSU) to facilitate vehicle-to-vehicle communication and vehicle-to-infrastructure communication.
Development of VANETS is institutional establishment of an infrastructure and communications protocol to allow me to apply your brakes when it suits me, to shut down your engine when I fancy it; fiddle with several vehicles’ active cruise controls– you get the picture.
The relevance of these two examples and that, earlier, of the public hotspots, is not to make a case to re-introduce a Luddite mentality. Instead it is to reflect on a key observation: Consideration of incremental services must be conducted mindful of the cyber vulnerabilities associated with that evolution and allow suppliers and users the opportunity of understanding, assessing and mitigating risks associated with the evolution.
Sadly our collective track record in this regard has been poor, and risk mitigation and sophisticated risk transfer constructs will increase in relevance as this phenomenon gains traction.
It’s a brave new world where everything changes, and yet, nothing changes.