A typical security analysis of IoT solution encompasses detailed description of the 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. A proven 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.

These threat categories are then assigned to each and every entity defined in the architecture, where not all of them apply to every type of entity. Having these categories of threats as a skeleton, the people involved can then brainstorm which particular threats can happen to the respective system entities. 

WHAT DO YOU WANT ME TO DO WITH THESE TEXT?

TODO: List mapping of threats per entity?

To support the brainstorming process here some references:

Reference: OWASP top 10 IoT vulnerabilities: https://owasp.org/www-chapter-toronto/assets/slides/2019-12-11-OWASP-IoT-Top-10---Introduction-and-Root-Causes.pdf

https://github.com/scriptingxss/OWASP-IoT-Top-10-2018-Mapping/blob/master/.gitbook/assets/2018iottop10.png

Further we have a document with examples of potential threats in order to help people with the question of “what can go wrong in my system” which we collected over time from the internet (STRIDE_Examples_of_threats.pdf) We are not sure in which detail we can put these texts here from a legal perspective or if it is better to just have the references here. What do you think?

o   Understanding the concept of security by design

o   Motivate performing a security analysis

It makes sense to implement an Information Security Management System which addresses people, processes and technology in a single, cohesive package. 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.

*Information Security Management System

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. 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.

Process:

• In case of not anonymous data, a regulation on data management is implemented to guarantee the integrity and security of this 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
• 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 party analysis 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 circuit board, the test points have no significant labels to avoid identification of particular signal lines like e.g. TxD or RxD from inspection of the circuit board.
• The elements used for the security functionalities cannot be replaced during the final assembly.
• The product can execute only digitally signed software (trusted source)
• During its run time, the software verifies periodically its integrity.
• A secure element is used to store the encryption keys.
• The software uses a hardware trust anchor to encrypt/decrypt/hash data (easy to use and more difficult to tamper than software functions).
• A physically unclonable function (PUF) is used to assure the identification of the product.
• If an operating system is used, mechanisms of memory isolation and least privilege of execution are used (trust boundary between the different software layers, ‘onion design’).
• If an operating system is used, with possibility to use privileged accounts, these accounts are only usable by the firmware. Remote access should be strictly regulated and not be available by default.
• 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 then compare hash values to control.
• In case of failed password attempts, a delay must be added before allowing the next try to avoid brute-force / bot-net attacks.
• Data type, format, length, and range checks are enforced.

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.