The trust of our customers is our most important asset and one that we work hard to maintain and improve. This document explains what data we collect, how we make use of that data, and the steps we take to ensure the confidentially, 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:
Customers access Comfy' products over the internet, using 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 tests all code for security vulnerabilities and other defects before release, and regularly performs network and application scans for vulnerabilities.
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
Service Availability Controls
Our Information Security Officer oversees all aspects of our security architecture. You may contact him at:
PGP Key Fingerprint: 869CD17E
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:
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, "buildingrobotics.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.
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 "buildingrobotics.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.
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.
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.
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:
At a high level, the Comfy architecture connects occupants and their building via our Cloud platform.
This figure shows the high-level data-flow within the Comfy cloud service. 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 building gateway/TR-2 via the web/mobile platform cannot be made.
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.
|SQL Injection||OWASP 2013 T10A1||Clients 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 T10A8||A 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 Injection||OWASP 2013 T10A1||Similar 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.|
|Sensitive cookies sent over insecure channels.||OWASP 2013 T10A6||An 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 injection||OWASP 2013 T10A1||Attackers 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 policies.||OWASP 2013 T10A9, T10A10||A 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 algorithms.||OWASP 2013 T10A6||Numerous 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.|