Establishing security guidelines for smart city projects
As technologists and citizens, we like the notion of smart cities. Open data, open source, and an attitude of service—mixed with a healthy serving of modern technology such as the Internet of Things (IoT)—can improve our quality of life, whether that's making it easier to pay for parking spots via a mobile application or implementing an integrated traffic signal network to shorten idle times at intersections.
More and more facets of our cities are going digital: transportation, water management, building design, and public safety, for example. Essentially, a smart city is one that's connected. Our cities are being reinvented to incorporate inexpensive computing, sensors, data storage, reasonably fast wireless connectivity, cloud computing, big data, artificial intelligence, robotics, and citizens armed with cell phones and a zest for mobile apps. In most cases, that's a good thing: Consider what's available to citizens in Boston and New York, for instance, and the power and transparency it provides to them.
But, as with any complex project, security and privacy has to be baked in. And thus, successful urban planning for smart city approaches requires some new business policies.
That's especially so when a government agency works with vendors and contractors to get the work done—and usually, they do. A 2016 report from CompTIA, Building Smarter Cities, predicts that we'll even see smart cities as a service, pulling in managed service providers and other technology solution providers for end-to-end service. Think of it as smarts in a box.
Having a third party involved raises another level of security awareness to any IT project, even the most mundane. It opens up the network to whatever malware infections the contractor cat drags in, whether it's cash registers or smart streetlights. Adding the IoT, sensors, GPS, and lots of new stuff? That type of infrastructure is especially vulnerable to hacking, due to ill-thought-out IoT security.
Make third parties accountable
Chris Walcutt is the director of security solutions at cybersecurity firm DirectDefense. He has 20 years of experience in network design, security risk analysis and mitigation, and regulatory compliance in the energy and manufacturing sectors, specifically with regard to the secure design and deployment of smart city initiatives. Walcutt was also part of the National Institute of Standards and Technology (NIST) standards body that drafted and released the latest revisions to the North American Electric Reliability Corporation critical infrastructure protection (NERC CIP-13), a set of requirements designed to secure the assets required for operating North America's bulk electric system. In short, Walcutt is the guy to go to when you wake up sweating from electric grid security nightmares.
Walcutt says that, yes, smart cities have to be open to some extent; vendors and contractors need access to work on these systems. But that doesn't mean cities can't be strict with the practice, he says: "It's not simple to do, but it's got to take place, smart city grid or any corporate network."
A big part of protection is ensuring the right contractual language. "If you trust the security posture of a third party, that's one thing," Walcutt says. "But if you put it in writing, it's a reminder you're looking over their shoulder."
Governments need to learn security lessons from industry failures. For example, Equifax had a patch that would have prevented the recent breach months before it happened, if only somebody had bothered to install it. Who was looking over Equifax's shoulder? Anybody? At least the power grid has NERC, which has been deputized by the Department of Energy to require energy companies to do certain things—like, say, evaluate a patch to see if it needs to be put in place within 35 days of it being released.
Unfortunately, a good chunk of the code out there can't be held to terms of a contract because it's open source. Where does the buck stop in the case of a breach? Doesn't matter: Nobody's sitting there. That's because there's been a big push to do IoT cheap and get Internet-enabled devices to market quickly, Walcutt notes. "[Developers] rely on specific functions in open source code to do that," he says. "Say, OpenSSL and OpenSSH. You can grab and use that code to support encryption, or a device has a site to go to configure it, like a router. When you do, you're relying on [open-source] code for some functionality. What happens with a bug like Heartbleed? Heartbleed attacked the OpenSSL code. It opened all devices relying on that code. They didn't write it, but they reused it. All of a sudden, they were susceptible to Heartbleed and weren't necessarily able to support it."
For example, San Diego has a technology partnership to manage the smart streetlight piece of its smart city initiative. Walcutt says the city wants to monitor and install up to 3,000 smart sensors. Those all need to be centrally managed, patched, and updated. If a vendor is responsible for doing that, the smart city's technologists might not be able to touch the code to access and update it—which again goes back to contracts.
Creating a foundation of security
A whole world of complexity is hidden behind the NERC curtain. Ask Joe Weiss about it. Among his many titles, Weiss is an ISA Fellow, an IEEE senior member, and managing director of ISA99 Applied Control Solutions. He also wrote a book, Protecting Industrial Control Systems from Electronic Threats, that explains how wobbly the bedrock on which we're building smart cities is.
An example: Remember Aurora? "Idaho National Lab did," Weiss says. Aurora was a generator test run at the lab in 2007 to demonstrate how a cyberattack could destroy physical components of the electric grid. The test attack shredded a generator within three minutes, but it would have happened much faster if the researchers hadn't stopped to assess the damage from each iteration of the attack. The simulation of a cyberattack opened and closed the breakers out of sync to maximize the stress. Each time the breakers were closed, the torque from the synchronization caused the generator to bounce, shake, and smoke. Pieces of the thing were flung 80 feet. Experts say that a real attack could cause a city to be plunged into darkness—for months.
Mitigations have been worked on, but Weiss shrugs them off. "Turns out, utilities have been fighting tooth and nail not to address that," he says, due to liability concerns. "That was 10 years ago. And this is how you bring the grid down for nine to 18 months."
Adds Weiss, "The problem is that none of the vendors have any security requirements, to this day, for the stuff that would go 'Boom' in the night—not for sensors, not for actuators, not for drives." On the proactive side, Weiss is on a brand-new committee to address security shortcomings that affect smart city planning. "We've had smart substations, smart plants, for 20 years now. Has it been at the level that you're seeing now?" Weiss says. "No. But this is not new. What's new are all these multiple devices, trying to make light bulbs that are smart, etc. But when you're talking cities, outside of an individual house or a streetlamp, it's vulnerable as hell." We've been focusing on smart houses, he says—smart refrigerators, smart thermostats, things like that. We haven't been focusing on smart substations, though, so let's bear in mind that, at least in Weiss's view, we're building smart cities on quicksand.
A slew of takeaways
A number of guidelines aim to help do smart city security right. (Or, at least, as right as it can get, given the state of the sensors smart cities run on.) The Federal Trade Commission, for one, has published a white paper on how to build security into the IoT, which obviously applies to smart cities. Here's what it recommends:
- Start with the fundamentals.
- Take advantage of what experts have already learned about security.
- Design your product with authentication in mind.
- Protect the interfaces between your product and other devices or services.
- Consider how to limit permissions.
- Take advantage of readily available security tools.
- Test the security measures before launching your product.
- Select the secure choice as your default setting.
- Use your initial communications with customers to educate them about the safest use of your product.
- Establish an effective approach for updating your security procedures.
- Keep your ear to the ground.
- Innovate how you communicate.
- Let prospective customers know what you're doing to secure consumer information.
Another resource is the NIST Framework for Improving Critical Infrastructure Cybersecurity. It provides guidance for managing security risks associated with infrastructure such as the power grid, the water supply, dams, bridges, food supplies, communications, defense, and the chemical sector.
And here's more advice from DirectDefense's Walcutt:
- Make data security a priority from the outset.
- Physically secure facilities controlling utilities such as power, gas, and water.
- Implement fail-safes and manual overrides in all systems and networks, including forcibly shutting down potentially hacked systems until security experts resolve vulnerability issues.
- Protect against hackers trying to breach control systems remotely. Encrypt sensitive data, and deploy network intrusion mechanisms that regularly scan for suspicious activity.
- If your institution partners with third parties, it's important to trust but verify. Control where and when vendors come in, monitor contractors while they're there, and turn it all off when they're gone.
These are some of the steps organizations can take to secure the structure underlying their smart city initiatives. There are guidelines for individuals to secure the IoT, as well, though how much influence cities have on citizens and their smart refrigerators, et al., is debatable.
In the end, the best we can hope for to ensure smart cities succeed is that industry and government work together to stay ahead of would-be attackers. The threats aren't theoretical. They're active, including state-sponsored actors with unlimited budgets. For example, US-CERT issued a technical alert in October warning of advanced persistent threat activity targeting energy and other critical infrastructure sectors across the country.
Thankfully, the government is working on it. The Securing Energy Infrastructure Act, introduced earlier this year by Sens. Jim Risch (R-Idaho) and Angus King (I-Maine), notes the need to "safeguard against cyber-attacks by replacing key devices like computer-connected operating systems, which can be vulnerable to cyber-attacks, with less-vulnerable analog and human-operated systems." The bill calls for a pilot program focused on identifying security vulnerabilities in the energy sector, as well as a working group made up of both government and industry stakeholders.
We need both cohorts in order to support needed cybersecurity research and remediation to make the IoT-run infrastructure of our cities and country truly "smart."
This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.