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.

DataDescriptionUsageData SourceRetention
EmailEmail AddressUsed for logging into the app and Usage/Functional AnalyticsApplication - User EnteredLife of Contract - Purged on Request
BrowserBrowser VersionUsage AnalyticsApplicationLife of Contract - Purged on Request
CityUser LocationUsage AnalyticsApplicationLife of Contract - Purged on Request
Initial ReferrerReferring URL at first arrivalUsage AnalyticsApplicationLife of Contract - Purged on Request
Initial Referring DomainReferring domain at first arrivalUsage AnalyticsApplicationLife of Contract - Purged on Request
DeviceMobile or Laptop/DesktopUsage AnalyticsApplicationLife of Contract - Purged on Request
Operating System/td>OS VersionUsage AnalyticsApplicationLife of Contract - Purged on Request
RegionUser LocationUsage AnalyticsApplicationLife of Contract - Purged on Request
Screen HeightScreen HeightUsage AnalyticsApplicationLife of Contract - Purged on Request
Screen WidthScreen WidthUsage AnalyticsApplicationLife of Contract - Purged on Request
CountryUser LocationUsage AnalyticsApplicationLife of Contract - Purged on Request
Demo ModeIf user is using demo mode of appUsage AnalyticsApplicationLife of Contract - Purged on Request
BuildingThe name of the building in which the user is currently “residing”Usage AnalyticsApplicationLife of Contract - Purged on Request
FloorWhich floor the user is onUsage AnalyticsApplicationLife of Contract - Purged on Request
Location/ZoneLocation/Zone where request was madeUsage AnalyticsApplicationLife of Contract - Purged on Request
Page URLThe page that the user was on.Usage AnalyticsApplicationLife of Contract - Purged on Request
User AgentThe user agent of the browser the user is usingUsage AnalyticsApplicationLife of Contract - Purged on Request
HostnameThe name of the host through which they are accessing the siteUsage AnalyticsApplicationLife of Contract - Purged on Request
Time of RequestWhat time the user made the requestFunctional AnalyticsApplication - User EnteredLife of Contract - Purged on Request
Type of RequestWarm or Cool My Space requestFunctional AnalyticsApplication - User EnteredLife of Contract - Purged on Request
Indoor Temp at Time of RequestIndoor Temp at time of requestFunctional AnalyticsApplication - User EnteredLife of Contract - Purged on Request
LoginsTime/Date of user loginsUsage AnalyticsApplicationLife of Contract - Purged on Request
Password (hashed)PasswordUsed for logging into the app and Usage/Functional AnalyticsApplication - User EnteredLife of Contract - Purged on Request
Who made the requestUser who made requestUsage AnalyticsApplicationLife of Contract - Purged on Request
BMS trend dataTime series operational trend dataOperation of ApplicationApplicationLife of Contract - Purged on Request
Customer Support ticketsComplaints/Customer Support ticketsFunctional AnalyticsApplicationLife of Contract - Purged on Request
Satisfaction surveysUser satisfaction with appFunctional AnalyticsApplicationLife of Contract - Purged on Request
Space typeDescribes the use of the spaces of the buildingFunctional AnalyticsCustomerLife of Contract - Purged on Request
BMS vendorMake/Model of building management systemFunctional AnalyticsCustomerLife of Contract - Purged on Request
Meta data contained in BMSMeta data for trended points and devices. Descriptions, part numbers, etc. Will vary based on vendorFunctional AnalyticsApplicationLife of Contract - Purged on Request
IP addresses of BACnet network devicesIP addresses of BACnet network devices (JACE, Field Panels, Workstations, Controllers)Operation of ApplicationCustomerLife of Contract - Purged on Request
Physical addressPhysical address of buildingFunctional AnalyticsCustomerLife of Contract - Purged on Request
Number of floorsNumber of floors in buildingFunctional AnalyticsCustomerLife of Contract - Purged on Request
Number of occupantsNumber of occupants per floor/buildingFunctional AnalyticsCustomerLife of Contract - Purged on Request
FloorplansBuilding floorplans for UI visualizationOperation of ApplicationCustomerLife of Contract - Purged on Request

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.

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.0; 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
[email protected]
PGP Key Fingerprint: 869CD17E

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 three 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 "[email protected]". In this case, the email domain, "example.com", determines which of the three 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 Architecture

At a high level, the Comfy architecture connects occupants and their building via the Comfy Cloud platform.

 

 

 

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.

Web Technologies
 
RiskReferenceDescriptionMitigation
SQL InjectionOWASP 2013 T10A1Clients inject fragments of database code (SQL) into requests, resulting in privilege escalation, downtime, data breach, or other exposure.Comfy uses an object-relational mapper for all database access. This design essentially eliminates the possibility of SQL injection since no SQL code is written by hand, and input arguments are always sanitized.
Cross-site request forgery (CSRF)OWASP 2013 T10A8A third-party webpage takes advantage of the fact that a user's webpage has a valid session with the Comfy server, and uses that session to make unauthorized requests.All requests which mutate state require a unique CSRF token to be included with the request. This token is uniquely generated with each page load and bound to the element being submitted. This provides strong control that the user, rather than another site, intended to submit the request.
XML InjectionOWASP 2013 T10A1Similar to SQL injection, an attacker attempts to create a message which causes an SQL parser to exhaust memory, load an external resource, or inject unwanted content inappropriately into the request. The result can be reduced availability, or a violation of access control.Comfy does not use XML or XML technologies in any user-facing components and so is not vulnerable to this attack.
Session fixationOWASP 2013 T10A2An attacker exploits a website which allows session identifiers to be reused by causing a user to log in with a known (to the attacker) session id.Comfy session_ids are not permitted in GET or POST request query variables, and are stored in HTTP cookies which cannot be read or set by JavaScript.
Sensitive cookies sent over insecure channelsOWASP 2013 T10A6An attacker obtains session credentials or other sensitive data by intercepting traffic between the server or client.All Comfy traffic uses HTTPS and HTTP-only cookies. We are actively working to deploy HSTS.
Buffer overflows Client requests cause a specific type of error in server code which enables an attacker to cause the server to crash, or run arbitrary code. Depending on the severity, this could result in denial-of-service or full remote code escalation.The Comfy application server is written in a technology which by design has essentially no vulnerability to this attack.
Command injectionOWASP 2013 T10A1Attackers exploit vulnerable applications to execute arbitrary shell commands on the server, resulting in denial of service, violation of access control, or information breach.The Comfy application development guidelines prohibit executing shell commands in user-facing code.
Insecure third party domain access or cross domain policiesOWASP 2013 T10A9, T10A10A website which loads resources from untrusted third-party resources may allow client code injection.Comfy hosts all resources itself or on a third-party CDN under our control. The X-Frame-Options: SAMEORIGIN header is sent on each request to prevent Comfy from being loaded in a frame controller by a third party.
Use of HTTPS other than SSLv3 or TLS, null ciphers, or insecure signature algorithmsOWASP 2013 T10A6Numerous vulnerabilities have been discovered in a variety of implementations of SSL as well as the underlying protocol design.Comfy disallows these insecure protocols, and routinely tests its SSL implementation against third-party lists of vulnerable protocols and implementations. Comfy's SSL certificate is signed using SHA-256 rather than SHA-1 or other insecure signature algorithms.
Returning verbose error information A web server experiencing an error returns detailed debugging information to the client. This can potentially be used to discover and exploit vulnerabilities in the server.When deployed to production, Comfy disables producing client error reports and logs those errors only to our monitoring system.