BSN.cloud Network Security

For a cloud-based content management and distribution network, database security and server reliability are of the highest priority. The BrightSign Network (BSN) has been built with these principles in mind. This section provides a general overview of security and recovery architecture for BSN. Note that some specific information may be withheld for security purposes.

Physical Security

All BSN servers are hosted using Amazon Web Services (AWS). Amazon strictly controls physical access to its platform infrastructure using military-grade perimeter control, as well as state-of-the art surveillance and intrusion-detection systems.

Access to the Amazon data centers is limited only to Amazon employees with legitimate business needs, and each grant of access is revoked once an individual’s business need expires, even if the individual is still an employee of Amazon. All physical and electronic access to data centers by employees is logged and routinely audited.

Physical assets used by BrightSign employees are managed and classified by the VP of finance. Relevant asset changes are communicated to appropriate constituents on a regular basis.

Virtual Data Center Security

All communication with BSN is mediated by two pairs of gateway servers. All calls to BSN domains are directed to these gateways. Each gateway communicates with a specific set of BSN nodes, and each pair of gateways is assigned traffic from a geographically distinct part of the globe.

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

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.

Business continuity and disaster recovery (BCDR) tests are conducted quarterly. Additionally, a Business Impact Analysis is conducted annually: All server instances are turned on and off to test resilience of the system to outages.

Protection Against Intrusion Attacks

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 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 database. Furthermore, only a very limited subset of individuals at BrightSign have the credentials for root access to the BSN database.

The minimum password length for BSN accounts is 5 characters. There is no complexity or lockout enforcement.

Logging and Records

Activity logs of the database, gateway, and secondary monitoring 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.

A combination of operating-system logs and application logs provide a history of successful/failed login attempts, password changes, and account modifications. However, there is currently no UI for account administrators to retrieve this information.

Data Storage

Data is stored in both a database and a file system. BSN 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 administrator). Database backups do retain some account and network state information, but not content files or PII data.

SQL queries against the database are used to retrieve/copy data without affecting the metadata.

Administrative Security

Information Assets

All BSN and BSNEE 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.

Employee Policies

All newly hired employees at BrightSign are required to sign a non-disclosure agreement (NDA) and anti-corruption documents.

Most BrightSign employees don't have access to BSN. 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.

Data Handling

The product and technical support groups within BrightSign are responsible for privacy in terms of client information. Access to customer data is restricted to a subset of employees within the company, and these teams are trained to comply with the NDAs that they sign when joining the company.

Personally Identifiable Information (PII) is not required and not recommended with BSN. Separate systems are in place to handle credit-card information, shipping addresses, and other personal information.

All BSN client data is sent and received electronically–physical media is never used.

Operating Procedures

All operating procedures related to BSN 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.

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.

Third Parties

All third parties used in conjunction with BSN are audited annually.

HIPAA Compliance

BSN is not HIPAA compliant and should not be used to store or transmit medical information.

Application and Communications Security

The BrightSign Network interacts with digital signage environments by communicating with BrightSign devices, BrightAuthor software, and the BSN API (i.e. the browser-based BSN WebUI).

Devices

The BrightSign Network and BrightSign devices communicate with each other using HTTPS, rather than HTTP. BSN requires a device to authenticate itself with a hashed and salted phrase before it can download content.

BrightAuthor

BrightAuthor requires BSN account authentication before affecting changes on the BSN servers. All communication between BrightAuthor and the BrightSign Network is carried out using HTTPS.

BSN API

Every API call requires account authentication before affecting changes on the BSN servers or returning content from the database.

Data Center Operation Block Diagrams

Notes

* During normal operations, the Remote Monitoring Server only receives updates from the Monitoring Server within Data Center 1. If the Remote Monitoring Server is no longer receiving updates from the Monitoring Server, it will switch to receiving information directly from each Gateway, Application, and Database node.

** The Database Servers in Data Center 2 constantly mirror the Database Servers in Data Center 1.

*** The Monitoring Server in Data Center 2 reports to the Monitoring Server in Data Center 1.

Remote DWS and WebSocket

BrightSign players running OS8.0.x and later maintain a persistent WebSocket connection to the BrightSign WebSocket server. This allows for BSN.cloud Control Cloud functionality: Authorized users can view and modify player settings in real time over the Internet.

Server-Side Security

The BrightSign WebSocket server implements a permissions model that ties each player to a single BSN.cloud network (via the player serial number). Only a person with the proper network credentials can perform Remote DWS calls through the WebSockets server. Credentials are validated using the same OAUTH 2.0 server as other BSN.cloud applications.

The WebSocket server validates all client data before processing to prevent malicious attacks.

Client-Side Security

Communication between the WebSocket server and BrightSign players is carried out using the secure WebSocket protocol ("wss://"): Messages are encrypted to prevent man-in-the-middle attacks against the player or server. The authenticity of the client (player) is validated using the same OAUTH 2.0 server as other BSN.cloud applications.

The BrightSign player validates all server data before using it to affect player settings. Data from the WebSockets server can also be passed along to an internal UDP port for processing by the client BrightScript/JavaScript application.