| Panel | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
ON THIS PAGE
|
...
All communication with BSN.cloud is mediated by Amazon Route 53.
Nodes located within the security group (i.e. behind the gateways) can communicate directly with each other because they have a list of internal IP addresses; however, these addresses are not communicated outside of the security group.
DDoS Protection
The gateway servers protect internal nodes from being overloaded in case of a distributed denial of service (DDoS) attack. Furthermore, there are backup gateway servers that are running “warm” 24 hours a day and can immediately come online if one or more gateway becomes overloaded with connections.
Each gateway also has process code for the other gateways installed on it, so all gateways can be rotated to different routings or geographical assignments in event of an attack.
General Disaster Recovery
Each BSN server node has a backup server that can take over in case of unscheduled
DDoS Protection
General Disaster Recovery
Each BSN.cloud server has a backup server that can take over in case of unscheduled downtime. The database server for the BSN has both a mirror and a backup that frequently update to prevent data loss in event the production database goes offline. All active server nodes are monitored by scripts that notify BrightSign IT personnel less than a minute after a problem arises with a node: Dates, times, and an incident description are Emailed to network administrators..cloud has both a mirror and a backup that frequently update to prevent data loss in event the production database goes offline.
Incidents are managed on a case-by-case basis. The recovery time objective (RTO) is 30 minutes or less, while the recovery point objective (RPO) is to prevent loss of any customer data. There are different thresholds for communicating impairments and outages to users, depending on whether the downtime is scheduled or unscheduled.
...
Quarterly scans are carried out to check for hacking and intrusion attempts. White-hat contractors are also employed to attempt breaching public-facing web applications. All server operating systems are also protected with industry-standard virus detection software.
All BSN.cloud account passwords are hashed and salted. Once a password is generated, it is impossible for even BrightSign IT personnel to obtain the password from the BSN.cloud database. Furthermore, only a very limited subset of individuals at BrightSign have the credentials for root access to the BSN.cloud database.
The minimum password length for BSN.cloud accounts is 5 characters. There is no complexity or lockout enforcement.
Logging and Records
Activity logs of the database, gateway, and secondary monitoring BSN.cloud servers is audited regularly by the DevOps team. Logs are retained for 6 months in an easily accessible form, and up to 2 years in archives.
...
Data is stored in both a database and a file system. BSN.cloud is a multi-tenant service: Client content is segregated, but the database cluster contains the information of all tenants.
Database backups are kept for 6 months in easily accessible form and up to 2 years in archives. Content is not retained in the backup cycle once it is deleted from the content store (by the client or a BSN.cloud administrator). Database backups do retain some account and network state information, but not content files or PII data.
...
Information Assets
All BSN and BSNEE .cloud software repositories and related confidential material are managed by relevant subject matter experts within the company. There is no broad-based access to this information within the company.
...
Most BrightSign employees don't have access to BSN.cloud. Order Administrator access is limited to technical support and order administrators; server access is limited to Development Operations engineers; and application-level access (for configuration and code changes) is restricted to the automated release system only.
...
Personally Identifiable Information (PII) is not required and not recommended with BSN.cloud. Separate systems are in place to handle credit-card information, shipping addresses, and other personal information.
All BSN.cloud client data is sent and received electronically–physical media is never used.
...
All operating procedures related to BSN.cloud servers and source code are generated and reviewed by management.
By management policy, server code is never pushed manually: A mix of Agile and Waterfall SDLC processes is used to manage and update code for BSN.cloud.
Privacy Policy
The full BrightSign privacy policy can be viewed here. Management reviews all code and configuration changes to ensure that they are in compliance with the privacy policy.
...
All third parties used in conjunction with BSN.cloud are audited annually.
HIPAA Compliance
BSN.cloud is not HIPAA compliant and should not be used to store or transmit medical information.
Application and Communications Security
The BrightSign Network BSN.cloud interacts with digital signage environments by communicating with BrightSign devices, BrightAuthor software, and the BSN.cloud API (i.e. the browser-based BSN.cloud WebUI).
Devices
The BrightSign Network BSN.cloud and BrightSign devices communicate with each other using HTTPS and WSS, rather than HTTP . BSN requires and WS. BSN.cloud requires a device to authenticate itself with a hashed and salted phrase before it can download content.
| Note | ||
|---|---|---|
| ||
Because of interference with caching/proxy servers, the file download service uses HTTP, but media files can be optionally encrypted using AES-128 |
BrightAuthor:connected
BrightAuthor:connected requires BSN.cloud account authentication before affecting changes on the BSN.cloud servers. All communication between BrightAuthor and the BrightSign Network :connected and BSN.cloud is carried out using HTTPS and WSS.
BSN.cloud API
Every API call requires account authentication before affecting changes on the BSN.cloud servers or returning content from the database.
...
You can use the Web Inspector to debug webpages on the BrightSign Chromium instance (see the HTML Best Practices page for more details). This tool does not require authentication, so any party on the network can access and alter content on the BrightSign player; therefore, the Web Inspector should be disabled in production environments.
Linux Security
Though the BrightSign application runs on a Linux stack, it is unlikely that conventional Linux malware will be able to infect BrightSign players. A BrightSign player will only execute a firmware image that has been cryptographically signed by BrightSign. Also, during normal operation, the filesystem used on the player is read-only.
...