...
...
...
| borderColor | #3D3D3D |
|---|---|
| bgColor | #F4F4F4 |
| titleColor | #3D3D3D |
| borderWidth | 0 |
| titleBGColor | #3D3D3D |
| borderStyle | solid |
...
ON THIS PAGE
| Table of Contents | ||
|---|---|---|
|
For a cloud-based content management and distribution network, database security and server reliability are of the highest priority. BSN.cloud has been built with these principles in mind. This section provides a general overview of security and recovery architecture for BSN.cloud. Note that some specific information may be withheld for security purposes.
Physical Security
All BSN.cloud 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.cloud is mediated by Amazon Route 53.
DDoS Protection
General Disaster Recovery
Each BSN.cloud server All calls to BSN.cloud domains are directed through Route 53 access points and distributed across load functions to the proper nodes. Traffic is automatically guided to locations based on geographic location.
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.cloud 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.cloud accounts is 5 characters. There is no complexity or lockout enforcement.
Logging and Records
Activity logs of the 8 characters and must contain the following character types: lowercase letter, uppercase letter, digit (0-9), and special character (!@#$%^&*). There is no lockout enforcement.
Logging and Records
Activity logs of the 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.
...
SQL queries against the database are used to retrieve/copy data without affecting the metadata.
Administrative Security
Information Assets
All BSN.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.
...
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.
...
BSN.cloud is not HIPAA compliant and should not be used to store or transmit medical information.
Application and Communications Security
BSN.cloud interacts with digital signage environments by communicating with BrightSign devices, BrightAuthor:connected software, and the BSN.cloud API (i.e. the browser-based BSN.cloud WebUI).
Devices
BSN.cloud and BrightSign devices communicate with each other using HTTPS and WSS, rather than HTTP 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
BrightAuthor:connected requires BSN.cloud account authentication before affecting changes on the BSN.cloud servers. All communication between BrightAuthor: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.
Operation Block Diagram
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.
The network settings of a BrightSign player are highly flexible and configurable. As a result, the integrity of a player is the direct result of the publishing and network configuration specified during the player setup process. Some configurations are best for networks where security is of little importance, while other configurations give the player a significant amount of resilience to outside attacks.
BrightAuthor Settings
The network settings of a BrightSign player are highly flexible and configurable. As a result, the integrity of a player is the direct result of the publishing and network configuration specified during the player setup process. Some configurations are best for networks where security is of little importance, while other configurations give the player a significant amount of resilience to outside attacks.
| Tip | ||
|---|---|---|
| ||
It's recommended that BrightSign players should not be connected directly to the Internet, but should always be behind a firewall that doesn't permit direct connections from the Internet to the player. |
There are four optional features in the BrightAuthor BrightSign Unit Setup window that affect the overall security of the player:
A. The Diagnostic Web Server: The Diagnostic Web Server (DWS) responds to requests sent to the IP address of the player, allowing a user who meets the username and password requirements to retrieve information about the player and send system commands to it (reboot, enter recovery mode, test video resolution, etc.).
...
| title | Note |
|---|
...
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.
Operation Block Diagram
All communication must be verified through OAuth2.0 servers before it may be passed between BrightAuthor:connected and a BrightSign Player.
BrightAuthor:connected Settings
The network settings of a BrightSign player are highly flexible and configurable. As a result, the integrity of a player is the direct result of the publishing and network configuration specified during the player setup process. Some configurations are best for networks where security is of little importance, while other configurations give the player a significant amount of resilience to outside attacks.
| Tip |
|---|
TipBrightSign players should not be connected directly to the Internet, but should always be behind a firewall that doesn't permit direct connections from the Internet to the player. |
There are four optional features in the BrightAuthor BrightSign Unit Setup window that affect the overall security of the player:
A. The Diagnostic Web Server: The Diagnostic Web Server (DWS) responds to requests sent to the IP address of the player, allowing a user who meets the username and password requirements to retrieve information about the player and send system commands to it (reboot, enter recovery mode, test video resolution, etc.).
The Diagnostic Web Server (DWS) is enabled on new players by default: The username is "admin" and the password is the player serial number. To change the login credentials or disable the DWS entirely, perform the player setup process.
| Warning | |
|---|---|
| title | ImportantFirmware versions before 6.2.147.9 have a cross-site scripting vulnerability and a permissions issue that allowed authorized users to view hidden storage directories (see t his this post for full details). These vulnerabilities are catalogued as CVE-2017-17737, -17738, and -17739. We recommend updating to the current version of production firmware to patch these vulnerabilities. |
B. Local Web Server: The Local Web Server responds to requests sent to the IP address of the player at port 8080. By default, this option also enables the device webpage at port 8008, which can optionally be disabled by navigating to File > Presentation Properties > Variables. The device webpage allows users on the local network to alter User Variables, which are numerical values within the presentation that extend the interactive capabilities of a player.
C. Local File Networking: Among the three networked methods for publishing content to a player, only Local File Networking can facilitate problems with network security. A player configured to use Simple File Networking or the BrightSign Network will send content update requests to a remote server based on internal conditions and intervals that are specified during the setup process: A player with one of these configurations will not respond to outside requests when fetching content updates. A player that uses Local File Networking, on the other hand, is configured to respond to connection and content-update requests from BrightAuthor or the local network.
D. Simple File Networking – Basic Authentication: If you configure a player for Simple File Networking with user name and password authentication parameters, the player will use digest access authentication by default. This will prevent replay attacks and other attempts by third parties to read authentication packet data sent to the server. If you check the Enable basic authentication box, the player will send the user name and password as plaintext data. This option makes the player compatible with certain server authentication systems, but credentials can easily be determined by anyone who can capture the packets from the network.
Other network settings that are configurable during the player setup process—such as proxy setup, wireless configuration, DHCP vs. manual IP—do not negatively affect the security of a player.
| Note | ||
|---|---|---|
| ||
For a full description of all the options in the Unit Setup window, please see the Setting up BrightSign Players section. |
.png?version=1&modificationDate=1575924925000&cacheVersion=1&api=v2&width=700)
High Security
Follow these steps during the BrightAuthor unit setup process to ensure the player has a high level of resilience to outside attacks.
- Disable the Diagnostic Web Server: The password-authentication system for the Diagnostic Web Server is vulnerable to brute-force dictionary attacks. Access to the Diagnostic Web Server allows an intruder to copy, rename, and delete contents from the local storage, as well as reboot the player or force it into recovery mode.
- Enable the Local Web Server with password protection: The authentication system for the Local Web Server is just as vulnerable to brute-force hacking as the Diagnostic Web Server, but the Local Web Server does not grant access to critical system processes.
- Do not use Local File Networking: A player set up for Local File Networking will listen for scheduling and publishing commands from a PC running BrightAuthor on the local network. It may be possible for an attacker to use this responsiveness to gain access to system processes on the player. If you would like to publish presentations over the network, use the BrightSign Network or a Simple File Network instead.
- Do not enable basic authentication: If you would like to securely publish content using Simple File Networking, make sure to use a server that is compatible with digest access authentication.
- Do not enable the Chromium Web Inspector: See the Advanced Topics section below for more details.
...
17738, and -17739. We recommend updating to the current version of production firmware to patch these vulnerabilities. |
B. Local Web Server: The Local Web Server responds to requests sent to the IP address of the player at port 8080. By default, this option also enables the device webpage at port 8008, which can optionally be disabled by navigating to File > Presentation Properties > Variables. The device webpage allows users on the local network to alter User Variables, which are numerical values within the presentation that extend the interactive capabilities of a player.
C. Local File Networking: Among the three networked methods for publishing content to a player, only Local File Networking can facilitate problems with network security. A player configured to use Simple File Networking or the BrightSign Network will send content update requests to a remote server based on internal conditions and intervals that are specified during the setup process: A player with one of these configurations will not respond to outside requests when fetching content updates. A player that uses Local File Networking, on the other hand, is configured to respond to connection and content-update requests from BrightAuthor or the local network.
D. Simple File Networking – Basic Authentication: If you configure a player for Simple File Networking with user name and password authentication parameters, the player will use digest access authentication by default. This will prevent replay attacks and other attempts by third parties to read authentication packet data sent to the server. If you check the Enable basic authentication box, the player will send the user name and password as plaintext data. This option makes the player compatible with certain server authentication systems, but credentials can easily be determined by anyone who can capture the packets from the network.
Other network settings that are configurable during the player setup process—such as proxy setup, wireless configuration, DHCP vs. manual IP—do not negatively affect the security of a player.
For a full description of all the options in the Unit Setup window, see the Setting up BrightSign Players section.
...
High Security
Follow these steps during the BrightAuthor unit setup process to ensure the player has a basic high level of protection against outside attacks.
| Note | ||
|---|---|---|
| ||
Diagnostic Web Server (DWS) password protection doesn't apply to added roHttpServer instances that are located on a different port. |
...
resilience to outside attacks.
Disable the Diagnostic Web Server
...
: The password-authentication system for the Diagnostic Web Server is vulnerable to brute-force dictionary attacks. Access to the Diagnostic Web Server allows
...
an intruder to copy, rename, and delete contents from the local storage, as well as reboot the player or force it into recovery mode.
...
Enable the Local Web Server with password protection: The authentication system for the Local Web Server is just as vulnerable to brute-force hacking as the Diagnostic Web Server, but the Local Web Server does not grant access to critical system processes.
Do not use Local File Networking: A player set up for Local File Networking will listen for scheduling and publishing commands from a PC running BrightAuthor on the local network. It may be possible for an attacker to use this responsiveness to gain access to system processes on the player. If you would like to publish presentations over the network, use the BrightSign Network or a Simple File Network instead.
Do not enable basic authentication: If you would like to securely publish content using Simple File Networking, make sure to use a server that is compatible with digest access authentication.
Do not enable the Chromium Web Inspector: See the Advanced Topics section below for more details.
...
Basic Security
Follow these steps to create the most feature-rich player setup possible. We recommend this setup only if a player is in a test environment or if security is not a concernduring the BrightAuthor unit setup process to ensure the player has a basic level of protection against outside attacks.
Diagnostic Web Server (DWS) password protection doesn't apply to added roHttpServer instances that are located on a different port.
Enable the Diagnostic Web Server
...
with password protection
...
: Access to the Diagnostic Web Server
...
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.
...
allows you to copy, rename, and delete contents from the local storage, as well as reboot the player or force it into recovery mode. Enabling password protection for this feature gives the player at least a basic level of security.
Do not use Local File Networking: A player set up for Local File Networking will listen for scheduling and publishing commands from a PC running BrightAuthor on the local network. It may be possible for an attacker to use this responsiveness to gain access to system processes on the player. If you would like to publish presentations over the network, use the BrightSign Network or a Simple File Network instead.
Do not enable basic authentication: If you would like to securely publish content using Simple File Networking, make sure to use a server that is compatible with digest access authentication.
Do not enable the Chromium Web Inspector: See the Advanced Topics section below for more details.
Test Environment: Low Security
Follow these steps to create the most feature-rich player setup possible. We recommend this setup only if a player is in a test environment or if security is not a concern
Enable the Diagnostic Web Server: Without password protection, the Diagnostic Web Server will be accessible by anyone on the local network at the player IP address.
Enable the Local Web Server: Anyone on the local network will be able to access the device webpage at port 8008.
Use Local File Networking: You will be able to use BrightAuthor to publish presentations and update schedules on a player connected to the local network.
Enable basic authentication: If you are using Simple File Networking, you can enable basic authentication to have the player send the user name and password credentials to the server as plaintext data. This makes Simple File Networking compatible with a greater range of server configurations.
Enable Chromium Web Inspector: If you need to debug HTML applications on BrightSign players, you can enable the Web Inspector in a presentation. See the Advanced Topics section below for more details.
Advanced Topics
| Anchor | ||||
|---|---|---|---|---|
|
...
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.
...
BrightSign players support a Java Runtime Environment (JRE): Developers can load Java applications using the roJRE BrightScript object. This functionality is not enabled by default and must be initialized by the autorun.
...