The Open Web Application Security Project (OWASP) has recently released the "OWASP IoT-Top Ten 2018", as part of the OWASP Internet of Things project, with the decalogue of things to avoid during the creation, distribution and management of IoT systems.
Let's see the ten points addressed in the document, as reported in the article (in Italian):
The OWASP has hit the mark and since the pace of new IoT devices we are installing continues to increase, we wanted to do a little examination of conscience to see how much we are adhering to this Decalogue.
We have discovered that we adhere to all ten points, in some cases we have always avoided exposing our systems on the Internet without an adequate level of security and in other cases for project logics aimed at addressing security as a priority.
1 Weak passwords, unsafe network services and system interfaces
In particular, points 1 to 3 are rules to be followed already in the software world, regardless of whether it applies to the IoT.
2 Security in firmware updates
Regarding updates, point 4, the technological solutions we have adopted allow us to manage field devices with unlimited and secure firmware updates, where there are also failover logics that allow devices to switch to fail-safe mode if for some the new firmware received should present some problems or arrive partially.
We can update the firmware of the single device as an entire group consisting of thousands of objects, thus ensuring a uniform update of the firmware versions, useful to be able to then provide support to the end customer.
3 Obsolescence of hardware and software components
We satisfy the point 5 with constantly updated software and hardware components, both thanks to the above and thanks to the cutting-edge software development frameworks that we have selected, also based on the fact that each release is performed an automated AUDIT on the security of every single module.
4 GDPR by Design
On point 6, we have chosen not to use email addresses and other sensitive data in the archives connected to the devices, so we can say that we are "GDPR Compliant by design”.
5 Data transmission and encrypted storage
Regarding the transfer and storage of data (point 7) we rely on secure transmission protocols and storage servers in web farms of suppliers with whom we have a ten-year relationship with zero data leak.
If we bring some data locally on our internal servers, this only happens on encrypted disks, so even in case of theft, the data remain inaccessible.
6 Management of the device fleet
The devices are managed through a software console that allows us at any time to know their health and determine the ownership of the device with security (point 8). The management of 3G connections with global unified tariffs is also simplified by management tools that allow us to temporarily switch off the SIM data, thus ensuring total control over this aspect.
For further precaution we compartmentalize the fleets per customer and application so as to contain any leaks and data leaks just like on a ship, closing only the compartments that can be flooded.
7 The default settings in our case do not exist
Each device can connect to the cloud, and consequently be reachable, only if it contains the appropriate certificates, no default password then (point 9)
8 No USB no party
If for Physical Hardening (point 10) we intend to make life difficult for those who have access to the physical device by preventing them from inserting their firmware and taking control of it, then there is much to be said here. The only way is to eliminate USB ports or other standard connections from which, through a special equipment, you can inject a different firmware from the original.
Even in this case, however, having adopted a priori the logic of recognition of the firmware through queries from the cloud, we can detect the anomalous behavior and possibly intervene.
9 Let's try to go beyond the 10 points of OWASP.
We having to opt for greater security, we recommend, when possible and economically sustainable in the project, to adopt dedicated 3G connections for devices, so as to avoid the use of WiFi networks or other channels more easily attacked.
As we said, with the 3G connection we can also completely inhibit the device remotely, by deactivating the SIM. The use of existing WiFi networks instead introduces an extra layer of security that must be managed, it is therefore a matter of carefully evaluating costs / benefits.
Another thing that we have learned is that divide functionalities between different physical devices, while technically being able to use only one, allows us to simplify the firmware with less need for updating and greater ability to delimit the perimeter in the case you identify malfunctions.
