Comfy Security Deep Dive

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.

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{e9290fcf194159b00bd5706507098f575c37a46aa9ed8beecb97ed8504778dcf}) 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.

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:

Scope	Purpose
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.

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:

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

Risk	Reference	Description	Mitigation
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.
Session fixation	OWASP 2013 T10A2	An 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 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.