...
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.
...
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.
...
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.
...
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.
...
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.
...
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.
| 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
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 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.
.png?version=1&modificationDate=1574442982000&cacheVersion=1&api=v2&height=400)
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.
...