Hi, I'm Matthew Clark and this is Module six. Secure build, ship and operate. Congratulations. We've completed Module five. This slide shows our progress towards our certificate of completion. Let's begin our new module with less than 6.1 manufacturing and provisioning,
and this lesson will look at insecure manufacturing.
We'll discuss common provisioning, missed aches and also how to address those using the i. O. D SF framework. So let's get started.
We've discussed the manufacturing process all throughout this course, and as a review was discussed, some of the threats and impacts to that process.
Well, let's start with counterfeiting. And this could include knockoff devices made of cheap materials and containing flawed execution code.
As the fake devices might not perform very well, it might actually be a safety issue in some cases.
So what are some of the impacts that a manufacturer could expect? Well, they could see direct loss, as in a loss of revenue as people by the counterfeits instead of the actual product.
Or it could be an indirect loss. You could incur brand damage, especially if people associate the inferior product to the actual product or if there's a significant newsworthy event that people tie back to your product.
Second, you could have production overruns where it's your product running your code. It's made from your materials, most likely at your expense. Um, but somebody else reaps all the reward. The impacts will direct loss, a loss of revenue because you're paying for someone else to sell your product,
even even if they pay for the materials, you're still losing the sale,
and your customers are going experience problems. For example, warranty issues could be a problem for customers who think they've purchased that actual product and then try to use the warranty on Lee to find out that there's no record of the sale.
The third is the loss of intellectual property,
and this is where someone else steals your code firmware secrets and uses it to build their own similar product. And now you have competition at little or no cost on their side.
And remember, threat actors do not have to subvert factory management. To do this. They cannot go after a very few select employees on the factory floor that air close to the process.
Threat actors could be opportunists that could be competitors or organized crime
you could have component substitution. XYZ This is where the contract manufacturers sourcing cheaper components
but building you for the higher priced components.
And what are the impacts for that? Well, you could have performance issues because these are not the components that you specified with your design.
It could lead to a direct loss a drug loss of revenues. As the device doesn't perform as advertised or expected, you could cause safety issues. Um, you could have, like a sub par lithium battery that could have caused problems for the customer by catching fire.
It could cause indirect loss, brand damage due toa all those things that we just talked about and, of course, unintentional actions. This covers pretty much everything that's not necessarily a malicious in nature. I've worked in manufacturing industry for my entire career, and factory workers there great paid on production sometimes.
But they may feel pressure to bypass some security measures in order thio improve their throughput or to meet their own production targets. And that might affect security, which may or may not be picked up during testing. Your cue? A. If it's picked up during testing, then you're gonna run into production delays.
And if not, then you could have an inferior product going out to market.
And all these have major impacts, and we kind of went through them as we went through those threats. Um, but each one of these kind of leans toward loss of revenues or unknown behavior of the device affecting brand damage. Right?
And of course, you need to think about your suppliers to because they can make or break you because they are actually the extension of you and their actions reflect on you not necessarily themselves right, cause it's your name is gonna be the one who's associate it with any issues. Again. You can transfer responsibility, but you can never transfer accountability.
Generally, some part of the provisioning process has to be exposed by the O. E M. To the contract manufacturer.
The economics of designing, building, marketing and selling and i o t widget dictate that not every decision could be made without some sort of compromise
insecurity. We really exist on that edge balancing functionality with risk tolerance,
and it's likely that the cost of manufacturing will attempt some OM to seek partnerships in geography. Is that have lower cost.
Oftentimes thes geography zehr far away from where the OM conducts their regular business, making it hard to ensure, or at least a test that production practices air always followed.
So stable connectivity may not always possible. So the OM may elect put in HSM or other component of their provisioning system on site,
which works as long as the contract manufacturer could be trusted. Otherwise, you have to design a secure service.
Rahm would authored a white paper called Secure Device Provisioning Best Practices
Heavy Truck Edition for the NCC Group, and in it he outlined several common mistakes that caused provisioning systems to fail. And I'll share several of his ideas with you here on this slide. But I've included a link to his paper and I recommend it to you. Please look at it,
he said. One of the first things was shared provisioning secrets using the same secret key and every device, Uh, trust on first uses another issue, and we've discussed this briefly before. But this is where a trust relationship has formed between unknown parties. For example, when a new device connects,
the greatest vulnerability in this process is the risk of a threat. Actor inserting themselves into it. Forgery through forgery and a man in the middle attack.
Plain text key provisioning is something else to look for.
Secrets are created offline and then added to the devices. The risk would be if those secrets or not encrypted in transit across the network or at rest while stored on a provisioning, USB key or shared directory somewhere
UN authenticated debug boards is another one that rob poop pointed out.
This involves physical access to the device.
The vulnerability would be if the debug ports are not protected. And we've discussed various ways to do that,
which would allow privileged access.
Then this is bad, especially if there's no authentication required
and insufficient entropy is another one. The strength of the key is built on its ability to be unpredictable. This is like having a password that you think is secure because you increments the number at the end each time you change it
and manufacturing this would be like using the date. Time field is part of the key generation process. Ke re use is another one that Rob points out. We talked at length about different ways that roots of trust can be created and how encryption forms and anchor of trust.
And that anchor gets weak when you reuse keys or overuse keys. Remember in dice, for example, the private device I D Key is never exposed outside of the first mutable code.
And in TPM, the endorsement key is used only for very specific purposes.
In his white paper, Rob Wood points out that keys that are used for both signing and encryption can lead to the compromise of the keys themselves.
Do you appreciate A cryptography is another one using obsolete cryptography, cryptographic algorithms, modes and key sizes. You know, those were just asking for trouble, especially after they've already been compromised.
Secret algorithms is the last one. When I studied for the C. S S P exam years ago, Kelly held her hand, drilled it in my head that open algorithms are there are more secure than secret proprietary ones because everyone has a chance to independently verify unopened algorithm strength.
So do yourself a favor and don't try that at home. Don't make your own secret algorithm or, worse yet, think that obfuscation is cheap and effective solution.
It's cheap, but it's not very effective
and hiding something is just delayed discovery.
So the i o t s f in their security compliance framework outlines several things that manufacturers could do to address these threats and concerns using an escrow service storing the encrypted I p. And I'll say location is one logging all the devices that are manufactured,
um, production testing is performed in using a secure boot. That's Ah, third one, as well as making sure that all the production tests and calibration software is removed
Additionally, using a secure location and process the revision devices. Um, not having global secrets secrets are unique to the devices. Um, making sure that ownership proof is extended along the supply chain and having an audible bill of materials.
Well, that's it for this lesson.
In this lesson, we took a brief trip into the mysterious world of manufacturing and provisioning. We talked about insecure manufacturing issues. We discussed briefly the provisioning risk,
and we consulted the I. O. T s F framework investigated appropriate security controls to address those risk. I'll see you next time