Security Policy At Limecraft, we employ a range of security measures to ensure the safety and integrity of your data. These measures include: 1. Access controls and access to the system a. Restricting access to data Collecting data Our services do not process our users’ data unless instructed by authorised users. We provide data templates and interfaces to project administrators, who are thus responsible for collecting and processing data (as defined by the EU GDPR Regulation). We use cookies, but these do not contain any personal data. They are only used to authenticate users through our services and support teams. Handling data Limecraft stores a minimum set of user information; a username and e-mail address are required, other fields are optional. x Credit card payment information (if applicable for your account) is never stored directly in Limecraft, but is forwarded to our payment system, the Chargify platform, and our payment provider Braintree Payments. x All user passwords are stored in a salted and hashed format to invalidate any brute-force reconstruction attempts on passwords. Additionally, accounts are temporarily locked out after ten successive failed login attempts. Data encryption All files imported into our Application Systems are automatically encrypted on further cloud storage services we use internally, using AES256. This is transparent to users at client companies and helps secure your files in the cloud. All communications between our application systems and your client (web application or native client) are encrypted with TLS (HTTPS). When switching from our database to backups, the data is always encrypted using TLS. Push notifications are also sent via HTTPS (web applications) and via APNS, which uses a TLS channel. Our systems are designed to never allow unencrypted communication of your data. Application Systems Access Rights Management Our user management modules within Limecraft allow you to fine-tune the user rights on each module individually (production office, MAM, subtitling). Each user can be assigned a “Reader”, “Editor” or “Manager” directly on each of these features, allowing project administrators to control the level of user access to your production data. Access is only possible if you have been given rights by production administrator. In all other cases, nothing can be accessed. Administration and support rights Access to the Limecraft platform for both regular and administrator users is governed using role-based access controls (RBAC). Users and administrators always access the platform with personal credentials (which can be individually disabled if required) and special roles for administration and client account data access are only granted to individual users on a temporary and need-to-have basis. By default, none of the Limecraft staff can access client data on the Flow platform, unless if explicitly granted. Only a select number of Limecraft staff are granted administrative access to the platform, and then only for the duration of the troubleshooting or debugging session. b. Password policies and hashing Passwords are never stored on our systems or exchanged in clear text, and they are always stored using cryptographic hashing ensuring that the original clear text password can not be recovered. We use a hash algorithm and store the result. This algorithm is bcrypt with 2^12 rounds (which can be increased as computation power increases) and a random salt applied to guard against the use of rainbow tables during brute-force password recovery. We make sure that users pick a strong password to log in to our application services. A weak password can be a threat to the entire production. To ensure this, we use an algorithm to calculate the complexity of passwords chosen by our users. This algorithm knows and rejects over 30,000 common passwords. The algorithm calculates the entropy of the password to ensure that its password would require an estimated 10^8 guesses to find. In addition, if a user tries to log in with the wrong password 10 times in a row, they will be locked out for a period of 5 minutes. Single Sign On (SSO) Limecraft can integrate with external SSO systems such that authentication relays to approved client companies’ authentication systems. This allows them to centralise account and password management in-house and still rely on all of Limecraft’s features. The system currently supports the SAML 2.0 standard as an integration protocol, enabling integration with various identity providers including Microsoft Azure AD, Google and Okta. Depending on the configuration of the SSO authentication system, users adopt two-factor authentication through this SSO system, or through Limecraft’s built-in 2FA functionality. Two-factor authentication (2FA) Users can enable built-in 2FA on their accounts. This adds a very strong security layer to their credentials by requiring them to use a dedicated 2FA application. At the moment, Limecraft supports Time-based One-Time Password-based (TOPT) 2FA authentication by default, with an optional fall-back to e-mail-based 2FA. 2FA can be enabled at the level of individual user accounts, or it can be enforced on organisation accounts, ensuring that all users involved adopt 2FA authentication. Failing to enable 2FA leads to access revocation in this latter case. c. REST API Data and methods in the Limecraft system are exposed through a unified REST API through which all interaction with the system can take place. Internally, the API is split into two functional parts, a Data Services API and Media API. The Data Services API provides user authentication and management; retrieval and storage of editorial and media object information are done through this API as well. The Media API is used for transferring (in and out) media files and is optimised for better I/O performance than the data services API. Both APIs share a common user session management, such that they interact with clients who seamlessly switch between both API backend parts. The REST API documentation describes in detail how third-party systems can access the platform using “API Access Tokens “, maintain the session, access production, drop and read metadata, etc. The complete reference documentation of the REST API can be accessed online at: https://developer.limecraft.com. Flow is equipped with an advanced user authentication and access control framework. All requests to the Flow API require an active user session and all operations performed within such a session are validated against the rights that a user was given within a certain production or client’s account. In standalone setups, Flow manages its user accounts and associated access rights with respect to data stored in Flow independently. Flow can also be set up to authenticate users against external user identity provider systems by means of a SAML 2.0 integration, such that centralised user management can be realised. Supported identity providers include Microsoft ADFS and Azure Directory Services and Okta. 2. Data in transit is encrypted a. Network Traffic for Limecraft In this section we provide an overview of the network traffic flows into and through the Limecraft platform. Limecraft Traffic Firewalling On-premise Flow deployments should be supported by network management and firewalling solutions set up in the client’s infrastructure. Typically, these include: x Network-managed routing of traffic between platform tiers such that traffic between tiers can be properly monitored and managed where required. x Traffic firewalling of inbound traffic from the Internet. x Further firewalling of unwanted traffic between tiers of the Flow platform (e.g., by only allowing required traffic to the front-end and back-end services). x A DMZ setup for the front-facing load balancing machines. Automated deployment scripts (based on the Ansible toolkit) used by Limecraft for installing Flow take into account potentially different VLANs and IP subnets for each platform tier such that a variety of network security and routing topologies can be easily supported. In addition to firewalling provided by the client’s infrastructure, Flow deployments are also setup by default with OS-level firewalling enabled (using Linux ip/net-filter capabilities) such that Flow machines will only accept traffic on those ports used by the server roles installed on that machine. Inbound Traffic Inbound traffic directly from the Internet arrives only at port 443 (HTTP) or 80 (HTTP) on the load balancer machines, which take care of the HTTPS encryption endpoint and reverse proxying of each request to the appropriate front-end application server. Traffic to port 80 is redirected in any case to a request to the 443 endpoint to ensure clients cannot communicate with the platform through an unencrypted connection. All application traffic addressed to the platform occurs over HTTPS at port 443 to the same REST API. This includes communication from the web application, but also requests from end-user applications such as Edge, or the Limecraft Cloud Connectors. Limecraft follows best practices in the implementation of HTTPS to ensure our deployment scores a grade A in terms of TLS best practices. 3. Data is stored securely a. Backup and restore procedures Limecraft manages several backup processes to ensure 100% availability of both assets and the services. x Backup – All metadata (including scripts and transcripts) are primarily stored in the PostgreSQL database. The database replication files are dispatched to both a backup database, and in parallel to a dedicated NAS for compliance recording, continuously. x Disaster recovery – Subsequently the database is backed up (on AWS S3) and restored daily to a locally managed instance of Limecraft Flow, i.e. the disaster recovery site. x The media themselves are backed up on a daily basis. The backup maintenance routine checks per individual production on a daily basis which media have been added and sends them to AWS as well, from which they can be manually restored in batch if necessary. 4. The platform is scalable and redundant a. Deployment and redundancy Limecraft Flow can be deployed in a variety of infrastructure environments. Customers can use the hosted Flow environment (available at platform.limecraft.com), provided by Limecraft and hosted in a redundant setup in a state-of-the-art Belgian data center. Cloud Infrastructure as a Service (IaaS) deployments are also feasible (including on AWS, Google Cloud and Microsoft Azure). Finally, Limecraft Flow can be deployed on customer-provided (and Limecraft-certified) hardware environments. For security and scalability reasons, the components of the Flow platform are spread across different types of server roles. This includes load balancers, application and file servers, backend servers, transcoders and media processing nodes. A functional and redundant setup includes at least two servers (virtual or physical) for each role if multiple roles can be shared on a single machine. In terms of networking, a number of isolated networks (e.g., firewalled subnets, VLANs or OS container namespaces) are used to interconnect services of the various roles. A front-end network (between the load balancers and application servers) is used separately from the backend network (between the application servers and backend servers). Finally, an additional high-throughput network is used for media storage connections. All network connections and nodes in the Limecraft Flow platform are properly firewalled, ensuring that only select services can be contacted on each server. With respect to the load balancers, only the HTTP and HTTPS ports need to be opened externally. No other inbound traffic is passed through. Limecraft Flow core services are setup in such a way that the availability of multiple servers of a single server role helps both in horizontal scaling of processing capacity and providing redundancy to ensure that the platform is resilient against down times of individual machines. This redundancy includes: x Application servers and load balancers can be scaled horizontally to scale with increasing volumes of client requests. x Transcoders, speech transcription and other media processing machines can be scaled horizontally to scale with increasing volumes of material handling tasks. x All databases and crucial messaging components are set up in a master-slave (for PostgreSQL, SOLR, Redis) or active-active (for the RabbitMQ message bus, Zookeeper service coordination framework and the Activiti workflow engine) for configurations such that an active failing server can always be replaced instantly with a hot spare, ensuring the platform’s availability. x The workflow coordination is spread across multiple workflow coordinator instances that can each be contacted by any media processing component to keep track of workflow progress and to initiate new processing tasks. A redundant service discovery mechanism ensures that workflow coordinators and processing nodes are always kept in sync with one another and that failed components can instantly be replaced with functioning ones. Throughout the workflow execution, a number of retry mechanisms have been built in to ensure that workflows complete even when individual components might have failed along the way. The following figure illustrates the deployment schema for Limecraft Flow, including the different tiers across which the software is deployed and how components interact with one another. In the most extensive setup, a different set of machines (physical or virtual) is employed to host each server role redundantly. This means that for each server type LB, TC, MO and DB, multiple indowntimesn be combined for scalability and redundancy. 5. Strongly organised software testing and development methodology Limecraft software development model is organised to deliver according to a Service Level Agreement that aims for 100% availability. Test-driven development and continuous integration development are critical parts of our approach of delivering operational excellence. a. Test-driven development During and post-development and deployment, software components are continuously tested and monitored on different levels. x During development, unit tests are operated on most methods of all instrumental components. Unit tests are built-in and fully automated as part of the staging process. In total, about 500 unit tests are executed and managed by Jenkins (www.jenkins.io) on a daily basis. This is part of the development environment. x After passing low-level unit tests, components are deployed to the QA environment for holistic application-level integration testing. Application-level testing is conducted by specific software that behaves like a software client, loading API’s with both correct and incorrect data. The result of the regression testing is logged in Atlassian Jira, so it can be properly followed up by the software development team. x The native clients (“Edge”) are tested as well. Build verification testing is conducted by automated execution of pre-defined use scenarios. As part of every new release, a representative corpus of files has been processed. A full test report is attached for illustrative purposes. x Once deployed in production, there is another series of tests executed on a permanent basis to monitor the health state of the system, which applies for both cloud-based as well as local deployments. For example, we measure the overall latency of a given ingest process. By measuring the change in the latency, we are capable of pre-emptively detecting any anomalies, like hardware that starts degrading, oversubscription, changed behaviour of the databases due to software updates, etc. b. Automated deployments Limecraft has automated the change management process to an extent whereby they apply service upgrades (OS and applications) at run time during office hours. A layered architecture (load balancers, application servers, databases, indices, workflow management, see technical description), whereby every layer is comprised by multiple redundant services instances that can be individually isolated and upgraded, enables Limecraft to execute the most complex upgrades without any service interruption at all. On top of the OS, Limecraft use Docker virtualisation. Limecraft software and configuration elements are distributed without manual intervention using Ansible scripts that control the execution of Docker containers. As part of that deployment, the contents of the database may be upgraded as well, which will happen with carefully crafted patches so that the upgrade can be executed at run time. 6. Privacy and PII are important to us a. Restricting acces to data Collecting data Our services do not process our users’ data unless instructed by authorised users. We provide data templates and interfaces to project administrators, who are thus responsible for the collection and processing of data (as defined by the EU GDPR Regulation). We use cookies, but these do not contain any personal data. They are only used to authenticate users through our services and support teams. Handling data Limecraft stores a minimum set of user information; a username and e-mail address are required, other fields are optional. x Credit card payment information (if applicable for your account) is never stored directly in Limecraft Flow, but is forwarded to our payment system, the Chargify platform, and our payment provider Braintree Payments. x All user passwords are stored in a salted and hashed format to invalidate any brute-force reconstruction attempts on passwords. Additionally, accounts are temporarily locked out after ten successive failed login attempts. Data encryption All files imported into our Application Systems are automatically encrypted on further cloud storage services we use internally, using AES256. This is transparent to users at client companies and helps secure your files in the cloud. All communications between our application systems and your client (web application or native client) are encrypted with TLS (HTTPS). When switching from our database to backups, the data is always encrypted using TLS. Push notifications are also sent via HTTPS (web applications) and via APNS, which uses a TLS channel. Our systems are designed to never allow unencrypted communication of your data. Application Systems Access Rights Management Our user management modules within Limecraft allow you to fine-tune the user rights on each module individually (production office, MAM, subtitling). Each user can be assigned a “Reader”, “Editor” or “Manager” directly on each of these features, allowing project administrators to control the level of user access to your production data. Administration and support rights Access to the Limecraft platform for both regular and administrator users is governed using role-based access controls (RBAC). Users and administrators always access the platform with personal credentials (which can be individually disabled if required) and special roles for administration and client account data access are only granted to individual users on a temporary and need-to-have basis. By default, none of the Limecraft staff can access client data on the Flow platform, unless if explicitly granted. Only a select number of Limecraft staff are granted administrative access to the platform, and then only for the duration of the troubleshooting or debugging session. At Limecraft, we are committed to providing a secure and trustworthy platform for all our users. If you have any questions or concerns about our security measures, please do not hesitate to contact us.
