Security, Security, Security. Slate. Security.

The higher ed world was abuzz yesterday because some bad folks decided to hack into three institutions via password resets at the institutional level (Single Sign-On and, via that access to student details, such as applicant information). The students were sent emails offering them a view of their application, including comments, scores, etc.,effectively an inside view of how their application had been received by the institution. This is certainly newsworthy and Eric Hoover did his job and jumped on the story.

I followed the story, the feedback from school counselors and college employees in a massive Facebook group, various threads on Twitter. I set up a Google alert and responded to concerned clients.

Technolutions, next to the SCIF in which I spent five years working on documents at the TS/SCI level, is an incredibly secure and cautious company when it comes to access and security. I didn’t feel anxiety for my clients. If I had any, it would have been further diminished by the email that was sent directly from Alexander Clark to all Security Administrators in Slate in addition to the security banner that was displayed across all instances all day long. Not only did the email clearly articulate the situation, it also provided helpful context for best practices and security in general. I’m not going to share the email here, but this morning Liz Gross shared a perfect thread to sum this all up. 

While Slate was the platform in which this data was stored, it was not, in fact, hacked. The institution was hacked and that’s a much larger problem.

This situation offers us an opportunity to talk about permissions and security in Slate and how institutions should be using them. One of the services RHB offers is a complete diagnostic of your Slate instance: what you’re doing well, where you can improve, and what opportunities exist ahead. We’ve completed a dozen or so of those in the last year and while not always the case, utilizing permissions, roles, or realms typically comes up in conversation. I also field this question a lot when kicking off implementations: “Can we lock this down?” Yes. My response is basically canned at this point: You can permission the heck out of Slate.

There are 70 standard permissions, including exclusive permission settings, spread across the system that allow you to modify views from the module down to a specific field. These are divided in most places into Read and Write configurations to allow further customization. Beyond that, you can create limitless custom permissions to fit your processes. Want to lock down which types of records certain users can see? Super. Use population restrictions, a whole OTHER layer of permissions. Want to hide specific records from everyone except one or two people? Great. Lock down individual records. Want to give someone the ability to see the things they’ve built but nothing else unless you give them specific access to a form or event registration? Top notch idea. Base module permission + template sharing options at four different levels configured on a user, permission, or role basis. Want to get an intermediate permission in something like queries where you can view queries for a certain type of user? Realms. User-aware experience? Permissions. Ability to SEND emails? Permission AND you have to type something in a field, just a friendly precaution to make sure you’re intentional. You can probably gather that Technolutions doesn’t take security lightly.
In Slate, you need to design a security strategy. This takes time. And effort. And a solid understanding of how everything in the system is interrelated. It’s daunting. But it’s so important.

However, security and permissions in Slate only matter to the extent that your institution is protected. And so, if you didn’t read Liz’s thread above, here’s an important part.

Time to get your security on.