This article is also available in:
This document contains the guiding principles at how at Easy LMS we maintain the security and privacy of our customers.

Security comes in layers and we have five guiding principles that allow us to have more and better layers of security within our organization and our product. Each of these five principles will be discussed separately in this document. Our five main security principles are:

Prioritize security principle
Discuss security principle
No unmaintained software principle
At least 4 + 2 eyes principle
Least privileged access principle

Prioritize security principle

Whatever we do, we fix security first.

No piece of software is without bugs, and even though we do our best effort to have the highest possible quality of our product, we are no exception to this. This means that sometimes we do find (potential) security issues within our system. Whenever the issue is present within our production installation, the logged bug is given top priority to ensure that no backlog exists of unresolved security issues. If multiple security issues are found, then the security issue with the highest severity is given priority.

In the scenario in which a security issue is found before it landed on our production environment, a process exists to make sure that further deployments of the vulnerable code are prevented until the security is resolved. Since it might keep us from deploying new features, these issues are also given priority for fixes.

We often say it's better to be safe than sorry. We think that ensuring a secure product is not about patching issues that are encountered, but about making sure that these issues never would exist in the first place. Hence, we think that security should be a priority right from the earliest stages of development to design security right into our product rather than patching things afterwards.

Discuss privacy/security principle

If we don't think and discuss on how to improve, we never will.

Although security is discussed and implemented at the heart of our software, we think there is always room for improvement. Having a conversation helps us to keep us focused and sharp on how we approach security. Also, a discussion is a way to transform good ideas into great ideas, and good designs into great designs. More importantly, since there is always room for improvement, a discussion can enable us to find out what we need to improve rather than what we can improve. Security is always as strong as the weakest part and when it comes to improving security, only improvements to your weakest part will actually improve your security. Hence, we believe that the ongoing conversion should always be kept alive about what our weakest part is, and how we can improve on that.

No unmaintained/unsecured software principle

Our software is not secure if the platform it runs on is not.

We did not invent the wheel, and certainly did not write our own operating system. So, yes, we depend on the code of third parties. This means that we also need to make sure that this code is secure. For the operating system (a linux flavor), the programming language environment (php / node), our http server (apache), and database systems (MariaDB), we make sure that we always use a version that at least still receives security patches. This means that our software is regularly updated to run on an up-to-date version. Also, it makes sure that we stay secure throughout, as for these components, we require that security patches are installed automatically.

For libraries that we use in our code, we use automated tools wherever possible to ensure that these have an up to date version, but more importantly a secure version. In practice we use 'npm audit' to make sure that our node.js packages are up to date. And we use 'roave/security-advisors' to make sure that our php libraries are secure.

At least 4 + 2 eyes principle

Every change, no matter how trivial it may seem, must be verified for quality.

To uphold the quality that we aim for, we believe that no matter the circumstances, our software should never be rushed. This means that a full review cycle is required for every change that we make to our product. This means that the code needs to be seen and approved by at least two developers and then tested by one of our testing team. This principle is anchored within our work flow. Before code can deployed onto a staging or production environment, it needs to pass a pull request. Pull requests must be reviewed by at least another developer. The actual merging back is done by someone of our testing team. Hence, a developer is in principle not able to merge back a pull request. Security is (obviously) part of the review cycle. The other developer will assess the code in order to see whether there are security related issues. The tester also tests for common security mistakes to prevent unnecessary leaks into our system.

A special mention should be made about infrastructure/system administration. Since the code development cycle allows for assessing security and quality before it hits production, we strive to manage our full infrastructure as code. This enables us to automate most of the features, which means we make fewer human mistakes. Furthermore, a single system administrator can make changes without notification that could affect our system security.

Least privileged access principle

Every person person must only have access to what he or she needs and every program should only be able to access what it needs.

The most reliable way to prevent any form of data leak, is by making sure that there is no data to leak whatsoever. The next best thing is to make sure that no one can access the unneeded information. For example, a developer does not need access to our production data to develop new features. Similarly, a translator only needs to see what can be translated in our system, and does not require access to our code base or customer information. We aim to make sure that anyone in our organization only can see and perform the tasks that is required for his or her role.

The least privileged access principle applies to humans, but it's also applied to systems and services. If a part of our system is compromised, we aim to minimize the impact it can have. Therefore, we aim to separate out services that can only access the information that they need. For example, we don't need to process payment information when displaying learning content. Hence, the systems responsible for learning content should not have access to our payment system. Furthermore, this is also possible for other services. We aim to disconnect services from the public internet if possible. This is preferably done by placing services into a private network, from which they can only be accessed from that network. If the service is not intended for public use, but is meant to be accessed over the internet we work with a white list of IP-addresses, to minimize exposure.

Final notes

We believe an ongoing effort is required to maintain a high level of security. This effort means that it should not stay with principles, but that these principles should be embedded in all our workflow processes. In this way, we can make sure that security has priority within our organization.
Was this article helpful?
Thank you!