UC-IoT

This project shows a software-only simulation of a Zero Trust framework applied to IoT networks.

Comment

Inspiration

In today’s world, billions of IoT devices power critical systems, from hospitals and smart cities to manufacturing and defense. But these same connected devices are now prime targets for cyberattacks such as ransomware, spoofing, and data breaches. Recent incidents, including attacks on hospital networks and energy infrastructure, show how one weak device can compromise an entire operation.

We were motivated to develop a Zero Trust IoT security architecture that enforces modern cybersecurity principles. Our system helps organizations stop attacks before they spread by continuously verifying every device and behavior without ever assuming trust. Zero Trust is more than just a policy when operational and digital safety are intertwined.

What it does

This project monitors security events from simulated IoT devices running in VirtualBox, showing live logs of allowed requests, denied spoofing attempts, and suspicious activity. Users can trigger simulated attacks with a single button to test the system. The dashboard automatically updates metrics and color-coded logs in real time, providing a clear and interactive view of the security state. This project integrates real-time monitoring, attack simulation, and an intuitive UI to visualize IoT device activity for security analysis.

How we built it

We built the dashboard using Streamlit for the user interface, Python for data processing, and Pandas to handle the log files. IoT devices were simulated using VirtualBox VMs, sending their data to a local gateway, which stores logs in real time. Attack simulations were triggered via a Python script, updating the dashboard automatically. We implemented dynamic metrics and color-coded logs to make security events easy to monitor.

Challenges we ran into

  • Endpoint restrictions affecting virtualization hardware access | Enterprise endpoint with some advanced security restrictions was unable to effectively create the virtualize nodes.
  • After multiple failed attempts to manually mount the .vdx file contained Ubuntu, we switched the virtual infrastructure to VirtualBox.
  • Ensuring persistence of the FastAPI service on VM-Gateway required interaction with systemd.
  • Potential ISO or VM configuration issues causing mid-write crash.
  • Sourcing and installed the Ubuntu 22.0.4 .iso file to an external drive caused I/O errors when attempting to create the virtual machines inside of VirtualBox.
  • Troubleshooting of non-NAT adapter traffic between client and server.
  • Host file modification. In other words, within the context of a private network for simulation, we needed to modify the host file in order to support DNS resolution in scope.
  • Enterprise level restrictions required copies of permissions across directories.
  • Working in the terminal for different python scripts to be created

