Handling & securing Data
At Maglr, we are aware of the risks when it comes to handling and securing data. Every day we are working on new functionalities for our platform. And during this process, we have to consider the security for every aspect.
Within the platform, we explicitly choose to not gather and store personal data of visitors of Maglr publications. With this choice, we align with the current GPDR regulations. We do save the credentials of our platform users with their company details. These credentials are needed for login access. Articles of publications can, however, also contain personal data depending on the type of editorial content, such as contact info.
The biggest risk of a possible security breach could be split into two situations. The first situation would be that an uninvited guest could gain access to the user data described above (name/email/hashed password). With this information, the guest can now access data and the content of projects on our platform. This should not be a risk initially as long as there is no secure content or sensitive information, since Maglr is mainly used as a platform to publish public content. The greatest risk, however, is when projects are deliberately being edited and published by people who don't have the authority. For example, changing content to display misinformation or even deleting complete projects.
In case of a security breach at Maglr, the first action we undertake is to fix or close the issue that is causing the problem for this specific situation. All user accounts will be temporarily locked from the back-end. The Maglr platform will still be functioning for the visitors reading and accessing publications. But until further notice, all users are not able to edit or create new content.
Based on the specific problem we will notify all clients or the specific client, depending on the problem. This will happen within 24 hours.
Examples of security breach situations:
When someone gains access through a regular login route within the system using a stolen password (or a simple password), we do not see this as a real security breach. In this situation, the client itself is informed.
When someone gains access through a security leak into our server infrastructure and potentially have access to all content, we will inform all clients of the platform.
Although we do our best to make Maglr as safe as possible for everyday use, we recommend that you do not upload "very sensitive" information within our platform at all times. Maglr is set up as a publishing platform to share information publicly. There are several security options available, but always be aware that content is uploaded to "the cloud". An incorrect entered setting in a 'secured project' can cause the information to become public and reach platforms like Google. The most common problems with security vulnerabilities are mistakes of human nature.
The steps we take to keep Maglr as secure as possible:
Maglr employees understand the usefulness of security and are reminded of this every week by our small team, combined with developers. It is something that plays an everyday role, due to the continuous activities related to developments in our Maglr platform. There is great awareness when it comes to security;
Local workstations are provided with passwords, automatically locked screensavers and anti-virus software. Passwords must be changed every six months;
Network/file access is divided based on different permissions per user, combined with firewalls and VPN access;
For services such as Microsoft 365 mail, Two-factor authentication is always used where possible;
Employees are taught not to share sensitive data through unsecured channels from third-party tools. Microsoft 365 mail is the main tool to communicate;
A limited number of people have access to the infrastructure and underlying internal or external servers;
Our office location in Breda is secured with an alarm and equipped with video surveillance, only accessible to Maglr employees;
Backups are stored offsite in a locked room.
The operating systems on the various installed servers are automatically provided with security patches and kept up-to-date with market-compliant versions;
Third-party modules or open-source plugins used in our software are kept up-to-date;
All servers run within Amazon Web Services network are equipped with different security layers and firewalls + two-factor authentication for access;
Only specific employees with the correct credentials have access to these AWS servers + 2FA;
Code deployment is done via CI/CD with integrated test situations and code approvals. This provides a central point where all code changes have to go through when putting new code updates live;
All steps within the platform and actions on the server are logged. We can look back what happened and what caused it, even when a page inside Maglr is suddenly changed;
Servers are monitored for security vulnerabilities by external software combined with automatic penetration tests.
The risks
Within the platform, we explicitly choose to not gather and store personal data of visitors of Maglr publications. With this choice, we align with the current GPDR regulations. We do save the credentials of our platform users with their company details. These credentials are needed for login access. Articles of publications can, however, also contain personal data depending on the type of editorial content, such as contact info.
Security breach
The biggest risk of a possible security breach could be split into two situations. The first situation would be that an uninvited guest could gain access to the user data described above (name/email/hashed password). With this information, the guest can now access data and the content of projects on our platform. This should not be a risk initially as long as there is no secure content or sensitive information, since Maglr is mainly used as a platform to publish public content. The greatest risk, however, is when projects are deliberately being edited and published by people who don't have the authority. For example, changing content to display misinformation or even deleting complete projects.
When something goes wrong
In case of a security breach at Maglr, the first action we undertake is to fix or close the issue that is causing the problem for this specific situation. All user accounts will be temporarily locked from the back-end. The Maglr platform will still be functioning for the visitors reading and accessing publications. But until further notice, all users are not able to edit or create new content.
Based on the specific problem we will notify all clients or the specific client, depending on the problem. This will happen within 24 hours.
Examples of security breach situations:
When someone gains access through a regular login route within the system using a stolen password (or a simple password), we do not see this as a real security breach. In this situation, the client itself is informed.
When someone gains access through a security leak into our server infrastructure and potentially have access to all content, we will inform all clients of the platform.
Pay attention to what you put online
Although we do our best to make Maglr as safe as possible for everyday use, we recommend that you do not upload "very sensitive" information within our platform at all times. Maglr is set up as a publishing platform to share information publicly. There are several security options available, but always be aware that content is uploaded to "the cloud". An incorrect entered setting in a 'secured project' can cause the information to become public and reach platforms like Google. The most common problems with security vulnerabilities are mistakes of human nature.
The steps we take to keep Maglr as secure as possible:
Office situation:
Maglr employees understand the usefulness of security and are reminded of this every week by our small team, combined with developers. It is something that plays an everyday role, due to the continuous activities related to developments in our Maglr platform. There is great awareness when it comes to security;
Local workstations are provided with passwords, automatically locked screensavers and anti-virus software. Passwords must be changed every six months;
Network/file access is divided based on different permissions per user, combined with firewalls and VPN access;
For services such as Microsoft 365 mail, Two-factor authentication is always used where possible;
Employees are taught not to share sensitive data through unsecured channels from third-party tools. Microsoft 365 mail is the main tool to communicate;
A limited number of people have access to the infrastructure and underlying internal or external servers;
Our office location in Breda is secured with an alarm and equipped with video surveillance, only accessible to Maglr employees;
Backups are stored offsite in a locked room.
The Maglr platform:
The operating systems on the various installed servers are automatically provided with security patches and kept up-to-date with market-compliant versions;
Third-party modules or open-source plugins used in our software are kept up-to-date;
All servers run within Amazon Web Services network are equipped with different security layers and firewalls + two-factor authentication for access;
Only specific employees with the correct credentials have access to these AWS servers + 2FA;
Code deployment is done via CI/CD with integrated test situations and code approvals. This provides a central point where all code changes have to go through when putting new code updates live;
All steps within the platform and actions on the server are logged. We can look back what happened and what caused it, even when a page inside Maglr is suddenly changed;
Servers are monitored for security vulnerabilities by external software combined with automatic penetration tests.
Updated on: 08/02/2023