Comfy Security Deep Dive

Protecting our customers is our top priority.

The trust of our customers is our most important asset and one that we work hard to maintain and improve. This page explains what data we collect, how we make use of that data, and the steps we take to ensure the confidentiality, integrity, and availability of our service.

Customer Data Collection

As part of a Comfy installation, we collect a variety of information from the control systems of the customer. This includes the following:

• Network setting and configuration information, sufficient for us to communicate with building controllers.
• Lists of BACnet devices, object names, and other metadata available using the BACnet/IP protocol.
• Time-series data created by periodically reading the value of objects enabled for trending.
• Other user-supplied names, tags, and other data used for organizing the collected trend data.
• Usernames and email addresses.

Aside from basic account information collected to allow you to log-in and access your data, we do not collect any personally identifying information or protected health information. Therefore, the application has been determined to be "low risk," according to the FIPS 199 system categorization. For more information, please refer to our Privacy Policy.

Customer Data Matrix

The matrix below is intended to be a representation of the data collected by Comfy: what it is, what it is used for, where it comes from, for how long it is retained, and an example of what that unit of data is.

Data Protection

Customers access Comfy products over the internet with industry-standard secure and encrypted connections (TLS 1.0-1.2) using high-grade 2048-bit, SHA-256 certificates. Individual user sessions are protected by unique session tokens which are verified on each transaction.

Comfy follows industry best practices and complies with applicable data protection requirements, such as those set out in the General Data Protection Regulation (GDPR). Examples of specific actions we have taken to protect our customer and user data include:

• Privacy by Design and Privacy by Default- We build privacy into our products from the earliest stages, including performing periodic Data Protection Impact Assessments.
• Data Transfer Safeguards- We comply with the EU-US and Swiss-US Privacy Shield Frameworks, for any personal data that may be transferred from the European Economic Area and Switzerland to the US.
• Incident Management- Beyond investing in advanced threat protection and detection technology, we have documented policies in place that govern how we respond to any security or privacy events, including personal or customer data breaches.
• Data Processing Terms- We have updated our data processing terms and associated agreements to clearly reflect our role as either a processor or controller of personal data, to align with the legal requirements of GDPR. Comprehensive Vendor Reviews. We have verified that all of our vendors adequately and contractually address the security, privacy, and confidentiality of our customers’ data. For any (sub) processors of customer data, we have ensured that the appropriate Data Processing Addendums are in place where required.
• User Rights- Since inception, we have provided users with the ability to request the deletion of any personal data that may have been collected by Comfy. We also support data export functionality and anonymization as required by GDPR.
• Employee Awareness and Training- We provide company-wide privacy and security training to all of our employees, regardless of whether they access customer data.
• Data Protection Officer (DPO)- We have appointed a DPO to ensure compliance with all legal requirements while also ensuring that we are following industry best practices.

Application Security

Comfy tests all code for security vulnerabilities and other defects before release, and regularly performs network and application scans for vulnerabilities.

• Comfy's applications are based on proven and secure open-source applications.
• We subscribe to and regularly triage security notifications from all software components used on Comfy systems.
• Major releases are review by our development team against the applicable OWASP security risks.
• Application servers are regularly patched against operating systems and software component exploits.
• Passwords are never stored in cleartext but are hashed according to industry best practices.

Physical and Environmental Security

Our service's third-party hosting provider (Amazon EC2) has extensive physical and environmental controls, including redundant power supplies, biometric identification before physical access, and other measures to ensure the security and integrity of their systems. We regularly review their ISO27001 and SOC2 reports to ensure that their security measure align with our commitments to our customers.

Network Access Controls

• Access to and from the production service is limited to dedicated gateway machines.
• Access to Comfy servers requires the use of multi-factor authentication with extensive access monitoring and audit logs.
• Communication from the Comfy Gateway device to the Comfy Cloud is initiated by the Gateway and is mutually authenticated using TLS/1.2; that is, the Cloud proves to the Gateway that it is legitimate, while the Gateway proves it to be a legitimate device. Controls data are pushed to the secure archive when available over the encrypted channel. Once stored within the secure archive, data are protected from unauthorized access by several levels of network partitions and firewalls to prevent access from the open Internet. Furthermore, the Gateway has write-only access to the secure archive. In the case of physical compromise or theft of the device, we remotely prevent further access to secure archive from the device immediately when notified by the customer.
• Learn more about BACnet Lock, Comfy’s end point security solution that prevents unauthorized access through the Comfy Gateway device.

Security Monitoring

• System access are logged to a separate, hardened server for auditing purposes.
• Application access logs, operating systems logs, and other relevant logs are collected and analyzed based on our internal security objectives.

Administrative Controls

• Access to customer data is restricted to authorized personnel.
• Access to production servers is limited to only full-time employees based on need.
• All access is limited, logged, and tracked for auditing.
• Employees in engineering, operations, and developer roles with access to production data have background checks as a condition of employment.
• All employees are trained on information security and privacy procedures.
• At no time is any user data removed from Comfy-owned computers, and Comfy machines use appropriate technical measures, including full-disk encryption and VPN access, to ensure that user data remains secure.
• We take our supplier relationships seriously and carefully check that they do not disclose data, except as required by law. Our servers are maintained by a SOC2-certified service provider.

Service Availability Controls

• Our service is hosted within the Amazon EC2 cloud, which provides extremely high levels of reliability. Our system is designed to allow us to quickly re-provision failing nodes, or to add additional capacity to meet increased load.
• Our backup strategy involves continuous log-shipping onto Amazon S3. This techniques us allows us to transfer near-real-time application updates to an extremely durable (99.999999999%) backing store. Backups are never sent out of the United States. Integrity of backups are tested quarterly by restoring a complete backup to test systems and verifying the data. Our production backup buckets are replicated to a geographically separate region in near-real-time.
• Every component of the system sends telemetry to our centralized monitoring system, allowing us to track availability and service quality. We use this data to make regular capacity planning decisions.
• All system and application configurations are stored in our configuration management system, tested in staging environment before deployment, and are treated as code subject to expert review before being moved into production.

