IoT Security
- Information technology (IT)
- PCs, servers, routers, firewalls, and so on
- Bought as IT devices by enterprise IT people
- Primarily using wired connectivity
- Operational technology (OT)
- Machines/appliances with embedded IT built by non-IT companies, such as medical machinery, SCADA, process control, and kiosks
- Bought as appliances by enterprise OT people
- Primarily using wired connectivity
- Personal technology
- Smartphones, tablets, and eBook readers
- Bought as IT devices by consumers (employees)
- Exclusively using wireless connectivity and often multiple forms of wireless connectivity
- Sensor/actuator technology (IoT)
- Single-purpose devices bought by consumers, IT and OT people
- Exclusively using wireless connectivity, generally of a single form, as part of larger systems
What is an IoT System?

- Sensor
- Electrical component that detects events or changes in environment
- Actuator
- Any component of a machine responsible for moving or controlling a mechanism or system
- Software
- Compiled instructions that control the sensors and actuators
- Can sit on a sensor or actuator device, major part typically in a central component
- Network
- Channel through which the devices communicate
- The letter “I” in IoT represents the deployment of many of these systems over the Internet.
Sensor
- A sensor is an element that allows to monitor the environment and the context on which IoT systems operate.
- Sensors can measure defined physical, chemical or biological indicators, and on the digital level, they collect information about the network and applications:
- accelerometers
- temperature sensors
- pressure sensors
- light sensors
- acoustic sensors
Actuator
- An actuator is the entity responsible for moving or controlling a system or mechanism.
- An actuator operates in the reverse direction of a sensor: it takes an electrical input and turns it into physical action.
Architecture
Layered Architecture

Why is the Gateway Layer not an Unnecessary Expense?
- Number of devices is many times the number of clients of a Client-Server Architecture; Servers are not able to handle such a large number
- Energy Costs on devices would “kill” the devices
- Long-haul communication costs, especially as many devices are far away from any wired communication infrastructure
- Security: SSL/TLS required for communication, devices to not all have full- fledged cryptographic support
Edge Device Architecture

Gateway Architecture

Cloud Architecture (Generalized Open Stack Infrastructure)

Custom
Process
- System Architecture Model: Create a logical view of architecture that meets the systems goals for analysis purposes
- Threat Analysis: Perform the threat analysis
- Threat Disposition: Sort the threats into categories: accepted, transferred, mitigated and detected (unaddressed)
- Design Countermeasures: Incorporate threat mitigation and “rinse and repeat”
- Security Architecture Review: Review the completed security architecture to ensure all threats have been identified and all mitigations are adequate
- Approval
Design Principles
- Open Design Principle: The security architecture does not depend on any secret constructions, and any publishment of the design will not weaken the security of the system.
- Economy of Mechanism Principle: The simpler the better for security
- Fail-Safe Default Principle: Default deny condition to be applied instead of a default accept (default accept requires validation of every possible condition and scenario that might cause a denial)
- Separation of Privilege Principle: Two lines of defense for getting elevated privileges
- Complete Mediation Principle: Never ever cache access control decisions (time of check is time of use)
- Least Privilege Principle: Only give a program the minimum number of privileges it needs to run
- Least Common Mechanism Principle: Any system action should be performed as independently as possible from others users (i.e. sharing between processes and users should be minimized)
- Defense-in-Depth Principle: A layering of independent defenses makes a system significantly more robust against attacks
- Trust No One Principle: Establish your root of trust and follow that everything else is verified back to the root of trust.
- Secure the Weakest Link Principle: Also attackers have finite resources
Example
- Scenario:
- All the factory devices need to be configured, or reconfigured.
- Assume that we do this in late-1990s automation style:
- Manageability is performed via a software agent on the device that is being managed.
- A management system in the cloud sends commands and receives status from the managed device.
- A management agent is an attractive target for an attacker as it is very likely to have elevated privileges somewhere.
- Review:
- Separation of Privilege Principle:
- The management agent must compartmentalize elevated privileged actions into a separate process that does not have network accessibility.
- Fail-Safe Default Principle:
- The agent must not have an listening ports; incoming ports are default deny.
- Network connections must connect out from the device to the management system, preferably with a whitelist approach.
- Open Design Principle:
- All connections must be performed over a secure channel, using encryption, integrity and message delivery protections.
- Complete Mediation Principle:
- All management commands must be cryptographically verified as coming from a trusted source.
- Each command carries its own (cryptographic) authorization (independently verifiable).
- Least Common Mechanism Principle:
- The agent should not share resources, memory or services with other applications or services on the device.
- Defense-in-Depth Principle:
- The agent should be protected by a host firewall on the device.
- The agent should use technologies that reduce the likelihood of buffer overflows (e.g. control-flow execution, source code analysis)
- Separation of Privilege Principle:
References
- ITU-T IoT reference model: ITU-T Y.2060, “Overview of the Internet of things”, https://www.itu.int/rec/T-REC-Y.2060-201206-I
- AIOTI High Level Architecture functional model, https://aioti-space.org/wp-content/uploads/2017/03/AIOTI-WG3-IoT-High-Level-Architecture-Release_2_1.pdf
- FP7-ICT – IoT-A Architectural reference model, http://www.meet-iot.eu/deliverables-IOTA/D1_5.pdf
- NIST Network of Things (NoT), http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-183.pdf
- ISO/IEC CD 30141 Internet of Things Reference Architecture (IoT RA), https://www.w3.org/WoT/IG/wiki/images/9/9a/10N0536_CD_text_of_ISO_IEC_30141.pdf
- ISACA Conceptual IoT Architecture, https://www.isaca.org/Journal/archives/2017/Volume-3/Pages/default.aspx
- oneM2M Architecture Model, See http://www.onem2m.org/images/files/deliverables/Release2/TS-0001-%20Functional_Architecture-V2_10_0.pdf
- IEEE P2413 - Standard for an Architectural Framework, https://standards.ieee.org/develop/project/2413.html
Attack
Mirai Attack Explained
- Mirai malware run on smart devices on the ARC processor
- Exploit is using preconfigured user-pwd combination on the stripped down Linux on ARC… Sic!

