Practical Guide: IoT Cybersecurity & Privacy

Wireless
Sectors	Wireless
Contact	David Witkowski
Topics	Case Studies Case Study Summary Findings & Discussion Considerations for Deploying Municipal IoT Funding Models History of Public WiFi Impacts to Municipal Governments of IoT Networks Internet of Things Introduction to Public WI-FI Use Cases Legal Issues Marketing & Outreach Practical Guide: Deploying an IoT Network Practical Guide: IoT Cybersecurity & Privacy Procurement Project Management Technology Strategy The Current State of Municipal IoT Deployments Wireless Blueprint

Authors

{{{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)

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:

1. Plan
2. Implement
3. 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.

Wireless Industry Announces New Cybersecurity Certification Program for Cellular-Connected IoT Devices.

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, 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.

Section Appendixes

Appendix A: IoT Threat Examples

Device Hijack - Confidentiality & Integrity

There are three main threats if a networked device can be accessed by unauthorized agents: direct misuse, exploiting connections for further unauthorized access, and misuse of Agency resources. Direct misuse might include a smart lock being actuated or surveillance cameras being watched. Exploiting connections means the attacker uses the device’s privileged position in the Agency’s network to access further networked assets. Resource misuse includes using the networked device to mine cryptocurrencies or attack internet-based assets outside the Agency’s control. Recent occurrences of these attacks are (Jan 2019 Nest camera access, aquarium thermostat, Mirai botnet). The first two threats directly open the Agency to liability concerns due to data privacy breach and operational risk due to unauthorized access, while the third may consume limited Agency resources like power or bandwidth.

Device can be compromised to spy on owners: IOT device that has Audio/Video capability can be compromised to listen the surrounding area or capture video footage that otherwise should not be available publicly. There are reported cases of Baby Monitors being used to spy on the inside of the house due to default or weak passwords.

Device can be compromised and used to attack other systems within the same network: As a connected device inside the network, connected device can be compromised and used as a hoping point to access more sensitive areas of the network. This threat becomes more severe on IIOT environments where simple networked cameras can be used as a gateway to access control systems.

Device can be compromised to attack other networks: There are multiple scenarios where the device can be used to attack other external devices on the Internet. Mirai is one of the best examples of what is possible thru this attack scenario.

• DDOS can be performed on website/services on the Internet (i.e. Mirai)
• Device can be leveraged to compromise other vulnerable devices on the Internet by running vulnerability scanning on vast amount of IP addresses and ranges.
• Device can be hijacked to send spam emails for financial gain
• Device can be hijacked to perform targeted phishing attacks on individuals that "trusts" the network which device belongs to for circumventing certain controls

Device can be compromised to cause physical damage: Smart cars can be hijacked to cause physical damage to the driver and passengers. There have already been reported cases of cars turning off during normal driving conditions at high speeds. Another example is HVAC systems being turned off during winter causing physical damage to the building unit. In the cases of IIOT applications, simple turning off a production machine can cause millions of dollars in damage as uncontrolled pause in production causes materials and time to be wasted (i.e. microchip production plants).

Information Disclosure or Modification - Confidentiality & Integrity

Information about the user or the infrastructure could leak to attackers: Widespread deployment of IOT devices turn our cities into data generation warehouses where great deal of information is being captured and shared between different services and service providers. Improperly secured communication protocols/devices can be eavesdropped to capture information about the environment as well as the users of the service.

Information processed and shared by the device can be modified: In certain cases, information modification can result in more serious outcomes then information disclosure. This is certainly the case in the medical field where data being received from an IOT device is used to provide health and safety services to individuals. In the simple case of an insulin pump, pump’s remote sensor can be tricked to send a signal to the pump to release high levels of insulin to the bloodstream

Service Disruption - Availability

Device can become non-functional disrupting the service: in the case of “Smart Homes” or buildings, lights can be turned off disrupting the lighting for the unit. In more serious attack scenario, all lights and smart devices in a specific region can be turned on drawing large amount of power from the GRID disrupting the electric grid. In the case of ransomware, device and the data it contains can be encrypted for demanding ransom before turning on the service.

Appendix B: Use Cases

Application	User Story	Connectivity	Typical Security	Threat Vector	Risk Management Proposal	Business Risk	City deployed and Status
Smart Waste	As a city operator I would like to know when to dispatch garbage Smart Waste collection in order to reduce the unnecessary routes contributing to pollution and improving efficiency	Wi-Fi LoRa	Radius 802.1X AES 128	Man in the middle DDOS
Connected Lighting	As a city operator I would like to have adaptive controls for my LED lighting in both the street and area environment to improve safety and energy efficiency	Wi-Fi LoRa Cellular	Radius 802.1X AES 128 SHA, ECC, PKI, Network authentication
Traffic Monitoring	As a city operator I would like to reduce traffic congestion within the city by deploying cameras and edge gateways	Wi-Fi LoRa Cellular Fiber	Radius 802.1X AES 128 SHA, ECC, PKI, Network authentication
Environmental Monitoring	As a city operator, I would like to understand certain conditions and pollutants in the city environment. I would like the gasses and particulates to be reported based on threshold events	Wi-Fi LoRa Cellular
Smart Parking	As a city operator I would like to provide the citizens with open arking space indication that is presented either by a digital sign or delivered via a mobile application	Wi-Fi LoRa Cellular Fiber
Digital Kiosk	As a city operator, I would like to provide an element of citizen engagement via the use of digital kiosks that will deliver city information such as nearby restaurants, parking, heat maps for where events are	Wi-Fi LoRa Cellular Fiber

Appendix C: Municipal Roles and Responsibilities

Personnel and Management Models

• Privacy Officer - manages policies, coordinates audits
• Data Owner/Custodian - determines required controls
  • should not be contractor
  • avoid conflict of interest
• Auditor (could be third party) - determines effectiveness of controls
• Administrator/Engineer - applies the controls

Incident management

• Chief IoT Officer. Dictates strategy and manages IT governance and security
• Software engineer. Manages software and program code.
• Developer. Goes beyond software and manages hardware.
• Networking engineer. Provides networking and connectivity capability.
• Designer. Ensures user interface that controls sensors and examines data.
• Data scientist. Works with sensor data to apply analytics.
• Coordinator. Supervises the manufacturing floor to address robot breakdown and disaster recovery.

Appendix D: IoT-related Standards and Laws

Many laws at the US federal level require that information systems protect sensitive data they store or process temporarily. Failure to comply with them 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 06:14 PM EDT

• Health Insurance Portability and Accountability Act of 1996 (HIPAA)
• NIST Cyber Security Framework (CSF)
• NISTIR 8200 (International Cybersecurity Standardization for IoT)
• Center for Internet Security (CIS) (20 critical controls)
• National Response Framework (NRF)
• National Incident Management System (NIMS)
• General Data Protection Regulation (GDPR)
• Information Technology Infrastructure Library (ITIL)
• ISO 27001/2
• FEDRamp
• State /Local Laws
• NIST White Paper (10/17/2018), "Internet of Things (IoT) Trust Concerns" NIST IR 8200, "Status of International Cybersecurity Standardization for the Internet of Things"
• NIST IR 8196 (DRAFT), "Security Analysis of First Responder Mobile Devices and Wearable Devices" goes into the Use Cases, Attack categories, Threat Analysis, Security Objectives and IoT Security Concerns"
• NIST IR 8228 (DRAFT), "Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks". The purpose of this IR 8228 is to help federal agencies and other organizations better understand and manage cybersecurity and privacy risks associated with their own IoT devices throughout their life cycles, this publication is the introductory document providing the FOUNDATION for a planned series of publications on more specific aspects of this IoT topic.
• NIST White Paper Draft (comments due March 18, 2019, "Security for IoT Sensor Networks: Building Management Case Study"
• NIST Privacy Framework
• New York City's IoT Guidelines (35 cities have adopted), https://iot.cityofnewyork.us/

Convention	Law/Regulation/Standards	Applicable to Municipalities’ IoT Projects?	Consequences of noncompliance	Covered Data	Security	Privacy	Case Studies
HIPAA	Health Insurance Portability and Accountability Act of 1996	Yes If IoT projects handles people’s protected health information (PHI) or e-PHI	compliance or corrective action through other informal means, including a resolution agreement, civil money penalties (CMPs) may be imposed for noncompliance against a covered entity.	the individual’s past, present or future physical or mental health or condition, the provision of health care to the individual the past, present, or future payment for the provision of health care to the individual	The Security Rule establishes a national set of security standards for protecting certain health information that is held or transferred in electronic form.	The HIPAA Privacy Rule, or Standards for Privacy of Individually Identifiable Health Information, establishes national standards for the protection of certain health information.	No Business Associate Agreeme nt? $31K Mistake – April 20, 2017

For reference: contained in CPAC Guidebook GCTC Cybersecurity and Privacy Advisory Committee (CPAC)

Appendix Conventions

1. Information systems
   The term information systems are defined in 44 U.S.C. §3502 as “a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information,” where information resources are “information and related resources, such as personnel, equipment, funds, and information technology.”
2. Cybersecurity
   Thus cybersecurity, a broad and arguably somewhat fuzzy concept for which there is no consensus definition, might best be described as measures intended to protect information systems—including technology (such as devices, networks, and software), information, and associated personnel—from diverse forms of attack. The concept has, however, been characterized in various ways. For example, the interagency Committee on National Security Systems has defined it as “the ability to protect or defend the use of cyberspace from cyberattacks,” where cyberspace is defined as “a global domain within the information environment consisting of the interdependent network of information systems infrastructures including the Internet, telecommunications networks, computer systems, and embedded processors and controllers”. Committee on National Security Systems, National Information Assurance (IA) Glossary, April 2010, Information security.
   In contrast, cybersecurity has also been defined as synonymous with information security (see, for example, S. 773, the Cybersecurity Act of 2010, in the 111 th Congress), which is defined in current law (44 U.S.C. §3532(b)(1)) as protecting information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide— (A) integrity, which means guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity; (B) confidentiality, which means preserving authorized restrictions on access and disclosure, including means for protecting personal privacy and proprietary information; (C) availability, which means ensuring timely and reliable access to and use of information; and (D) authentication, which means utilizing digital credentials to assure the identity of users and validate their access.
3. Information security
   Synonymous with cybersecurity