Humly Room Display
Security can not be added as an afterthought and it should not be seen as a hurdle to pass. Security is a continuous, never ending process that needs to be considered from the beginning. For Humly, security is the very DNA which already exist in the conceptual stage of the product. For over a decade the biggest enterprises, banks, law firms and governments around the globe have been using devices and systems engineered by the team behind Humly.
To meet the requirements of the most demanding customers Humly makes sure to have full control in every single component which goes into the hardware and every line of code that makes up its software. The Humly Room Display system is custom design hardware running a tailored Linux based firmware with our own frontend and backend applications developed inhouse. For every update and improvement a lot of effort is put into staying one step ahead of hackers - and the competition.
Cadence of firmware and application upgrades
Humly continuously improves the products. Up to three bigger updates and a few minor updates are provided every year. In case of special urgency a release cadence as short as 2 weeks are supported. As a part of the release management a penetration testing regime is applied where the application software is tested by an external team of penetration testers. In addition to a hacker approach they also have source code access to locate potential vulnerabilities that would beyond any scope for a regular penetration test. Penetration tests are done on all major releases (X.Y.Y), and on all normal releases (Y.X.Y).
Processes, protocols and principles
The secure product development lifecycle of Humly is based on threat assessment and processes from several sources, but the two main ones are ENISA Hardware Threat Landscape and Good Practice Guide, and CIS Security Cybersecurity Best Practises.
A few key principles that provide several layers of security for our products are listed down below.
Minimize exposed surface
The operating system is custom built based on the Yocto project with board support package from NXP/Freescale. It is a stripped down version that only includes services and functions that Humly actually uses to make the attack surface as small as possible.
There is no way to leave the application layer and reach underlying systems and all I/O interfaces beyond the touch screen and RFID/NFC reader are disabled by default and only available for limited use cases initiated by an authenticated administrator. Any tampering will lock the device out from the service and alerts the system administrator.
The devices only need a single port of encrypted communication on the network, effectively turning them into a dead end for any potential malicious user who tries to use the connection as an entry point.
Same policy also applies on the server side. In addition to the aforementioned traffic between device and server only one additional port is required for encrypted communication with the meeting booking or calendar system. However, in a default setup there is an internet connection over 443 for licensing, firmware upgrades and support.
Restricted access to functions and methods combined with input validation
All server and client side functions are restricted based on authentication level, and all external and internal input from authenticated users passes validation to avoid code or database injections.
The devices only store information that is already available to display on the device. No customer credentials or other sensitive information is held in the device. Even the meeting details are stored in non-persistent memory in case a device would be stolen.
On the server side the least amount of data required is handled to operate the system so in the unlikely event of a breach there should be no sensitive information to access.
The overall system security is largely depending on the environment in which it lives. Humly recommends setting up the devices on a separate VLAN that is locked down to limit access to only the Humly Server and if needed a separate NTP server. The server on which Humly Server is installed have to be accessible by authorized administrators only and passwords to both server and the Humly Control Panel must be secure and protected.
For customers interested in deploying the Humly Room Displays on an 802.1x protected network we provide basic support on a handful of configurations and are looking to expand this support together with customers on real pilot project.
- The Humly Server communicates with Humly Room Displays via HTTPS over a configurable port (default 3002).
- The Humly Control Panel web application communicates with the Humly Server using configurable HTTP port during initial setup to configure SSL certificates. After SSL has been configured all communication uses HTTPS on the port configured during initial setup (default port 3002).
- The Humly Server communicates with the booking system via either HTTP (80) or HTTPS (443)
- The system uses configurable NTP servers using UDP over port 123 to synchronize time and date.
- The system will connect to Humly Cloud using HTTPS over port 443 to validate and renew licenses and provide maintenance services like updates and error logging.
- Other devices and integrations can be allowed to communicate with the Humly Server over HTTPS using the same port that has been configured for the Humly Room Display (default 3002).
 Devices can be provided in a locked down version where wifi, bluetooth and USB port have been disabled on hardware layer.
Article is closed for comments.