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.
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.
|Email Address||Used for logging into the app and Usage/Functional Analytics||Application - User Entered||Life of Contract - Purged on Request|
|Browser||Browser Version||Usage Analytics||Application||Life of Contract - Purged on Request|
|City||User Location||Usage Analytics||Application||Life of Contract - Purged on Request|
|Initial Referrer||Referring URL at first arrival||Usage Analytics||Application||Life of Contract - Purged on Request|
|Initial Referring Domain||Referring domain at first arrival||Usage Analytics||Application||Life of Contract - Purged on Request|
|Device||Mobile or Laptop/Desktop||Usage Analytics||Application||Life of Contract - Purged on Request|
|Operating System||OS Version||Usage Analytics||Application||Life of Contract - Purged on Request|
|Region||User Location||Usage Analytics||Application||Life of Contract - Purged on Request|
|Screen Height||Screen Height||Usage Analytics||Application||Life of Contract - Purged on Request|
|Screen Width||Screen Width||Usage Analytics||Application||Life of Contract - Purged on Request|
|Country||User Location||Usage Analytics||Application||Life of Contract - Purged on Request|
|Demo Mode||If user is using demo mode of app||Usage Analytics||Application||Life of Contract - Purged on Request|
|Building||The name of the building in which the user is currently “residing”||Usage Analytics||Application||Life of Contract - Purged on Request|
|Floor||Which floor the user is on||Usage Analytics||Application||Life of Contract - Purged on Request|
|Location/Zone||Location/Zone where request was made||Usage Analytics||Application||Life of Contract - Purged on Request|
|Page URL||The page that the user was on.||Usage Analytics||Application||Life of Contract - Purged on Request|
|User Agent||The user agent of the browser the user is using||Usage Analytics||Application||Life of Contract - Purged on Request|
|Hostname||The name of the host through which they are accessing the site||Usage Analytics||Application||Life of Contract - Purged on Request|
|Time of Request||What time the user made the request||Functional Analytics||Application - User Entered||Life of Contract - Purged on Request|
|Type of Request||Warm or Cool My Space request||Functional Analytics||Application - User Entered||Life of Contract - Purged on Request|
|Indoor Temp at Time of Request||Indoor Temp at time of request||Functional Analytics||Application - User Entered||Life of Contract - Purged on Request|
|Logins||Time/Date of user logins||Usage Analytics||Application||Life of Contract - Purged on Request|
|Password (hashed)||Password||Used for logging into the app and Usage/Functional Analytics||Application - User Entered||Life of Contract - Purged on Request|
|Who made the request||User who made request||Usage Analytics||Application||Life of Contract - Purged on Request|
|BMS trend data||Time series operational trend data||Operation of Application||Application||Life of Contract - Purged on Request|
|Customer Support tickets||Complaints/Customer Support tickets||Functional Analytics||Application||Life of Contract - Purged on Request|
|Satisfaction surveys||User satisfaction with app||Functional Analytics||Application||Life of Contract - Purged on Request|
|Space type||Describes the use of the spaces of the building||Functional Analytics||Customer||Life of Contract - Purged on Request|
|BMS vendor||Make/Model of building management system||Functional Analytics||Customer||Life of Contract - Purged on Request|
|Meta data contained in BMS||Meta data for trended points and devices. Descriptions, part numbers, etc. Will vary based on vendor||Functional Analytics||Application||Life of Contract - Purged on Request|
|IP addresses of BACnet network devices||IP addresses of BACnet network devices (JACE, Field Panels, Workstations, Controllers)||Operation of Application||Customer||Life of Contract - Purged on Request|
|Physical address||Physical address of building||Functional Analytics||Customer||Life of Contract - Purged on Request|
|Number of floors||Number of floors in building||Functional Analytics||Customer||Life of Contract - Purged on Request|
|Number of occupants||Number of occupants per floor/building||Functional Analytics||Customer||Life of Contract - Purged on Request|
|Floorplans||Building floorplans for UI visualization||Operation of Application||Customer||Life of Contract - Purged on Request|
Data ProtectionCustomers 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.
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.
- 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.
- 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.
Our Information Security Officer oversees all aspects of our security architecture. You may contact him at:
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 "email@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.
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 Parameter||Description||Default Value|
|Login code lifetime||The amount of time after code generation that login link is valid for. After this period, the user will need to generate a new login link.||7 days|
|Session lifetime||How long sessions are valid for after a successful login. After this period, users will need to complete the login process, including email loop, again.||180 days|
Login via Google AccountsComfy 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.
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:
|profile||Obtain users' real name (First and Last)|
|email (formerly https://www.googleapis.com/auth/userinfo.email)||Obtain users' email address to confirm login suffix|
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:
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.
|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.|