Open Kitchen Data Security
- nicholas pearson
Open Kitchen’s security measures across all points in the IoT data chain ensure a robust and safe connection to and from the cloud
ConnectWare Module plugs directly into a port on the side of the equipment for a secure wired connection directly to the equipment controller, providing access to the equipment’s data. Because the ConnectWare module communicates with the equipment via a serial interface, it provides an “Air Gap” between the Internet and the Equipment, preventing any unauthorized access to the equipment and its data.
The ConnectWare Module ensures authentication of the equipment (preventing “spoofing”) by using the concept of a “public / private key pair” and/or authentication token. The Client Certificate or authentication token uniquely identifies the ConnectWare Module/equipment and is used to validate all data being sent to the Open Kitchen cloud. The ConnectWare Module transfers all data via HTTPS to the Open Kitchen servers.
Secure Wireless transfer of data between ConnectWare module and Secure Access Point (SAP) using a hidden, secure, dedicated network created for the sole purpose of communicating with local equipment.
The Secure Access Point (SAP) is factory provisioned with an X.509 Client Certificate, ensuring that SAP and the Cloud connections have full two-way authentication. To further ensure security, all traffic also goes through a VPN connection directly to the Open Kitchen Cloud.
There is no way to communicate with the Equipment from the Internet, other than through responses to the Equipment’s request via HTTPS through the SAP. This prevents an outside entity from sending unsolicited traffic to an IoT device.
The SAP connects to an open port on the customer-provided Internet Switch via Ethernet cable for a secure and reliable communication path. Ethernet provides the best form of local security since it requires a physical connection to an Ethernet network, and thus, the traffic cannot be detected without physically connecting to the network.
Open Kitchen follows security best practices by using TLS v1.2 and v1.3 for all in transit encryption.
The Open Kitchen portal and databases are hosted on Amazon Web Services (AWS), taking advantage of all security and resiliency capabilities offered by AWS. The database is replicated in real time to a back-up database for disaster recovery.
All data is encrypted in transit. Data at rest is stored in a form that is not attributable to a specific customer. For at rest encryption, we use bcrypt for password hashing and AES (128-bit keys) for other sensitive data.
Password requirements can be configured by each customer. There are multiple role-based user types available through Open Kitchen. User logins are tracked, and the most recent login is visible in the application. Audit logs are available upon request. Our security and data handling procedures are all part of our PCI Level 1 Certification, which is conducted regularly by a third-party security auditing firm.
Scenario: Customer opts not to use SAP
Scenario: OEM opts to not use the ConnectWare Module; uses “Virtual ConnectWare” instead
Added risk: The OEM in this case is responsible for ensuring the operating system on the equipment controller is updated with all security patches. The equipment controller is directly running a TCP/IP stack to communicate with Open Kitchen via the SAP. If there is a vulnerability in the TCP/IP stack, it could be exploited. The risk here is minimal as well.
Scenario: OEM uses “Virtual ConnectWare” and customer eliminates SAP
Added risk: The OEM is responsible for ensuring the operating system on the equipment controller is updated with all security patches. All communications with equipment are directly exposed to the Internet, relying on SSL encryption for security. SSL encryption is the same level of security that a consumer would have between their home computer and home network.
Related Content:
1. Implications in the unlikely event of a hack
2. What is PCI certification?