Our Security Policy
Ian Maison avatar
Written by Ian Maison
Updated over a week ago

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

Password Policy

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

User Levels

Signagelive currently supports the following user levels:

  • Read Only

  • User

  • Administrator

  • Local User

  • 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

  • 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

  • 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

  • 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

Access control

  • 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

Cryptographic Practices

  • 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

Data Protection

  • 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

Communication Security

  • 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

System Configuration

  • 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

Systems Monitoring

  • Signagelive uses New Relic and loggly to monitor the infrastructure and application performance, any alerts are sent to our development and infrastructure team, who are available 24 hours a day to resolve any problems.

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

Penetration Testing

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

  • Penetration Tests are conducted by Signagelive’s CREST Approved Partner Nettitude.

Why Nettitude?

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

Continuous Scanning

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):

  1. OWASP Top 10 Vulnerabilities

  2. Cross Site Scripting

  3. Cross Site Request Forgery

Vulnerability Scans check for (amongst other things):

  1. Open ports

  2. SSL Certificates - checks ciphers, dates etc

  3. Unexpected access points

  4. Unauthorised software

Physical Computer Access

Core Signagelive:

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

Did this answer your question?