Jan 20, 2019Recently, I participated in several tenders for smart-city projects around the world. I also partook in CEO roundtable discussions at Telecom Exchange LA, including one about what Los Angeles would look like in 10 years for the 2028 Summer Olympics. From those projects, I realized there are several issues that may impact making a smart city secure.
Although the tenders originated from different countries, they had a lot in common. All were published by a single government agency, all were requirements specific to that agency and all asked for the standard set of security products: next-generation firewalls, intrusion-prevention systems, Web application firewalls, anti-DDoS, APT protection and so on.
The TexLA CEO roundtable, titled "Get Ready for the Olympics LA: IoT, Smart Cities, & Infrastructure Predictions," was interesting. It asked what cyber-threats and protections would be like in 10 years when L.A. hosts the Olympics, what infrastructure would be like and what could be done to prepare.
What struck me about all of the above was that cybersecurity technology was not the issue; the smart-city requirements and the discussed roadmaps covered those rather well. What I saw not being addressed were the deployment of multiple Internet of Things (IoT) devices, conflicting or singular requirements for solutions, and organizational self-interest.
Deployment of Multiple IoT Devices
Most cities deploy a lot of IoT devices. Traffic cameras are the most noticeable, but there are also sidewalk and building cameras. Industrial control systems (ICS) abound for water, power, traffic, transportation and more. Parking meters now accept credit cards; so far, there are IoT devices with PCI-DSS implications.
It is common knowledge that IoT devices are built for functionality and not security. Even IoT devices that have protection do not have good security. Earlier this year, one of my research teams found a number of vulnerabilities in Schneider Pelco Sarix Professional Cameras, a popular IP camera used for surveillance. All but one of the vulnerabilities were considered "high" or "critical," as they could disclose information, allow privilege escalation or command execution.
Some interesting papers propose using RFID to create intelligent traffic-control systems in smart cities. None discuss the security implications of their proposed solutions.
There were many ICS-related vulnerabilities disclosed this year. Siemens disclosed that some models of SICLOCK central plant clocks had several vulnerabilities, some deemed "critical." SICLOCK clocks are used at industrial plants to synchronize time across devices within the plant. Then there are IoT devices in smart buildings for heating, ventilation and air conditioning (HVAC) and environmental controls, as well as physical security and perimeter access, elevators and more, which most people don't think about but which could be used to jump air-gapped systems. There are several "ICS villages" around the world to promote awareness and education about ICS security. You should visit their sites to view information on or demonstrations of ICS cyberattacks.
None of the tenders in which I participated had any significant requirements related to IoT security. The government agencies offering the tenders had to be using the IoT, as all were related to specific infrastructure areas.
There was some discussion at the CEO roundtable regarding IoT security, but this was considered to be adequately addressed by the LA Cyber Lab, the first city-based cybersecurity lab in the United States. The LA Cyber Lab is an exciting concept, but it is little more than a year old and has yet to respond to a major regional cyber-event.
Conflicting or Singular Requirements for Solutions
Having worked with government agencies, I have often seen an agency that wanted to buy a solution and created requirements or performance specifications with little thought to the other agencies with which they interfaced. This was highlighted as a critical issue affecting response to the mass shooting at LAX airport in March 2014, due to the number of incompatible radios between all first-responders and airport security. The County of Los Angeles has since begun developing the Los Angeles Regional Interoperable Communications System (LA-RICS) to facilitate communication between all public-safety agencies across 88 cities within the county.
Although Los Angeles City and County should be lauded for LA-RICS, there are still dozens of cities and agencies running incompatible systems within a similar vertical infrastructure. Will the city and county be able to replace these legacy systems prior to the Olympics? Only time will tell.
More troubling is that the interoperability standards specified in the new smart-city tenders were minimal. There were the primary syslog and SIEM requirements, but no STIX/TAXI, XML/JSON or similar to pass or consume threat intelligence data. I can understand an agency's systems sending alerts and data to an SOC, but not the need to receive any data back. It could be argued that related agencies will use the same systems, but the tender process may prevent that. That is why it is essential to document and require all necessary interoperability standards.
Organizational Self-Interest
All government agencies have their own requirements to operate. But no agency wants to be secondary or beholden to another agency or organization. If we agree that happens within a city or national government, imagine what it is like between cities or large governments.
Los Angeles completed a 30-year project in 2013 to synch 4,400 traffic lights throughout the city. The project was originally started as part of the traffic plan for the 1984 Olympic Games, but expansion was never completed. One reason it stalled was the inability to get surrounding cities to agree to modify the timing of their traffic lights to accommodate the Los Angeles plan. The project, restarted in 2005, still only covers the signal lights within the City of Los Angeles boundaries and cities surrounded partially by those boundaries.
I live in the Coachella Valley of Southern California, where a single city, earlier this year, opted out of a plan to improve traffic flow down a major traffic corridor through seven cities. The city manager claimed the city was "not comfortable surrendering all control of the city's traffic signals over to CVAG as the association is assuming 'lead agency status.'"
I know there is a great deal of focus on traffic lights, but keep in mind that traffic infrastructure uses a lot of IoT devices to monitor and manage those lights. The point is, unless there is a higher authority to drive standards and cooperation, smart cities are at risk of having vulnerabilities lost in the political shuffle until it is too late.
At TexLA, I spoke with two former CTOs for the City of Los Angeles about this topic. Both agreed that it was an uphill battle at times to promote standards over a given agency's desire for some specific solution. Why? Because there was one justification an agency could provide that trumped all else: "If we don't get this {fill in the blank}, people will die!" Mayors and city councils are hard-pressed to argue against that.
Can a Smart City Be Secure?
How does one upgrade 4,400 traffic cameras in a timely fashion? That process could take months, if not years, to complete. Then what happens when subsequent vulnerabilities are found, and new patches are released in the middle of that cycle?
Are there sufficient access controls in place to prevent someone who gains access to the water infrastructure from accessing the power grid? Since traffic cameras have dedicated access into the power grid, could they be a potential risk? Now extend that question to dozens of other IoT systems throughout the city. The US-CERT has published an advisory about the Russian government targeting critical infrastructure using similar tactics.
If it is known that incompatible systems are in place, does that lower the risk of compromise across systems? Or could someone use the differences to send first-responders in different directions during a crisis, if they were unable to coordinate and verify properly? What is the possibility of an agency installing an insecure system without notifying related agencies or the city SOC and still tie the system into the city for the agency's convenience? Having experienced it first-hand, I know it is possible.
During the past two years, there have been 184 cyberattacks on U.S. public safety organizations, 42 of which were directed at 911. It is routine to block a large-scale distributed denial-of-service (DDoS) attack on the internet, but how do you defend against a telephony-denial-of-service (TDOS) attack using 6,000 infected cellphones to jam local 911 call centers?
These days, public service systems like 911 receive data from non-secure systems, including public cellphones that send text, images and video, along with the voice calls to help responders locate an emergency. Even the phones of responders should be considered insecure. What about the service providers 911 centers use for connectivity? The U.S. Department of Homeland Security released a primer titled "Cyber Risks to Next Generation 9-1-1" to help educate agencies to secure their systems better.
Honestly, it will be tough to ultimately secure a smart city with today's technology. Smart cities are large, complex organisms with many system interactions that are unknown and unforeseen. A single vulnerability could ripple or impact many other unrelated systems. Existing cybersecurity products as specified in the tenders would be hard-pressed to identify and protect against those ripples.
Planning and oversight have the most significant impact on securing a smart city. We need to require that standard systems and protocols be followed, as well as ensure that risk analysis be carried out for each system as it relates to any other system, no matter how tenuous. But the key to securing a smart city will be the cooperation and communication of all agencies within that city.
Good luck with that.
Guy Rosefelt is the director of product management for threat intelligence and Web security at NSFOCUS. Prior to this position, Guy began his 20-plus years of experience in application and Web security with 10 years with the U.S. Air Force, five of which he served as a captain. Guy then moved on to his next chapter with a position as a sales engineer at Raptor Systems, before working his way up the ladder at several SEIM and WAF companies, including big name brands such as Symantec and Citrix. During his two decades in the industry, Guy was part of several big-name acquisitions, including those of Axent Technologies, Novell, Intellitactics and Teros. In his current position at NSFOCUS, he is passionate about his work to develop and promote Web security and NTI strategy and offerings.