Key Personnel

Our Information Security Officer oversees all aspects of our security architecture. You may contact him at:

Stephen Dawson-Haggerty
steve@comfyapp.com
PGP Key Fingerprint: 869CD17E

Assessments and Certifications

Comfy believes that regular, rigorous third-party assessment of our security controls is an essential component of any security program. We perform annual SOC 2 assessments, and are evaluated against the security, confidentiality, and availability trust principles. A SOC 2 attestation letter is available upon request, and the full report may be made available to customers with an appropriate non-disclosure agreement. Additionally, we annually perform third-party penetration tests on our service, and fully remediate any findings.

Comfy Login and Authorization

To enable users to log in and control their space, Comfy offers flexible authentication and authorization of users. Generally speaking, users log into Comfy using one of four methods:

• Email domain-based Login
• Login via Google Accounts
• Password Authentication
• SAML 2.0

Users log into Comfy by providing an email address associated with their office or organization, such as "user@example.com". In this case, the email domain, "example.com", determines which of the four login methods will be used to authenticate new users; this is configured per-domain in consultation with the client.

Space-Based Authorization

Once logged into Comfy, authorization to access and control different building areas is provided through the use of Spaces. A space is a set of locations (VAV zones) which are associated with one or more email domains; users in the Comfy interface will have access to any location associated with a space containing their email domain.

An example of this mapping is shown below–each VAV location on a floor is associated with a space. This space controls which users will have access.

Email Domain-Based Login

The default way Comfy authenticates users and authorizes them for access to spaces is through the use of an email-based login system.

Users wishing to use Comfy present the system with their email address. In response, Comfy generates a one-time use code in the form of a link (the "login link"), and emails it to the user. The user clicks the link in their email and is logged into Comfy.

This method requires little to no IT support – as long as all users have valid email accounts, they will be able to log into Comfy. As usual, users receive access only to zones to which their email domain name is entitled – typically their own space within the building. When employees leave, they may maintain access to Comfy for a period of time after their email account is terminated; this period persists until the user manually logs out, is removed from the system, or their session expires.

Login via Google Accounts

Comfy supports single sign-on through the use of Google Accounts. This support is enabled at the domain granularity–for instance, enabling all users with the "example.com" email suffix to log in using Google Accounts.

When enabled, users logging in with an email address from a domain managed by Google will be prompted to "Sign in with Google."

Upon clicking on the "Sign in with Google" button, the user will be redirected in a popup to complete the login using their Google credentials. This will result in a domain-specific set of steps managed by Google and/or the client; it may prompt the user for their Google-managed password and two-factor token, or redirect them to an organization-specific sign on portal.

After completing the login with Google, Comfy generates a local account using information retrieved from their Google data and discard the OAuth session. Following this point, the user's Comfy experience is identical to that of users logging in with other mechanisms.

Implementation Considerations

Generally speaking, logging in with a Google account is both the most convenient and most secure way of authenticating users with Comfy. Users benefit from their organization's, and Google's efforts to secure their authentication system using password complexity requirements and two-factor authentication. The potential for compromise via Comfy is limited, since Comfy does not store any OAuth credentials except for a very brief period while the user logs in.

Users are asked to reauthenticate when their Comfy session expires, eliminating the need to synchronize accounts between the organization login system and Comfy. Comfy generally also does not need any additional setup beyond configuring the organization domain to use Google login to enable this login method; no IT-department configuration is generally needed.

OAuth2 Usage

Comfy uses the Google-provided oauth2client library to implement the OAuth authentication flow. During phase 1, it requests access to two scopes:

Using the client library, Comfy performs the step 2 exchange of the OAuth2 flow using the code returned by Google in step 1. Once complete, Comfy uses the credentials returned to use the Google plus v1 API to retrieve the user's name and email. After that point, it discards the credentials.

This process is repeated whenever a user is asked to reauthenticate with Google. Comfy does not save the credentials and makes no access to the Google APIs other than during login.

Password Authentication

An alternative login solution requires Comfy users to create a password to access the service. When enabled for a domain, new users are prompted to create a new password. The password must meet a set of password complexity requirements in order to be valid, and other password controls are available to ensure that users pick strong passwords.

SAML 2.0 Authentication

Comfy supports single sign-on via SAML 2.0, which is implemented by such identity providers (IdPs) as Microsoft Active Directory (hosted in an organization's intranet), Microsoft Azure (in Microsoft's cloud), and OneLogin. When enabled, users logging in with an email address from a domain configured to use SAML will be prompted to "sign in with your organization" (keeping it vague). Users are redirected to the third-party IdP where they complete authentication and are sent back to our server, where we validate and complete the login.

Users will navigate to the Comfy website, and be prompted for their email address. If the user enters an email domain that is configured for SAML, she is directed to a SSO page:

From this page, the user is directed to the SAML Identity Provider site (onelogin is Comfy's)

Comfy Data Flow

This figure shows the high-level data-flow within the Comfy Cloud. A key point of decoupling is the building command queue, which separates client-side operations driven by Comfy clients from building-side operations in contact with the control system. The diagram is meant to demonstrate that direct access to the Comfy Gateway via the web/mobile platform cannot be made.

Security Technology Overview

Comfy makes use of modern technologies to protect the integrity of the service and our user's information. This page reviews common vulnerabilities and the way in which Comfy mitigates these risks. This list has been developed based on industry best practices such as OWASP Top 10, taking our technology and customer requirements into account.