1. Make Multifactor Authentication Nonnegotiable on Applications
Credential theft is the No. 1 threat to every online application, and K–12 apps are no exception. Asking students to use multifactor authentication may not be feasible, but all high-level logins (such as faculty or administrators) must be secured with some type of two-factor authentication. If you’ve already adopted an application that doesn’t have multifactor authentication enabled, turning that feature on is your first step.
2. Minimize Your Attack Surface Using Controls
For many SaaS applications, the easiest thing to do is open the virtual box and let people dive in. That’s very agile, but it can also leave you open to ill-chosen defaults. Take the time up front to configure, partition and isolate your data in the application to minimize possible damage. Many SaaS apps also offer access controls, such as geographic limits; if they’re not already in place, turn those on.
3. Pick the Right Tools for K–12 Users
Many cloud applications are aimed directly at the K–12 market, and software vendors will be familiar with the regulatory issues, such as compliance with the Family Educational Rights and Privacy Act, that apply to schools. While repurposing an application not designed for the education market may look innovative, it may not be worth the risk if the security doesn’t match K–12 privacy requirements.
DOWNLOAD NOW: This checklist has five simple steps to secure student data.
4. Federate Where You Can
The intersection of cloud applications and identity and access management systems is still a fuzzy target, both for IT managers and SaaS vendors. That doesn’t mean you should give up on trying to link your cloud applications to your own central authentication and authorization system. Look for this type of integration — and if it’s not there already, ask the vendor to add it to the development plan.
5. Make a Plan to Address Future Problems
It could be a data breach. It could be inopportune downtime or access issues. It might be accidental or malicious data corruption. IT teams may no longer have to keep the apps going, but if there’s a problem, they are responsible for coordinating the school’s response. If (or when) there’s a problem, having a written plan and knowing who will respond, who your security and audit counterparts are at the SaaS vendor, and what steps need to be taken, will reduce the likelihood of a small glitch becoming a major disaster.
MORE ON EDTECH: Discover security tools for districts in today's K–12 environments.
