IoT Security Guideline 1 - overview

challenges created by the IoT

1. Availability: Ensuring constant connectivity between Endpoints and their respective services
2. Identity: Authenticating Endpoints, services, and the customer or end-user operating the Endpoint
3. Privacy: Reducing the potential for harm to individual end-users
4. Security: Ensuring that system integrity can be verified, tracked, and monitored

the Challenges of Availability:

1. How can Low Power Wide Area Networks (LPWAN) be implemented with a similar level of security to modern cellular systems?
2. How can multiple mobile operators support the same level of security as new IoT Endpoints migrate across network boundaries?
3. How can network trust be forwarded to capillary Endpoints that rely on Gateway Endpoints for communication?
4. How can the power constraints of Lightweight Endpoints be addressed in secure communications environments?

Solutions: In the future we will also see the integration of Low-Power Wire-Area (LPWA) wireless technology into the cellular communications space covering the needs of IoT. Mobile operators will be integrating LPWA protocols and technologies into their offerings to provide services and solutions to businesses in the near future.

ps:Low-Power Wide-Area Network (LPWAN) or Low-Power Network (LPN) is a type of wireless telecommunication network designed to allow long range communications at a low bit rate among things (connected objects), such as sensors operated on a battery.

the Challenges of Identity:

1.Can the user operating the Endpoint be strongly associated with the Endpoint』s identity?

2.How can services and peers verify the identity of the end-user by verifying the identity of the Endpoint?

3.Will Endpoint security technology be capable of securely authenticating peers and services?

4. Can rogue services and peers impersonate authorized services and peers?

5.How is the identity of a device secured from tampering or manipulation?

Solutions: While the mobile industry is typically associated with the removable SIM card, the GSMA has created a SIM based solution called the 『Embedded SIM Remote Provisioning Architecture.

Identity technologies, such as the Embedded SIM, are designed as trust anchors that integrate security by default. They are manufactured to withstand attacks such as:

• Glitching
• Side-channel analysis
• Passive data interception
• Physical tampering
• Identity theft

They won』t simply be used to verify the security of the network, they will also be capable of securing application communications and the application itself, similar to traditional computing trust anchors.

the Challenges of Privacy:

1. Is the identity of an Endpoint exposed to unauthorized users?
2. Can unique Endpoint or IoT Service identifiers allow an end-user or Endpoint to be physically monitored or tracked?
3. Is confidentiality and integrity employed with sufficient security to ensure that patterns in the resultant cipher-text cannot be observed?
4. How does the product or service store or handle user-specific Personally Identifiable Information (PII)?

Along with the capabilities of the SIM, the mobile industry has developed resilient protocols, processes, and monitoring systems to enable security and reduce the potential for fraud and other malicious activities. For example, 3G and 4G technologies use mutual authentication to verify the identity of the Endpoint and the network. This process helps ensure that adversaries are unable to intercept communications.

Furthermore, network technology can be secured through the use of the SIM and technologies such as GBA 8 or EAP-SIM 9. By using these technologies, the SIM can be provisioned with a session security key that can be used in communications with application network peers over well-known protocols. This process can diminish the potential for adversaries to manipulate the application protocol to compromise the devices or service. Thus, it is possible to secure both the network and the application with this model.

IoT Models

risk accessments

• What assets (digital or physical) need to be protected?
• What groups of people (tangible or intangible) are potential threat actors?
• What is a threat to the organization?
• What is a vulnerability?
• What would the result be if a protected asset were compromised?
• What is the probability of the asset being compromised?
• What would the result be when put in context with different groups of attackers?
• What is the value of the asset to the organization and its partners?
• What is the safety impact of the asset being compromised?
• What can be done to remediate or mitigate the potential for vulnerability?
• How can new or evolving gaps in security be monitored?
• What risks cannot be resolved and what do they mean to the organization?
• What budget should be applied toward incident response, monitoring, and risk remediation?

privacy consideration

Where data relates to specific individuals, this complex, 『connected』 ecosystem may raise concerns from the consumer over:

