Internet of Things – Best Practices
By Julian Gehman
The Internet of Things (IoT) is Wild West of telecommunication – growing exponentially, providing innovative services, collecting new and valuable consumer information in unknown ways, at subject to little regulation and sporting weak security gives happy hunting ground for hackers.
When one encounters the Internet of Things, it isn’t called that. It is called a smart grid, or a fitbit, or an Apple watch, or a connected factory, or a digital doorbell, or a condition monitoring and preventative maintenance service for heavy machinery. Nevertheless, these and many more things share in common the following attributes that comprise the Internet of Things:
- a sensor that detects or measures something like motion, a hearbeat, temperature, humidity, machine vibration, speed, direction, elevation, orientation, electricity flow, fluid level, etc.;
- a communications device, usually a radio frequency (RF) transmitter, that sends the information, through a gateway to a cellular system, or over unlicensed spectrum to the cloud, or directly device-to-device;
- an aggregator to collect, sort and analyze the data received from sensors;
- a logical decision rule to trigger an alarm, send a report or activate an actuator; and
- in some cases, an actuator that takes physical action, such as opening or closing an automatic valve, moving the flaps of a jet airplane or pumping insulin into a diabetic.
The Internet of Things is big already, and is predicted to grow much larger. Estimates of the size of the IoT market are all over the place, with widely varying estimates of number of IoT devices and projected revenues. According to a conservative estimate, nearly nine billion IoT devices were active in 2020. This is projected to grow to 20 billion active devices by 2030, with annual IoT revenue of $105 trillion by 2030.
Succeeding generations of IoT are projected to have common protocols so that IoT systems and devices can interoperate with each other. This would facilitate artificial intelligence and the independent interaction of IoT devices without human intervention.
This article covers best practices in the Internet of Things: Pay attention to the data, Consider the business case, Develop secure IoT devices, Secure the IoT system, Defend the corporate network against IoT, Comply with privacy laws, and Use the best connectivity. Special emphasis is placed on security, as IoT systems seem to be readily hacked.
PAY ATTENTION TO THE DATA
Contractually identify rights to own, collect, access, use, share or resell data
The whole point of the IoT is to generate data. Data is becoming increasingly valuable. Consumer or other data becomes even more valuable when combined with other data streams to form a multi-dimensional profile of the subject. Similarly, multiple streams of aggregated data can be combined to form a profile of a target market.
The ownership rights to data are unsettled. Many parties could claim some sort of right to the data produced by an IoT system. Therefore, it is important that each contract address exactly what rights, if any, the counterparty has in the data generated by the IoT system. If the counterparty has no such rights, the contract should explicitly so provide. If consumer data is being collected, the contractual rights to data become doubly important due to consumer privacy concerns.
Parties that could access the data generated by an IoT system include but are not limited to: the sensor manufacturer (with an RF transmitter sending data back to the manufacturer), the device manufacturer (same), the IoT platform provider (the data passes platform), the telecommunications carrier (the data travels over the carrier’s network), the database provider (responsible for storing the data), and any other service or device provider connected with the particular IoT system. Contracts with each of these should address rights to the data.
Where data is accessed, shared or sold, include the right to recover the data or require destruction in the event of the partner’s or purchaser’s bankruptcy, insolvency or for other certain contingencies. For example, RadioShack, as part of its bankruptcy, tried to sell the consumer data the company had collected over the years. Apple intervened and demanded that RadioShack not sell data that was collected from iPhone users.
Pay attention to rights to intellectual property (IP) created by the particular IoT system. IP rights help to define rights to data. Even with a commercial IoT platform, each IoT system is unique and will generate IP. As with the data, many parties could claim rights in the IP. The respective rights in IP should be specified by contract. If a counterparty has no right to the IP, this should be explicitly stated in the contract.
Identify what is needed at each step of the data process
An IoT system will have a data process. Each step of the process should be defined with expected outputs. Following is a typical data process for IoT, along with considerations for each step:
- Collect the data (using sensors) – what data do you need?
- Process the data – how should it be processed and organized?
- Display the data – what format should reports take? Who gets the reports?
- Use the data – which data is time critical such that an alarm or actuator should be triggered? Does it require algorithm driven action, human intervention or both?
- Archive the data – store the data for how long? Will any data be discarded or minimized? What security will protect the archived data?
- Analyze the data – How to optimize the algorithms? Combine with other data? Will the data be shared with anyone?
CONSIDER THE BUSINESS CASE
Start small and iterate
This approach is common to many business ventures but applies especially to the Internet of Things. IoT is still new, and there are no “tried and true” methods. IoT platforms, technologies, and protocols are in a state of flux with little industry-wide standardization. Experimentation is important.
Consider whether to use a silo, or an enterprise-wide, solution
Enterprises and municipalities (the “smart city”) should consider adopting a common platform to serve enterprise-wide or city-wide, rather than allowing IoT silos within an enterprise or city. The IT department, headed by a CTO or CIO, would take the lead on developing the enterprise-wide IoT system. However, the operating unit and senior management need to buy in and be involved with the project. The company could take a discreet IoT project, experiment and try various options until finding one that works, and then make that project the template for other IoT offerings within the company.
Consider whether to use an off-the-shelf platform or develop a custom platform
Amazon Web Services, IBM Bluemix, Microsoft Azure, Google Cloud Platform and AT&T, all offer off-the-shelf IoT platforms that the company or municipality should consider. With a standardized platform, the company does not have to “reinvent the wheel.” However, ownership of, and access to, data could become an issue: at least a few of these companies specialize in collecting consumer data for their own use. Therefore, as noted above, special attention should be paid to contractual rights to the data and IP generated by the IoT system.
Consider the change in business model that could be facilitated by an IoT system
Many heavy equipment manufacturers have traditionally sold through dealers, distributorships or resellers and have not had direct access to the customer. By putting sensors and instrumentation on the heavy equipment, with a radio link to the manufacturer, direct access to the customer can be obtained. The manufacturer can move from selling heavy equipment to providing hours of service on equipment – from a capex to an opex business model. The manufacturer could sell equipment as a service with uptime guarantee and predictive maintenance. This changes the revenue stream to recurring revenue, gives the manufacturer access to the end customer and helps design better products. Another example is automobiles where OEMs are experimenting with transportation as a service. Other industries and types of businesses similarly could be transformed by a transition to an IoT service.
DEVELOP SECURE IOT DEVICES
Utilize best practices in designing devices, particularly consumer devices
Many consumer IoT devices were designed by consumer product companies that do a good job of predicting demand and marketing to consumers but do not include network experts who are good at security. These consumer devices are designed to get to market quickly, ahead of the competition, be compact and lightweight, and to conserve battery usage. Consequently, these devices may lack the computing and battery power to perform encryption or receive over the air updates and security patches. As a result, many consumer devices have weak security and are easily hacked. Here are some best practices for designing IoT devices, particularly consumer devices.
- Make the device physically tamper proof – assume that a malicious actor will have physical access to the device.
- Use computer chips that integrate security at the transistor level, embedded in the processor, and provide encryption and anonymity.
- Use the most recent version of the operating system. If using Linux, use the most recent version of Linux. The most recent version will have the most recent updates and security patches.
- Design the system with disruption in mind. Design the device to fail safely and securely with no further disruption to the network or IoT system.
- Give the device enough computing and battery power to handle encryption and security measures, including updates and patches.
- Transmit software and firmware updates and patches as problems are discovered and resolved.
- Provide for a device reset to the factory settings by remote, over the air command.
- Ship devices with random, hard to crack user names and passwords as the default setting. Do not use the same password on every device. Many consumers never change the default password, so make it a secure password. Of course, the manufacturer should keep a record of these randomly generated user names and passwords, and this database will need to be encrypted and protected.
- Do not permit a backdoor. If a backdoor exists, a hacker will find it.
- Establish device support and a user forum.
- Label the device with contact and support information.
- Minimize or eliminate personal information stored on device – a hacker will get physical access to the device.
- Develop the device with end-of-life in mind. At some point, the device will no longer be updatable or patchable. Be prepared to replace the device with a more recent version and communicate to consumers and retailers the danger of using the device beyond its sunset date.
SECURE THE IOT SYSTEM
Make security part of the initial design and engineering of the IoT system, not an afterthought
As noted above, the marketing and consumer products side of the company traditionally has dominated the design of consumer IoT, with less emphasis placed on security. However, the optimal design balances security against competing objectives of cost, functionality and speed to market by putting in place the right amount of security to adequately protect the system. NIST described this process well:
“There is no system that can be engineered to be perfectly secure or absolutely trustworthy. That fact, coupled with the basic uncertainty that exists and the trade-offs that will be made routinely across contradicting, competing and conflicting needs and constraints necessitates that systems be engineered to achieve adequate security. . . . Adequate security is a trade space decision or judgment driven by the objectives and priorities of stakeholders. Such decisions or judgments are based on weighing security protection, performance and effectiveness against all other performance and effectiveness objectives and constraints.” National Institute of Standards and Technology, Systems Security Engineering, NIST Special Publication 800-160 (Nov 2016) 16.
In order to secure the IoT system, examine each component
A flow chart or diagram of an IoT system might look something like the following:
Sensor -> transmitter -> communication channel -> aggregator -> communication channel -> database -> communication channel -> actuator.
Each of the above steps represents a potential attack surface for a hacker and a potential point of failure in the event of an operational failure. In order to secure entire IoT system, each step along the way must be secured.
Encryption is a necessary but not sufficient condition of security
The Edward Snowden leaks and commentary tell two things about encryption. First, strong encryption works. According to Snowden, it is one of the few things that can be relied on. Second, the architecture around and outside of encryption is vulnerable. Surveillance agencies and hackers access confidential information in plain text form, either before encryption, or after encryption or sitting someplace that is assumed to be secure. As discussed above, each individual component of an IoT system should be examined separately and individually secured.
Pay attention to the supply chain and beware of Made in China
Both the U.S. intelligence community and the Chinese government seem to agree that IoT devices manufactured in China tend to be insecure and susceptible to hacking. SOS International, China’s Internet of Things (Oct 2018) 106. Further, Chinese components have been shown to contain backdoors allowing the Chinese military to snoop on U.S. telecommunications equipment. Pay attention to who is supplying the components for the IoT system.
Include extra security for medical and health related IoT
Medical records are worth ten times as much as credit card records on the black market. This valuable commodity deserves extra protection.
Data breach insurance is a good idea, so long as the company lives up to representations made to the customer and the insurance company. Cottage Health Care System (“Cottage”) had a breach of data where they did not have encryption on their network servers. This made confidential patient information accessible on the Internet. Cottage was hit with a class action lawsuit and its insurer, Columbia Casualty, paid $4.125 million to settle the class action. Columbia Casualty has filed a lawsuit against Cottage seeking reimbursement of the settlement amount plus attorneys’ fees in both actions. Columbia Casualty claims that Cottage misrepresented the security employed to protect patient data.
COMPLY WITH PRIVACY LAWS
Following is a chart of the more important U.S. privacy laws and standards. One should identify the privacy laws most likely to apply to the particular IoT system in question and seek legal advice as to whether these laws actually apply. For example, a medical device may collect health and medical data that qualify as “protected health information” under the Health Insurance Portability and Accountability Act (HIPAA), but the provider of the IoT service might not qualify as a “covered entity” or a “business associate” that would make HIPAA applicable. The details of the particular IoT service would need to be examined to make this determination.
| STATUTE AND ENFORCEMENT AGENCY | APPLIES TO | REQUIREMENTS |
| California Consumer Privacy Act of 2018 Effective January 2020; Calif. AG to issue regulations Enforced by California Attorney General and limited right of private action. | California residents. Personal information (PI) is broadly defined: includes biometric data, as well as IP addresses and other device-related information of persons or households, among other things. | Complex series of requirements and exceptions. Generally, a company must notify the consumer of any collection, sale or sharing of PI, and give the consumer the ability to opt-out from collection, sale or sharing of PI, and to request that their PI be deleted. |
| Federal Trade Commission Act Enforced by the Federal Trade Commission (FTC) | Deceptive or unfair trade practices. Does not apply to telecom. common carrier services. Other than telecom. service, FTC likely would have some jurisdiction over consumer-facing IoT service. | FTC enforcement of deceptive or unfair trade practices, as defined by the FTC on an ad hoc basis. Most important requirements: fully disclose practices for collection and use of personal information; and abide by published policy and advertisements. |
| Health Insurance Portability and Accountability Act (HIPAA) Enforced by the Office of Civil Rights (OCR) within the Department of Health and Human Services | “Protected health information” (PHI), which is defined broadly to include medical data, as well as anything that could identify a person, including a URL or IP address. Seek legal advice as to whether HIPAA applies to a particular health IoT service. | “Covered entity” and “business associate” must protect security and privacy of PHI and disclose only to the minimum extent necessary to carry out legitimate function. |
| Graham-Leach-Bliley Act(GLBA) Enforced by the Federal Trade Commission (FTC) and the Consumer Financial Protection Bureau (CFPB) | “Financial institutions,” including companies that offer financial products and services to a customer. Seek legal advice as to whether GLBA applies to a particular finance IoT service. | Financial institutions must publish privacy policy, notify customers of privacy policy, keep personal information secure and confidential, and allow customers to opt out of sharing with third parties. |
| Fair Credit Reporting Act (FCRA) Enforced by the FTC, CFPB, and private right of action. States enforce state FCR laws. | Providers and users of “consumer reports.” FTC warned mobile-application developers that if they provide consumer information to employers, they may be providing a “consumer report” and be subject to FCRA. | Must tell consumer what is in the file and whether information has been used against consumer, must obtain consent to use in employment screening, must correct or delete inaccurate, incomplete, unverifiable or outdated information. |
| Controlling the Assault of Non-Solicited Pornography and Marketing Act (CAN-SPAM) Enforced by the FTC. | Any email advertising a commercial product or service. IoT is subject to CAN-SPAM where the provider sends a commercial solicitation by email. | Must identify the email as an ad, identify the sender and provide physical address, allow recipient to opt out of receiving future emails. |
| Children’s Online Privacy Protection Act (COPPA) Primarily enforced by the FTC. Also, states and certain other federal agencies have authority to enforce COPPA. | Commercial websites and online services (includes mobile apps) that collect, use, disclose PI of children under age of 13, or operators of such sites or services with actual knowledge of PI of children. | Post clear privacy policy, give direct notice to parents, give parents access to children’s PI, allow parents have the PI deleted or otherwise not further used, keep children’s PI secure and confidential, use only for stated purpose. |
| Electronic Communications Privacy Act Enforced by U.S. Dept. of Justice | Wiretap Act protects IoT by prohibiting interception of electronic communication. | Prohibits interception of electronic communication. |
| Computer Fraud and Abuse Act Enforced by U.S. Dept. of Justice | Protects IoT by prohibiting unauthorized access to computers, distribution of malware. | Prohibits unauthorized access to computers, distribution of malware. |
| State data breach laws Enforced by each state’s Attorney GeneralAll 50 states have a data breach law | Definition of “personal information” or similar terms varies from state to state but usually includes name, address, social security number and other identifiers. | Requirements vary from state to state. Generally require notification of the state’s Attorney General or other public forum in the event of a data breach exceeding a certain size. |
| U.S./EU Privacy Shield Voluntary participation by U.S. companies doing business with or in the EU. Administered by Dept. of Commerce. Enforced by the FTC and Dept. of Transportation. The European Court struck down the Privacy Shield. The Biden Administration is negotiating with Europe. |
Broadly defines “personal data” and “personal information” as “data about an identified or identifiable individual that are within the scope of the Directive.” “Sensitive information” includes information on medical or health conditions. | Twenty three Privacy Shield principles, including providing notice, giving consumers choice, maintaining accountability for onward transfer, and maintaining security, and purpose limitation and data integrity. |
Develop a strategy to deal with California residents and the EU.
One of the broadest and most far reaching privacy laws is the California Consumer Privacy Act of 2018, which will apply to California residents. This law became effective January 1, 2020. The company will have to decide whether to treat California residents differently from those of the rest of the United States or to level set the company’s uniform practices to California’s requirements. Similarly, the EU has a broad privacy directive, and similar considerations apply there as well.
Provide an accurate privacy statement
In the privacy policy, state what steps the company will take to protect personal data and do not promise an end result such as “anonymized.”
Describe the company’s process, not an end result. For example, the company’s policy may be to disassociate a person’s name, address and telephone number from the sensor data generated by that person. If so, then describe the specific steps the company will take. Do not promise that the data will be anonymized or de-identified.
Sensor data are particularly easy to re-identify with the individual who generated the data, and a hacker or other third party may do so. For example, fitbit data can identify with good accuracy what a person’s gender is, whether the individual is tall or short, whether heavy or light, and can completely identify a person by the gait – how the person walks. Each person has a unique gait or way of walking. If something is known about the gait, the fitbit data can be re-identified with that person with high accuracy. A digital camera can be individually identified from the unique pattern that it displays on a digital image. Location information can be used to re-identify cellphone data with the person who carried the cellphone, just from knowledge of where the person was on a few separate occasions. Similarly, every road has a unique signature. Data from the accelerometer in a cell phone that was riding in an automobile driving down a particular road can be re-identified with that location if the data are available from that road from just one other car ride.
In the privacy policy, do not promise something that the company cannot deliver. The company can promise that it will disassociate or separate the sensor data from an individual’s name, address and telephone number. The company would be able to deliver on that promise. However, the company cannot guarantee that this data will, in fact, be “de-identified” or “anonymized.”
PROTECT THE ENTERPRISE NETWORK AGAINST IOT
An enterprise or a municipality should periodically conduct an audit of devices, protocols and networks that currently are connected to the corporate network.
In a prototypical scenario, the office manager buys a new refrigerator for the lunch room in one of the enterprise’s offices. The refrigerator happens to be a smart refrigerator and gets connected to the company’s wifi or wired network. But, a weak password (or no password) is used to put the refrigerator in operation. A hacker finds the refrigerator on SHODAN or via other means, breaks the weak password and obtains access to an otherwise secure corporate network. This vignette illustrates that the IoT dramatically increases attack surfaces for hackers and that large organizations often do not know what devices are connected to the network.
An enterprise or other large organization should periodically audit all the devices connected to the corporate network. The audit should utilize a variety of sources: employee survey, walk-through and visual inspection for connected devices, review of IT records of connected devices, and running searches in SHODAN, www.shodan.io, or similar sites. In the era of Bring Your Own Device, the audit and review of devices, passwords and security procedures becomes doubly important. The security vulnerability of each device should be assessed. Are there devices on the network that have not been authenticated? If so, how did they get there?
Conduct a risk assessment
The enterprise should consider the worst-case scenario for each device. Is a data breach the worst that could happen from a given device? If so, what data? And, how important is the data to the enterprise? Would compromise of the data cause reputational damage to the enterprise? Can a device, or a network that the device is connected to, cause physical harm? For example, could an automatic valve cause flooding to an inhabited area? In most instances, the damages from physical harm would far exceed those of a data breach. Identification of the worst-case risk for each device and network will help to inform the level of security needed for that network.
The enterprise or smart city should isolate the high value portion of its network from the IoT network or other, more exposed portion of the network.
This common network practice should be employed with an IoT system in view of the greater risk of compromise of the IoT system.
CONNECTIVITY
Connectivity options in the target geographic market could drive the type of IoT service
GSM 2G or 3G is the most widely deployed network technology worldwide. This is the only choice to reach certain parts of the planet. Depending on its characteristics, a particular IoT service might need to be adapted for a GSM 2G environment. If the target market is the United States, then there are more options for connectivity, and GSM 2G and 3G are being phased out.
Choice of licensed or unlicensed spectrum, and choice of carrier, will impact device design
If an IoT service will run over a carrier’s cellular service (Verizon Wireless, AT&T, T-Mobile, Sprint), the device must be certified by the carrier. Carrier certification is different from FCC certification, which is also required. Each carrier has its own specific requirements and individual tests for certifying devices. The carrier’s goal is to ensure that the device will be compatible with the carrier’s network, will not cause interference and will not use too many network resources.
If the IoT system will run only on unlicensed spectrum (e.g., over wifi), usually, no carrier certification is required because there is no carrier. Some carriers will include an unlicensed component for their otherwise licensed IoT offering. In this instance, the carrier would need to certify the device. Also, certain “non-carriers” such as SigFox, specialize in providing networks over unlicensed spectrum and will have their own requirements.
The use case ideally should inform the choice of connectivity
Different types of IoT services require different types of connectivity. For example, a smart grid that connects to residential electric meters may require only a small message size, intermittent messaging and can tolerate higher latency, but may also require transmission over long distances and the ability to penetrate buildings and reach meters located underground. By contrast, a medical device may require low latency in order to transmit time-sensitive information quickly and also require larger bandwidth for larger message size.
The Third Generation Partnership Project (3GPP) developed three technologies to address various IoT use cases, and released these standards in its Release 13. The three standards are called Extended Coverage GSM Internet of Things (EC-GSM-IoT), LTE for Machine Type Communications (LTE-M), and Narrowband Internet of Things (NB-IoT).
EC-GSM-IoT is designed to be backwards compatible with GSM networks which, as discussed above, are the most widely deployed worldwide, and can operate on as little as 600 kHz of bandwidth. LTE-M is based on LTE technology and is designed for LTE networks. LTE-M uses flexible system bandwidth of 1.4 MHz or more and is capable of serving higher end IoT applications requiring low latency and high throughput. LTE-M potentially could be the appropriate choice for medical devices. Finally, NB-IoT is a new radio access technology, developed largely in China (see above regarding Made in China), capable of operating in as little as 200 kHz, with channels as narrow as 3.75 kHz to support extreme coverage. NB-IoT potentially could fit in a guard band, thereby giving more choices as to possible spectrum assignment. NB-IoT over lower frequency-band spectrum potentially could be the appropriate choice for the smart grid discussed above, if security is assured. The point is not that a 3GPP standard must be selected for the IoT service, but to illustrate that there are different standards that are tailored for certain typical use cases.
Ideally, the decision would flow something like the following:
- Define the use case;
- Identify message size and timing, latency and throughput requirements mandated by the use case;
- Identify frequency band, bandwidth and standard that would be appropriate for the requisite latency and throughput; and
- Identify the IoT platform(s) and telecommunications carrier(s) that could provide the requisite frequency, bandwidth and standard. There are over 300 IoT platforms on the market and, at least in the United States, multiple connectivity options.
However, where there is only one carrier, as in some parts of the world, or where there are two carriers and both are using GSM 2G or 3G, then, as discussed above, the decision would have to flow backwards, and the bandwidth and standards would dictate the use case to a certain degree.
Strengthen the local area IoT gateway
Typically, the IoT gateway performs network functions of authentication, authorization, management, and provisioning. Where a rogue device attempts to gain access to the local area network, it will seek to disable, bypass or otherwise game the authentication and authorization functions of the gateway. The gateway should be strengthened and special attention should be paid to authentication and authorization.
Consider oneM2M standardization
According to McKinsey & Company, up to 40 per cent of the potential value of an IoT system can be unlocked by making it interoperable with other IoT systems.
oneM2M is group of trade associations that is developing a global standards platform that seeks to make IoT systems interoperable. According to Sand Hill:
“oneM2M provides of standards to provide horizontal platform architecture, enabling applications to connect securely, through standardized APIs, to data sources regardless of the underlying connectivity technology used. It incorporates the most commonly used industry protocols for IoT, such as MQTT, CoAP and HTTP. It offers device management functionality using device management standards from OMA and the Broadband Forum.”