IOT & SDL: Securing Windows 10 IOT at the Requirements level

Security Development Lifecycle (SDL) in Windows 10 IOT is part of the convergence of information technology, data science and operational technology that makes up the latest cycle of the Internet of Things.  Using Windows 10 in your IOT systems allows you to provide defense-in-depth trust model for your hardware, secure boot, validation of trusted drivers and your applications as well as the enforcement of security policies related to software components that you are designing for school, hobby or industry.

If you are a student or academic making use of the DreamSpark/Imagine Azure offering, then this article will be useful for ensuring that you are designing with security in mind.  In today’s world, security must be a consideration in any design!

Code:

• This blog is a discussion blog, no code used.

References

• Secure Coding Guidelines
• Security Development Lifecycle for Agile Development
• Security and Identity
• Securing IoT with Microsoft
• The growing challenge for consumer health devices: keeping up with medical regulatory requirements

Goal:

It is likely that you have designed a working prototype, without considering security.  In this blog I assume that you have designed something similar to the smart doorbell.  Now, you realize that to make money off of your great idea, you need to set up requirements that investors can understand.  Hardware and software may be understood by developers, but people with money like your relatives, friends and others may want to see the requirements and because of recent security hacks want to understand how security incorporated into your product.

Initially you may drawn the diagram on a napkin at dinner with friends, or the company you work for is using a similar design.  In many IOT designs, security is overlooked.  Why?  Many times, the IOT system was designed as a hobby and suddenly it appears to be a potential money makers. 

The original design works and why mess with that design if it works?  There are two reason to mess with the design: Security and Test, let’s take a look at the process of creating high level requirements for investors or other non-technical people:

Using the SDL approach

Requirements Phase

For this blog, we will use the Simplified Implementation of the Microsoft SDL, and assume that you have taken the Security Training, which is the first part of the process.  And since you took the training you now know that you can’t put security considerations off to the end, it must be considered up front.  The least expensive point to start your security considerations is the initial planning stages.  This early definition of requirements allows the team to identify key milestones and deliverables.  At project inception performing security and privacy requirements analysis will save money for a successful product and may warn that the project will not be successful if there is not enough room in the budget for security, there is unlikely a place for profit.

Security Requirements

1. Identify key milestones
   • Make sure to integrate security and privacy in a way that minimizes disruption to plans and schedules
2. Set Quality Gates/Bug Bars
   • Use these to set the levels of security and privacy quality
   • By defining these critieria at the start of the project will identify and fix security bugs during development
   • The gates are negotiated, if there is more than one person on the team.  The project team must negotiate compliance with the quality gates in order to complete the Final Security Review, which comes up later in the security process, this blog only discusses requirements.
3. Security and Privacy Risk Assessment
   • Which portion of the project will require:
     • Threat models before release
     • Security design reviews before release
     • Are penetration testing by group that is external to the project team
     • Additional testing or analysis requirements
     • Is fuzz testing required
       • What is Fuzz Testing? Fuzz Testing is a specialized form of dynamic analysis used to induce program failure by deliberately introducing malformed or random data to an application.
     • What is the Privacy Impact Rating:
       • P1 High Privacy Risk: App stores personal information
       • P2 Moderate Privacy Risk: One time, user-initiated anonymous data transfer
       • P3 Low Privacy Risk: No Behaviors exist within feature, no anonymous or personal information is stored, transferred, no settings are changed on the user’s behalf and no software is installed.

Using the Security Requirements during the Requirement Phase

The Requirement Phase is the least expensive place to make changes and to identify security issues.  Also, with IOT, I am pretty sure you cheated and not only designed your smart doorbell, but you built the hardware and have it working already.  Now you have to move back to the requirements phase.  Bear in mind that you may determine you do not need to do the SDL process, but you should document that you examined the security requirements.

At a minimum, products that meet the following criteria should follow a SDL process, and my answers to the criteria considerations:

Now that we have the Requirements considered, the working prototype you implemented can now undergo the next cycle of security consideration, which will be covered in a separate blog, and that is: Design Requirements.

Conclusion

We have investigated the use of SDL in IOT, clearly products like a Smart Doorbell may be simple, the Smart Doorbell will have a number of vulnerabilities that could be exploited if not dealt with.  In the control of the developer would be the Smart Doorbell, Azure and the Smart Doorbell, these products can be secured using Secure Coding Guidelines, the facial recognition server is outside of the boundary of the smart doorbell.