IOT Security: Attack surface areas, Vulnerabilities & Considerations
Posted by Jai on January 5, 2017
In this post we will discuss the security aspects around connected devices solution. As typically goes in M2M information flow, from connected devices hardware till the information is available to end-user on dashboard or mobile gadget.
There are varieties of connected devices getting in market day by day. The size and processing power of each of such devices put extra emphasis on the security aspects around these devices. Here we will discuss the information flow in case of connected devices, how data flows from devices to end users of those devices. On top of that what are different attack surface areas, what common vulnerabilities those expose and what are the common ways to eliminate those threats for connected devices.
In the previous posts, we discussed about availability of different type of IOT platforms in market, typical characteristics of such a platform and the technical challenges in building your own IOT platform.
Below diagram explains the typical IOT data flow, possible vulnerabilities is such system and the considerations to build strong and secure security architecture model for such solution.
Information Flow Networks
In a typical IOT scenario, the device captures the data, either using local gateway or telecom the data is transmitted to cloud server for further processing. The processed data is further made available to end consumer or respective events are triggered or information shared further with ecosystem parties.
Commonly below different data flow networks are used in the system,
- Device Network
- Device Communication Network
- Telecom Network
- Hosting/Cloud environment Network
- IOT Platform
- Mobile applications/Gadgets network
- Data Privacy
The data flow diagram shows, how the data flows in such system. The data goes from device to view layer for display. In scenarios where remote control/command is allowed the information also flows from consumer to device typically the bi-directional communication.
Based on domain/sector different intermediary networks comes into play. For industrial solutions, local network of devices is generally used which communicate to device gateway using short range communication technologies and only gateway having internet data transmitting capability which can be over wifi or wired connections. For Autonomous vehicle telecom network comes into play which uses the telecom connection to transmit data to cloud servers.
We will go through each of the below network and we will analyse how the information flow takes place and the different Attack Surface Areas in each of the network. Most common vulnerabilities available in each of the network and the Considerations that needs to be taken into account to secure the data flow and create a robust security architecture for the entire IOT solution.
1. Device Network
This network area involves physical device and OS/Firmware and data stored on the device side. The possible attack areas are,
a) Device Physical Access
The possible vulnerabilities and considerations in each of the cases are,
i) Firmware Access
Vulnerability: Firmware extraction, access to firmware may lead to exposing hidden vulnerabilities in the firmware.
Consideration: The suggested approach is to use the firmware in encrypted form.
ii) Console Access
Vulnerability: User CLI/Admin CLI, Access to user console or admin console to receive data from device or to be able to do administrative tasks on device may expose to exploit data leak or compromise the device itself.
Consideration: Preferred approach would be not to expose the console access to devices for debugging purposes etc. If that is required, firmware needs to have access level at fine-grained level. Each function, configuration and access for each role needs to be analysed and tested accordingly.
Limit Debugging Access, for the live devices, limit the debugging access.
- For example, block debugging port on live devices on physical access.
- For debugging portal based on configurations etc. limit same to the authorised users only.
- Firmware should be locked down so serial access is not available.
- All GPIO, UART, and JTAG interfaces on the hardware should be disabled for production versions.
iii) Escalated Privilege
Vulnerability: Privilege escalation, physical access to device if it is not configured with granular level access may result in exposing functions not desired to be exposed.
Consideration: As already suggested, the firmware and access level needs to be designed at granular level and fully tested.
iv) Undesired State
Vulnerability: Reset to insecure state, possibility to reset device data either in memory or storage to undesired state in case of physical access.
Consideration: Possibility to reset any of the state, data, configuration, command or firmware at device side needs to be denied using access level and data encryption strategies.
v) Data Leak
Vulnerability: Removal of storage media, physical access to device, may lead to storage media access which can further expose firmware, control keys and local data information.
Consideration: Based on the domain and use case of the IOT device, additional security at hardware level can also be incorporated. Additional security at transistor level, processor level or additional encryption hardware etc. can also be used.
vi) Hardware-rooted trust chain
Vulnerability: Lack of Hardware level trust chain in software/code verification still make it available for attack.
Consideration: Many a times only software level verification can be overcome with malicious code. Providing hardware-rooted trust chain enables it to verify the software/code at hardware level and only authorised piece of code is allowed to execute.
vii) Timestamped Data
Vulnerability: Lack of proper and unsecured timestamp information from device may lead to wrong device status notification
Consideration: Most of the data from devices is timestamped to know the current and latest device status. Any tampering to the device clock may lead to notifying wrong status of device. Make sure the data is accurately timestamped, and clock synchronization procedures in place.
b) Device Operating System
Device firmware resides on the operating system. Any bugs or vulnerability in same may lead to compromised device.
i) Operating System
Vulnerability: Open access to operating system may lead to exposing hidden vulnerabilities.
Consideration: Make sure the device build with latest operating system versions which will ensure to fix the known issues. Regular bug fixing and patching support is required to patch the vulnerable systems. From both device and platform side, the support should be provided.
Lot of devices use open source embedded operating systems. Regular bugs alerting and fixes for same are available, make sure to keep an eye on same and provide patches as soon as possible and applicable.
ii) Device Booting
Vulnerability: Unsecured device boot may lead to execute malicious software on device side.
Consideration: Secure boot, integrity of the software should be verified on the device side. This ensure only verified piece of software is able to run on the device.
c) Device Firmware
The firmware part provides the features and function for a solution. Domain and sector specific data and logic processing is taken care by firmware. Below vulnerabilities and considerations are commonly possible,
Vulnerability: Hardcoded/Default credentials, there is a lot of IOT devices where default credentials are set on the device by the manufacturer and those are never reset by the consumer. Botnets can be used to exploit the default credentials leading the compromised device.
Consideration: Business process and technical solutions both needs to be incorporated to change/reset the credentials once such a device is in use to make sure additional security is adopted either by practice or by enforcement.
ii) Sensitive Information Leak
Vulnerability: Sensitive information, data or control keys disclosure may lead to compromising the device.
Consideration: Firmware should make sure to store the sensitive information in encrypted form and not accessible to attacker through physical or debugging level.
iii) Global Shared information
Vulnerability: The sensitive information like control keys or credentials should not be shared across devices.
Consideration: Separate Control Keys is preferred. Same control keys, either encryption keys or credentials should not be shared across devices. In case single device gets compromised same should not be allowed automatically. Separately control keys per device adds additional security umbrella for each device.
iv) Diagnostic Access
Vulnerability: Full diagnostic access to critical function may lead to disastrous after effects in case device compromised.
Consideration: Allowing device diagnostic access should be allowed carefully. From device side device should be allowed to do only minimum diagnostic activity which does not have critical ramifications if possible otherwise the access for diagnostics access should be controlled in right way.
v) Firmware Access
Vulnerability: Firmware Access, direct access to firmware at times leads to explore additional vulnerabilities.
Consideration: Encryption options for firmware puts additional security on hidden vulnerabilities.
vi) Firmware install
Vulnerability: Not proper firmware verification may lead to ability to install compromised firmware installation resulting in device compromise.
Consideration: Secured firmware installation guarantees that only verified firmware has been updated on the device. Proper encryption ways and firmware image verification is required.
Vulnerability: In case, one component gets compromised, design to avoid exposing critical function of solution using segmentation and logic separation of components.
Consideration: Physical/Logical separation, if possible the firmware parts should be designed in a way to have segmentation of processors and firmware images which have only pre defined interfaces to interact and proper authorised access between different components. Restricting the flow of commands and messages between different components allows to have much more fine-grained security model on device side.
Vulnerability: Lack of analysing vulnerability and lack of auditing ability may hide the vulnerability without any steps or data to debug same further.
Consideration: Proper event logs should be stored on device side for auditing purpose to debug late the root cause of the incident.
ix) Firmware Update Enforcement
Vulnerability: For critical fixes, lack of design or procedure for firmware update enforcement may leave device vulnerable.
Consideration: Most of times consumers don’t regularly upgrade firmware if there interference is required. The solution should be allowed to automatically update at least critical bug fixes without end consumer consent.
x) Third-Party Libs
Vulnerability: Any bugs in third-party libs may result in exploiting device.
Consideration: Mostly the bugs are patched for firmware in your control. Process and procedure to keep an eye on open issues and exploits in third-party libs used should be there. Use libraries that are actively maintained and supported.
xi) Firmware Image
Vulnerability: Unsecured or weak encryption at firmware image may expose firmware image.
Consideration: Secured and encrypted firmware image transfer is required.
d) Device Memory
i) Clear text credentials
Vulnerability: Clear text usernames/passwords may lead to credentials information leak and platform compromise resulting in device compromise.
Consideration: Different devices use different procedures for usernames to uniquely identify the device and also for platform connectivity. Most commonly it remains the device unique serial number printed on the device. The information should not be available in clear text and be encrypted and should not be easy to guess.
The credentials information to connect to platform should not be available in clear text passwords. It should be in encrypted form or control keys generated using algorithm stored encrypted in memory.
Third-party credentials, any communication with third-party systems should also be in encrypted form and not plain text.
ii) Encryption keys
Vulnerability: Access to encryption keys may lead to ability to decrypt information.
Consideration: Access to encryption keys can be used to decrypt information captured from device, over network or from cloud. The encryption keys used to encrypt local storage data or data transfer should not be directly available from memory.
iii) Data Leak:
Vulnerability: If not properly stored or encrypted the data leak from device side may expose critical device information.
Consideration: The possible options are to encrypt Local Storage of Sensitive Data. NAND or other memory/storage mediums should be protected with epoxy, ball sockets (so the memory cannot be removed and dumped), or other methods to prevent physical attack.
e) Product Life span
Vulnerability: The IOT products aren’t meant forever. Failing of any of such critical device without notification or intimation may lead to sever effect.
Consideration: Possibility to monitor and alert of life span and performance of IOT devices is also required.
f) Device configurations
Vulnerability: Access and Manipulation of device configuration may lead to undesired state of device.
Consideration: Lot of times, many of the device configurations are built-in the solution for testing and debugging perspective. It should be carefully exposed and properly analysed all the possible device configurations and proper access control should be in place for device configuration updates.
It should be properly tested and hardened based on combination of different device configurations and accordingly the default configurations should be tuned. By default encrypt configuration storage and communications.
g) Sim Misuse
Vulnerability: Lot of devices have embedded sim used, which expose misuse of the sim cards.
Consideration: Additional security from telecom providers is required to avoid sim misuse.
- Sim and device coupling on telecom side, so that it can not be used with any other device
- Sim management interfaces to lock/unlock or change sim states effectively if required in case of incidents.
2. Device Communication Network
Direct connectivity to internet at times is not required from device side. This is where device gateway to connect to internet comes into picture.
i) Device connectivity
Vulnerability: Unsecured device connectivity may lead to execute undesired state.
Consideration: Secure device connectivity is critical part of security aspects. How does an actuating device prove the instructions it is receives are valid?
- Only device initiates connection, can’t be done from platform side
- Proper authentication between device and platform to guarantee to establish the connection
- Proper command data encryption to guarantee only valid commands are processed
- Proper access level to guarantee only pre defined set of commands are allowed
ii) Connection Nature & Purpose
Vulnerability: Open access to devices to connect to gateway or directly with internet may expose it to attackers.
Consideration: Nature and purpose of connection through gateway or internet should be clearly worked out. Each device should explicitly be configured and set privileges based on what it is supposed to connect to.
iii) Inter device communication
Vulnerability: Open access between devices on network may allow attacker to pass undesired commands.
Consideration: Properly designed for message authentication scheme to avoid message spoofing.
iv) Network Ports
Vulnerability: Any unwanted exposure of ports or services may expose further vulnerabilities leading to compromise the device.
Consideration: Only relevant network ports should be exposed on the gateway and devices.
v) Network Isolation
Vulnerability: Not all devices be available on public network by default which may expose those to attackers.
Consideration: Ideally all relevant devices for a specific solution should be isolated from rest of the network. Smart Home network or industrial internal network should be isolated from public networks, and intermediary gateway solutions should be used for same.
vi) Network connectivity
Vulnerability: Security aspects and model should not be dependent on network connectivity.
Consideration: Devices should be allowed to communicate and work independently even if the network connection is not available. Device under no internet connectivity areas or slots should be able to function properly. The devices state should be in sync as soon as the connectivity is restored.
The devices should not rely on the network to provide security. Rather, the device’s security model should assume the network is compromised, and still maintain protection methods.
vii) Network Addressing
Vulnerability: Ability to scale and add new devices on internet protocol should be there.
Consideration: Devices should support latest networking protocol IPv6.
In this post, we haven’t covered the security aspects around different short range communication technologies used in different solution. Each of those technologies have there own pros and cons which can be taken in details in separate post.
3. Telecom network
i) Public Network
Vulnerability: Devices connecting to platform on open public network expose those to attacks.
Consideration: Private APN is preferred approach for device or gateway to interact with the platform. Only M2M device allowed on the private APN from telecom provider adds additional security layer.
ii) Public IP address
Vulnerability: Exposing devices to allocate public IP addresses makes those vulnerable to reach out from internet.
Consideration: If possible based on different sector, the preferred approach is to have private IP addresses for the devices so that these not available on public network.
iii) Data Encryption
Vulnerability: If devices data is not encrypted and it flows through telecom network, exposes data for leak.
Consideration: Based on each band 2G, 3G and 4G etc. different encryption levels are used by the telecom providers. To safe guard the data further make sure relevant and latest encryption levels are used by the telecom providers.
iv) Sim Management
Vulnerability: No access to sim management may lead to handle sim misuse incidents.
Consideration: Sim management portal allows to control sim status and track usage and association with devices for communication layer.
v) Man-in-the-middle (MITM) & Impersonation (spoofing)
Vulnerability: Data interception using Femto-cell to intercept device data and simulate as telecom antenna and intercept data may lead to data leak.
Consideration: Make sure the data is properly encrypted and attacker should not be able to spoof or replay the data also over the connection.
vi) Device-to-Device Communication
Vulnerability: Open device to device communication may lead to exploit other devices if one of the devices gets compromised.
Consideration: Device to device communication if not required by the solution, within telecom network internal communication between devices should be blocked.
vii) Platform Communication
Vulnerability: Unsecured data communication from telecom to platform server leaves it open on public internet, exposing for data interception.
Consideration: The communication between telecom network and platform systems should be secured.
- IP white listing can be used to send data only to platform servers.
- MPLS connection to directly send data to designated servers is also suggested.
- IPSEC tunnel can also be used to encrypt the site to site data between telecom and platform system.
i) Data interception
Vulnerability: Unencrypted Communication, in clear text over public internet is open for data interception.
Consideration: All the communication over public internet should be encrypted.
ii) Cryptographic integrity
Vulnerability: Weak encryption may lead to data interception over public internet.
Consideration: Well proven and strong encryption should be used for data transfer over public internet. Transport Layer Security (TLS) for secure communications to and from IOT controllers should be used.
5. Hosting/Cloud environment Network
Platform hosting environment security aspects also plays a big role in the whole IOT solution.
a) Physical Security
i) Physical Access
Vulnerability: Physical access to server may lead to data leak for devices and consumers.
Consideration: Make sure the ISO certifications etc. in place for the data centres for physical access to the systems hosting the solution.
b) Network Security
The network policies like Intrusion detection/prevention systems etc. should be in place as part of network security.
i) Network security model
Vulnerability: Open access to servers may expose system to attackers.
Consideration: Clearly defined security model for network security should be in place. Ability to configure firewall for connection and rules should be in place.
ii) DDOS Attacks
Vulnerability: Any denial of service attack may impact service availability.
Consideration: Ability to handle different denial of service for the IOT solution should be in place. The intrusion detection system should be in place and procedure for relevant steps should also in clearly stated.
iii) Open ports
Vulnerability: Unwanted open ports on servers may expose system to additional vulnerabilities.
Consideration: The system should open only relevant port to public for the solution. All other ports should be closed.
c) Hosting Platform Security
Vulnerability: In case cloud platform as a service is used, inherent security model should be in place for all services.
Consideration: For any IOT solution, different services are used for data processing and storage. Cloud platform security model comes into play and make sure relevant security models are in place to guarantee data sanity.
6. IOT Platform:
i) Device Connectivity
Vulnerability: Unsecured Device Management Portal may lead to multiple vulnerabilities exploitation.
Consideration: Device connectivity is the first component of the IOT solution from platform perspective. Make sure necessary security model from connectivity, testing, provisioning and management perspective is in place.
ii) Unauthenticated communication
Vulnerability: Unauthenticated communication between device and platform may lead to represent wrong device status.
Consideration: All communication between device and platform should be authenticated properly. Any unauthenticated communication may lead to unwanted firmware upgrade and notifying wrong device status.
- authenticity protections: Strong authentication mechanism should be in place.
- authentication update: Use credentials that can be updated from cloud server in case credentials got compromised.
iii) Decommissioning system
Vulnerability: Any single compromised device may lead to system compromise.
Consideration: Handling compromised device, Eventually is there to happen, is just matter of time.
- Debugging and Decommissioning, the system needs to be prepared to handle such incidents. Understanding the issues, proper monitoring and alerting of such incidents is required. Relevant auditing to debug and understand the problem and take relevant steps to mitigate the problem should be there. Procedure to handle the device lost access should be properly documented and detailed out. Provision on platform to handle such scenarios should be available.
- Reset Device, ability to reset a device from cloud side in case reuse of device. Clearing data and reset configurations should be allowed from platform side.
- Corruptible individual device identity and reputation
iv) Ecosystem Coordination
Vulnerability: Lack of proper coordination between different components of the IOT solution may leave whole system compromised if one component fails.
Consideration: In case the IOT solution is part of the whole ecosystem providing the feature and functionality to the end-user. In some cases, may be one of the component of the system may be compromised. Evaluating the complete system in terms of vulnerabilities and proper coronation and measure to fix such eventualities is required.
v) Device Metadata & Categorisation
Vulnerability: Lack of proper categorisation of severity of each component may lead to prioritization confusion in case of incidents.
Consideration: Ability to categorise each device or component in the solution based on their criticality in the solution allows to take relevant actions accordingly. Ability to manage device metadata allows domain/sector specific features and functions to be added to the device.
vi) Purpose & Access Level
Vulnerability: Lack of proper purpose of each device and access level for each end point or function may result in access right escalation without knowing it.
Consideration: Ability to configure and set what each device can do. ACL at device or group level allows to have much more fine-grained control over devices and filling up necessary security gaps.
- The design aspect around security model should be restrictive than permissive.
- Adding new device in the system should be secure enough. Fine grained authorised users only should be allowed to do so.
- Device Provisioning, ability for the platform to support device testing and provisioning should be secure enough. Automated systems are built for device registration and provisioning. Platform security model to have access level at each function of the process provides additional security level.
vii) Firmware Updates
Vulnerability: Unavailability of unsecured patching system may still leave the device vulnerable for known issues.
Consideration: To fix software bugs, new features or functions or improved performance would be required on regular basis. Platform needs to provide same.
viii) Encryption Options
Vulnerability: Unavailability of encryption option may leave the system unsecured for exploits.
Consideration: The communication should be encrypted between device and platform. Any of the options can be used for same,
- Per device authentication mechanism should be supported by platform
- Support for TLS/DTLS etc. is required.
- Ability to support X.509 certificates/PKI certificates and be able to revoke certificate in case device compromised.
ix) Cloud-to-Device Communication
Vulnerability: Unsecured, unmonitored or non alerted communication from cloud to device may result in compromised or undesired device status.
Consideration: The communication from cloud to device should be set in a secure manner.
- All the command or data transfer should be encrypted.
- Auditing trail information should be maintained.
- Device acknowledgement information should be available.
- Device confirmation on command etc. should be available on platform.
In most of the scenario the communication from cloud to device is in pull or subscribe model. There are scenarios where using messaging capability of telecom platform to push information from cloud to device is used. Secured communication for cloud to telecom to device is required in terms of encrypted and authenticated information only.
7. Mobile applications/Gadgets network
i) Data interception
Vulnerability: Unsecured communication between cloud and app is exposed for data interception.
Consideration: The communication between cloud and app should be secured and encrypted. API communication is commonly secured using HTTPS communication.
ii) Data Leak
Vulnerability: Unsecured local data storage may lead to data leak on mobile side.
Consideration: In case data stored locally on mobile application, it should be in encrypted form to avoid exposing device status and other information.
iii) Authentication Mechanism
Vulnerability: Lack of proper authentication mechanism may increase credentials leak.
Consideration: Vastly used authentication mechanism should be used while authenticating with the cloud side. Rather than transferring the credentials to cloud each time, token based mechanism are used. Maintaining token life span to small and refreshing same automatically adds additional security.
iv) Device Commands Verification
Vulnerability: Lack of verification of any command from mobile to cloud to device expose it to misuse.
Consideration: Any command which updates device configuration or a feature on the device, additional verification should be implemented for same. Certain verification can be used for same,
- App side verification in case of double confirmation, CAPTCHA to make sure of change can be used.
- Cloud side verification for any such change can be achieved using OTP.
8. Data Privacy
Data privacy is one of core component of IOT security aspects. Some of the critical requirements for data are,
- Data needs to be private
- Data should be trusted
- Safely arrival of device data to consumer
- Timely arrival of device data to consumer
- Data needs to be audited
It is very important that data is protected at each layer in the process from collection to servicing to consumer.
i) Device Level
The data collection happens at the device level.
Vulnerability: Unsecured device may lead to data (device information, domain data, configurations, control keys, credentials) leak at the device level.
Consideration: As shared above from device physical security, device operating system, device firmware to device memory all constitute to secure the data on device side.
ii) Data transmission
Data is transferred from device to server using device gateway or telecom and further from internet to cloud servers.
Vulnerability: Data interception may lead to data leak while transferring data from device to cloud.
Consideration: Data encryption over secured network should be used to avoid any data leak while data gets transmitted over the internet.
iii) Data Processing
Vulnerability: Unsecured data processing services may lead to data leak or data manipulation on the platform side.
Consideration: All the technical components and services used on the platform side should ensure to be used in secured way. Proper authentication and authorizations should be in place while reading or writing data on these data processing services.
iv) Data storage
Vulnerability: Unsecured data storage layer may lead to data leak and exposing sensitive information.
Consideration: All the data storage layers used in the IOT solution should be secured properly. The data storage layers can be in memory databases, RDBMS, NoSQL data layers or even Big Data Hadoop storage layers. Unauthenticated or Unauthorised access to these may cause data leak and exposing sensitive customer information.
iv) Data Servicing
Vulnerability: For consumer facing solutions, unsecured data servicing layer may lead to data leak and even device compromise.
Consideration: Once data is collected by device and processed by the platform, it is available for the end consumers applications or dashboard to service that information. The data servicing layer should be designed properly using authentication, authorisation and encryption layers.
v) Data Sharing
Vulnerability: Unmonitored and unsecured data sharing with third parties may lead to data leak.
Consideration: For complete ecosystem of an IOT solution, in general lot of third parties are involved with system integrator. Most of times such solution involves data sharing between these parties. Make sure to transfer and grant access to consumer data to all involved parties in a secured and encrypted way.
vi) Data Ownership
Vulnerability: Unclear ownership of data may lead to misuse of consumer data.
Consideration: Any IOT solution needs to clearly define the data ownership, data guardianship and in what forms data can be used further. End user needs to be made aware of what data device is capturing, what data is transmitted and any dependency in the device functioning. Both ownership and responsibility should be clearly stated for each component like device, data and network etc.
viii) Data Privacy Verification
Vulnerability: Lack of data privacy verification policy may lead to hidden data misuses.
Consideration: Any IOT solution needs to clearly define the data privacy verification policy on regular basis. Third party assessment are at times used to guarantee same on regular basis.
Security Principles and Model
Security is not one time effort, it is continuous process through the device life and daily operations of any IOT solution. Certain security principles which needs to keep in mind,
Security by Design
Security layer cross cutting around all layers. Security at design phase. Make sure to use or refer the existing security architectures for IOT solutions. Secured coding standards and penetration testing are prerequisite to have solid security architecture.
Incident Monitoring, Auditing & Management
Evidence capture capability and ability to debug the problem whenever happens.
It is just matter of time when it will happen, prepare the system for such scenarios. Regular vulnerability patching and management system is required. Ability to take compromised component or device out of system and fix same.
Information Sharing policy
Coordinated Efforts Policy: Identification, disclosure and fixing the vulnerability sometimes require coordinated effort. Be make sure to be part of the such body who keeps regular eye on such things and always stay in touch. There are domain specific guidance available from security aspects which needs to take into account. Sector specific approaches and solutions are also available which needs to be taken into account.
Conduct risk assessment for the devices, solution and any third-party components throughly regularly. Any gaps found in such exercise prompt both trust and confidence in the solution and also gives opportunity to fix and open gaps in security.
All actors in the complete IOT solutions plays an important role. Relevant level of security aspects needs to be taken into account by each actor.
From device firmware implementation, configuration setup, testing to set up the provisioning process the developers and testers play a big role from device security perspective.
Proper procedure should be in place from Manufacturer perspective to guarantee safe guarding the device default configuration, control keys and critical business logic etc.
Typically system integrators provide the IOT solution based on the devices and create entire ecosystem to solve the business problems. SI make sure the security aspects are well in place from each component in the eco system from device, network, cloud to platform etc.
For all the features allowed to end consumer, part of security of it reside with consumer also. Physical security and Credential security lies with the consumer and awareness to same helps.
Read out further about same,
The Open Web Application Security Project,
IOT Security Foundation,
IOT Security Wiki,
Securing the Internet of Things: A Proposed Framework,
Industrial Internet Consortium
Online Trust Alliance
Hope this adds to the security modelling and considerations while exploring or building any secured IOT solution.