IoT Security Checklist

 

The most recent version of the IoT Checklist can be
downloaded in Word format here

 

For your reference, it’s also available here online (HTML format):

1.      Identifying Assets

☐ Have you identified all intellectual property that needs to be protected?

☐ Have you determined if the entire electronic design needs to be protected?

☐ Have you determined if certain proprietary circuits need to be protected?

☐ Have you determined if the binary / executable needs to be protected?

☐ Have you determined if there are algorithms that need to be protected?

☐ Have you determined if there is any source code shipped in the product (Python, PHP, script files) that needs protection?

☐ Have you determined if there is any data, if it got into the wrong hands, could cause harm to your company, your client or someone else?

☐ Have you determined if there is any removable data storage device that needs to be protected?

☐ Have you determined if the file system needs to be protected?

☐ Do you need to protect the device from being reprogrammed from an unauthenticated user?

☐ Do you need to protect the entire fleet from being reprogrammed from an unauthenticated user?

☐ Have you determined ways the company’s reputation could be harmed from a security breach with this system?

☐ Have you determined what functionality must remain functional in the face of the most extreme security breach?

☐ Have you determined if a security breach on one device could bring down or be used to take over the entire fleet?

☐ Have you determined if a security breach on one device could bring down or be used to take over other similar products that you make?

☐ Is there personal information, direct or indirect, available in our device that needs to be protected?

☐ Are there keys, passwords, and certificates of authority that need to be protected?

☐ Are there aspects of a wireless network that need to be protected?

☐ Are there aspects of a wired network that need to be protected?

2.      Identifying Threats

☐ Have you identified all intellectual property that needs to be protected?

☐ Verify that the estimated cost of losing all or some of the above identified assets has been documented should a threat agent have access to the wireless services on the device

☐ Verify that the estimated cost of losing all or some of the above identified assets has been documented should a threat agent have access to the Cloud services used by the device

☐ Verify that the estimated cost of losing all or some of the above identified assets has been documented should a threat agent have access to the Mobile app used by the device

☐ Verify that the estimated cost of losing all or some of the above identified assets has been documented should a threat agent have access to the physical device

☐ Verify that the estimated cost of losing all or some of the above identified assets has been documented should a threat agent have access to the wired networks used by the device

Insecure Web, Cloud or Mobile App Interface – Anyone who has access to the web interface or the Internet or the Mobile App (OWASP #1 Threat & OWASP #6 Threat & OWASP #7 Threat – Insecure Mobile App)

☐ Verify that default usernames and default passwords are changed during initial setup

☐ Verify that weak passwords are not allowed

☐ Verify that usernames and passwords are not sent in plain text over any network

☐ Verify that there is no backdoor hard coded username and password

☐ Verify that the username is locked out after 3-5 failed attempts to log on

☐ Verify that usernames cannot be identified with the password recovery scenario

☐ Verify that the code has been reviewed for code injection errors

☐ Verify that the code has been reviewed for cross-site request forgeries

☐ Verify that the code has been reviewed for cross-site scripting

Insufficient Authorization / Authentication – Anyone who has access to the web interface/ mobile interface / cloud interface (OWASP #2 Threat )

☐ Verify that the device has some mechanism to time out access after a period of inactivity requiring the user to re-login

☐ Verify that extremely sensitive functions require the user to re-verify their credentials

☐ Verify that the need for two factor authentication has been reviewed and implemented if necessary (Especially for administrative functions)

☐ Verify that the need for granular access controls (ie different levels of access for different users) was evaluated when the system was designed.

☐ Verify that access controls are implemented properly.

☐ Verify that neither the usernames nor the passwords are stored in clear text in the device

Insecure Network Services – Anyone who has access to the device via a network connection (OWASP #3 Threat)

☐ Verify that there are no open ports

☐ Verify that all open ports need really need to be open

☐ Verify that a Denial of Service attack does not shut down essential functionality of the device

Lack of Transport Encryption – Anyone who has access to the network the device is connected to (OWASP #4 Threat)

☐ Verify that no data is passed in clear text after installation

☐ Verify that the encryption method is secure to the level of the value of the assets

☐ If SSL, TLS or other secure libraries are used, verify that there are no pre-existing security flaws in them

☐ If SSL, TLS or other secure libraries are used, verify that they are configured properly

Privacy Concerns – Anyone who has access to the device, the network, the mobile application (if applicable) and the cloud interface (OWASP #5 Threat)

☐ Verify all data types collected by the device, the mobile app, and the cloud have no privacy issues – or that special procedures and processes are created for this private data

☐ Verify that medical information stored in the device or in the cloud conforms to the HIPAA requirements

☐ Verify that, if medical information is transmitted to or stored in the cloud, that the cloud server is HIPAA compliant (See https://www.hipaajournal.com/hipaa-compliance-checklist/ and https://compliancy-group.com/hipaa-compliance-checklist-2018/  for other HIPAA checklists that may be helpful)

☐ Verify that the only data collected and stored is that data which is necessary

☐ Verify that all personal data (e.g. date of birth; home address; phone number; etc.) that is stored on the device, in the cloud or in an app is encrypted when both sent and stored

☐ Verify that access controls to personal data is appropriate for the level of access

Insufficient Security Configurability – Anyone who has access to the device (OWASP #8 Threat )

☐ Verify that the administrative access to the configuration of the device has appropriate security measures (username, strong password, two step verification)

☐ Verify that the administrative access to the configuration of the device requires strong passwords configuring users if security is very important.

☐ Verify that administrative access is more secure than user access

☐ Verify that the administrative configuration allows for logging, security alerts and alarms. For example logging whenever someone logs in as an administrator; sending an alert any time a security option is changed, etc.

☐ Verify that there is software to monitor security violations and either log them or send alerts or both. For example, in a Bluetooth mesh network, log anytime a non-authenticated device sends a beacon to request provisioning.[1]

Insecure Software / Firmware – Anyone who has access to the device, the device’s network and the device’s update server (OWASP #9 Threat)

☐ Verify that the device has the ability to update remotely. If not, provide a justification to the Director of Development.

☐ Verify that the update file is encrypted at all stages after development

☐ Verify that the device has the ability to authenticate the update and uses it.

☐ Verify that the update server is itself secure.

☐ Verify that keys used to decrypt the file are not stored in plain text on the device or in the cloud

Insufficient Physical Security – Anyone who has physical access to the device (OWASP #10 Threat)

☐ Verify that the data storage devices cannot be easily disassembled and data recovered

☐ Verify that all external ports require authentication (including the boot serial port)

☐ Verify that all external ports exposed are indeed required in production and if only needed in development are not easily accessible (for example by adding a connector).

☐ Verify that all administrative configuration capabilities are limited to local access if possible

 

[1] This assumes that only pre-authenticated devices can be provisioned on a Bluetooth Mesh network.

ADVERTISMENT