It’s been 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 I have tried hard to stay connected to the industry. I’ve also always had a keen interest in security, and that interest grew as Litmos started to appeal to larger companies. Security reviews and concerns would often come up in the bigger deals, and Litmos would always satisfy requirements. I guess it was a culture of security from the early days that eventually paid off in the long run.
By the time I was ready to move on from Litmos, it was clear to me that protecting the sensitive data and trade secrets that companies upload into software products like the LMS would be my next gig. As a result, ThisData was born, and our first attempt to address this problem was to look at backup. However, while this is useful, we wanted to get to the root cause of why the data gets lost in the first place. A SANS Institute report revealed that for 95 percent of the data that has been breached or stolen online, the problem started with a single user’s login details being compromised. In the security industry, they call this a phishing attack. For the rest of us, it’s just a nightmare followed by multiple expletives.
Why does LMS security matter?
Let’s roll things back a bit and look at the state of security in the LMS industry—a software service where companies upload trade secrets, go-to-market strategies, and various other types of sensitive data that could spell disaster in the wrong hands. A breach of the LMS could result in a loss of competitive advantage, or worse, a compliance infringement. Either way, it’s bad.
Fortunately, most of the leading LMSs have good security practices. They secure back-end infrastructure, use SSL, offer single sign-on, adhere to certifications like SOC 2, and get external security audits. A few also participate in bug bounty programs. I tip my hat to those vendors for a job well done; as a customer, I’d be looking for a new LMS if mine didn’t support these basic hygiene factors.
So herein lies the problem: LMS vendors are taking care of back-end infrastructure and process security, but that doesn’t change the fact that 95 percent of data breaches are through the front door of the house. Attackers know you do a good job of securing infrastructure, so the end users are a much easier target.
This is an incredibly hard problem to solve, as most users simply don’t care about security. 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-factor authentication. In fact, Neil Lasher recently wrote a great cybersecurity article that, among other things, revealed the extremely poor password choices so many people make.
So how do we solve this problem and help users protect their accounts and the sensitive 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 rapidly increasing number of attacks and data breaches, it’s evident that the training just doesn’t work. People simply tick the boxes and yawn their way through the security training to satisfy their company compliance rules. It’s like that definition of insanity that says something about repeating the same thing over and over while expecting a different result.
I propose an alternate solution, one that attempts to protect users while allowing them to continue using their dog’s name as their password. Plus, their accounts will remain just as secure as if they had used a more complex combination of characters and symbols. Better yet, it won’t add friction to the login process or require any behavioral changes by the user.
In fact, it is the user’s behavior that you can utilize to add an additional layer of security to the LMS. By monitoring things like devices, locations, and the time of day the LMS is typically accessed, then cross-referencing those factors with intelligence data collected about known hacker profiles and risky IP addresses, we can accurately predict whether the user accessing the LMS is who we think it is. If they don’t exhibit the same behavioral patterns, then we alert the LMS administrator or the user about this unusual activity that was detected.
Once again, 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 years now, and it really works. After all, the last thing you want is someone hijacking your Facebook account and posting cat photos to your page (unless, of course, you’re really into cats).
As a bonus, when you start thinking about using behavior to authenticate users, a whole new realm of possibilities starts to pop up. For example, suppose you have a compliance requirement to verify a user throughout an online course or assessment. Rather than having the user enter a password over and over again, this verification could be done continuously in the background. This way, you know with more certainty it’s the same user and not just someone signing in from another location to complete the course for them.
Vendors need to own user security
Here’s my final thought on this: The technology now exists to solve these issues and further protect our data without end-user involvement, yet we keep on beating that same old drum about the need for “more security training” and blaming users for their weak passwords and insufficient security practices when there’s a breach. In reality, we’re really only as strong as our weakest link. Isn’t it time for software vendors to stop blaming users and start doing more to help by way of engineering the users’ lack of security know-how out of the equation completely?