IoTEdu: Access Control, Detection, and Automatic Incident Response in Academic IoT Networks

The growing presence of IoT devices in academic environments has increased operational complexity and exposed security weaknesses, especially in academic institutions without unified policies for registration, monitoring, and incident response involving IoT. This work presents IoTEdu, an integrated platform that combines access control, incident detection, and automatic blocking of IoT devices. The solution was evaluated in a controlled environment with simulated attacks, achieving an average time of 28.6 seconds between detection and blocking. The results show a reduction in manual intervention, standardization of responses, and unification of the processes of registration, monitoring, and incident response.

💡 Research Summary

**
The paper presents IoTEdu, an open‑source, integrated security platform designed specifically for Brazilian academic campuses where the proliferation of Internet‑of‑Things (IoT) devices has outpaced existing management and protection mechanisms. The authors first outline the problem: universities such as UFRGS and Unicamp still rely on manual, bureaucratic onboarding processes that can take several business days, while other institutions lack any formal workflow, policy, or service‑level agreement for IoT devices. This results in ad‑hoc practices, inconsistent security postures, and an enlarged attack surface across hundreds of heterogeneous devices.

IoTEdu addresses these gaps by unifying three essential functions—access control, continuous threat detection, and automatic incident response—into a single end‑to‑end workflow. The architecture is organized into three logical layers. The frontend, built with Next.js, React, and TypeScript, provides role‑based interfaces (regular user, administrator, super‑user) and communicates with the backend via authenticated REST calls. The backend, implemented with FastAPI 2.0, follows a modular router pattern for authentication, device management, firewall interaction, and incident handling. Data persistence relies on MySQL with SQLAlchemy ORM and Pydantic validation, while authentication integrates OAuth2, SAML (CAFé), and JWT to interoperate with existing university identity providers.

The network‑management layer couples two mature open‑source tools: pfSense and Zeek. pfSense serves as the gateway, DHCP/DNS server, and firewall; its REST API is used by IoTEdu to create and modify aliases, filtering rules, and DHCP mappings automatically. Zeek continuously inspects all LAN traffic, generating alerts in notice.log whenever suspicious payloads are observed. A dedicated ZeekService parses these logs, forwards relevant information to an IncidentService, and stores each event in a relational table with severity classification. When an incident reaches a predefined criticality, the platform automatically triggers a blocking command through the pfSenseClient, which removes the offending device from the allowed list and adds it to a blocked list. The block is applied within one second, and a separate curl‑based monitor confirms loss of network connectivity.

The experimental evaluation was conducted in a fully virtualized testbed on a single notebook (Intel Core i7‑1185G7, 32 GB RAM). VirtualBox hosted a pfSense VM (4 vCPU, 8 GB RAM) and a Zeek instance; the IoTEdu API ran on the host OS. The test scenario consisted of two phases. First, a device registration request was issued, approved by an administrator, and the device’s MAC/IP were provisioned in pfSense’s allowed list. Second, an SQL‑Injection attack against a dummy server was launched using sqlmap, with the start time recorded. Zeek detected the malicious payload in an average of 12.1 seconds (range 11–14 s). The API then performed six sequential operations—authentication, device lookup, incident logging, correlation, rule generation, and pfSense update—taking an average of 16.8 seconds, identified as the primary bottleneck. The firewall rule was applied in 1.0 second, and the client lost network access after an additional 1.4 seconds. Across ten repetitions, the total mean response time from attack initiation to complete blocking was 28.6 seconds.

Resource usage remained modest: total RAM consumption was ~215 MB, and CPU load per service ranged from 6 % to 39 %, indicating that computational capacity was not a limiting factor. Detailed timing breakdown showed that the most time‑consuming stages were the incident‑processing functions (≈3.2 seconds) and the interactions with pfSense (≈4.6 seconds). Network latency introduced by the virtualized environment (host‑to‑VM round‑trip latency 1–237 ms, Wi‑Fi link 2–327 ms) contributed significantly to the overall delay, suggesting that performance gains would be achievable by reducing communication overhead and moving to a non‑virtualized or container‑orchestrated deployment.

The authors acknowledge several limitations. The current implementation depends on pfSense and Zeek, which may not be present in all campus networks. The detection logic is rule‑based; while effective for the simulated SQL‑Injection, more sophisticated or zero‑day attacks would benefit from machine‑learning‑enhanced anomaly detection. The sequential processing pipeline introduces latency that could be mitigated with asynchronous messaging (e.g., RabbitMQ) or micro‑service orchestration.

Future work outlined includes: (1) scaling studies with thousands of devices to evaluate resource consumption, latency, and incident throughput; (2) stress testing under high connection churn; (3) refactoring the API to use asynchronous, non‑blocking I/O and message queues to cut the 16.8‑second processing time; (4) integrating device fingerprinting and AI‑driven threat intelligence to improve detection accuracy; (5) extending the platform to support inter‑institutional threat‑information sharing, Zero‑Trust micro‑segmentation, and applicability to smart‑city or Industry 4.0 environments.

In conclusion, IoTEdu demonstrates that a tightly coupled combination of existing open‑source networking tools with a purpose‑built orchestration layer can provide rapid, automated protection for academic IoT deployments. The measured 28.6‑second average response time—substantially faster than manual remediation—validates the feasibility of the approach. By addressing the identified bottlenecks and expanding the detection capabilities, IoTEdu has the potential to become a reference framework for secure IoT management across diverse educational and research institutions.