• Who is collecting, sharing and using individuals』 data?
• What specific data is being acquired?
• Where is the data being acquired from (what technologies or interfaces)?
• When is the data being collected?
• Why is the data being collected from the user?
• How the privacy (not just the security) of individuals』 information is ensured?
• Are individuals in control over how their data is shared and how companies will use it?

Recommended Privacy Considerations for IoT Service providers

Evaluation and Review

• Evaluate the technical model
• Review the current product or service』s Security Model
• Review and evaluate Recommendations Implementation and Review
• Ongoing Lifecycle

Evaluating the technical model

The first and most important step in the process is understanding the organization』s own IoT product or service. In order to perform a security review and risk assessment, the team should be familiarized with each component used in the organization』s solution, how components interact, and how the components interact with their environment.

1. Start by making a document describing each component used in the system.
2. Identify how the component is sourced, how it is used, what privilege level it requires, and how it is integrated into the overall solution.
3. Map each component to the technologies described in the Model section of each Endpoint Ecosystem and Service Ecosystem guidelines documents.

• What components are used to build the product or service?
• What inputs and outputs are applicable to the given component?
• What security controls are already applied to these inputs and outputs?
• What privilege level is applied to the component?
• Who in the organization is responsible for implementing the component?
• Who in the organization is responsible for monitoring and managing the component?
• What process is in place to remediate risks observed in the component?

Review the Current Security Model

what technologies are most vulnerable, or most desirable to the Attacker, in the product or service being developed.

Review and Evaluate Recommendations

This section will not only provide methodologies for implementing recommendations, but will provide insight into the challenges involved in implementing the particular recommendation.

Implementation and Review

By this stage, clear Security Tasks have been outlined and the business will have a better comprehension of their security vulnerabilities, their value and their risk. The business shall now create a clear architectural model for each Component being adjusted, and use the Risk Assessment process chosen by the organization to develop a threat model of each Component, incorporating the Recommendations and Risks that are appropriate for each Component and Security Task. When the architectural model is completed, the organization can begin implementing each Recommendation in order to fulfil the Security Tasks.

Ongoing Lifecycle

Example based upon Automotive Tracking System

Evaluating the Technical Model

The engineering team creates a document that itemizes the technologies used in the solution in order to organize personnel, assign Security Tasks, and track progress. For the sake of simplicity, our automotive tracking system will have the following capabilities:

Endpoint Ecosystem:

• A simple Graphic User Interface (GUI) that allows a user to:
• Log in with a username and password
• Disable tracking
• Enable tracking
• Identify and visualize current location
• A cellular module for connecting to back-end services
• A SIM card for the cellular module
• A Lithium-Polymer battery for back-up power
• A Central Processing Unit (CPU)
• An embedded application in Non-Volatile RAM
• RAM
• EEPROM

Service Ecosystem:

• Cellular Data connectivity
• Secure Private APN
• Service Access Point
• Cellular Modem OTA management service
• SIM Card OTA management service

The Service and Network model is a standard mobile- enabled IoT service.

Review the Security Model

In our example solution, there are only two threat surfaces that are relevant to an attack:

• The cellular network
• A localised attack on the vehicle

Since there is no local network connection, only a mobile network connection, an Attacker would have to either compromise the cellular network connection, enter the communications channel from the private APN or enter via the Service Access Point, cellular modem OTA management server or SIM card OTA management server.

Physical attacks are the only other way to compromise the device of which there are multiple entry points as shown in the above diagram, so in the case of this IoT service the Endpoint should be heavily focused on.

Review and Assign Security Tasks

Each team should assign a specific person to each Component of the solution that needs evaluation. This should be evaluated not only from the high level perspective (Endpoint, Network, and Service) but from the subcomponent perspective. This means that the CPU should be assigned a worker, the operating system, the network service, and so forth.

Once each Component is assigned to an owner, the process can begin. This means, at this stage, the team understands:

• How the technology is composed
• What technologies affect security
• What engineering stakeholders own the given technology

Review Recommendations

the group can engage in valuable discussion on what remediation or mitigation strategies will have the most balance from a cost effectiveness, longevity, and management perspective.

