Security Must Be a Primary Requirement in Our Smart Cities

Walter Paley, Director of Marketing, SafeLogic
341
561
119

Walter Paley, Director of Marketing, SafeLogic

Everything is relative when you use the word “smart”. At this point in our technological journey, saying that the goal is to create a “Smart City” is tantamount to Henry Ford’s goal of building a “horseless carriage.” The Model T was technically the completed achievement and it was crossed off the list, but we have come a long way since (all the way to Tesla’s Model S, naturally) and we have a long way to go with “Smart Cities” by the same token. With the intent to build smarter, more automated, more AI-driven cities, (yes, I am more comfortable with the incremental descriptions than the blanket term), there remain a myriad of hurdles. Chief among them are the twin issues of security and privacy.

“We must treat every addition to the “Smart City” as though it is the most crucial piece of a federal acquisition and subject it to our highest level of testing and assurance”

I hate to have to rain on the parade of progress, especially during CES season, when we are all inspired by the innovation on display and the visions of full-scale deployments dance in our heads, but the undeniable truth is that those same ‘smart’ gadgets that silently gather our motion, location, temperature, and other data to helpfully leverage it for good can also be harnessed and used with malicious intent. The potential outcome is that ‘smart’ devices would become double agents. It’s the ultimate combination–enticing enough technology that you choose to assimilate it into your routine and invasive enough to your privacy to be useful to criminals. Let’s look at some examples of technology in the realm of the ‘Smart City’ that fit this description.

Amsterdam has addressed concerns of motor vehicle congestion in the bicycle-heavy city with a mobile application that connects drivers who are looking for a parking spot with other citizens who rent out their own personal off-street locations. This  concept is advanced in many cities, although the direct monetization and private ownership of the garages and driveways is a new spin. Most cities pursuing this type of solution are trying to streamline the discovery of metered street parking to minimize frustration and maximize meter revenue. In either scenario, the application requires the registration of your identity and an associated vehicle. The lack of anonymous options creates the first red flag for users. Next, you realize that the application has an inherent need to locate your vehicle (and by proxy, you) and confirm the time and duration of your parking activity. Of course they need that information. How else would they be able to accurately bill your credit card for that time? Now they have your payment information as well. Add that to the list of personal data that has been aggregated. How about pairing that credit card with your billing address? That is pretty typical, and the billing address is often your home address, which they can accurately infer is not currently occupied by you, since you just parked your car in the city! This is when high tech and low tech criminals join forces.

If a hacker has successfully exploited vulnerability in the application, they may reap the data and begin to build target profiles that can be sold remotely or passed to a local partner. The burglar, the low tech half of the pair, now knows your probable home address, your habits in the city, and the make and model of your vehicle. That is a pretty strong candidate to return home to the suburbs and find that Smart TV no longer mounted on the wall.

I hope this does not seem like I am picking on Amsterdam or what appears to be an ingenious way to both enable enterprising citizens to make a little extra money and reduce the demand for street parking. The concept of violated privacy and security extends to many technological advances worldwide.

Toll roads have become quite popular in the United States. They are used to fund new highways, to charge congestion fees, and to pay for tunnel and bridge maintenance and other key infrastructure. The system again relies upon the collection and aggregation of data points such as. vehicle type, owner, address, usage patterns, credit card authorizations. These are all elements once more of a technology process that is built with the priority on user experience. The consumer is in their vehicle, driving 65 miles per hour, with a wireless transponder so they don’t need to slow down, let alone stop. Their account is identified, logged and billed seamlessly. It’s a brilliant way to accelerate traffic flow without sacrificing the monetization. It’s a huge improvement from the old tollbooths still in use twenty years ago.

Unfortunately, in the same way as in Amsterdam’s parking application, each connection–the transponder to the receiver, the receiver to the back end, the back end to the financial database, and then the transaction processed through the merchant banking interface–creates a potential vulnerability. Each one represents a seam between systems that offers hackers an opportunity to intercept data.

So what do we do? It may seem dramatic, but it really is pretty black-and-white.

First option is to simply not use it. In the face of potential malicious activity, consumers can choose to opt out. They would trade the time savings and the ease of use in favor of anonymity, either avoiding the toll roads altogether or choosing only those which still have tollbooths where you can pay cash. In Amsterdam, they may choose to take public transit into the city instead, or feed a traditional meter with coins.

Alternatively, we build these systems, indeed the entire “Smart City” from the ground up with security and privacy at the top of mind at every strategic inflection point. Citizen safety must be of primary importance and no level of convenience is worth deploying systems that have not received enough testing. The U.S. federal government has instituted a variety of benchmarks that are required before agencies acquire technology solutions. For example, FedRAMP certification is a must for Cloud-based products, and FIPS 140-2 validation is mandatory for every single instance of encryption. In the same way, we must choose to prioritize these standards above all else.

We cannot flee from technology. Option one is really not an option. So the only answer is to factor in security requirements from the start. Luckily, we are still early enough that we can do so but we must do it today, immediately. We must treat every addition to the “Smart City” as though it is the most crucial piece of a federal acquisition and subject it to our highest level of testing and assurance. Only then we can encourage citizens to embrace the technology with the comfort level that reflects the importance of each person’s privacy and security.

Read Also

Smart City-Smart Re-Invention

Joe Iannello, VP & CIO, Capital Metro

Looking at a Smart City Deployment Model

Scott McCarley, Sr. Director Solution Management, Smart Cities, PTC

Buidling a Bridge between Employees and Leaders

Johnathan Hughes, Facility CIO, U.S. Department of Veterans Affairs

The Transformation of Business Processes and Tools

Ed Toner, CIO, State of Nebraska