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 are 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.
2FA (Two-Factor Authentication) is available as an option for Signagelive users, but is required for all Signagelive staff - enforced by our Technical Policy.
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.
In addition to the above, Signagelive implements role-based security with the Granular User Permissions functionality. This provides Signagelive Administrators the ability to customize and create their own roles with unique permissions that isolate chosen Signagelive functionalities to specific roles and assign these as they see fit.
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
Two-Factor Authentication available for Signagelive users to leverage
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 (65 characters max), 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 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 30 mins
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 Amazon CloudWatch, New Relic, and Loggly to monitor infrastructure and application performance. Alerts are sent to our development and infrastructure team, who are available 24 hours a day to resolve 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 AWS (Amazon Web Services) product.
Database backups are tested weekly to ensure that the solution can be recovered in the event of a system failure.
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, such as changes to the Authentication procedure or new APIs used by the platform.
Signagelive’s CREST Approved Partner Nettitude conducts Penetration Tests.
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 weekly by Tenable. We use two products from Tenable
Vulnerability Scans check for (amongst other things):
Open ports
SSL Certificates - checks ciphers, dates etc
Unexpected access points
Unauthorised software
Insecure Configuration
3rd party dependencies are scanned as part of the continuous integration process those with vulnerabilities halt builds.
Physical Computer Access
AWS:
Data Center Location and Operation: The servers used to provide the Services are located in AWS data centers, which are part of a comprehensive global infrastructure with numerous Regions and Availability Zones (AZs) worldwide. AWS owns and operates these data centers, ensuring consistent security standards. (Note: Except for China Regions, where local Chinese companies are the service operators.)
Data Center Access: Access to AWS data centers is strictly controlled and limited to AWS employees and vendors with a legitimate business need and knowledge. Access is granted based on the principle of least privilege and is time-bound. Permissions are immediately revoked if no longer required.
Data Center Staffing and Monitoring: AWS data centers are continuously monitored with 24/7 global Security Operations Centers (SOCs) overseeing physical access, intrusion detection, and providing support to on-site security teams. Video surveillance is continuous, and electronic intrusion detection systems are deployed. While explicit statements of 24/7 on-site staffing may vary across sources, the comprehensive security measures implemented by AWS strongly suggest continuous monitoring and the presence of personnel, either on-site or remotely, to respond to security and operational needs at all times.
Data Center Entry Authorization: Entrance to AWS data centers is authorized by multi-factor authentication (MFA), including badges and two-factor authentication for building entry. Biometric access control methods, such as Amazon One Enterprise (palm-based identity service), are also being implemented.
Employee Background Checks: AWS conducts thorough hiring verification processes for all employees, including validation of education and previous employment. Background checks are performed for employees with data center access, as permitted by law and regulation. These checks can include criminal history, driving history, credit profile, and verification of educational and employment history. For specific roles, active US Government security clearances may be mandatory.
Administrative Access: AWS personnel do not have direct administrative access to customer data, except when explicitly requested by the customer, or if necessary to prevent fraud and abuse or to comply with legal obligations. AWS recommends and provides tools for customers to manage their administrative access using AWS Identity and Access Management (IAM) best practices, including least privilege, MFA, and temporary credentials.
Proof of Play:
The servers used to provide the services are located in a controlled-access data centre operated by Amazon Web Service Inc.
Please refer here for a detailed overview of the security controls in place at AWS.