IOTSF Secure Design Best Practice Guides
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
Already have an account? Sign In »
8 hours 10 minutes
I'm Matthew Clark, and this is less than 6.8
I o. T s f secure design. Best practice guides.
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
well, let's get started.
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.
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
as we go through this information,
we should have at least covered the majority of it.
Let's start with the classification of data.
So the I. O. T. S f recommends that we defined a data classification scheme and documented
and then apply a data classifications rating to each item of data stored, processed or transmitted.
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
doing items such as providing secure protective casings and mountings,
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.
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.
They also recommend masking cryptographic functions and including fault injection countermeasures in our design
for device secure boot, they recommend using ah hardware based tamper resistant capability,
checking each stage of the boot code. Then it's validated and trusted and immediately before running that code
and not booting to the next stage until the previous stage has been successfully booted.
And also ensuring failures at any stage of the boot sequence fail gracefully into a secure state
and that any code run must have been previously authenticated.
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
and disabling all ports and protocols and services. They're not gonna be used.
They also recommend that shipment should include the latest stable operating system. Component. Versions that are available at the time,
as well as devices should be designed and shipped with the most secure configuration in place.
They also recommend ensuring that the operating system is securely booted
and setting permission so users and applications can't right to the root file system
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.
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,
as well as implementing a trusted rollback function
for application security. They suggest documenting the security design of the applications.
And they say that applications must be operated the lowest privileged level possible not as root,
and that applications should be isolated one from each other
and ensuring compliance within country data processing regulations. And that has to speak to some of the ongoing privacy regulations that are constantly changing
and removing all default user accounts and passwords
well and securing design and coding techniques and never hard coating credentials into an application
for encryption. They recommend applying the appropriate level of encryption with the classification of data that's being processed
and using industry standard cipher suites.
They also recommend when configuring a secure connection, removing the weaker options so they can't be selected for use in a downgrade attack.
They also suggest not using an insecure protocol like FTP until Net,
and if implementing public private key cryptography, using unique keys per device and avoiding the use of a global key
for credential management, they suggest that devices should be uniquely identified by means of a factory set, tamper resistant hardware identifier
and to use good password management.
And each password stored for authenticating credentials
must use an industry standard hash function, along with a unique salt that's not obvious. Like using a user name.
And that password stored for credentials must be strongly encrypted. Using an industry standard algorithm
for network connections, toe activate Onley Those network interfaces that are required
run on lee services that are required and open up network ports that are required
running a correctly configured software farm all on the device, if possible, and always using secure protocols. Https um secure FTP
never exchanged credentials and clear text or, over weeks solutions like http
Um, authenticating every incoming connection and authenticating the destination before sending sensitive information.
Well, that's it for this lesson.
So in summary, we reviewed the I O. T. Security foundations, secure design, best practice guides.
We discussed briefly. They're recommended security controls, and quite frankly, we didn't go through half what's in these guy.
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
on. And all of this should be familiar to you
s o take a look at this and think about how to apply these things. This is a really great advice and guidance.