A typical security analysis of IoT solution encompasses detailed description of the security and privacy assets (i.e. what needs to be protected? What is its value?), stakeholders (their roles & rights), possible threat scenarios (attack vectors & inherent vulnerabilities) followed by standard security countermeasures. Among others one structured method to do so is Microsoft’s STRIDE methodology. It helps to identify the potential security threats of a system by providing categories of threats. STRIDE is an abbreviation for six categories of threats: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service & Elevation of privileges. They are briefly explained in the following table.

Reference: book from Adam Shostack

Some helpful references for the brainstorming process of “What can go wrong at this entity of the system?” are:

• OWASP Internet of Things Security Verification Standard
• OWASP Top 10 IoT risks of 2019
• OWASP Top 10 IoT risks of 2018

For a more detailed explanation on how to do the security analysis and also how to answer the second question of “What can I do about the identified threats?” you can download this document. 

It can be challenging for non-security professionals to answer the first question regarding potential security loopholes in the system. Especially in an initial security analysis when big design decisions are still open.

Also it is difficult if not impossible to prepare for all kinds of threats. Yet one is much better off the more threats have been identified in advance and have been thought through on how to deal with them. 

Feedback from IoF use cases shows that it can initially be a bit overwhelming to perform a structured security analysis, when never having done it before. There are many ifs and buts which could be hypothetical. However, at the same time the feedback shows that after having worked through the analysis - which’s structure provides guidance in the process - it can still reveal quite some security issues people haven’t thought about before and finally are happy to have discovered them.

• IoT solutions developers (system architects & Engineers)
• Security architects
• Integrators
• Vendors

IoT ecosystems are very heterogenous in their nature. Security issues can arise in a multitude of positions within them, ranging from small IoT devices all the way up the chain towards the connected cloud infrastructure. It is important to understand the data path from source to sink. Hence an architecture overview forms the basis of a structured security analysis like Microsoft’s STRIDE methodology. In the early phases of the project this can as well be a coarse overview, which can be detailed at later stages. For instance having IoT sensor nodes, communicating via a gateway with a cloud server.

Based on the physical architecture diagram a dataflow model diagram is derived. In this diagram all entities are assigned to four different categories: Processes (Software or hardware that does any kind of data processing), external entities (persons, organizations, external services that interface with the system), storage (databases, local memory, cloud storages) and dataflows (which connect all of the three beforementioned entities).

Well implemented security should possess the following properties:

Unobtrusive: Security should be designed and integrated in such a way that it doesn’t affect the performance and intended functionality of the IoT solution.
State of the art: Security should comply to the latest standards recommended by national or international security standardization organizations (NIST, BSI, CEN, OWASP, ISO 62443)

Upgradable: It should be modular such that newer versions of security can be integrated into the system with less effort.
Decentralized: Security should not be developed in one central module but should be distributed amongst all components of the developed IoT solution.
Layered: Security should have multiple layers or “walls of defense” such that if one is compromised the whole system is still not vulnerable for hackers.
Third-party reviewed: Don’t invent your own security solution and rather rely on proven and tested standard protocols and solutions recommended by national or international security standardization organizations.
Adding Value: A secure solution develops trust with customers. Although value-add is not always directly visible it prevents “security by pain” scenarios the IoT solution.

It makes sense to implement an Information Security Management System which addresses people, processes and technology in a single, cohesive package, as illustrated in the previous figure. If you have got the technology in place but you do not have proper processes and have not trained your staff properly then all your efforts to achieve a more secure system go in vain.

Below listed are the general best practices for IoT product development. Some of these ‘best practices’ can be used to reduce the danger of some of the threats.

Process:

• In case of not anonymous data, a regulation on data management is implemented to guarantee the integrity and the safety of these data
• ‘Security through obscurity’ is not a good security doctrine
• From the beginning of the project, realize and keep updated a risk analysis of the product and define threat’s mitigations (STRIDE analysis for IoT Use Cases)
• Choose and apply a cybersecurity standard
• The product has a secure process of software update
• No network protocol or encryption algorithm with known weakness is used (md5, sha1…)
• The source code is written according to coding rules (OWASP/CCERT/MISRA/internal…)
• The source code is verified by a third software (static and dynamic source code analysis tool) and should cover at least simple fault injection, simple logic attacks and side channel attacks
• All functionalities associated to cybersecurity are unitary tested
• The security bulletins of all third-party software and services used for the realization of the software are followed during the design and the product’s life to react to the identification of a weakness (software provider website, specialized website: http://cve.mitre.org, …)
• The firmware is verified by a series of antivirus before it’s sent in production
• Every version of the product is validated by a Pen Test and/or fuzzing attack (authorized simulated attack)
• People: 
• Name a security manager who defines and guarantees best practice of design as well as the preservation of the product’s security
• Do not design your own security mitigation technology, use standard & available ones. If you need a custom solution, ask experts. 
• The people having access to the keys of encryption and to the firmware are clearly identified during the production
• Technologies:
• All network protocols use an encryption (HTTPS, TLS, FTPS, SSH) and are protected against replay attacks (use of session keys)
• The secret keys used are unique for each product and stored on a protected memory.
• Strong password policies are enforced
• Activate a secure start/initialization of the product by secure booting/initialization (load of a trusted encrypted image of the software)
• Once the final software is ready to be released, all debug interfaces (i.e. JTAG etc.), all software debug functions are disabled or removed and the security fuses are blown to lock configuration.
• Some compilers embed security feature like the stack protection on ARM compiler, use these features after a careful read of the document
• The different data stores embed integrity and reverse engineering proof mechanism
• The unused network interfaces (bus + port) and unused services are deactivated
• On the final product’s electronic board, the test points have no significant names
• The elements used for the security functionalities cannot be replaced during the final assembly
• The product can execute only numerically signed software (trusted source)
• During his run time, the software verifies periodically its integrity
• A secure element is used to store the encryption keys
• The software uses physical devices to encrypt/decrypt/hash data (easy to use and more difficult to tamper than software functions)
• A unique and not modifiable identifier is used to assure the identification of the product
• If an operating system is used, mechanisms of memory insulation and least privilege of execution are used (trust boundary between the different soft-ware’s layers, ‘onion design’)
• If an operating system is used, with possibility to use privileged accounts, these accounts are only usable by the firmware, without possible remote access
• The default user password must be changed at the first use of the product
• If passwords must be stored, store the crypto hash values instead (passwords encryption) then compare hash values to control 
• In case of failure of the password seizure, a delay must be respected before the next try (brute-force attack resistance)
• Data type, format, length, and range checks are enforced
• In general, developers following security by design principles should ensure that below security properties are adequately addressed for the intended IoT solution they wish to create.