Once the recommendations are reviewed, the Component owners can determine whether a recommendation has already been applied, or mark a recommendation pending. This will allow the group to have a discussion regarding the applicability of a recommendation prior to its deployment. This is a better strategy to follow, as some recommendations may have side effects that impact the fulfilment of other recommendations, or existing controls.

In this example, the team would have determined that:

• An application trust base should be used
• An Organizational Root of Trust should be defined
• Device personalization should be implemented
• Tamper resistant casing should be implemented
• Endpoint password management should be enforced
• Endpoint communications security should be enforced
• Cryptographically signed images should be implemented
• Privacy management should be implemented
• Device power alerts should be integrated

Review Component Risk

the Components section should be evaluated to identify the various risks involved in implementing or integrating a particular Component into the product or service. This section can generally be reviewed only by the Component owner to minimize work. After reviewing Recommendations and the Component risk section, the following security gaps were identified:

• Secrets were stored unprotected in EEPROM
• Secrets were not processed in internal RAM
• User interface must protect passwords
• User privacy should be outlined for the user

Implementation and Review

The team re-implements components, where necessary, and adds security controls, where necessary.

In this particular instance, the team has identified that provisioning an SIM card that contains application-capable trust anchor technology.

• They will resolve their need for a trust anchor by using the existing SIM card.
• This also resolves personalization, as each SIM can be personalized in the field using standard GSMA technology.
• SIM technology can also help provision communication * * * security keys over the air, resolving the need to implement communications authentication and privacy.
• The SIM company-specific zone can be programmed with a trusted root base that enables the business to authenticate peers using a certificate chain. This resolves Organizational Root of Trust and peer authentication requirements.

Ongoing Lifecycle Now that the team has achieved an approved configuration, they are ready to deploy their technology. However, security does not stop here. The team negotiates a methodology for monitoring Endpoints for security anomalies, and a methodology for identifying whether the technology they are using contains newly discovered security gaps. The team will plan how each incident or gap is identified, remediated, and recovered from. This will ensure that, over time, the evolving technological and security landscape will not take the organization by surprise.

Example – Wearable Heart Rate Monitor

The Endpoint Overview

composition:an light photo sensor and a Bluetooth Low Energy (BLE) transceiver enabled microcontroller. The sensor is used to capture pulse rate data, while the microcontroller analyses the data emitting from the sensor and chooses what data to send over the built-in BLE transceiver. A coin cell battery is used in this example to transmit data from the HRM to another device, such as a smart-phone or tablet.

The Service Overview

The Security Model

From an endpoint perspective, the team learned the following issues are of concern:

• Cloning
• Endpoint impersonation
• Service impersonation
• Ensuring privacy

In this example model, the endpoint would not require a substantial change. Since the endpoint has very little functionality, minimal security can be employed on the endpoint for both application security and communication. Since the endpoint application is flashed on a single device, as long as the device firmware is locked, there is no real threat of attack against the endpoint within the given use case. However, since privacy is an issue, the organization should employ at least a Personalized PSK version of a Trusted Computing Base (TCB). This would ensure that encryption tokens were unique to each endpoint, so that one compromised endpoint cannot compromise all endpoints. If the personalized (unique) keys were encoded into the locked microcontroller, it would be reasonable to believe that this use case were adequately secured from the threat of cloning, impersonation, and privacy issues.

The trusted computing base (TCB) of a computer system is the set of all hardware, firmware, and/or software components that are critical to its security, in the sense that bugs or vulnerabilities occurring inside the TCB might jeopardize the security properties of the entire system.

From a service perspective, the team decided the following issues are of concern:

• Cloning
• Hacked services
• Identifying anomalous endpoint behaviour
• Limiting compromise
• Reducing data loss
• Reducing exploitation
• Managing user privacy
• Improving availability

The server infrastructure, however, requires a significant amount of changes.

• There is no security front-end diminishing the effects of a Denial of Service attack
• There are no ingress or egress controls limiting the flow of traffic to or from services
• There is no separation of duties between service tiers
• There is no separate secured database containing Personalized PSK tokens
• No adequate security measures are implemented in the service operating system
• There are no metrics taken to evaluate anomalous endpoint behaviour

