IT for education providers

Education IT is often treated as ordinary business IT on a tighter budget. The budget is usually tighter, but the interesting differences are structural, and a design that ignores them will fail in predictable ways.

Three properties distinguish it, and each one changes an architectural decision.

Everyone arrives at once

Business load is distributed across a day. Education load is not: a timetable means several hundred people connect within the same two minutes, and again at the start of each subsequent period.

This produces a specific failure. A network sized on average concurrent users behaves acceptably almost all the time and fails at exactly the moment it is most visible, and it fails in ways that look like something else — slow authentication, devices that will not associate, applications timing out.

• Size wireless for simultaneous association at period boundaries, not for average concurrency. Device density per access point is the constraint, not total bandwidth.
• Authentication is the usual bottleneck. Several hundred simultaneous authentication requests is a different load profile from several hundred users being connected.
• Assume multiple devices per person. A phone, a laptop and a tablet are three associations and three addresses.
• Check address pool sizes against peak devices rather than headcount, since exhaustion presents as intermittent connection failure with no obvious cause.
• Load-test at the boundary, not in the middle of a session.

The seasonal version of the same property matters too. Enrolment periods, results days and term start concentrate load into hours in a way that no business equivalent does, and capacity that is comfortable in November is not automatically comfortable in September.

The population turns over every year

Businesses experience gradual staff turnover. Education replaces a substantial proportion of its user population annually, on a known date, all at once.

That makes identity lifecycle a designed process rather than an administrative task, and doing it manually does not scale past the first year.

1. 1

   Automate provisioning from the authoritative record

   The student information system is the source of truth. Accounts, group memberships and access should derive from it rather than being created alongside it.

2. 2

   Automate deprovisioning on the same basis

   This is the half that gets skipped, and it is why education estates accumulate thousands of active accounts for people who left years ago.

3. 3

   Decide what happens to leavers' data before the first cohort leaves

   Retained, archived, or deleted, on a stated period. Deciding it during the first leaving season produces an inconsistent answer that persists.

4. 4

   Handle the people who are both

   Staff who study, students who work. An identity model with one role per person breaks on them, and the workaround is usually a second account nobody tracks.

5. 5

   Plan for the annual rollover as an event

   It is the single largest identity change of the year and it happens the week before everyone returns.

A significant part of the user base is testing the network

This is not a criticism and it should not be treated as an unusual threat. In an environment containing several hundred young people, some of whom are studying computing, a proportion will explore what the network permits. Some of it is curiosity, some is circumvention of filtering, and occasionally it is more.

The consequence is that education networks are probed continuously from the inside, which is the position most business network designs assume is rare.

• Segment student devices from staff and administrative systems firmly, not nominally. The systems holding assessment data and personal records should not be reachable from the student network at all.
• Assume the student network is hostile and design it that way. This is a straightforward design position and it is simpler than the alternative.
• Apply the data plane protections that prevent one device attacking others — rogue DHCP and ARP spoofing are on-network attacks that a perimeter never sees.
• Expect filtering to be circumvented and design so that circumvention has limited consequence, rather than relying on the filter as a boundary.
• Protect the network devices themselves properly. A switch with default credentials on a network like this will be found.

Safeguarding obligations

Education providers commonly carry duties relating to the safety of the people in their care, and those duties have technical consequences that other sectors do not have — filtering, monitoring, and retention of records that may be needed later.

The specific obligations differ by jurisdiction and this article does not state them. Two engineering points hold generally.

First, monitoring that exists for safeguarding is monitoring of minors, and it therefore needs the strongest access controls in the estate. Who can see it, what they can see, and a record of who looked, are not optional details.

Second, a filtering or monitoring system that produces alerts nobody reviews satisfies no duty at all. The reviewing process is the control; the technology only supplies the input.

Budget reality, honestly

Education budgets are genuinely constrained and advice that ignores this is not useful. Three things deliver the most per unit of cost in this setting.

• Automating the identity lifecycle. It removes recurring administrative effort every year and closes the dormant account problem at the same time.
• Segmentation. It requires configuration rather than purchase, and it limits the consequence of the internal probing described above.
• Wireless sized for the peak. Under-sizing here produces continuous, visible failure that consumes support time indefinitely, so it is rarely the right place to economise.

Conversely, the least effective spending in this sector is usually additional filtering sophistication, because the population adapts to it faster than it can be tuned, and it is not the control that limits consequence.