How To Manage Remote Learning Security Risks Caused by EdTech

The surge in EdTech during the COVID-19 crisis is creating remote learning security risks that aren’t often well understood

Remote learning security risks are on everyone’s mind today. Since the coronavirus pandemic has closed schools, K-12 remote learning is the new reality in many places around the globe. Teachers are getting very creative in the ways that they are helping students continue to learn during this difficult time. Vendors are also providing schools with discounted or free access to remote learning resources.

As a result, the use of EdTech applications has increased significantly. Along with that comes an increase in the security risks faced by K-12 IT staff. It’s important that IT leaders understand and manage these risks to avoid cybersecurity attacks, accidental data loss, and other compliance issues during this unprecedented time.

A Review of EdTech Security Risks

Remote learning security risks with EdTech include vulnerability to ransomware, account takeovers, and data security issues. Many district IT teams know about a range of SaaS EdTech applications that their community uses, but the EdTech security risks increase with “shadow” EdTech.

Shadow EdTech describes applications that are connecting to district Google and/or Microsoft environments without any IT vetting or management. These were already notoriously difficult to identify before the shut-downs began. With everyone now working remotely, and with so many free offerings, it’s almost certain that you don’t know about all the applications your district’s community is connecting to your environment through OAuth.

This allows unrelated servers to authenticate access to data using an access token without needing access to the single sign-on credentials. The result is that OAuth risks are undoubtedly increasing along with the increased use of EdTech applications.

OAuth risks generally land into two different categories: malicious/intentional and accidental due to poor infrastructure security. Neither of these two reasons make risking data security and student data privacy OK from an ethical or compliance point of view. Either create serious account takeover risks that district IT teams need to protect their systems against.

5 Steps for Managing Remote Learning Security Risks Caused by EdTech SaaS

No one wants to compound the effects of the coronavirus pandemic with those of a serious cybersecurity attack. Using a remote learning checklist and completing these five steps will help you avoid getting into that situation.

1. Run a security audit

This cloud application security audit includes a checklist that you can use to spot cloud security issues you need to address. It will also give you the opportunity to identify the applications your community is using and the risk profile for each.

If you use G Suite and/or Microsoft 365, cloud application security isn’t just a “nice to have”—it’s a requirement.

Without it, you can’t monitor or control activities that go on within those applications. Hackers love exploiting this gap in your cybersecurity infrastructure. Including cloud security in your tech stack and protecting against that type of attack is even more important as remote learning and working security risks increase.

2. Create or Update Your Approved SaaS Vendor List

Teachers and district staff don’t really know whether the SaaS applications they find for remote learning are safe or not. Further, as many teachers, staff, and students are using their own (unmanaged) devices, many will authorize an app using their school credentials, whether on purpose or not. In most cases, your users simply don’t realize that SaaS EdTech can cause these remote learning cybersecurity risks.

To combat that problem, create a reference list of vetted and approved apps that they can check to see if the app is OK to use. This will help your users decide when to try a new application, and at least create some awareness around the data privacy and security risks.

It’s also a good idea to update the list as you conduct security audits. Using the right cloud security tool, you will be able to see what apps your teachers, staff, and students are using. You can then sanction or un-sanction these apps based on their risk profile (and the appropriateness of the apps being connected to a district account). Using this information helps keep the list of approved apps updated and relevant.

Similarly, and likely in the same document or other resource, you can create a list of unsanctioned/risky apps that are not allowed or have not yet been vetted. If you can impress upon your users how important it is to stay away from potentially dangerous applications, they may even start to contact you before they start using a new teaching aid!

3. Create an App Security Review Workflow

It’s a good idea to create a process for your teachers and staff to use to request a security review on applications that aren’t on your list described above. They may ask your advice without a process, but you can’t really count on that.

One idea is to create a Google Form (or other type of online form) that asks for at least the name of the application and the link where it can be found. After you’ve had a chance to do a student data privacy and security review, you can either approve or reject the application (and incorporate that information into your approved/disapproved app document for others to reference).

If you haven’t yet created a SaaS vendor list, using your approval form workflow would be a good place to start. Ask your users to list all of the SaaS apps they’re currently using. You can then do security reviews on those applications, and then generate a list of approved and rejected SaaS vendors and applications for distribution.

4. Set Up 24/7 Monitoring

Set your systems up with 24/7 monitors that will spot new SaaS applications as they connect. You can do a security review on any apps you’ve not already analyzed and update your approved/rejected list. If you discover an application you need to reject, you can remove the application from your environment and send a notice out to potential users along with the updated list.

If you’re using a cloud security application, you can also create policies around your app review to automatically monitor for and sanction or unsanction apps as they are connected to your environment.

5. Automate SaaS Connection Monitoring & Management

Naturally, the best way to keep your district’s data safe is to automate the monitoring process. An OAuth EdTech security platform can be configured to automatically perform sanctioning and unsanctioning. It can also remove unsanctioned applications from your Google and/or Microsoft 365 environments.

If you’re thinking that your next-gen firewall and/or web content filter has you covered when it comes to EdTech SaaS security, you are unfortunately wrong. If you think that all of this is the responsibility of Google, Microsoft, or whatever other SaaS vendor your district is using, you are also wrong.

But you are definitely not alone. A 2019 K-12 cybersecurity report from CoSN found that, while 100% of surveyed school districts use a firewall and a web content filter, only 3% use cloud security technology to monitor and secure their G Suite and Microsoft 365 environments. At the same time, millions of students, faculty, and staff are using these cloud applications every day to store, access, and share sensitive data (these numbers have reportedly doubled in the past month with the move to remote learning).

At the same time, a study from the K-12 Cybersecurity Resource Center found that the number of K-12 data security incidents tripled in 2019 compared to 2018!

To help keep K-12 school district’s cloud applications secured from EdTech and other data security risks through this coronavirus crisis, ManagedMethods is offering free access to our cloud security & student safety monitoring platform through May 31. This offer is exclusively for public and private K-12 schools and districts. ManagedMethods activates in minutes and requires no agents, proxies, or extensions.