Network requirements

What a device needs from the network to reach Cloud, and how the connection is secured. If a network administrator has to approve the installation, this page is the one to send them.

Network security

The platform was designed with security as a first principle, and is intended not to put your network at risk. Devices running the SixEye SDK communicate with the cloud back end and share status information. The tunnel between the device and the back end allows actions to be run on that specific device, and lets the device pull down new firmware or configuration settings.

Does Cloud expose my network?

No. The technology establishes communication only between the specific devices running the SixEye SDK and the back end. Users cannot reach the rest of your network through it.

A device running the SDK only supports the features and file types its own manufacturer supports. A lighting device, for example, accepts only its proprietary firmware and project files — it cannot be loaded with generic scripts or executables.

What connectivity do devices require?

A device needs a valid gateway IP address with internet access and a DNS server IP address, in the same way any computer does. Devices make secure outbound connections to remote servers using TLS 1.2 or higher (TLS 1.3 where the endpoint supports it).

To perform initial authentication, a device makes a handful of short-lived connections to AWS servers in London, UK. Once authentication completes, the device creates and holds a single TLS connection to an AWS server in London, UK, which carries two-way communication with the device.

Devices need access to the following addresses.

Every connection uses HTTPS to port 443 on the remote server. All other connections are closed, and no inbound connections are required. Blocking all inbound connections with a properly configured firewall is recommended.

These addresses can change

They are accurate at the time of writing. Some may be retired and others added during ongoing development. Specific IP addresses cannot be supplied, because the underlying services use dynamic IP addressing for load balancing — a firewall rule has to be written against the hostname, not an address.

Does Cloud support encryption of data in motion?

Yes. Encryption of data in motion is always on and cannot be disabled. All connections use HTTPS to port 443 on remote servers over TLS 1.2 or higher (TLS 1.3 where the endpoint supports it). This applies both to connections made by devices and to connections made to the API server by any web client.

Keeping AV data off the wider network

Separating audio, lighting and video network traffic from other traffic is good practice. Configuring the AV network with a dedicated VLAN, or using an additional router between the AV network and the company network, is recommended.

Because only an outbound connection is needed, a router can be configured to block all AV protocols and all incoming data, permitting only outbound internet traffic on port 443.

Is it easier to use a mobile modem?

The solution is lightweight and robust, and performs well over 3G, 4G and 5G, so a mobile connection is a viable option. A separate modem does, however, bring an additional subscription, plus its own monitoring and configuration overhead.

For IT professionals, supporting compatible devices on the existing network is generally lower risk than allowing a third-party-configured router onto the premises.

What is the internet usage of these devices?

Because the back end already knows about the devices that connect to it, only limited data is needed to update values. The SDK on the device sends changes only, keeping data usage to a minimum. As a guideline, a device being interacted with a reasonable amount uses approximately 2–5KB per minute, or roughly 250Mb per month.

File transfers — firmware, project files or content — account for most data usage, with file size and transfer frequency having the largest impact. File transfers are stable and resume partial transfers when a connection is restored, avoiding unnecessary data use.

User access

The sections below cover how data shared with the cloud is protected and accessed.

How is data in the back end accessed?

The SixEye back end offers a multi-tenant web API. An integrator becomes a tenant and accesses their data through their own portal, which can be branded and served from the integrator's own domain using DNS routing.

Connections from the web client to the back end are encrypted over HTTPS, using TLS 1.2 or higher (TLS 1.3 where the endpoint supports it).

A portal built on SixEye technology can be identified by the "powered by SixEye" mark at the bottom right of each page, and by an Amazon-issued certificate pointing to https://sixeye.live.

Each portal contains sites, which in turn contain one or more devices — usually one device per physical device on a project.

How do users get access to connected devices?

Access to a site is granted by email invitation only. Users are invited to a site and can be given access to specific devices within it. Other capabilities, from viewing the control panel to running a task or rebooting a device, each carry their own permission — see Permissions.

Site owners set the permissions for their site, and can grant other users the ability to set specific permissions. Users see only the sites they have been invited to.

Is single sign-on (SSO) supported?

Microsoft 365 SSO is available.

Can two-factor authentication be used?

Each user can optionally enable two-factor authentication on their account, based on a time-based one-time password (TOTP) using an app such as Google Authenticator or LastPass Authenticator. Two-factor authentication can also be made mandatory for every user in a portal, at the portal owner's request — ask your portal's support contact to arrange it.

Portal admins, and users who have been granted the relevant permission by a portal admin, can reset the 2FA key for a user in the portal.

What about multiple sessions and automatic logout?

A user can be logged in from multiple devices at once, as the nature of the application sometimes requires it. A session lasts ten days from signing in, whether or not it is used in that time. Past the ten days it survives only while it is still in use: fifteen minutes after the last request, it closes and the next one has to sign in again.

Do admins have access too?

At portal level, one or more portal admins — typically employees of the portal owner — can be assigned at the portal owner's request. A portal admin can view all sites and grant themselves access to a site.

At platform level, a limited number of SixEye super admins can grant themselves access at the integrator's request. All activity is logged.

How is a device connected to a specific site?

A key is created from a site, with a maximum validity of seven days, and copied onto the device. The device manufacturer provides the means of transferring the key to the device, usually through its normal configuration application.

The key contains a set of temporary credentials for the device to connect with, along with the information the device needs to identify which site to connect to. Once the first connection completes, the key becomes invalid and cannot be used to connect any other device.

Is data encrypted at rest?

Yes. Data in the SixEye database is encrypted using AES-256.

What protection mechanisms are in place?

Any client consuming the API, such as a SixEye-powered portal, creates a TLS connection to a load balancer. Application servers sit in an AWS VPC (Virtual Private Cloud) with no public access, and AWS Shield provides DoS protection. Devices verify the server's certificate during the TLS handshake, so an attacker cannot eavesdrop on communications.

What logging is in place for data access?

Access to infrastructure components — load balancer, servers and database — is logged, as are application errors, events, and operations performed by users. All activity within a site is visible to site owners.

Who owns the data?

Data provided by the users of a tenant is owned by that tenant. Data pushed by a device is owned by the manufacturer of the device.

How is data backed up, and can it be restored?

SixEye holds a rolling seven-day backup.

How is data segregated between tenants?

Tenant data is held in separate database schemas, with access restricted to users of the originating tenant. This covers user data, project data, permissions and similar.

Devices are handled slightly differently: the use of a device in a particular project is segregated by tenant schema, but some of the status information a device pushes sits outside tenant scope, for the benefit of manufacturers.

How are vulnerabilities identified in the source code?

• Library version dependencies are tracked.
• Libraries are upgraded early.
• In-house solutions are preferred over unfamiliar libraries.
• Tests are automated.
• Test coverage analysis tools are used.
• Every commit is code reviewed.
• Test environments are duplicated before release.

Are there browser recommendations for best performance?

The web app is built using standard web technologies and needs no extensions or plug-ins. Any modern browser will work:

• Desktop — Firefox 62.0.3 or later, Chrome 70.0.3538.67 or later, Edge 44.17763.1.0 or later, Safari 10.1 or later.
• Mobile — Safari 10.3 or later, Chrome 70.0.3538.64 or later.

A 3G internet connection or better is advised. File transfer performance improves with higher bandwidth.