This is a continuation of a previous post on Basic Cybersecurity Hygiene.   These are common, simple mistakes that many device developers still make today.

As a reminder, the tips from Part I are:

Do NOT use hard-coded user credentialsSanitize any inputs from outside your software (e.g. check your XML processing libraries for vulnerabilities!)

Let's continue!

Don't roll your own crypto

Never, ever, create your own cryptographic scheme or implementation.   Always use established cryptography libraries for password protection, authentication, encryption, etc.  

Need to encrypt data sent over a network?  Need to encrypt it on disk?   Need an authentication scheme to be sure users are who they say they are?    Don't try to make your own!  Cryptography is extremely difficult to design and implement correctly.  There are established methods and off-the-shelf libraries available for any conceivable cryptographic task.

There is a well-known saying in the cryptography community:

Anyone can create a crypto-system that they themselves cannot break.

Limit your networking attack surface

Determine all network services running on your device, and disable any that are not explicitly necessary.   Got a SSH server on your device for development?   Remember to turn it off before you release for production!

You can run a port scan on your device to determine what TCP and UDP ports it has open.  You should understand and approve of any open ports on your device. See https://nmap.org/book/man-port-scanning-techniques... for more detailed information on using the popular open-source tool “nmap” to perform port scans.

Monitor software components for known vulnerabilities

It is often the case that devices are vulnerable because they include software libraries that have publicly known (and patched) vulnerabilities.   The vulnerability has been published, which means that hackers know about it.  A fix for the software is available, which means that if the device has the fix, it isn’t vulnerable.  However, the device developers aren’t aware that there is a vulnerability, so the vulnerability goes unfixed, and now hackers have a roadmap to compromise the device.

For example, the National Vulnerability Database lists this critical flaw in OpenSSL 1.1.0a that can allow a hacker to completely take over a device.  Do you have the OpenSSL library on your device?  Which version?  Are you sure?

The answer is that you must create a "Software Bill-of-Materials (BOM)" for your device.  This is a list of all software packages, and their versions, that are installed on the device.    Then, you should monitor the National Vulnerability Database for vulnerabilities that affect any item on your Software BOM.