IOTSF Secure Design Best Practice Guides

00:00

I'm Matthew Clark, and this is less than 6.8

00:03

I o. T s f secure design. Best practice guides.

00:08

In this lesson, we're going to cover the secure design. Best practice guides were gonna briefly go over specific entries in this guide for various sections such as physical security, side channel, attacks, device security, boot secure operating systems, credential management, encryption and so forth. So

00:28

well, let's get started.

00:30

The I. O. T. S F Secure design best practice guide is just one of many guides from the I. O T. Security Foundation. And I would recommend you to take a look at their guides and download them. They are full of really good information.

00:44

We're gonna use this particular one. We're not gonna look at all everything that's in this guy. We're going to select them on Bond. Hopefully, none of this information should be absolutely new. Um, it'll be a good checkpoint for our learning, as we kinda have review everything up to this. This point, all the modules that we reviewed

01:03

as we go through this information,

01:04

we should have at least covered the majority of it.

01:08

Let's start with the classification of data.

01:11

So the I. O. T. S f recommends that we defined a data classification scheme and documented

01:18

and then apply a data classifications rating to each item of data stored, processed or transmitted.

01:26

And then we need to take an account. The collections of data may be more sensitive than individual items and that when documenting the security design, we should also document the data items and their classification, as well as their security design features that we're going to use to protect them. For physical security, they recommend

01:44

doing items such as providing secure protective casings and mountings,

01:49

Um, using tamper evident device packaging, um, to use active masking and shielding to protect against side channel attacks for high security deployments and blowing on ship fuses to disabled J tags.

02:05

To combat against side channel attacks, they recommend implementing air checking to combat bit flipping, to obfuscate your signals and your hardware and software based functions, as well as inserting dummy operations.

02:19

They also recommend masking cryptographic functions and including fault injection countermeasures in our design

02:25

for device secure boot, they recommend using ah hardware based tamper resistant capability,

02:32

checking each stage of the boot code. Then it's validated and trusted and immediately before running that code

02:38

and not booting to the next stage until the previous stage has been successfully booted.

02:45

And also ensuring failures at any stage of the boot sequence fail gracefully into a secure state

02:51

and that any code run must have been previously authenticated.

02:55

For secure operating system, they recommend, including in the operating system on Lee the components, libraries, modules, packages that are required to support the functions of the device

03:07

and disabling all ports and protocols and services. They're not gonna be used.

03:12

They also recommend that shipment should include the latest stable operating system. Component. Versions that are available at the time,

03:20

as well as devices should be designed and shipped with the most secure configuration in place.

03:25

They also recommend ensuring that the operating system is securely booted

03:30

and setting permission so users and applications can't right to the root file system

03:37

for securing software updates. They recommend encrypting the update packages on do they suggest that the update routine must be cryptographic Lee validated and validate the integrity and authenticity of the software package before installing it.

03:52

They also say ensure that the package cannot be modified or replaced by an attacker between being validated and installed, and that's a time of check, time of use attack,

04:02

as well as implementing a trusted rollback function

04:06

for application security. They suggest documenting the security design of the applications.

04:12

And they say that applications must be operated the lowest privileged level possible not as root,

04:18

and that applications should be isolated one from each other

04:21

and ensuring compliance within country data processing regulations. And that has to speak to some of the ongoing privacy regulations that are constantly changing

04:31

and removing all default user accounts and passwords

04:35

well and securing design and coding techniques and never hard coating credentials into an application

04:44

for encryption. They recommend applying the appropriate level of encryption with the classification of data that's being processed

04:51

and using industry standard cipher suites.

04:55

They also recommend when configuring a secure connection, removing the weaker options so they can't be selected for use in a downgrade attack.

05:04

They also suggest not using an insecure protocol like FTP until Net,

05:12

and if implementing public private key cryptography, using unique keys per device and avoiding the use of a global key

05:21

for credential management, they suggest that devices should be uniquely identified by means of a factory set, tamper resistant hardware identifier

05:30

and to use good password management.

05:33

And each password stored for authenticating credentials

05:36

must use an industry standard hash function, along with a unique salt that's not obvious. Like using a user name.

05:45

And that password stored for credentials must be strongly encrypted. Using an industry standard algorithm

05:51

for network connections, toe activate Onley Those network interfaces that are required

05:57

run on lee services that are required and open up network ports that are required

06:01

running a correctly configured software farm all on the device, if possible, and always using secure protocols. Https um secure FTP

06:13

never exchanged credentials and clear text or, over weeks solutions like http

06:18

Um, authenticating every incoming connection and authenticating the destination before sending sensitive information.

06:27

Well, that's it for this lesson.

06:29

So in summary, we reviewed the I O. T. Security foundations, secure design, best practice guides.

06:34

We discussed briefly. They're recommended security controls, and quite frankly, we didn't go through half what's in these guy.

06:42

I would encourage you to download the best practice guide and hopefully the things that we reviewed in this very briefly. None of it should have been the first time that you've seen it or heard it

06:53

on. And all of this should be familiar to you