Security FAQ

Yes. Both on the main website and in the Lucen Timeline Online app, the session timeout is set at 8 hours. If the user doesn’t access the site or the web app before this period expires, they will be automatically logged out of their account.

We use SSL/TLS for communication channel encryption, and we are protected against XSS (cross-site scripting) attacks. Payment card data is captured directly by Stripe using their hosted payment elements; it never touches our servers. This keeps Lucen within PCI-DSS SAQ-A scope.

Yes. Our technical security expert maintains the security coding standards, which are applied by developers, testers, and team leaders when uploading code on the repository. Every team receives ongoing training on security code policies.

We have a testing process for the source code (including automated tests, unit and integration tests and automated source code analysis tools), which is used, reviewed and maintained constantly by our developers and security manager. This process gives testing requirements the same priority as functional requirements in development cycles, so we can quickly identify any risks early.

Our framework applies context-aware output encoding as its default mechanism to mitigate XSS, in line with OWASP guidance. We also apply secure coding standards and code review to catch cases the framework cannot.

Yes. We have a comprehensive internal audit system which logs all application events containing data related to users, orders, payments, invoices, emails, etc. These logs, along with errors, are saved, tracked and reported (on website and by email) via alerting and error tools from Kibana and Rollbar.

No. Our website and application do not require any plugin; however, you will need to have JavaScript enabled in your browser.

We’re using PBKDF2 with HMAC-SHA256, 128-bit salt, 256-bit key, 10000 iterations, when storing passwords.

‍

All data is protected at rest by Azure systems; more information, including the algorithms, can be found here: https://learn.microsoft.com/en-us/azure/security/fundamentals/encryption-atrest.

Yes. Both the Lucen Timeline Online app and the main website are accessible over HTTPS, and the communication channel is encrypted with SSL/TLS, to provide high levels of integrity and confidentiality.

We have defined and provisioned a suite of security related alerts that are triggered via Microsoft Azure’s monitoring service. For example, these events include website crashes, database availability, CPU/memory load threshold, or other services down alerts. Our administrators and security managers are notified by email and SMS whenever an alert is triggered.

We are not aware of any security incident resulting in unauthorized access to or disclosure of customer data within the past 24 months.

Yes. We use Microsoft Azure's Web Application Firewall (WAF) and DDoS Protection to stop network and application layer attacks at the edge, as well as to control, log, filter and block traffic to our backend. In addition, we have a process in place to ensure only authorized personnel can access it. We also utilize network zoning to provide an additional layer of security – where each edge component is in its own network, and the internal networks communicate through VPN, allowing only desired traffic through.

Yes. Customer-sensitive data and the application credentials, SSL certificates, and encryption keys are managed, stored, and transmitted securely through the Azure Management Portal in adherence to Azure Data Security and Encryption Best Practices. Additionally, access to the management portal is restricted and requires specific permission, which is logged and recorded in a secure manner.

All our networks leverage Azure's advanced security services, which include protection against Man-in-the-middle attacks such as Address Resolution Protocol (ARP) and Flooding. As an additional layer of security, networks can only be accessed through user authentication with strong password requirements.

Depending on the type of license they purchase, some Lucen Timeline users will set up user accounts. These users can:

‍

A) Set their password at registration from our website or inside the product, and they have several options to change it if needed:

1. Clicking the Forgot Password link at login. The system will email the user a confirmation code that will allow them to set a new password securely.
2. Changing it from their Account Settings page once logged in. To prevent unauthorized access, the user will need to confirm their email address before setting a new password.
3. Contacting our support team. In this case, our support representative will initiate the reset and create a temporary password, which the user will be requested to change as soon as they sign in to their account.

B) Choose “Continue with Microsoft” at registration. In this case, users will not create a local Lucen Timeline password, as they’ll use their Microsoft account credentials to log in. Password management will be handled through their Microsoft account settings.

‍

Yes. The minimum password security requirements we enforce are:

• 8 to 20 characters

And at least 3 of the following:

• Lowercase letters (a-z)
• Uppercase letters (A-Z)
• Digits (0-9)
• Special characters
• @ # $ % ^ & * - ! + = [ ] { } | \ : ' , . ? / ` ~ " ( ) ; < >

Passwords are hashed by Azure B2C and cannot be recovered (even in encrypted form) by our team. To avoid any issues, we strongly recommend logging in directly with your Microsoft Work account, which will allow you to use the security measures configured by your company. If you're not using a Microsoft account, consider a password management tool to store your credentials.

