The following article describes security practices implemented within the Signagelive solution, during the development process of the Signagelive solution and the Signagelive infrastructure.
Application Layer Security
- All communications use HTTPS between the browser and client devices (if they support it) - see [xxx] 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 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 practice. The current password policy can be reviewed here.
Signagelive currently supports the following user levels:
- Read Only
- 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 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 12 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 of the same user level or above 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 protection of data in transit
- Failed TLS connections do not fail back 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 component 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
- 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 on a daily basis and stored in a protected storage container which is not publically 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 regularly tested 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.
- Penetration Tests are conducted by Signagelive’s CREST Approved Partner 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.
In addition to quarterly penetration tests the Signagelive environment is scanned daily by Qualys. We use two products from Qualys; 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):
- Open ports
- SSL Certificates - checks ciphers, dates etc
- Unexpected access points
- Unauthorised software
- Qualys are a leading provider of Security and Compliance solutions, including many of the Forbes Global 100 See https://www.qualys.com/customers/
- Breadth of services and available and experience is unmatched
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.