Network security monitoring for education

Place the first Suricata and Zeek sensors at the internet edge, where traffic leaves and enters the campus, and then add visibility at the boundaries that matter most on a campus: between the guest and wireless zones and the administrative network, at the uplinks of residence halls, and at the entrance to any research enclave that holds sensitive data. The edge sensor shows inbound scanning and outbound command-and-control patterns, but it cannot see what happens once a compromised student laptop reaches a database. Residence uplinks are often where the largest volume of unmanaged devices appears, so a sensor there gives the security team a view of the population most likely to be infected, without requiring agents on personal hardware. For each placement, decide between a network tap and a switch span port. A tap copies traffic passively and does not depend on switch configuration, which matters when a span port is shared with other monitoring jobs or drops packets under load. A span is cheaper to start with but must be checked for mirror-port limits on each switch model. Do not size sensors from throughput figures in vendor brochures or from a campus average. Measure peak traffic at each point during a site survey, and confirm the link speeds, sensor counts and NIC configuration against that measurement before buying hardware. Security Onion's hardware documentation lists minimum sensor specifications, which is a starting point, not a sizing answer. Do not limit monitoring to the perimeter. Student record systems, the learning management system and the identity provider create east-west traffic between internal segments, and most of the risk to student records sits on that path. Plan at least one sensor position that sees traffic into the segment holding the student information system, and agree with the registrar and the IT team which hosts and database ports must be visible. Before the site survey closes, confirm the expected link speeds, the number of sensors per building and whether the research and administrative VLANs can be mirrored without disrupting the systems they carry.

Full packet capture is the setting most likely to put education records into a security tool. A capture stores payloads, not just connection summaries, so a single session to a student information system, a financial aid portal or an email client can hold names, grades, Social Security numbers or disciplinary notes in plain text where the traffic is not encrypted end to end. Under FERPA (34 CFR Part 99), those records are personally identifiable information from education records, and the institution must keep a record of each disclosure, including who accessed it and their legitimate interest (34 CFR 99.32). An analyst who opens a packet store and reads a student's session is therefore making a disclosure decision, not just running a query. Before enabling full capture on any sensor at a campus edge or residence network, confirm with counsel whether the traffic in scope can carry education records and whether the access log your Security Onion deployment produces can answer the 99.32 question for each review.

The default position should be metadata first. Zeek writes connection records and application-layer logs such as DNS, HTTP and SSL certificate data, which supports most investigations without retaining payloads. Security Onion's full packet capture through Suricata can then be scoped to segments that carry no student data, such as guest Wi-Fi or research lab subnets with no records, and kept off the student and administrative VLANs unless a documented need exists. Confirm in the Security Onion configuration which capture settings apply per sensor and per node role, and test that capture is not running on the administrative segment by default. Restrict the packet store and search nodes to a small named group of analysts, separate from people who administer the school's systems, and review that group each term. Access control of this kind is what the institution needs to show under 34 CFR 99.31(a)(1)(ii), which requires reasonable methods so school officials see only records in which they have a legitimate educational interest.

Retention is the decision most likely to be made by default rather than by design. Set a packet retention period in writing before the sensors go live, record who approved it, and have counsel confirm it against FERPA's record-keeping duties and any state student privacy law that applies. The period should be as short as the investigations require, and the institution should know how it will delete captures at the end of that period. FERPA enforcement can reach the whole institution: if it does not comply, the Secretary may withhold further payments, issue a cease and desist order or terminate funding eligibility under 34 CFR 99.67, so an undocumented capture program is a funding risk, not only a privacy issue. Ask your partner to document the capture scope, the access roster, the retention decision and the disclosure log format as part of the rollout handover.

Start with the question that decides whether the project can legally proceed: will the partner accept school official status under 34 CFR 99.31(a)(1)(i)(B)? Ask them to show, in writing, how they meet the three conditions: the work is one the institution would otherwise assign to its own staff, the institution keeps direct control over how education records are used and maintained, and the partner follows the redisclosure limits in 99.33(a). Ask whether their confidentiality terms name packet captures, Suricata alert records and Zeek logs as potentially containing personally identifiable information, and whether they will log each access by their staff to those stores so the institution can meet the recordkeeping duty in 34 CFR 99.32. Ask also how they will support access limits by role, since 34 CFR 99.31(a)(1)(ii) expects technological controls that keep staff within their legitimate educational interests.

Next, ask how they place sensors at residence and guest edges and what they will capture there. Ask which span or tap points they propose for student housing uplinks, the guest wireless boundary and the administrative segment, and whether they will record only connection metadata at the residence edge while leaving full packet capture off by default. Ask how they handle student-owned devices in alert tuning: whether they can suppress noise from peer-to-peer traffic, game consoles or BYOD malware scanners without hiding activity on administrative systems, and how each suppression is recorded and reviewed. Request a sample of the rule set and the suppression list they expect to deliver, and ask who approves changes to them.

Finally, ask about upgrades and handover, because the platform itself is moving. Security Onion 2.4 reached end of life on October 1, 2026, and 2.4 installations on Oracle Linux 9 can upgrade to version 3 only after full packet capture moves from Stenographer to Suricata, while other distributions need a fresh install. Ask the partner which path they recommend for each node, how they will test the migration on a non-production manager, and what happens to retained data during the move. Ask for a written handover plan for a small team: runbooks, alert triage procedures, a named list of administrative accounts, and training sessions that show staff how to run the Detections interface and the soup update process. Also confirm whether the quote covers Security Onion Pro, which adds OIDC single sign-on and API features, and what support the partner provides once the engagement ends.