
The Lyosis application implements security concepts to protect sensitive data it can process and store.
As this application might be deployed both internally or in the cloud, we've assessed those design principles:
- User identification: we implement the principle of least privilege and enforce separation of duties with appropriate roles and permissions.
- Traceability: user actions are audited. By logging every database change, we can trace what happens to any data, by who, at what time.
- Security scan automation: we've shift security left by running Static Application Security Testing (SAST) on each source code change. This allows us to find security vulnerabilities that make our application susceptible to attack.
- Data in transit and at rest protection: any data that is being put over the network goes trough an encrypted communication (TLS). All stored data are encrypted, temporary files and backups.
- Containerization: our application is distributed as a Docker image to provide additional isolation than running together on the same host Operating System. This also allows to get rid of many system requirements (risk of not being able to setup again the same exact host installation) and a faster disaster recovery time (you just need Docker installed).
Security and compliance are a shared responsibility between BoneMonitor and the customer. A high level of technical security makes no sense if an administrator writes down his password on paper and is distributed to anyone who asks for it.
That is why we think that responsibilities should be explicitly shared.
Customer responsibility in the application - Customer responsibility is to keep user identification, host infrastructure access and secrets private. A secure usage.
BoneMonitor responsibility of the application - BoneMonitor is responsible for protecting sensitive data treatment, storage, and processes by implementing a high level of security trough encryption and design patterns.

- User management: you must grant your users access to the application. The customer is expected to handle user management, credentials distribution, roles, and permissions. To achieve a good securty level, please avoid shared account. If every person is identified by a separate account, you can give them the least privileges they need and leverage non-repudiation of changes they could have applied to the database.
- Installation key: when installing our software for the first time, you must provide an installation key. This is unique to your installation instance. An attacker that stole your data files would also need that installation key to decrypt and use them. The installation key is also needed to decrypt and restore a backup archive.
- Unencrypted documents produced: the application allows user to produce CSV or PDF documents that might contain sensitive data. It is your responsibility those documents are handled only by people that have the right to.
- Data accuracy: you are responsible of your own data you input in the system. Medical data can hurt patients if they are wrong or disclosed without medical opinion.
- Network & Firewall: reducing the application's network attack surface is the responsibility of the customer if deployed on premises. Our software only exposes one TCP port (443) for all network communications, that should help you reduce risks.
- Host system infrastructure: if an attacker can access the system hosting the application, he could potentially access your installation key and reset user accounts passwords.
- TLS Data in transit: out of the box, data are exchanged trough a single TCP port (443) encrypted with a default self-signed TLS certificate. This ensures all data going in or out of the application is encrypted while moving. For additional security, TLS certificate should be handled by a proxy (HAProxy, Trafik) in front of the application to provide full TLS compliance (the green lock in the URL bar).
- DB encryption data at rest: the inner database is encrypted. That means that even if working live files are stolen, you would need the installation key to exploit them.
- Authentication: the application provides an authentication mechanism to identify users.
- Backup: an automated backup is produced every night. The backup is encrypted and is expected to be secured before the next one is triggered. In that way, the application ensures the backups do not stay on the same system than the running application.
- Roles and Permissions: the application provides a fine-grained permissions system that can be granted trough roles, a set of permissions. It will allow you to implement the principle of least privilege.
- Logging: every user changes to database are logged to have a better comprehension of the current state of any data by tracing changes. It will give you the keys to investigate any incident.
- Software: our mission is to provide you the most secure software by checking our source code against known vulnerabilities. That is why every source code change triggers a Static Application Security Testing (SAST) that helps us to identify unsecured code or dependencies. With the help of automation, we can release fast and secure application updates.