Practical Guide: IoT Cybersecurity & Privacy
- Authors
{{{summary}}}
Chapter Summary
The purpose of the chapter
With the advent of IoT devices and their rapid and wide adoption in Smart Cities, municipalities face an urgent necessity to ensure the IoT-related ecosystems are trustworthy by design. New regulations will no doubt be enacted by the federal and local regulatory bodies in due time, but municipalities face an urgent need for practical guidance for built-in security and privacy protection.
Whom is it intended for The audiences are municipality policy makers, department heads, innovation officers and strategists as well as technology implementers tasked with building IoT capabilities. Policy makers and administrators can expect to gain a good understanding of big-picture considerations and relevant legal considerations to aid their planning while technology implementers can leverage a set of tools to facilitate their implementation.
What the reader should expect to take away
The readers can take away an easy-to-adopt and one-size-does-not-fit-all approach for municipalities to plan on cybersecurity and privacy needs for IoT capabilities.
Collaboration with other chapters
This chapter may cross-reference the other chapters where appropriate for a seamless reading experience. Convention and general cybersecurity and privacy considerations are available in Global City Teams Challenge: Cybersecurity and Privacy Advisory Committee Guidebook.
I. IoT: Cybersecurity and Privacy Risks
The infamous Mirai botnet pushed IoT security risks on the world stage on October 21, 2016. Initially as a money-making project of three college students, the distributed denial of service (DDoS) stunned the world with its powerful impact: it made high-profile companies such as GitHub, Twitter, Reddit, Netflix, Airbnb inaccessible for hours as well as the backbone of the Internet DNS service provider Dyn.
This IoT devices-centered DDoS was neither the first, nor the last of attacks. In fact, IoT systems can be leveraged to cause damage to all three pillars of information security: confidentiality, integrity and availability.
Another attack at a Las Vegas Casino significantly dented the high rollers’ trust and confidential information. (More description: here, here and here)
[http://www.govtech.com/security/Security-Privacy-Governance-Concerns-About-Smart-City-Technologies-Grow.html Municipalities suffer more severe setbacks or impacts when security is ignored at even an inconspicuous seemingly unimportant component]. The primary cause of the 2003 Northeast blackout was a software bug in the alarm system in an energy company’s control room that led to a catastrophic shutdown of the electrical grid, affecting 55 million people. 20 Appendix A offers more types of risks of which all IoT project personnel should be aware.
Similarly, the ubiquity of IoT devices and constantly evolving laws leave much to be desired for privacy protection. The fact that IoT devices are identifiable across more networks further exacerbates the need to protect against unintended sharing of information. Many data points can be correlated about citizens and their households to create profiles of people and places in order to make decisions about them. Since municipalities are expected to serve their stakeholders’ best interest, they bear more responsibilities to protect all stakeholders’ privacy and do it right the first time. Municipalities with Smart City ambitions and IoT enablement vision ignore privacy considerations at their own peril.
II. IoT: Trustworthy and Resilient through Risk Management
With unprecedented potentials come unforeseeable risks. It is paramount to maintain people’s trust and ensure resilient IoT systems. Such a goal is only feasible through risk management, especially in cybersecurity and privacy.
Cybersecurity and privacy risk management is far from an undue burden; on the contrary, any IoT capabilities without designed-in risk management will prove to be costly, prone to disruptions by cyber threats and unsustainable.
Risk management is a mature discipline that ensures the most cost-beneficial outcome for IoT deployment. The Cybersecurity and Privacy Advisory Committee (CPAC) under NIST’s Global City Teams Challenge and the Smart Secure Cities and Communities Challenge, has summarized the following lifecycle after combining three disciplines, namely risk management, information security and project management:
- Plan
- Implement
- Monitor
These iterative phases have integrated NIST Risk Management Framework and Cyber Security Framework. The table below depicts the key activities in each phase, as well as the corresponding activities in RMF and CSF. More details are available in CPAC’s Guidebook. Cybersecurity and Privacy Risk Management Cycle
III. Best Practices and Considerations
Best Practices:
- Empower an individual with accountability and resources in early planning
- This individual will be motivated to adopt best practices wherever available.
- Establish a cybersecurity framework and privacy framework
- Such frameworks allow the teams to realize fully the benefit of a consistent lexicon and methodologies. Data Privacy is the guiding directive by which we are able to preserve our freedoms, including the freedom to be informed and the freedom to choose.
- Ensure collaboration and transparency whenever possible
- Approaches that do not integrate across organizational silos have proven not only limiting in capabilities, but also costly. Seek assessment and validation by independent third parties to avoid blind spots.
Technical and IoT-Specific Considerations
- Technological diversity and limitations – Given the diverse array of technologies in the
smart city environment (e.g., IoT devices), selected controls – including common controls – may not be able to be implemented as intended. Factors restricting implementation may include limitations in built-in functionality, processing power, battery life, etc. This may necessitate significant effort in terms of tailoring security and privacy controls, determining compensating controls, or assessing risk acceptance. Organizations and system owners will need to document how controls are actually implemented and configured and determine whether the residual risk is acceptable. Additional discussion of IoT and associated cybersecurity and privacy risks and considerations can be found in the following resources: Draft NISTIR 8228: Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks and NIST Cybersecurity White Paper: Internet of Things (IoT) Trust Concerns.
[https://www.ctia.org/news/wireless-industry-announces-internet-of-things-cybersecurity-certification-program Wireless Industry Announces New Cybersecurity Certification Program for Cellular- Connected IoT Devices].
[[Media:iot-ddos-nist-sp1800-15b-preliminary-draft.pdf|NIST teams together with industry leaders have proposed MUD].
- Common control challenges and opportunities – Collaboration across government departments and agencies can lead to increased efficiency, for example, with the identification and implementation of common controls. However, diversity of technologies, architectures, and infrastructures could limit the feasibility of common controls. Collaboration from policy, governance, budget, and infrastructure perspectives may be needed to maximize the effective implementation of common controls. Establishing, implementing, and maintaining common controls can be enabled by some of the other considerations identified in this document (e.g., leveraging the procurement process, external communications).
- Continuous monitoring in highly dynamic smart environment – Smart city environments are highly dynamic with frequent changes to the technology environment. Corresponding cybersecurity and privacy requirements and controls will undoubtedly need to be revised, updated, reconfigured, etc. Organizations and systems owners will need to determine the appropriate minimum frequency at which necessary risk management processes will be conducted. This frequency may vary by system security category and impact level, mission, information type(s), and other organization risk factors. That said, the long-term risk management objective is to continue to move towards increased automation and truly continuous (i.e., real-time) monitoring of risk.
Indeed, NIST 800-37 Rev. 2 recommends that “Organizations should maximize the use of automation, wherever possible, to increase the speed, effectiveness, and efficiency of executing the steps in the Risk Management Framework (RMF). Automation is particularly useful in the assessment and continuous monitoring of controls, the preparation of authorization packages for timely decision-making, and the implementation of ongoing authorization approaches—together facilitating a real-time or near real-time risk-based decision-making process for senior leaders. Organizations have significant flexibility in deciding when, where, and how to use automation or automated support tools for their security and privacy programs. In some situations, automated assessments and monitoring of controls may not be possible or feasible.”
Legal and Liability Considerations
- Understand new and/or additional regulatory exposure – Depending on the organization(s) and on the types of data being processed by the IoT system, various regulatory requirements may come into effect. For instance, if a system includes healthcare data (e.g., vital sign information from wearable sensors worn by first responders), HIPAA may apply. Alternatively, if a system includes data that allows members of the public to be identified (e.g., video recordings), various privacy regimes may apply, such as GDPR or California data privacy laws.
- Risk mitigation through cybersecurity insurance – Smart cities can consider cybersecurity insurance as a risk mitigation measure (i.e., risk transfer). Cybersecurity insurance is an expanding and open area of business support/development, and can reduce potential financial loss (i.e., consequence) and thereby reduce total risk. However, insurance would only be suitable for mitigating certain risks (i.e., those that can directly translate into monetary loss). A recent Wall Street Journal survey suggested that a majority of the 25 largest U.S. cities have, or are considering, cyber insurance.
- Cautious use of non-disclosure agreements - The use of non-disclosure agreements (NDA) should be carefully considered. The municipality may need to share vendor information with external regulatory bodies or even other vendors (e.g., data formats sent by an IoT device may need to be known by packet inspection engines). NDAs should provide enough latitude to enforce the municipality’s chosen cybersecurity and privacy risk posture while also respecting vendors’ intellectual property and proprietary information. The municipality will benefit from periodic technology audit/risk review assessments, similar to those carried out for financial audits and reviews of banks, financial, and other complex organizations.
US Federal level agencies Eric A. Fischer, Federal Laws Relating to Cybersecurity: Overview of Major Issues, Current Laws, and Proposed Legislation, December 12, 2014
Many laws at the US federal level require that information systems protect sensitive data they store or process. Failure to comply with these laws may incur various consequences including stiff fines. In worst cases, data breaches and business interruption are common consequences after a successful attack as in Atlanta City in March 2018. FBI investigating cyberattack on Atlanta that involves ransom note BY BRETT SAMUELS - 03/22/18
- - Summary of impacts of major laws, regulations and standards; with the list in Appendix D
The Risk Assessment section of the Blueprint provides guidance on the types of risks that might arise when deploying IoT projects in Agency contexts. Risks might be technical, operational, contractual, or legal. Mitigations, when available, can take various forms just as the risks can. Everyone involved in deploying IoT projects should be familiar with the contents of the Risk Assessment section.
Risks associated with IoT projects can be thought of as all of the risks of any IT project, and a new set of risks brought on by:
- The presence of networked computing devices at the edge of the network
- New network transports
- Rich data sets traversing the network and being stored in data repositories
- The introduction or expansion of cloud-based IT solutions in the Agency’s technology ecosystem
Beyond the technical risks brought on by IoT, there may be operational and organizational challenges related to systems that were previously the exclusive purview of Operational Technology departments or roles now interacting much more closely with Information Technology departments or roles. Departmental communication and training may be advantageous to leverage the potential benefits and address the new risks of such integration.
Risks should be assessed using a combination of evaluating the likelihood of the risk being exploited and the costs resulting from any exploitation.
This section attempts to call out specific risks related to IoT deployments and is not intended to prescribe a complete risk management framework. The Agency should consult a document such as NIST 800-30r1 for an overview of a complete risk management framework.
The appendix to this document includes a Risk Assessment Questionnaire that may be useful in working through the risk discovery process during the system design process.
Considerations – Risk Gaps
IoT projects introduce devices with connectivity and computational power at the network edge. Previously, devices with these capabilities were generally contained within data centers, or other network segments that could be configured for limited ingress/egress and monitored. The deployment of these edge devices might also introduce new network technologies at several layers of the OSI network model. The Agency’s existing threat model and risk assessment framework may need to be extended to cover these new system components. Additionally, IoT projects may be leveraging unvetted, or at least immature, technologies or systems with inadequate documentation (examples include the Heartbleed flaw in TLS, KRACK in Wi-Fi, and 802.11R flaws in WPA roaming). This is in addition to the classic risks of IT projects like data stewards, failure to adhere to the principle of least responsibility, improper configuration of data center resources, etc.
Considerations – Costs to Recover
In the event of a breach, remediation might include technical, contractual, and legal effort. The breach should be understood so that future similar breaches can be prevented. Any theft or loss resulting from the breach might require reporting to relevant regulators as well as affected residents and enterprises. The costs associated with such actions should be considered in evaluation the potential impact of a breach.
Considerations – Costs to Implement
Risk mitigations must be considered as part of the overall budget of any IoT project. Some costs may be up-front (e.g., system design reviews, pre-deployment comprehensive penetration testing) and others might be ongoing (e.g., active network traffic monitoring, insurance).
Considerations - Regulatory Requirements
Depending on the Agency and on the type of data being processed by the IoT system, various regulatory requirements may come into effect. For instance, if the system includes healthcare data (vital sign information from wearable sensors worn by first responders, say), HIPAA may apply. Alternatively, if the system includes data that allows members of the public to be identified (video recordings for instance) various privacy regimes may apply (GDPR or California privacy law).
Considerations – System Implementation Insource vs Outsource
As IoT products become more mature, vendors are increasingly able to provide risk documentation and mitigation strategies. Agencies are encouraged to involve vendors in the Risk Assessment process, both for the components the Agency is procuring from the vendor, and to help evaluate risks at touchpoints between components that may come from different vendors, or already exist in the Agency’s infrastructure. Use of standard authentication technologies like server certificate verification as part of TLS connections, network mapping and monitoring, and device whitelists for network access will require vendor support and should be built in to system specifications, with attendant contractual terms.
Considerations – Risk Evaluation Insource vs Outsource
Conversely, vendors may not have adequate familiarity with the particular risks and especially their associated costs faced by the Agency. In such cases, it would be prudent for the Agency to take the lead on risk evaluation. Vendors may have information on vulnerabilities in system components that are discovered as time goes on. The Agency may wish to require that vendors keep the Agency informed as vulnerabilities are discovered. The Agency may also wish to require that vendors disclose standard software components that are used in system components so that the Agency can independently be aware of vulnerabilities. For instance, the CERT CVE database of vulnerabilities can be useful.
The use of Non-Disclosure Agreements should be carefully considered. The Agency may need to share vendor information with external regulatory bodies, or even other vendors (for instance, data formats sent by an IoT device may need to be known by packet inspection engines). The Agency should ensure that any NDAs provide enough latitude to enforce the Agency’s security posture.
The Agency may benefit from periodic technology audit/risk review assessments, similar to those carried out for Agency finances. Banks and financial institutions are held to a technology audit/risk review assessment that results in finding reports, so considerations that apply to banks should be considered for the Agency. For more information see, [https://www.occ.treas.gov/topics/compliance- bsa/bsa/index-bsa.html Bank Secrecy Act]
Approach – Areas of Risk – Risk Gaps
Special attention should be paid to:
- Interfaces between system components
- Services that may be driven by the data from the system
As an example, consider the BigBelly trash collection system. If someone hacks the BigBelly communications channel and causes unneeded collection truck trips, who is liable for the costs associated with those trips? BigBelly, for making it possible for the trashcans to be impersonated? The telecoms provider for making a channel that an attacker could hack? The garbage service for rolling a truck without verifying the need?
As another example, suppose an eavesdropper is able to listen in on public safety dispatch communications and commit crimes in places far away from current police presence. Encryption can be provided by both the device and the telecoms channel. In general, a philosophy of defense in depth suggests both layers of encryption should be applied. If the two channels are provided by two vendors, and somehow the combination is cracked, who is responsible?
Approach – Technical Attack Vectors
Consideration should be given to encryption of data in transit and at rest. Standard technologies like TLS for sockets over the internet help with both authentication and encryption. Configuration errors can cause these protections to be ignored or not present, though, so verification of correct performance should be included. The transport technology may offer its own layer of encryption (Wi-Fi WPA2 for instance), which should be used. Encryption within encryption is encouraged, and encryption implementations using standard libraries is encouraged. Library versions should be cataloged and tracked with device firmware versions so that if a library flaw is discovered, it can be known which devices are at risk and need to be updated or withdrawn from service.
Unauthorized access to devices is a huge risk. If an attacker can log in to the device, which is higher risk with IoT devices, they can use it for their own purposes, whether that is launching Denial of Service attacks on third parties, mining cryptocurrencies, or accessing the Agency’s other IT resources. Network services on the device should be disabled if not needed for the designated task of the device, all authentication methods should be unique, and any default authentication methods should be changed by the end user at installation/commissioning time.
Network whitelists should be considered. Devices should have unique identifiers like MAC addresses that can be used at the network transport layer to ensure this communication is expected. Whitelists can be applied at multiple touchpoints and will depend on the particular network architecture.
Backend attacks on databases and cloud infrastructure should be addressed through the techniques common to all such IT projects.
System components will almost certainly use standard software components like OpenSSL for TLS and cryptography algorithm implementations, TCP/IP stacks, and Linux, BSD, or real time operating systems. Vulnerabilities in standard software components are often tracked in the CERT CVE database. A list of components used across the system, including version information, is invaluable because it can be compared to the CERT CVE database to ascertain quickly the technical risks.
Approach - Technical Attack Consequences
Any breach of the system, whether at the edge, the datacenter, or somewhere in between, can have a wide range of consequences. Data may be exfiltrated, Agency services may be compromised, Agency resources (included the IoT devices) may be leveraged by an attacker for their own purposes. Telecom or datacenter usage limits may be breached, leading to financial consequences.
Risk Assessment Outcomes
The risk assessment process should leave the Agency with a set of documents outlining the solution architecture, an awareness of the risk vectors for each component in the solution, an awareness of how the solution interacts with other Agency IT assets, and a quantified set of costs to implement the system including risk mitigation, and a quantified set of costs to recover from breaches. The technical documentation (including risk vectors for each component) should be maintained as system components are updated (including firmware updates) or replaced, and as vulnerabilities are discovered in the deployed components. The documentation should include locations of vulnerability listings, like the CERT CVE vulnerability database.
Key Smart City Risk Management Considerations
Operationalizing and standardizing risk management across the organization is critical for minimizing cybersecurity and privacy risks during the development and operation of smart city capabilities and solutions. It will be up to cities and their partners to determine the appropriate risk management policies and processes to adopt and implement based on their current risk management practices, risk posture, and their risk management strategy. While aspects of risk management may seem daunting and challenging, there are certainly opportunities that cities can leverage to their advantage. The following considerations are things that smart city organizations should keep in mind as they pursue the development and maturation of their risk management programs.
- Risk management as a smart city enabler – Proper risk management practices and communication of those risk management practices can actually help enable the development, deployment, and operation of smart city capabilities. Risk management should not be viewed as an encumbrance. Proper cybersecurity and privacy controls can help gain public trust and buy-in and promote requisite participation in smart city functions.
- Intra-governmental coordination and collaboration – Given the interconnectedness and multi-stakeholder nature of smart city capabilities and solutions, successful risk management will require significant communication, collaboration, and coordination between city departments and agencies. This necessitates the development of consensus, modification of existing structures and processes, and consideration of new shared resource and service models.
- Public-Private and intergovernmental coordination – Smart city systems often involve a mix of assets (e.g., city-owned and operated; regional; commercially-owned and operated). Successful risk management will require sharing of information (including potentially business-sensitive information), coordination of risk management and governance practices, and alignment of organizational and system boundaries.
- External communication of risk management strategy and policies – It is important for organizations to adequately communicate risk management strategies, policies, and guidance not only to internal departments and agencies but also to existing and prospective external partners, service providers, vendors, and constituents. This enables external parties to understand the risk management environment in which they are expected to participate and also enables capability providers to develop capabilities based on well-established risk management practices (e.g., security and privacy control
baselines).
- Leverage acquisition and procurement mechanisms – Risk management needs to include acquisition and procurement offices and personnel – both in the establishment and implementation of risk management practices. Smart city solutions’ dependence on external services and COTS products provides an opportunity for smart city buyers to dictate risk management requirements in contractual agreements, service level agreements, product certifications, etc. This is a means for smart cities to have some level of control over the security and privacy of systems and products that would otherwise be out of their control and ultimately assist in mitigating enterprise risk.
- Management of risk from external services, systems, and products – Smart cities’ reliance on external services, contractor-owned systems, and COTS products necessitates mechanisms to ensure the risks associated with external services, systems, and products are properly managed. This includes all aspects of the risk management process, including the prioritization of systems and assets; the selection and implementation of controls; and the independent assessment and continuous monitoring of systems. This may require contractual agreements, service level agreements, or participation in independent, third-party certification programs.
- Identifying, understanding, and assessing interdependencies – Smart city functionality may introduce new dependencies (e.g., data dependencies), and risk management decisions will need to consider the nature of these interdependencies. While an information system or an information type may be low impact for some stakeholders, the system or data may be high impact in another stakeholder’s context.
- Technological diversity and limitations – Given the diverse array of technologies in the smart city environment, selected controls – including common controls – may not be able to be implemented as intended. Factors restricting implementation may include limitations in built-in functionality, processing power, battery life, etc. This may necessitate significant effort in terms of tailoring security and privacy controls, determining compensating controls, or assessing risk acceptance. Organizations and system owners will need to document how controls are actually implemented and configured and determine whether the residual risk is acceptable.
- Common control challenges and opportunities – Collaboration across government departments and agencies can lead to increased efficiency, for example, with the identification and implementation of common controls. However, diversity of technologies, architectures, and infrastructures could limit the feasibility of common controls. Collaboration from policy, governance, budget, and infrastructure perspectives may be needed to maximize the effective implementation of common controls.
- Risk mitigation through cybersecurity insurance – Smart cities can consider cybersecurity insurance as a risk mitigation measure (i.e., risk transfer). Cybersecurity insurance could reduce potential financial loss (i.e., consequence) and thereby reduce total risk. However, insurance would only be suitable for mitigating certain risks (i.e., those that can directly translate into monetary loss).
- Leverage existing IT/system assessment and auditing functions – If a city already has an independent assessor or auditor (whether a government organization or a contractor) for their enterprise IT systems, the scope of work could be expanded to include smart city systems. However, the city will need to consider whether the assessor or auditor has the requisite, specialized expertise to evaluate the diverse set of smart city technologies and systems.
- Continuous monitoring in highly dynamic smart environment – Smart city environments are highly dynamic with frequent changes to the technology environment. Organizations and systems owners will need to determine the appropriate minimum frequency at which necessary risk management processes will be conducted. This frequency may vary by system security category and impact level, mission, information type(s), and other organization risk factors. That said, the long-term risk management objective is to continue to move towards increased automation and truly continuous monitoring of risk.