eLearning Security: How to Keep Data Protected in Your Open Source LMS
Protecting user data and sensitive information in your Learning Management System (LMS) should be taken very seriously. eLearning security is essential in preventing costly regulatory penalties around incidents related to leaked personal information, confidential organizational data, or other potential security risks. And according to TeachPrivacy.com, protecting privacy is essential to people’s trust in an organization. Your prospective customers, clients, partners, vendors, and employees need to feel assured that any private information shared or recorded is kept safe from hackers, competitors, or other threats.
Defense in Depth Approach
The best approach to achieving the highest levels of protection for your data is what, in cybersecurity parlance, is called “Defense in Depth.” This approach leverages multiple security mechanisms to provide layers of protection much like the layers of an onion. On the Moodle™ or Totara Learn open-source LMS platforms, there are 6 layers of protection. From the top layer of the onion, there’s SSL which protects data being sent and received from your site, followed by SSO authentication, site registration, password security, role and permissions and finally backups and disaster recovery. Read on to learn more about each of these layers. To learn more about the difference between open-source and closed-source LMS systems, read “Open-Source vs. Closed-Source: Why the Technology Your LMS Uses is Important."
Secure Socket Layer (SSL)
SSL is a standard security technology which establishes an encrypted connection between your website and a user’s web browser. The technology uses encryption algorithms to scramble the data, thus preventing it from being read while in transit. This allows data (such as login details) to be transmitted between the two in a secure manner. Without SSL, however, this data is sent in plain text which would permit prying eyes to capture this information using a “sniffer” and then use it to maliciously access your site. To establish this secure connection, an SSL certificate must be installed on a web server which performs two functions:
- It authenticates the identity of the website thus guaranteeing that visitors do not visit a fraudulent site, and
- It encrypts the data being transmitted.
From the end user’s perspective, with this certificate in place, the URL of the web site will start with “https://” (as opposed to “http://”) and, depending on the web browser, they will see the familiar padlock icon in the address bar. We strongly recommend that all learning management systems use SSL technology to ensure the security of their user’s data. This is especially important when authenticating with other systems which leads me to the second layer of the security onion: authentication.
Authentication is the ability to verify the identity of a user or process. Basically, it determines whether someone or something is who or what they say they are. This is analogous to having the keys to the door and is essential for keeping unwanted (and unauthenticated) users out of your platform. One issue that often arises from this need to authenticate users, though, is that users may have multiple login credentials for the many accounts they have on the Internet and local networks. This is where SSO authentication comes into play. SSO, or Single Sign-On, allows for the centralization and management of user authentication in one location. This means that users only need one set of credentials to access all their accounts. It also means that users only need to remember a single password and are less likely to write them down in unsecure places. Moodle™ and Totara offer a variety of solutions for SSO authentication. These include integrations with LDAP (Lightweight Directory Access Protocol); SAML2 (Security Assertion Markup Language) for connecting to any number of authentication management platforms such as Azure AD, Okta, and OneLogin; CAS (Client Access Server) integration; Shibboleth; and OAuth2 for authenticating via Google, Office365, LinkedIn, Facebook and others. In addition to the above options, there are also a number of third-party authentication options from which to choose. As you can see, the Moodle™ and Totara Learn platforms are no slouches when it comes to SSO authentication. One may choose one or multiple types of these authentication methods when setting up your site. We strongly recommend using SSO authentication to simplify your authentication needs. As you can see, the Moodle™ and Totara Learn platforms are no slouches when it comes to SSO authentication. One may choose one or multiple types of these authentication methods when setting up your site. We strongly recommend using SSO authentication to simplify your authentication needs.
In many ways, site registration works in tandem with authentication. While authentication controls when and how users can log in to your site, registration handles when and how they can sign up. With Moodle™ and Totara Learn, administrators can simply turn off this option if they don’t want users to have this ability, thus limiting their access using one or more of the above authentication methods. To the contrary, administrators can “open up” a site by allowing email-based self-registration which allow users to create their own accounts. These registrations, however, can be controlled by limiting them to specific email domains and even require the approval of the site administrator. If email-based self-registration is enabled, then we recommend using both domain-based registration and administrator approval in addition to reCaptcha which ensures that the person trying to sign up is a real body and not a spambot.
Along with authentication and site registration options, password security is another important part of the defense-in-depth strategy. There is quite a bit that Moodle™ and Totara Learn administrators can do to ensure that users have strong passwords. They can configure the password policy by defining how many characters it should have, how many digits, lowercase or uppercase letters, and how many non-alphanumeric characters there should be. They can also define how many times a user must change their password before they can reuse old ones. They can force users to log out after changing a password, which is always a good idea. Finally, they can define the maximum time to validate a password reset request and the number of failed logins before the account is locked. We recommend a strong password policy for all users on your Moodle™ or Totara Learn systems. One thing to keep in mind is if you ARE using an SSO for authentication, the password policy will need to be defined via the SSO method being used.
Roles and Permissions
Authentication, registration, and a strong password policy control how a user can access your Moodle™ or Totara Learn sites. What happens after they get in? How does one control what a user can do and see on your site? This is where user roles and permissions become so very important. User roles and, consequently, the permissions users receive from being given these roles control what users can do on a Moodle™ or Totara Learn site. Basically, roles are a collection of bundled permissions that users can be assigned to control what they can access, see and do. There are numerous out-of-the-box predefined roles available on both systems. For example, the “authenticated user” role simply gives the most basics access to users. They can access the dashboard, their profile page and user preferences. From there, users can be given additional roles such as student, non-editing teacher, editing teacher, course creator and manager. Don’t worry if one of these pre-packaged roles don’t meet your needs. It’s simple enough to modify their bundled permissions and a site administrator can even duplicate these roles and create custom roles like teacher’s assistant, incomplete student, department heads, and instructional designer. In addition to defining and customizing roles and role permissions, user roles can also be defined by the context types where the role may be assigned. They can be assigned at the system, user, category, course, activity module and block levels. So, in addition to defining a role and setting it permissions, a site administrator can control where these roles can be assigned and even who can do the assigning. The result is that both Moodle™ and Totara Learn provide a very robust infrastructure for controlling what users can do once they log in to the system, thus further fortifying the site.
Backups and Disaster Recovery
While all the above layers of security are paramount to defending your site against attack, it’s worth mentioning that unfortunately, in a world of cyber trolls and hacker collectives, it’s not about if your site will be hacked, it’s only about when, so it’s critical that you also have your data backed up. While technically not a security measure, a good backup and disaster recovery protocol should be included in a proper defense-in-depth strategy. They are both critical if something goes awry on your site. The Moodle™ and Totara Learn LMS systems offer very robust backup and restore options. Backup of courses can be made both on-demand by a teacher, a site administrator, or for that matter, anyone with a role that provides the permissions to do so. Backups are also usually made based on a set schedule of automated course backups for the whole site. Furthermore, teachers and administrators can select from a variety of options when making these backups. Should the backup include enrolled users and user data? Activities and resources? How about blocks, filters, comments, completion data, course logs, grade history (and much, much more).. Furthermore, when making automated backups, they can be made once a week or every day, include partial course data or all course data. As you can see, Moodle™ and Totara Learn offer powerful solutions for protecting user data. If you are interested in an open-source LMS and want strong security features, then the choice is simple. Contact us to learn more about any of these security features or LMS solutions. Or, request an individual demonstration below.