Accomplishments that we're proud of

  • This was our first hack-a-thon as a team, and we quickly worked together to assume roles which played to our individual strengths.
  • Being able to work within the constraints of a less permissive enterprise device, while still being able to create a virtualized infrastructure.
  • Troubleshooting the implementation of the virtualized infrastructure and being able to shift from Hyper-V to VirtualBox.
  • Started a service on the VM-Gateway host and confirmed that port binding between 127.0.0.0:8000 is functional. (*Image: IT'S ALIVE! *); and ensuing that this service maintains persistence following power cycles using systemd modification.

What we learned

  • We learned that modifying the transmission states of virtual machine adapters i.e. modifying from [NAT-to-Intranet], VirtualBox allows users to "pause" the machine, and make changes the network adapter on-the-fly, instead of requiring a full power cycle, and modification to the VMs settings. We also learned how powerful the concept of Zero Trust can be when applied to real-world systems, especially in environments where reliability and safety are non-negotiable. Building the simulation taught us that security isn’t just about keeping attackers out, but about constantly verifying trust between every connected device. We saw firsthand how even small lapses in identity management could expose an entire network, and how enforcing principles like least privilege and continuous verification can prevent that. On the technical side, we gained experience integrating authentication frameworks like Auth0, designing secure API gateways with FastAPI, and visualizing security events through real-time dashboards. More importantly, we understood that cybersecurity isn’t just a technical challenge, it’s a societal responsibility that protects people, data, and the systems they depend on every day.

What's next for Zero Trust IOT

  • In the future, we plan to expand the dashboard to support real IoT devices in addition to the VirtualBox simulations. We want to integrate automated alerts using emails or text notifications when suspicious activity is detected. Adding advanced analytics for anomaly detection are also on the roadmap. Finally, we aim to make the system cloud-ready, so it can scale and monitor multiple gateways across different networks. In the future, Zero Trust IoT will evolve from a security framework into a core foundation for how connected systems operate. As billions of new devices come online, from hospital sensors to autonomous vehicles, the ability to verify each device’s identity, intent, and behavior in real time will be essential. The next step is combining Zero Trust with AI-driven analytics to detect anomalies faster and adapt policies automatically. We also expect growth in hardware-backed identities using secure elements and TPMs, ensuring devices can prove who they are at a hardware level. Additionally, edge computing will play a major role, pushing Zero Trust enforcement closer to where data is generated, rather than relying on central servers. Ultimately, Zero Trust IoT will help create ecosystems that are not only connected but self-defending, where every device continuously earns and maintains trust before it can interact with others.

Built With

  • 0.0.0.0
  • adapter
  • apt
  • bridging
  • client-server-network
  • connectivity
  • curl
  • dhcp
  • endpoint
  • etc/hosts
  • firefox
  • firewall
  • gateway
  • gemini
  • host
  • hostname
  • hyper-v
  • ifconfig
  • indentation
  • internal-network
  • ip-addr
  • iptables
  • ipv4
  • localhost
  • logs
  • nat
  • nc
  • netplan
  • networkmanager
  • node-1
  • node-2
  • openai
  • permissions
  • ping
  • port
  • pycharm
  • python
  • service
  • snap
  • static-ip
  • subnet
  • symlink
  • systemd
  • tarball
  • testing
  • ubuntu
  • ufw
  • update
  • uvicorn
  • virtual-box
  • virtualbox
  • yaml
Share this project:

Updates

posted an update —

We got all three servers running, got the python scripts running to test those servers as well. We also have the dashboard set up to capture the logs. We also completed our video and successfully submitted everything.

Log in or sign up for Devpost to join the conversation.

posted an update —

Part 1 Complete:

  • Successfully implemented our security monitor, which was created using Pandas and Streamlit and offers crucial operational insight for our Zero Trust rules.

Key Features & Technical Details:

  • Architecture: Dashboard runs on Streamlit and uses Pandas to ingest and process data directly from the gateway’s live log.txt file.

Data Source:

  • Ensures constant, real-time reflection of the network's current security posture by parsing all gateway policy decisions.

Live Security Monitoring & Metrics: We provide instant validation of the security system through three dynamic metrics:

  • Allowed Requests (ALLOWED): Tracks successful, authorized traffic.

-Denied Attempts (DENIED_SPOOFING): The most important measure which counts attempts where an unauthorized device or role violates the Zero Trust access policy.

  • Suspicious Events (SUSPICIOUS): Tracks activity that falls outside of expected behavioral patterns.

Operational Intelligence (Color Coding): The Live Security Logs table uses conditional coloring for immediate visual alerts:

  • Red (CRITICAL): Denied Spoofing attempts, confirming policies are actively defending against unauthorized access.

  • Yellow (WARNING): alerts about unusual activity or possible exploitation.

  • Green (NORMAL): Confirms authorized access and successful transactions.

Policy Validation and Testing: A core feature demonstrating instant testing and validating policy effectiveness

"BIG RED BUTTON":

  • Triggers the attack_simulator.py script, which sends malicious and spoofed requests to the gateway.

Purpose:

  • We can quickly verify that all Zero Trust rule updates are appropriately enforcing the DENIED_SPOOFING state and verify system resilience under malicious load.

Project Impact:

  • The dashboard is the operational centerpiece of our Zero Trust model

  • The dashboard provides transparency and accountability by verifying that the security framework works in a real world scenario.

  • Provides quick visual identification and context for important security events, which significantly speeds up incident response times.

Log in or sign up for Devpost to join the conversation.

posted an update —

Here's a quick update from my side (Role 1).

The Gateway is Live

I've got the "brain" of our project, the gateway.py server, fully built and tested.

  • The FastAPI endpoint is up and running.
  • I successfully integrated the Auth0 (OAuth 2.0) logic. Instead of just faking it with our own tokens, our gateway is now verifying real identity tokens against Auth0's servers.
  • It's correctly checking the token's permissions (scopes) and sorting "Heart Monitor" traffic from "Hacked TV" traffic.
  • It's also logging every single attempt (GRANTED, DENIED_POLICY, DENIED_SPOOFING) to the log.txt file, so Role 3 (Dashboard) should be able to see all the data coming in now.

I'm ready to git clone this into the VM-Gateway as soon as the network is up.

Log in or sign up for Devpost to join the conversation.

posted an update —

Role 4 is my “red team / QA” hat, I play the threat actor so we can prove the gateway actually does what it’s supposed to do. In practice I write and run the malicious simulators (spoofing, fake JWTs, replay/expired-token tries, etc.) and hammer the mock hospital network to see whether a device can fake a heart monitor, steal access, or access the vitals DB without the right key. The goal isn’t to break things for real but to validate the Zero-Trust assumptions: if I don’t have the correct token/role the gateway should deny me and log a clear DENIED_SPOOFING or DENIED_POLICY event. I also act as the project’s QA, I tune attack cadence so the demo is dramatic but controlled, confirm the dashboard shows the right red alerts, and collect reproducible test cases and log lines to hand back to the team. Importantly, I do all of this in an isolated test environment (VMs or an internal virtual switch), with the team’s consent, and I document each failed check and a suggested fix so the Gateway Architect can harden the system.

Log in or sign up for Devpost to join the conversation.

posted an update —

This script represents the trusted IoT device in our Zero Trust setup, the real heart monitor that should be allowed to send data to the hospital network. It continuously sends heartbeat and oxygen readings to the gateway’s /vitals-db endpoint every two seconds, along with a valid JWT token that verifies its identity. When I run it, I’m basically showing what normal, authorized traffic looks like in our system. The gateway checks the token, recognizes the device as legitimate, and logs an “Access Granted” event that appears as a green “Allowed” entry on the dashboard. It’s a simple but effective way to prove that trusted devices can communicate smoothly under the Zero Trust framework, while anything suspicious or unauthorized like the attacker script gets flagged or denied in real time.

Log in or sign up for Devpost to join the conversation.

posted an update —

My attacker script is the “make trouble” tool, it repeatedly sends a POST that pretends to be the heart monitor (HM-123) but with an intentionally fake JWT. The goal is to prove the gateway is actually checking identity and policy, not just IPs: when the fake token hits the gateway you’ll see DENIED_SPOOFING or 401 in the logs and the dashboard lights up in red, while the real heart monitor stays green and uninterrupted. I tweak the attack cadence and payload so the demo is dramatic but controlled, and I tie this script to the dashboard’s button so I can trigger the spoof live and walk the judges through what’s happening.

Log in or sign up for Devpost to join the conversation.