The State of Security in the LMS Industry

It’sbeen a couple of years since I stepped down as CEO of Litmos LMS(learning management system), but I’ve always had a passion for learning, so Ihave tried hard to stay connected to the industry. I’ve also always had a keeninterest in security, and that interest grew as Litmos started to appeal tolarger companies. Security reviews and concerns would often come up in thebigger deals, and Litmos would always satisfy requirements. I guess it was aculture of security from the early days that eventually paid off in the longrun.

Bythe time I was ready to move on from Litmos, it was clear to me that protectingthe sensitive data and trade secrets that companies upload into softwareproducts like the LMS would be my next gig. As a result, ThisData was born, and ourfirst attempt to address this problem was to look at backup. However, whilethis is useful, we wanted to get to the root cause of why the data gets lost inthe first place. A SANS Institute report revealedthat for 95 percent of the data that has been breached or stolen online, theproblem started with a single user’s login details being compromised. In thesecurity industry, they call this a phishing attack. For the rest of us, it’sjust a nightmare followed by multiple expletives.

Why does LMS security matter?

Let’sroll things back a bit and look at the state of security in the LMS industry—asoftware service where companies upload trade secrets, go-to-market strategies,and various other types of sensitive data that could spell disaster in thewrong hands. A breach of the LMS could result in a loss of competitiveadvantage, or worse, a compliance infringement. Either way, it’s bad.

Fortunately,most of the leading LMSs have good security practices. They secure back-endinfrastructure, use SSL, offer single sign-on, adhere to certifications likeSOC 2, and get external security audits. A few also participate in bug bountyprograms. I tip my hat to those vendors for a job well done; as a customer, I’dbe looking for a new LMS if mine didn’t support these basic hygiene factors.

Soherein lies the problem: LMS vendors are taking care of back-end infrastructureand process security, but that doesn’t change the fact that 95 percent of databreaches are through the front door of the house. Attackers know you do a goodjob of securing infrastructure, so the end users are a much easier target.

Thisis an incredibly hard problem to solve, as most users simply don’t care aboutsecurity. They don’t listen to the training, they don’t use a password manager,and they’re not going to add friction to their life by enabling two-factorauthentication. In fact, Neil Lasher recently wrote a great cybersecurity articlethat, among other things, revealed the extremely poor password choices so manypeople make.

Sohow do we solve this problem and help users protect their accounts and thesensitive data stored in an LMS? If you’re thinking we need more education,more training, more boxes to tick, I’d ask you to think again. With the rapidlyincreasing number of attacks and data breaches, it’s evident that the trainingjust doesn’t work. People simply tick the boxes and yawn their way through thesecurity training to satisfy their company compliance rules. It’s like thatdefinition of insanity that says something about repeating the same thing overand over while expecting a different result.

Ipropose an alternate solution, one that attempts to protect users whileallowing them to continue using their dog’s name as their password. Plus, theiraccounts will remain just as secure as if they had used a more complexcombination of characters and symbols. Better yet, it won’t add friction to thelogin process or require any behavioral changes by the user.

Infact, it is the user’s behavior that you can utilize to add an additional layerof security to the LMS. By monitoring things like devices, locations, and the timeof day the LMS is typically accessed, then cross-referencing those factors withintelligence data collected about known hacker profiles and risky IP addresses,we can accurately predict whether the user accessing the LMS is who we think itis. If they don’t exhibit the same behavioral patterns, then we alert the LMSadministrator or the user about this unusual activity that was detected.

Onceagain, we can take a few cues for software development from the consumer web.Facebook and Google have been running systems like this for a couple of yearsnow, and it really works. After all, the last thing you want is someonehijacking your Facebook account and posting cat photos to your page (unless, ofcourse, you’re really into cats).

Asa bonus, when you start thinking about using behavior to authenticate users, awhole new realm of possibilities starts to pop up. For example, suppose youhave a compliance requirement to verify a user throughout an online course orassessment. Rather than having the user enter a password over and over again,this verification could be done continuously in the background. This way, youknow with more certainty it’s the same user and not just someone signing infrom another location to complete the course for them.

Vendors need to own user security

Here’smy final thought on this: The technology now exists to solve these issues andfurther protect our data without end-user involvement, yet we keep on beatingthat same old drum about the need for “more security training” and blamingusers for their weak passwords and insufficient security practices when there’sa breach. In reality, we’re really only as strong as our weakest link. Isn’t ittime for software vendors to stop blaming users and start doing more to help byway of engineering the users’ lack of security know-how out of the equationcompletely?