Why Confidentiality, Integrity and Availability Are Key
Security experts traditionally use a tool called the CIA triad — with those letters representing the areas of confidentiality, integrity and availability — to help break down and describe InfoSec risks. They then immediately focus most of their energy on confidentiality, because data breaches and loss of privacy are generally the biggest issues that enterprise IT has to worry about. In contrast, OT in smart cities faces all three risks rather equally; in fact, confidentiality is often the least important security risk (unless security cameras are involved).
When traditional IT managers begin to focus on security, the shift in emphasis from confidentiality toward data integrity and overall system availability can be a bit jarring. The relative lack of traditional tools and techniques presents an additional challenge.
For example, one of the first security rules every IT manager learns is to keep systems patched and updated. Well, in the world of OT, patching is not so simple. Some of the components in an OT system may not be easy to patch. The vendors are smaller and often don’t have the resources to generate new software for older devices, so there may not be patches available. The devices may require physical disassembly to update firmware or software, costing money and system downtime. Testing patches and updates is also hard when virtualization and test labs are not available. Finally, compatibility issues between vendors and products will sometimes completely block patches.
OT Systems Require Resiliency, Reliability and Safety
This change in perspective means that securing OT systems is not the same as simply repurposing IT security tools into the OT environment. Instead, it is critically important to start from scratch and consider each of the risks in the CIA triad when building a threat mitigation plan. Potential threats to data integrity and data availability are especially significant when smart city systems may be making real-time decisions on everything from traffic control to lighting and building security.
For example, corrupted (maliciously or accidentally) sensor data has very real consequences if it affects flows within the city’s water or sewage systems. OT security practitioners sometimes emphasize the need for special focus by reorganizing the letters in the CIA triad to AIC and by adding their own security terms, including resiliency, reliability and safety.
An additional risk to keep in mind is that many smart city systems are the grandchildren of devices that were never meant to be connected to any outside network. While they may use networking internally, they were designed to be run in isolation: This is an example of “air gap security.” The security issues can be immense when IT and OT teams try to leverage existing city networks, close the air gap and bridge these types of devices to less secure city or internet networks.
LEARN MORE: What are the main security vulnerabilities in a smart city?
IT Pros Must Conduct Clear Risk Assessments
The greater emphasis in OT security on reliability, trust and safety over traditional IT concerns such as privacy and confidentiality requires IT professionals to take a deep breath and begin with a clear risk assessment.
As with traditional IT programs, it’s helpful to start with broad layers (physical, network and application) and then dive deeper. For example, many smart city projects may include some public cloud components — weather information, maps, cloud-based authentication services and so on — creating additional risks of availability, integrity and confidentiality as third parties and their infrastructure become part of the project.
When traditional end-user computing devices such as tablets, smartphones or laptops built into kiosks are part of the project, then equally traditional endpoint protection technology such as anti-malware tools, mobile device management systems, encrypted hard drives, certificate-based authentication and locked-down configurations can be brought into play.
If a custom device is part of the project, some of these risks may need to be dealt with by assuming that the device is compromised (even if it is not) and protecting every other part of the system based on that assumption.
