ProptechOS Data Security

Per Karlberg and Erik Wallin

Idun’s security is based on principles of minimizing attack surfaces and minimizing our security footprint by utilizing state-of-the-art security from Platform-as-a-Service suppliers.

Design, technology and practices is ensured bottom up in the following way

  • Secure low level infrastructure
  • Secure deployment
  • Secure internet communication
  • Secure usage
  • Secure operations

Secure low level infrastructure

ProptechOS is built on Azure using Platform-as-a-Service components. Security on the lowest level such as Operating System, Boot stack etc. is ensured by Microsoft and their delivery of those components. All services within ProptechOS that are not implemented using PaaS components are containerized and run on Azure Kubernetes Service where low level hardening is applied uniformly across all nodes and even every running pods and containers particularly.

Data at rest

Data stored in Azure is encrypted and decrypted transparently using 256-bit AES encryption, and data stored in Neo4j is secured by following the Neo4j operations best practices with volume encryption and encrypted backups.

Edge nodes

Edge nodes, minimal servers acting as “connectors” with edge systems, have no general access to the ProptechOS or keys that have access beyond themselves. An Edge node can only send and receive edge messages to ProptechOS, and only with the credentials of specific devices provisioned to a specific Edge node. Similarly a node can and will only accept messages (“cloud-to-device”) from ProptechOS’s instance of Microsoft Azure IoT Hub. All edge messages (in both directions) are sent over an encrypted connection initiated by the edge node over AMQPS (over outgoing ports 443 and 5671).

Idun provisioned Edge nodes are Ubuntu servers running nothing more than Docker. They are updated regularly using apt-get (encrypted over port 443) and only accept non-root-user encrypted interactions over SSH and SCP, with Fail2Ban to prohibit brute force attempts at gaining access. The Edge node image running in Docker – IoT Edge connector module – is downloaded from Idun’s Git repository (hosted by GitHub) over SSH with single use keys (deploy keys).

The edge node configuration does not include any open incoming ports to the internet, except a port for SSH access.

Secure deployment

Individually secure services

ProptechOS consists of a set of intercommunicating components and services (databases, application logic, API servers etc.). ProptechOS does not rely on network segmentation or firewalling as the primary source of security for its services. All services are secure in themselves and have no open interfaces – neither to the local network nor the internet. This reduces the number of escalation paths. We employ closed off and separated networks for internal services, but that is for added security and noise reduction. Similarly, we employ a VPN for some services but only to strengthen credentials management (see below) not a firewall-based-security.

Inter-service access management

All services restrict all access by default. Only the necessary inter-service communication is white-listed and explicitly handled at both ends. Purpose specific service principals are used for accessing and administering Azure resources.

Inter-service communication encryption

All inter-service communication is encrypted, whether it is internally in the Microsoft Azure cloud of ProptechOS, or over the internet. We employ a strict policy refusing all connections without TLS version 1.2 or higher, applied to all core components and to supporting services like Twilio, Prometheus, ELK services (Elastic, Logstash, Kibana) etc.

Secure internet communication

Idun and ProptechOS use Cloudflare for its internet facing front(s). Certificates, DNS and HTTPS requirements tied to proptechos.com are managed via Cloudflare, along with protection against DDoS attacks.

User authentication is made using the Azure Active Directory and Identity platform and IoT related authentication is made via Device ID and Device keys in Azure IoT Hub.

Rest API

The API is accessible only with access tokens generated via OAUTH2 from the Azure Identity platform.

Streaming API

The Streaming API is provided using Microsoft Azure Event Hub. Users and applications consume data using individual keys.

Edge messages

ProptechOS telemetry and commands is handled via edge messages sent to or from ProptechOS’s Azure IoT Hub instance(s).

All edge messages are signed by an authenticated device identity. No data is fed into ProptechOS without it being attributable to a device that serves both an application logic purpose, but also means that all edge data can be scrutinized for anomaly detection, and in necessary cases traffic can be blocked with high granularity.

Additional related details are covered in the Edge nodes section, below.

Secure usage

To ensure secure usage of ProptechOS, access authorization is managed with a fine grained matrix so that users and applications do not need to be given general access beyond their specific scope. The matrix has three dimensions:

  • Resources (what building(s) or part thereof, device(s) etc.)
  • Capabilities (to read, write or actuate etc.)
  • Roles (Organization admin, group owner, user etc.)

Furthermore, access can be handled by groups, so that access management does not deteriorate over time.

Analysis and reporting via Power BI

Idun provides first party access to a RealEstateCore modelled analysis environment (referred to as a “Data Source”) in Microsoft Power BI and reports made by either Idun or the customer herself, using the analysis environment.

Access to the analysis environment or report is authenticated and authorized using Microsoft Office 365 accounts and partly governed by the customer in their Office 365 organization.

Secure Operations

Developement

Idun’s Microsoft Azure resources are compartmentalized, so that the general development team does not have access to customer resources – only to the Idun development environment. Idun require 2-Factor-Authentication where either physical U2F device or an OTP code is the second factor. All code that is pushed to production is reviewed at least by a second developer, signed with individual PGP keys, and there are automated alerts for code dependencies that can be updated or are vulnerable.

Employee credentials

Idun staff use single-use passwords only, hardware 2FA and all secrets that are used in manual operations (individual passwords or shared secrets to partner or supplier accounts) are encrypted and stored using the 1Password application. Whenever sharing secrets within the team or with customers, partners and suppliers we use a single purpose 1Password vault rather than sending the secret over insecure communication channels like email, sms or chat services.

Keys and secrets used in ProptechOS are generated by PBKDF2-HMAC-SHA256 and stored encrypted by AES-GCM-256 authenticated encryption in Microsoft Azure.

Idun employs Single-Sign-On (SSO) to all services where it is possible, so that the number of access lists that Idun must maintain and credentials each employee must maintain, is minimized. In cases where internal services do not support SSO, they are mounted behind a VPN so that there is an added way to restrict access and quickly offboard individual users.

References

Idun has based its security work and practices on industry best practices and applied them to the Idun and ProptechOS scale and scope. The resources and frameworks we have relied on the most include