Learner Data Privacy (and what SIF can do to help)
As school IT staff, we handle very large volumes of learner information and, although it seems “everyday” to us, this information represents the identities of hundreds to millions of children and teachers whose data we maintain. Now, type “school data breach” into your favorite search engine and see for yourself how frequently this information is “lost” or falls into the wrong hands. This article is not intended to talk about how bad things are or alarm anyone (beyond the previous sentence) – its purpose is to outline some ways an educational institution can prevent it from happening.
Practices we recommend here are not the “throw the baby out with the bath water” techniques so often recommended as proper security that make everything so secure that nothing works properly. We also try to avoid suggesting policies like “change your password every 17 days to one you’ve never used before with 4 alphabetic (2 upper and 2 lower case), 4 numeric, and 3 special characters and make sure to not write them down”.
Policies like this end up being the least secure of all because they go far beyond the capabilities of their audience and in practice, the passwords end up getting written down somewhere (sticky notes). Strong passwords are good, but it is also important to remember that you are working with normal people who are also trying to memorize perhaps 20 to 30 other passwords with somewhat similar cycles and restrictions.
What we are presenting are technologies that allow those that need to work the tools to do their jobs with minimal interference, and at the same time, an infrastructure that makes this data transfer more reliable, secure and private by using software that keeps track of the data as it delivers it. If questions arise later, it provides auditors with powerful tools to quickly answer questions.
One note before getting too far: when we use term “learner” in this article, we will be referring to students but also teachers, bus drivers, cafeteria workers, administrators and anyone else whose personal data may stored in one of the many systems found in an educational institution.
In this article, we will consider several areas that all contribute to keeping data secure and private:
- Participants: who can access this data and on whose computers (or devices, networks) will this data sit (be transmitted, …)
- Software features designed specifically for data privacy
- Tools available to IT professionals
- Tools available to Educational professionals
(things in dark red are those that are going to be covered by most of the detail of this article)
There are many people, companies, computers, networks and other devices that come in contact with learner personal data. Some that come to mind are:
- People and Companies
- Learners, Teachers, other School Staff (employees)
- IT Staff (they generally have different permissions than do other school staff)
- Outside people who fix computers, suppliers from whom you buy applications and through whom you get support
- Computing facilities:
- Servers that host administrative applications
- Servers that host shared academic applications
- Servers that host dedicated, specialized applications
- Applications that share data through SIF
- “In the cloud” hosted applications
- Desktop computers in the classroom
- Learner-owned computing devices (laptops, others)
- Devices such as USB memory devices, portable hard drives
- Internal administrative networks
- Internal academic networks (perhaps different from the administrative network (on a different subnet))
- Internet public network
- VPNs and connections to other larger private networks
Some of these items above perhaps are already properly addressed, but all need to be properly addressed (or at least reviewed) before a school’s data can be considered private and secure. So, let’s take a look at them in detail.
People and Companies
Teachers, Other Employees and IT Employees
Since IT staff have access to all student information, we recommend that they be required to have the same background checks as would teachers. This may be different than current policy, but if so, you should consider changing your policy. We would assume that almost every school would have the first item handled properly as well as the second, at least in the UK. In the US, the first item (Teachers) is likely to be handled well, but if required at all, IT staff are often only required to have a “criminal background check” as they are in Pennsylvania. If that is the case, we would suggest upgrading the type of check to the same as those for teachers. In Australia, we would recommend that IT personal be required to have the “WWC” background level check.
This gets more difficult, especially when those companies are located in a different country. But, in order to ensure learner data privacy, these suppliers must also fall under these security checks. Local suppliers:
- If these contractors come in contact with learner data, then they should be background checked, just as an IT employee would.
- They should not bring in USB memory sticks or external hard drives or anything else that could be used to take data back out.
- If they use a screen-sharing technology for support, it should be one where the local IT person “invites” the support person and participates in the session (the remote person cannot make an unattended or non-shared session).
Suppliers from other countries: This is where things get potentially more difficult, especially when the issue of customer support is considered. The same principles as those listed (above) for local suppliers should apply, but some new issues arise:
- Have all the employees in the supplier’s company had background checks similar to those they would have received in the local country?
- If in the process of diagnosing a problem, student data leaves the country, does the data in the suppliers country have similar learner privacy protections as it did the data was in the country of origin?
At Visual Software, since we have been asked to address these issues by our UK customers, we have made business adjustments and taken steps to address these concerns:
- Each employee, no matter what the job function gets the same level of background check as would a teacher in our local public school system and has it renewed each year.
- Visual Software has become what is known as an “US-EU Safe Harbor” certified company. In this way, we have adjusted our policies and customer support methods so that we don’t have situations where learner personal data ever gets stored on our computers, causing such problems. Presently, Visual Software is the only SIF supplier to be US-EU Safe Harbor certified.
Safe Harbor Certification
According to the US Department of Commerce: The European Commission’s Directive on Data Protection went into effect in October 1998, and would prohibit the transfer of personal data to non-European Union nations that do not meet the European "adequacy" standard for privacy protection. While the United States and the European Union share the goal of enhancing privacy protection for their citizens, the United States takes a different approach to privacy from that taken by the European Union.
The United States uses a sectoral approach that relies on a mix of legislation, regulation, and self-regulation. The European Union, however, relies on comprehensive legislation that, for example, requires creation of government data protection agencies, registration of databases with those agencies, and in some instances prior approval before personal data processing may begin.
As a result of these different privacy approaches, the Directive could have significantly hampered the ability of U.S. companies to engage in many trans-Atlantic transactions. In order to bridge these different privacy approaches and provide a streamlined means for U.S. organizations to comply with the Directive, the U.S. Department of Commerce in consultation with the European Commission developed a "safe harbor" framework. The safe harbor — approved by the EU in 2000 — is an important way for U.S. companies to avoid experiencing interruptions in their business dealings with the EU or facing prosecution by European authorities under European privacy laws.
Certifying to the safe harbor will assure that EU organizations know that your company provides "adequate" privacy protection, as defined by the Directive. If you are in the United Kingdom, considering implementing SIF and working with a US supplier who is not Safe Harbor certified, it might be worth reading the document, especially sections 2.3 and 2.4: (the title below is a link to the document)
[[“Data Protection Act 1998, The eighth data protection principle and international data transfers The Information Commissioner’s recommended approach to assessing adequacy including consideration of the issue of contractual solutions, binding corporate rules and Safe Harbor.”]]
Well, the most important topic that we could talk about are the applications that share data through SIF. In terms of data privacy, there are many topics even within SIF transfer – for example:
- Object level permissions: restricting data from going where it doesn’t need to go based on the object designation
- Element-level filtering: further restricting the dissemination of the information to applications at the element level
- Does your provider publish more than it needs to? Does your publishing SIF agent allow you to tailor what it publishes?
Object Level Permissions (ACLs)
Object level permissions have been around since the first versions of SIF. They are commonly referred to as ACLs or Access Control Lists. They are a list of permissions assigned by the ZIS administrator that control what a SIF agent connection is allowed to do at a particular connection. For example, the following is a screen on a ZIServer administration screen where the administrator sets these permissions
Element Level Security
In March 2008, we began to hear from the community (mostly in the UK) that there was a need for a higher level of control over how data was being distributed and that the requirements of the UK Data Protection Act required that we add functionality to our ZIServer product to give this level of control. Since nothing in the existing specification prohibited us from doing so, we added “Element Level Security” shortly thereafter. Since then, this has been adopted as part of the SIF standard, both in the US and in the UK. In ZIServer, if an object has elements that may be restricted and that object is being activated for this agent, a green (no restrictions have been set) or yellow (restrictions have been set) button appears at the end of its row as in this example:
If the user clicks on the link, he or she will see the element level filtering options for that object as in this example:
Pushing the button next to the element will cause that element to be stripped out of any message before it is delivered to this agent.
Publishing More Than You Need To…
The best approach of all to privacy, of course, is to not publish the things that don’t need to be published. In the words of the wise teacher, Mr. Kesuke Miyagi (from Karate Kid II, 1986):
“Remember, best block, no be there.”
So, if your agent allows, don’t publish those fields that you know none of the subscribing agents will need. We designed this capability into our ZIAgent™ configurable agent knowing that this would be a common need:
In this example, we are choosing not to publish “CitizenshipStatus”. Although we may store it in the student management system and the SIF agent is capable of distributing it, we also know that no other application will ever need it. The most secure way of protecting that value is to never distribute it in the first place.
Blanket Level Filtering and Managing Zones
A separate but very large topic in and of itself is the management of zones. In large enterprises with hundreds to thousands of SIF zones, you should consider the effort that will be involved with the management of all those zones and the thousands of agents connections in those zones. Because most of the learner data is managed at the school level in the UK, this issue became clearest to us there.
To address this need, we created our Envoy product and the concept of “Managed Virtual Zones”. Managed Virtual Zones allows an organization to create a “Virtual SIF Zone” from a group of other SIF zones. For example, 20 school SIF zones could be grouped together forming a single Local Authority Virtual Zone. An application hosted at the LA could register in that zone instead of connecting separately to all 20 school zones. The Managed Virtual Zone administrator would then only need to administer one set of permissions for the LA application. There are many other advantages; you can read more about the technology in Scalability and Reliability.
In summary, data privacy is best maintained by:
- Not publishing the data you don’t need to publish in the first place
- Only publishing what is needed by each application that receives it (choke off what is not needed by a subscriber at the ZIS)
- Make sure that if the data is moving off-site that it is encrypted and that both ends have used digital certificates to identify each other.
- Know beforehand where the different types of data can go
- Know beforehand who has access to sensitive data and make sure they have been properly background checked
- Keep track of what data has been distributed and where it has gone (keep accurate, full audits)
- Have the necessary tools so that the people with the proper access authority can get to the audits if and when they are needed. In an emergency, you don’t want to need to resort to bringing in a third party just to read the audits (see number 4 above).
Yes, there are many, reasonable measures that can be put in place to ensure the privacy of learner and teacher private data. These are a few to get the discussion started. If you have others, you can make them known in our user forums.