SXSW Day 5 session 3: Connected cities, hackable streets

Panel with Nadya Bliss (Arizona State University) moderating Tom Cross (Drawbridge Networks) and Robert Hansen (OutsideIntel)

Smart cities represent the confluence of machine learning, big data and IOT in a city context.  Most cities start with power related applications.
Security represents a special challenge in cities, which have both old, legacy, vulnerable systems as well as modern sensors and tools that we have not figured out how to protect very well quite just yet.  Basically, a lot of the attention directed towards smart cities today is based on the marketing of the device manufacturers who are trying to increase sales of their devices in the guise of cost reduction.  The cities themselves are still not 100% clear on the usecases.

One example of a hacking of a very simple smart city feature:
Many cities have smart traffic lights - traffic lights that have sensors buried under the road that senses when a car is on top of it, and signals the traffic light (usually wirelessly) to change the lights.  Since the device is communicating wirelessly, and almost never securely, it's relatively simple to identify and decipher the signals it is sending to the traffic light, and then using a transmitter more powerful than the sensor, disrupt the operation of the traffic light, even from a distance.

There are three actor classes who may be involved in hacking cities:
1. Board teenagers - kids who would hack a traffic light for the LOLs.  They represent a low threat overall in the category of connected cities.
2. Criminals and criminal organizations - they are usually looking for how to monetize a vulnerability.  They would be involved in very specific usecases.
3. Nation states - possibly most interested in vulnerabilities of connected cities, especially when they can accumulate effects to generate a large impact on the whole city or state.  They can shut down devices for general disruption, or introduce subtle changes to how the system operates, to achieve a specific goal.
For example, in the case of traffic light, a nation state can attempt to disrupt an election by causing traffic slowdowns or jams in areas where there are a lot of voters to a particular candidate.  This type of attack would be extremely difficult to even identify as a hack, let alone trace it back to the originator.  Also, cities are resource poor - they get all of their resources from outside the city.  An attack on delivery trucks or the transportation routs they take could deprive a city of food in a matter of a few days.
Not all "hacking" is done by people trying to cause disruption; there have been reports of police feeding false information into Waze to fool people on where they actually are located.

Because they are such diverse domains, smart cities have numerous points of failure.  And because product developers want to get their product to market fast, they don't always want to perform intensive security testing and fixing, which takes time and costs money.  Also, given the way some of these devices are used, not many of them are built with the ability or even accessibility to patch them.
As such, what are the ethical considerations around disclosing discovered vulnerabilities?
In the software industry there are developed norms for how to disclose vulnerabilities; in newer industries, such as connected cars, however, there is less openness, as not all manufacturers adopting the software mindset quite yet.

What should be done?

• All messaging needs to be encrypted
• Companies in all areas of smart city services and devices need to be made to follow rules around security - SLA on logging, encryption, upgrades, etc.
• Need to have one throat to choke - each city needs to have a Chief Security Officer or innovation officer who can coordinate security concerns for the city.  Cities should also create panels for advising them on how to add smart city features securely
• Determine for each device whether it really needs to be connected to the public internet - is there a good reason for public connectivity?
• Consider data as a liability, not an asset, and treat it accordingly

What challenges are we facing in this domain?

• The people making the technology are not incentivized to spend money and time on security
• People buying the technology are not aware of the risks and dangers
• There is a lack of talent to fill the need

What are the main questions you should consider when building for security?

• What happens if you get a reply you didn't expect?
• What happens if you get no reply at all, when you expected one?

I asked a question about Estonia, and whether there are any specific applicable lessons that could be learned from that country's experience both in advanced digitalization of public services, as well as withstanding attacks from a nation state attacker (Russia); the panel did not have any information around this, but someone in the audience was able to give me some interesting details:

1. Estonia uses Guardtime (an industrial blockchain platform) to log minute by minute records of anything that happens in their database, so they can be sure no one can tamper with their data undetected
2. Estonia is planning to build "data embassies", which are secure data centers outside of the country, that act as a backup in case of attack and are treated like real embassies.