What are we Protecting?

The data collected in smart city applications varies across almost every possible spectrum and includes among the most sensitive personal data, as well as largely mundane and uninteresting data. Pressure readings in water mains, wind speed data from environmental monitors, and light level readings from smart lighting applications are the kinds of large-scale environmental data collections in some smart city applications that seem relatively innocuous and unconcerning and probably largely are. This data is valuable for adjusting city services for efficiency, and it poses little threat from breach or exposure. However, many smart city applications will collect information that is tied to individual users, their devices, their locations, and other sensitive information.

Smart parking applications or automated license plate readers will not just collect user license plate numbers, but they will tie that license plate to geocoded data about where it was collected. This is prototypical surveillance data, and often users will not have any option to opt in or opt out. Even seemingly less invasive applications, like city-provided free Wi-Fi hotspots or Bluetooth connections, could collect unexpected user data, like data from an embedded medical device that automatically connects to open Wi-Fi to upload telemetry. Are cities prepared to safely store logs filled with device information on citizens pacemakers, and would the pacemaker owners feel comfortable with this? Would the citizens even know?

Part of the challenge here is that we are consistently adding more and more devices to the environment, and so the data privacy concerns are broader than just data collection, and they increasingly include data collation across disparate and unconnected datasets. Datasets that will be, in the case of the smart city, owned and protected by either the municipality or their vendors. Cities are, in many cases, not currently prepared for the task of warehousing the vast amounts of data that smart city applications will produce—in terms of both the logistics of holding such data and the defensive agility to protect such data. Historically, cities have collected and stored a lot of sensitive data, but they did so largely at a human scale. The automation of collection platforms, the increasing sensitivity of data (because of technologies like geocoding and facial recognition), and the use of data to actually change physical city operations through actuators on infrastructure systems (vastly increasing the importance of data protection, and particularly data availability and integrity) means the new data protection challenge for cities is different in both scale and type.

Smart city systems collect data to improve the effectiveness and efficiency of city services. These technologies can add to the span of delivery, save energy, fill gaps, add customization to offerings already provided, or enable new applications developed based on the data gathered. Once these digitally enabled services become the default, however, citizens and city officials alike will depend on them.

Once that happens, cities will face the same challenge as all critical infrastructure providers: high uptime requirements. High uptime requirements make updating systems more difficult because infrastructure often needs to be taken offline to be updated. With this concern in mind, city networks must be designed for resiliency and segmented appropriately to prevent attacks from spreading from system to system and to enable administrators to update systems regularly.

Additionally, systems must be designed to “fail usable.” While failing safely or failing securely are common themes in engineering discussions of fault tolerance, even in terms of urban infrastructure and smart cities, failing to a usable state is less commonly explored or discussed.¹ The comedian Mitch Hedberg once joked, “I like an escalator man, because an escalator can never break, it can only become stairs.”² Smart city applications–like Hedberg’s escalator–will have to remain usable in some form if their digital componentry or network connections fail.

…The city must have a manual backup or usable setting that is automatically engaged upon system failure.

If essential city services are digitized—parking meters that are tied to phone applications, for example—and the application driving the service fails, the city must have a manual backup or usable setting that is automatically engaged upon system failure. City street lights controlled by motion sensors, for example, should default to “on” if the control system fails. An illustrative example of not “failing usable” was the ransomware infection on the payment kiosks of the San Francisco Municipal Transit Authority (SFMTA) light rail system. Because there was no manual back up, the system was faced with serious challenges, and the city ultimately decided to let customers ride for free for several days while they reimaged all the systems in the payment kiosks.³

There is a fundamental question that has yet to be answered: to what degree are cities responsible for the safety of their citizens? Some cities (and countries)⁴ consider the digital security of their citizens to be just important as the physical security of their citizens, but this is a new and still frontier idea. There is still more work to be done on how much protection a city should and can provide, and to whom it provides protection. For example, is protection provided only to citizens of the city, or does it extend to those who work in it and those who travel to it?

Smart cities technology can improve the quality of services provided to citizens, but it will also introduce a considerable amount of additional digital risk to citizens, their data, and the services that are provided to them.