Product design (hardware): Part 1

Hi, I'm Matthew Clark. And this is Module 5: Secure Development. Congratulations. We've completed Module 4. This slide shows our progress towards our certificate of completion. Let's begin our new module with Lesson 5.1: Product Design (Hardware), Part 1. In this lesson, we'll take a look at hardware development, different considerations for it, and we will introduce the product development process. So let's get started. The software and hardware industries exist in a symbiotic relationship with each depending on the other for a reason to exist. Silicon chips are useless without software, and software can only perform as well as the capability of the underlying hardware. Although they exist together, both are separate industries with different characteristics. The hardware industry, for example, is much more regulated. If you take the cover off of an electronic device and look at all the white stamps and printed on the board, you'll see a variety of different things. For example, electrical safety. In the US, this is typically managed by the UL standards and those test for issues like fire and shock and overheating, such as batteries. We've seen in the news where lithium batteries cause fires and the Department of Transportation has restricted the transportation of those. EMI and RF testing. In the US, this is based on the FCC regulations. The products may intentionally or unintentionally emit EMR, electromagnetic radiation, and that may interfere with other devices such as a pacemaker or may be hazardous to the health in other ways. Environmental regulations is something else to consider. Both Europe and California have really strict environmental regulations, or you could have voluntary standards like the Energy Star rating that you want your product to comply with. The type of product can also impact regulations. For example, if your product comes in contact with food. In the US, it must be regulated as a food grade. The FDA will mandate what materials can come in contact with food. So if you have an IoT device that's going to be used with food, you'll have all these additional regulations to consider in your risk assessment. And the types of regulations tend to make hardware manufacturers a little bit more risk adverse. Whereas the software industry does have regulatory concerns. As well, the recent privacy law, such as the GDPR and the California Privacy Law are making software developers consider different data design requirements that they haven't previously. And there are industry-specific regulations that drive specific requirements such as HIPAA and healthcare and GBLA and SOCS in the finance sector. And developers have to be careful about what types of technology could be exported. For example, encryption source code is prohibited from being exported in many countries because it could be used by terrorists. And licensing and use of intellectual property are also large areas to consider. So in this lesson, we're going to take a look at some of the issues related to the hardware development side. Welcome to Hardware Development 101. And this is not like software development where you can quickly make a change with a few lines of code. In hardware, something doesn't work. You may need to make a change to the printed circuit board or in scrap a bunch of previously printed boards. And it's not always the fastest method to correct issues, especially when you get into production. Hardware development has a direct correlation to software development. Hardware changes can affect software development. When you take the CISSP class, the SDLC is just drilled into your head, for example, Waterfall versus Agile, but you don't want to do software development if the chipset or memory is going to change because the change in the physical world will have a direct impact in the software world. And this means that software development can be out of sync with the hardware development. So if one team experiences a lag in hardware development, there can be pressure and for another team to hurry up the software development to catch up to where the hardware development is and rushing development always tends to lead to security problems. So let's break down the hardware development. There's silicon. And these are the microprocessor chips. And there's a lot of considerations for silicon chipsets that have nothing to do with security capabilities. When choosing chipsets, the first consideration, quite frankly, is meeting the capability requirements and then it's cost. Or it could be the opposite where cost is really the only consideration. But just think about what we discussed in Module 4. Every choice when it comes to chips is going to have different implications. When you consider the PCB fabrication, the printed circuit board, the OEM might design the PCB internally using something like Autodesk EAGLE or SOLIDWORKS PCB, or they may hire an outside contracting firm to do this if the OEMs expertise software instead of hardware. The components are going to be sourced from different vendors, and silicon is going to come from one source, and other chips will come from different sources. And a contract manufacturer may be hired to assemble and build the PCB using all those components. And you'll have to consider the device manufacturing. You have to design and build the device case using injection molding process. And there are different considerations with that. Remember in a previous lesson when we talked about how even the design of an internal antenna can have an impact on communication depending on how it's placed within the device and how the device is held. And sometimes you may use a contract manufacturer, there are several key risks associated with that decision Device identity has to be injected safely. The OEM has to protect the encryption keys. The CPSO has to ensure the intellectual property is protected and make sure their product overruns are limited. And there are many opportunities within the design and manufacturing process where secrets are not so secret. So a lot of security-related decisions need to be made then. In an assembly, someone has to put the final product together. And, of course, we have quality testing. We have to build a process to test the product. And I've heard that in manufacturing, sometimes it seems like you're designing and building two things at the same time. First, you're designing and building the product, and second, you're also designing a building the ability to properly test that product. This slide shows the generic product development process, and this illustrates the manufacturing stages from least to most mature. These stage gates help identify and address risk. It's important to catch flaws early before thousands and thousands of units are created. In the concept, you create an MVP, a minimal viable product. Then, as you move through each phase of the process, you encounter different stage gates. And there's three verification tests. For example, the engineering verification test, the design verification test, and the production verification test. And the process is not always easy, and there's no guarantee that even if you follow a process all the way to the end, that you're going to have a good product. If you google Dyson 5127, for example, you'll find that Dyson took 15 years and 5127 prototypes before they created the very first model, the DCO1 bag-free vacuum. That's 5126 failures over 5475 days. That's a failure a day after vacation holidays. But, of course, it was worth it. His net worth in 2020 was $6.3 billion. Well, that's it for this lesson. In this lesson, we took a brief trip into the mysterious world of product design. We looked at regulations and common challenges. We discussed software versus hardware development, and we explored the product development process. I'll see you next time.