The following article describes security practices implemented within the Signagelive solution, during the development process of the Signagelive solution and the Signagelive infrastructure.
You can see a top-level network diagram of Signagelive and the incoming and outgoing communications, here.
Application Layer Security
All communications use HTTPS between the browser and client devices (if they support it) - see this article for further details.
Signagelive user accounts are protected by a secure login, see below for password policy.
Users can only be added to the platform by Users with Administrator level access.
Users can only be removed from the platform by Users with Administrator level access.
Requests to Signagelive applications and APIs require users to be authenticated.
Requests are subject to the following validation checks:
The token is valid and has not expired
The user is active and not disabled
The user has access to the network they are requesting data for/trying to update
The user has the appropriate privilege for the operation they are performing.
The request is not a Cross Site request
User passwords are encrypted in transit and at rest and not available to Signagelive employees.
Signagelive has a secure password policy, which is continually reviewed to ensure it meets current industry best practices. The current password policy can be reviewed here.
Signagelive currently supports the following user levels:
Message Manager User/Custom RSS Editor
See here for full details and a more detailed explanation of each user level and role.
Secure Coding Practices
Signagelive adheres to OWASP Secure Coding Practice, the key points are:
Incoming data is validated on a trusted system (the server) before data is processed, including expected value, data range, data types
Incoming requests are validated to ensure they are coming from a trusted source
Dangerous incoming requests that include hazardous characters such as <> “ ‘ % ( ) & + \ \’ \” are rejected where appropriate
Outgoing data is sanitised to ensure that no confidential data is returned
Data is contextually encoded as it is returned
Authentication and User Management
Authentication is required for all pages and resources, except those specifically required to have public access
Authentication is always enforced by the server
Authentication systems always fail securely
Passwords are encrypted when at rest
Authentication is only validated when all input has been completed
Authentication failure does not reveal which part of the authentication data was incorrect
Passwords require a minimum of 10 characters, 1 uppercase letter, 1 lowercase letter, 1 number, 1 special character (e.g. * % $ £, etc)
Passwords are not transmitted to the user by email
Passwords are obstructed on the user's screen e.g web forms use the input type ‘password’
Passwords can only be reset by users with the correct granular permission and a reset email is sent to the user with a secure token
Passwords can be set to be changed at the next login
Session Management uses the servers frameworks session controls
Sessions are only created on the server
Session domain and path for cookies are restricted appropriately
Sessions are terminated when the user is logged out
Session inactivity timeout is set to a minimal value, currently 1 hour
Logout is available from all pages that are protected by the authorization mechanisms
Session identifiers are not returned in URLs, error messages, or logs, they are only returned in cookies
Authorization is standardised across the Signagelive environment
Access controls all fail securely
Application access is denied if the application cannot access the security information to validate user
Authorization is enforced for every request
URLs, application data, functions are restricted to authorised users
All cryptographic functions are performed on the server
The latest framework cryptographic procedures are used
Error handling and logging
Sensitive information is not disclosed in error messages
All application errors return a generic error message to the user
Logging is implemented server-side
Sensitive information is not stored in logs, such as session identifiers or passwords
Logs are only accessible to authorised individuals within the Signagelive team
All system exceptions are logged
Sensitive data is encrypted in transit and at rest
Server-side code is not available to download by a user
Sensitive data is not included in HTTP GET requests e.g. passwords
Server access is only permitted by authorised Signagelive Employees
Signagelive where possible (see here for exceptions) enforces that clients use TLS for the protection of data in transit
Failed TLS connections do not failback to insecure connections
All authentication mechanisms require TLS
Sensitive data is always transmitted using TLS
Servers, frameworks, and system components always use the latest approved version
Servers, frameworks, and system components have all critical and high priority patches installed ASAP once verification has taken place, other patches are installed alongside platform updates
A pre-configured ‘gold hardened’ image is used for all server builds
Our hardening procedure includes:
Avoiding using insecure protocols
Firewalls are locked down to the minimum number of ports that are required for the application to function
Minimizing unnecessary software on the servers
Ensure that Operating Systems are up to date with the latest approved security patches
Admin access to the servers is protected by a secure password that only key members of the Signagelive team are aware of
Development, Testing, and Production environments are isolated
All changes to the system code are recorded internally and a sanitised user-friendly version is made publically available with each release - these comprise the release notes available here
See EUA for full details of response times.
System Backup and Restoration
Databases are backed up every 3 hours and stored in a protected storage container which is not publicly available
Media Assets are stored using the Rackspace Cloud Files product. Backups are instantly taken and copies of the files are stored in 3 locations, please refer to Rackspace for further information relating to the Cloud Files product
Database backups are tested weekly to ensure that in the event of a system failure the solution can be recovered.
A backup of the production data is always used as part of the QA process prior to any platform updates.
Signagelive conduct quarterly Penetration Tests of the Cloud Platform to align with major updates to the Signagelive platform.
All aspects of the platform are tested however critical items such as account access, horizontal user-level escalation, and access to unauthorised data and functions are validated with high priority.
Out of band Penetration Tests are performed if there are significant changes to the Signagelive environment, for example, changes to Authentication procedure or new APIs used by the platform.
Nettitude are a CREST member company and hold Penetration, Web Application and Infrastructure Testing qualifications. See http://www.crest-approved.org/membercompanies/nettitude-group-uk/index.html for further details of CREST and Nettitdues certifications.
Nettitude have been selected by Signagelive as they are an internationally recognised company with offices in the UK and USA ensuring they adhere to international best practice in key Signagelive markets.
See https://www.nettitude.com/penetration-testing/ for more details of the Penetration Services Nettitude provide and the process we have implemented with them.
In addition to quarterly penetration tests the Signagelive environment is scanned daily by Tenable. We use two products from Tenable; Web Application Scanning and Vulnerability Scanning.
Web Application Scans check for (amongst other things):
OWASP Top 10 Vulnerabilities
Cross Site Scripting
Cross Site Request Forgery
Vulnerability Scans check for (amongst other things):
SSL Certificates - checks ciphers, dates etc
Unexpected access points
Physical Computer Access
The servers used to provide the Services are located in a controlled access data center operated by Rackspace US, Inc. or a Rackspace affiliated company.
Access to the data center will be restricted to Rackspace employees or its agents who need access for the purpose of providing the services.
The data center will be staffed 24/7/365 and will be monitored by video surveillance.
Entrance to the data center will be authorised by proximity-based access cards and biometric hand scanners or other approved security authentication methods.
Rackspace performs pre-employment background screening of its employees who have access to customers' accounts.
Rackspace restricts the use of administrative access codes for customer accounts to its employees and other agents who need the access codes for the purpose of providing the services. Rackspace personnel who use access codes shall be required to log on using an assigned username and password.
Proof of Play:
The servers used to provide the services are located in a controlled-access data center operated by Amazon Web Service Inc.
Please refer here for a detailed overview of the security controls in place at AWS.