Each class of service has been broken into separate tiers to help secure and scale the technology easily in the event that demand spikes.

• Two additional tiers were added, a database tier and an authentication tier, to separate critical systems from services that directly interface with the outside world.
• A security front-end was implemented to help guard the internal network from multiple types of attacks, including DoS and DDoS attacks that reduce the overall availability of the system.
• Finally, an administrative model was defined to allow management secure access to the production environment. * * One component not depicted in the above diagram is the presence of an analytics model that observes when endpoint behaviour may be indicative of a compromise, or a flaw in the firmware or hardware design.

With the service ecosystem ramped up, there is far less of a threat to both users and the business. Cloning and impersonation is no longer a threat. Privacy is ensured by granting each endpoint unique cryptographic tokens. Systems that contain critical information are separated and secured from more heavily abused public-facing systems. This model, while slightly more complex, reduces the overall risk of the production environment.

Example – Personal Drone

Thus, a robust back-end service is required to ensure a high degree of service availability for each drone that might connect to the system. Availability is also necessary for the high bursts of network traffic required to transmit videos and high-resolution images over a cellular link. There must also be a web interface that allows the operator to view media uploads from a web browser.

From an endpoint perspective, the team learned the following issues are of concern:

• Endpoint identity
• Endpoint impersonation
• Trust anchor attacks
• Software and firmware tampering
• Secure remote management
• Detecting compromised endpoints
• Service impersonation
• Ensuring privacy

From a service perspective, the team decided the following issues are of concern:

• Managing user privacy
• Improving availability

The endpoint infrastructure, however, requires a significant amount of changes.

• The bootloader is not properly validating the application prior to executing the operating system kernel, leading to a risk of tampering
• There is no TCB used to manage the security of the application or communications
• Because there is no properly implemented TCB or trust anchor, endpoint impersonation is a problem, which may lead to data leakage
• Without a well implemented TCB, the endpoint can』t properly authenticate services
• Without a well implemented TCB, the endpoint can』t properly authenticate the operator over the proprietary radio interface
• The engineers have relied on the security of LTE to ensure the communications channel can』t be compromised, but has not considered the threat of endpoint impersonation or Femtocell repurposing, both of which bypass the security of LTE to compromise weak service security

For the existing drone system already in production, the engineering team issues a firmware update that implements a Personalized Pubkey security model. The firmware update improves the bootloader as well to bake security into the core architecture. Since a Personalized Pubkey model was used, anyone attempting to abuse the initial lack of security in the endpoint to attempt to impersonate another user』s endpoint would fail.

Example – Vehicle Sensor Network

three high- level components involved are:

• A telematics uplink unit that manages the sensor network, makes complex decisions on behalf of the driver, and maintains a connection to the back-end system
• A vehicle-to-vehicle (V2V) system that detects and reacts to V2V events
• A general sensor network that provides metrics to the telematics uplink unit

From an endpoint perspective, the team learned the following issues are of concern:

• Endpoint impersonation
• Service or Peer impersonation
• Side-channel attacks
• Detecting compromised endpoints
• Ensuring safety at the risk of security

From a service perspective, the team decided the following issues are of concern:

• Identifying anomalous endpoint behaviour
• Managing user privacy

Key:vehicle communications network One concern that engineers have in this type of environment is the risk that a computer will make critical decisions using data that is not properly authenticated.

Another critical issue in these environments is detecting compromised endpoints. For example, how can the environment recognize whether a simple sensor, such as a Tire Pressure Monitor (TPM) has been compromised? If the computer makes a critical decision based on the TPM signalling a tire has blown, a safety issue may arise. As a result, the behaviour of devices, and their trustworthiness, must be reassessed at every boot-up phase. All devices should have tamper resistance, and must be able to notify the network if there is a compromise. Inversely, there should be a way that other devices in the sensor network can evaluate the trustworthiness of peers in the network.

conclusion：a single flawed endpoint can cause the entire system to become vulnerable.

推薦閱讀：