- Attacker attacks many devices and installs new firmware that include DDoS attack on Dyn
- Attacker installs several CC servers that will command & control the DDoS attack on Dyn
- Each CC instructs its botnet of thousands of IoTs to send attack traffic to defined IP address of Dyn
- Dyn is flooded with starting with 300 MB/s at once (with a peak at 2GB/s)
- Its servers broke down (21.10.2016, 7:00 am EST)
Resolution of Mirai Attack
So simple and frustrating together:
- Action by end users:
- Change the default passwords for your devices
- Disable the network ports or interfaces that you do not use
- Manufacturers:
- All IoT devices should support updates including administrator credentials
- Make change of default user-password mandatory before installation in the Internet
- Patch IoT devices regularly
Economy
Cybercrime Actors
- Basic user, also known as script kiddie, unstructured hacker, hobbyist or even crackers.
- Someone who uses already established and potentially automated techniques to attack a system. This attacker has average access to hardware, software, and Internet connectivity, similar to what an individual can obtain through purchase with personal funds or by theft from an employer.
- Represents the lower bound of our profiles with all the dimensions set to the lowest value. Usually, attacks from this type of profile are believed to be very frequent. However, in the case of CPS might not be the case.
- Insider, which for example can be disgruntled employees or a social engineering victims.
- The employment position or the system privileges he owns (e.g., user, supervisor, administrator) are tightly related to the damage he can cause to the target. This type of attacker is of high importance for systems that are mainly protected through air-gaps between the system network and the outside world (often used in CPS).
- It is the only profile which has an advance knowledge of the system because it has physical access to it. He has a structured strategy to perform his attacks. His aim are physical properties of the system (e.g., damage the system to attack its availability. He acts alone, with low budgets but with dedicated tools.
- Hacktivist
- A portmanteau word which combines hacker and activist, as defined in. This class of attackers uses their hacking abilities to promote a political agenda. Often related to freedom of information (e.g., Anonymous).
- Similar to the cybercriminal but with a lower financial support but higher manpower support.
- Terrorist, also known as cyber-terrorist.
- Is a politically motivated attacker who uses computers and information technology in general to cause severe disruption or widespread fear.
- Low offensive skills and average resources. The attacks mainly targets the physical availability of the system and their stealthiness is not important.
- Cybercriminal, sometimes generally called black hat hacker or structured hacker.
- An attacker with an extensive security knowledge and skills. This category of attackers takes advantage of known vulnerabilities, and potentially has the knowledge and intention of finding new zero-day vulnerabilities. The cyber-criminals’ goals can range from blackmailing to espionage (industrial, foreign) or sabotage.
- Advanced knowledge of network attacks but low of physical layer attacks. Advanced tools and average financial support.
- Nation-State
- An attacker sponsored by a nation/state. Possibly belonging to (or that used to belong to) a state organization for carrying out offensive cyber operations. His targets usually are public infrastructure systems, mass transit, power or water systems, and general intelligence.
- On average the most powerful profile between the archetypes. High offensive skills and tools, high resources and determination. The stealthiness of the attacks is very important.
Cybercrime Activity
- Internet Fraud mainly through unauthorized use of information, e.g. credit card fraud, identity theft, sale of classified data
- Motives:
- Profit
- via theft or extortion
- Destabilization of an entity
- Profit
- Relevance for IoT:
- IoT places many more systems in and around us that contain sensitive data about us (health, credit cards, email addresses, phone numbers, user accounts).
- Some IoT devices can be used for surveillance on us, such acquiring data about us that we never placed in the IoT systems.
- Motives:
- Illicit Sales of e.g. drugs, export controlled items, pornography and services such as hacking, child labor, cryptocurrency mining, mostly via dark web
- Motives:
- Profit
- Relevance for IoT:
- IoT devices who are not well protected are misused as storage devices for illicit content
- IoT devices compute power may be used to run the websites to perform such sales
- Motives:
- Cyberextortion, e.g. DDoS, Ransomware
- Motives:
- Profit
- Relevance for IoT:
- Many IoT devices are privy to sensitive and valuable information, e.g. web cams, home security or devices used for toll gate payment or parking payment
- Also the sheer number of IoT devices makes them relevant for the attacker (availability)
- Motives:
- Cyberwarfare
- Motives:
- Destabilization of an entity
- Relevance for IoT:
- IoT devices are part of the critical infrastructure to improve operational efficiency (e.g. road systems, power grids, waste disposal systems)
- Motives:
- Cyberterrorism
- Motives:
- Destabilization of an entity
- Indirect profit via extortion
- Relevance for IoT:
- See cyberextortion or cyberware
- Motives:
Threat Analysis
- Areas to secure: Systems (Authentication, Access Control), Application, Communication/Network, Cloud, Device, Gateway, etc.
- Different Approaches:
- Threat Analysis (e.g. RFC 3552)
- Implement Security Recommendations (NIST, IETF, etc.)
- Learn From Attacks
- Follow Design Patterns
Threat Modeling
- Threat Modeling is the process of analysing in a structured way the vulnerabilities of a system from the point of view of a hypothetical attacker.
- It helps identifying risks, quantifying their likelihood and potential severity, and prioritising mechanisms for mitigation/prevention
- However, there are many different methodologies/taxonomies, including
- STRIDE (Microsoft)
- Open Threat Taxonomy
- ITU-T X.800
- ENISA
- OWASP IoT
- Others
Process

Assets

Threats

Impact

Weighted Impact

Likely Attack Scenarios

Example (Fitness Tracking System)
![]()
OWASP IoT Top 10
https://wiki.owasp.org/index.php/OWASP_Internet_of_Things_Project
- Weak, guessable, or hardcoded passwords
- Insecure network services
- Insecure ecosystem interfaces
- Lack of secure update mechanism
- Use of insecure or outdated components
- Insufficient privacy protection
- Insecure data transfer and storage
- Lack of device management
- Insecure default settings
- Lack of physical hardening
1. Weak, Guessable, or Hardcoded Passwords
Use of easily brute forced, publicly available, or unchangeable credentials, including backdoors in firmware or client software that grants unauthorized access to deployed systems.
2. Insecure Network Services
Unneeded or insecure network services running on the device itself, especially those exposed to the internet, that compromise the confidentiality, integrity/authenticity, or availability of information or allow unauthorized remote control.
3. Insecure Ecosystem Interfaces
Insecure web, backend API, cloud, or mobile interfaces in the ecosystem outside of the device that allows compromise of the device or its related components. Common issues include a lack of authentication/authorization, lacking or weak encryption, and a lack of input and output filtering.
4. Lack of Secure Update Mechanism
Lack of ability to securely update the device. This includes lack of firmware validation on device, lack of secure delivery (un-encrypted in transit), lack of anti-rollback mechanisms, and lack of notifications of security changes due to updates.
5. Use of Insecure or Outdated Components
Use of deprecated or insecure software components/libraries that could allow the device to be compromised. This includes insecure customization of operating system platforms, and the use of third-party software or hardware components from a compromised supply chain.
6. Insufficient Privacy Protection
User’s personal information stored on the device or in the ecosystem that is used insecurely, improperly, or without permission.
7. Insecure Data Transfer and Storage
Lack of encryption or access control of sensitive data anywhere within the ecosystem, including at rest, in transit, or during processing.
8. Lack of Device Management
Lack of security support on devices deployed in production, including asset management, update management, secure decommissioning, systems monitoring, and response capabilities.
9. Insecure Default Settings
Devices or systems shipped with insecure default settings or lack the ability to make the system more secure by restricting operators from modifying configurations.
10. Lack of Physical Hardening
Lack of physical hardening measures, allowing potential attackers to gain sensitive information that can help in a future remote attack or take local control of the device.
Attack Scenarios
Scenario 1: Sensor Tampering
Modifying the values read by sensors or their threshold values and settings
Scenario 2: Man-In-the-Middle
Modifying the values intercepted from the man in the middle
Scenario 3: Unauthorized Access
Modifying or sabotaging normal settings of the device
Secure “IoT cLoud”
Challenges
- Central Data Management and Analytics
- Authentication of all IoT devices must scale
- Data incoming to the cloud should not look like a DDoS attack
- End-to-End-Integrity of data must be ensured
- Device Provisioning, registration, authentication and authorization
- Robustness of devices: Cloud services must only communicate with legitimate devices
- Data input by rogue devices must be prevented
- IoT Device Management and Updates
- IoT devices’ lifetime is 10 years and above: Software and Firmware must be updatable (securely) after deployment
- Encrypted Communication
- Every communication channel (from sensors or actuators to the gateway and on to the cloud) must be considered for encryption
Authentication
The ability to authenticate an IoT device depends on the ability:
- To correctly identify the IoT device (“need to trust the device is the device”)
- To manage the necessary key material for authentication securely

Device Provisioning

- Device manufacturer adds the device registration information to the enrollment list.
- Device contacts the DPS endpoint set at the factory. The device passes the identifying information to DPS to prove its identity.
- DPS validates the identity of the device by validating the registration ID and key against the enrollment list entry using either a nonce challenge (TPM) or standard X.509 verification.
- DPS registers the device with an IoT hub and populates the device’s desired (twin) state.
- The IoT hub returns device ID information to DPS.
- DPS returns the IoT hub connection information to the device. The device can now start sending data directly to the IoT hub.
- The device connects to IoT hub.
- The device gets the desired state from its device twin in IoT hub.
Secure Connections in IoT
Protection of the Little Devices
- The small devices are the most difficult to protect as they do not have much resources.
- Biggest rule to follow: protect them by the gateways and other network infrastructure
- Rules on the device:
- Turn off all unnecessary ports: SNMP and telnet forbidden. Management over https or Message Queuing Telemetry Transport (MQTT) over TLS.
- Run the network code under a normal user account instead of a privileged one: network software listening to to the network port is exposed, and should never ever be run as root.
- Perform fuzz testing on all open ports.
- Perform static code analysis.
- Reboot often, use a secure boot mechanism.
- Update securely (everything), e.g. by digitally signing and verifying updates
- Authenticate all communication before sending payload
- Gather very small devices behind a firewall
Protection of the Bigger Devices
- Rules on the device:
- Run a firewall to protect the device, run a firewall at the gateway, and at the cloud interface
- Filter incoming traffic to find known attacks. Combine with a host IDS.
- Maintain a (secured) whitelist of trusted endpoint.
- Always use a secure channel (confidentiality, integrity, authenticity)
- Use the hardware protection available on the device
Overview on Security of Protocols

Secure Patching
- Two steps necessary:
- Consider it in operations (vs. “fire and forget”)
- Prepare the device for device management at the start!
- Preparation means that you enable the device with cryptographic keys to receive and securely process the updates.
- Preparation also means that you test the updates before provisioning them to the IoT devices
Privacy in IoT
Example

Privacy Preservation in Data Mining
Preserving in data mining means hiding output knowledge of data mining by using several methods when this output data is valuable and private.
Mainly two techniques are used for this:
- Input privacy in which data is manipulated by using different techniques
- Output privacy in which data is altered in order to hide the rules.
Privacy Controls for IoT
- Access Controls to personal identifying information (PII) data:
- Mandatory logins
- Restrictive operating system permissions on files
- Password “security”
- 2FA for privileged accounts
- Account “maintenance” (old/unused accounts)
- Data Anonymization
- Delete the data from the data set
- Mask
- Generalize
- Tokenize
- Differential Privacy: introduce a certain amount of error in data set
- Data Retention and Deletion Policy
- Privacy Regulation
- GDPR (General Data Protection Regulation)
- Datenschutz-Gesetz
- California Consumer Privacy Act (2018)
Relevant Note(s):