Our data center provider is Microsoft Azure, which meets a broad range of international and industry-specific compliance standards, from ISO27001, HIPAA, and FedRAMP, to SOC 1 and SOC 2. Rigorous third-party audits verify Azure's adherence to the strict security controls mandated by these standards. Azure's compliance reports are available on Microsoft's Service Trust Portal.

Yes. We use Elasticsearch clusters to sync data for reports, to log emails sent by the system, and for internal data auditing purposes. In addition, we also use Kibana for logs and errors (please see our FAQ on logging security-relevant events).

Yes. All data is saved in the cloud and it is backed up every minute using Azure cloud back-up services. Our back-up and recovery architecture uses geo-redundant storage (RA-GRS) to ensure that the backups are preserved even if the data center is unavailable. Backups are automatically kept for 35 days.

Yes. We back up regularly and store these back-ups with Azure. Additionally, we regularly back up to removable media, which are stored at off-site facilities. All backup data is encrypted.

Azure is composed of globally distributed datacenters that are strictly controlled to reduce risk of unauthorized users gaining physical access. We do not have physical access to them.

Yes. We have a business continuity and disaster recovery (BCDR) process that covers disaster recovery procedures and best practices to ensure business continuity. It addresses disruptions in the service we provide customers, to keep our applications running during unplanned downtimes. Additionally, it leverages Azure recovery services (auto-healing, auto-restart servers, machine replication, geo replication etc.) to ensure business recoverability during outages.

Backups are done automatically through Azure and retained for 35 days. Additionally, we back up data offsite – these backups are automatic as well. As for restoration, this is done manually by authorized staff.

Yes. Depending on the severity of the business disruption, we may send notifications explaining the issue and letting users know the impact, restoration times and any temporary alternative solutions. To ensure maximum visibility, such notifications may also be posted on all our social media channels.

We have not experienced a material service-impacting disruption (as defined by our BCDR policy) in the past 24 months.

Yes. We have a dedicated security professional who oversees secure architecture and practices, and we have a technical security expert who is responsible for specific, code-related data and secure software development processes. Both receive ongoing information security training and stay current with the latest technologies, and threats, applicable to our applications.

Our development and delivery process is based on the Agile methodology. We use Continuous Integration and Continuous Delivery for our build and release process to ensure that we can deploy changes quickly and in a sustainable way. Our teams work in iterations and cycle through processes of planning, design, development, testing and deployment, and tasks are adjusted as the situation demands. This practice allows us to detect problems early, reduce risks, and easily adapt to changes in requirements.

Development teams create unit and integration tests and also perform manual testing for code changes before deploying to a Development server. Then, the testers create and execute automated and manual tests on both the Development and Testing servers. When the testing teams certify and approve code changes, they are deployed to a Staging server and re-tested simulating a Live environment. The final phase is to swap Staging with Live and re-test in the Live environment.

We have a managed development process. When a developer has finished working on a task, that work is submitted for review and approval from a reviewer board. The code will be merged into the main branch (repository) only when the work is approved.

No, real customer data (emails, Stripe customer ID, etc.) is never used for development or testing. We have a mock database which is used for development and testing.

No. Once the testing team certifies and approves code changes, a small group of key DevOps staff follow a carefully managed methodology to deploy new code into production.

Yes, we use tools for automated source-code analysis. These tools are developer productivity extensions for Microsoft Visual Studio that provide continuous code analysis and immediate detection of errors and problems. Our development teams use them to find runtime and compiler errors, code smells, and redundancies as they code. They are also used to scan existing code to ensure compliance with the most current coding standards.

Yes, Lucen Timeline is SOC 2 compliant. We’ve received our SOC 2 Type 2 Report, which provides an external audit that demonstrates we are meeting the security commitments we have made to our customers. We use Drata’s automation platform to continuously monitor 100+ internal controls mapped to the SOC 2 Trust Services Criteria, with automated evidence collection. Automated alerts and evidence collection allows us to confidently prove our security and compliance posture any day of the year, while fostering a security-first mindset and culture of compliance across the organization.

‍

If you believe you’ve discovered a bug in Lucen Timeline’s security, please get in touch at timeline-security@lucensoftware.com. Our security team promptly investigates all reported issues.