Skip to main content

Building CyberCube: An AI-Powered SOC Platform from Packets to Alerts

Updated 5 min readMarkdown

Most security tools tell you something is wrong. A good one also tells you why, and what to do next. CyberCube is a security operations (SOC) platform I built to do all three: it reads network traffic, flags threats with a machine-learning model, and explains each alert well enough for an analyst to act on it.

Where it started

CyberCube began as our major project. We could have built another full-stack app, but we wanted to try something different, so we moved into cybersecurity as an experiment. This post covers what we built and what its numbers do and do not mean.

From packets to alerts

Traffic can enter the platform in two ways:

  • PCAP upload. You drag a packet-capture file into the web app. A parser I wrote unpacks the binary data field by field, reading the Ethernet, IP and TCP headers by hand. It then groups packets into two-way flows and runs the model on each one.
  • Live capture. The sniffer tries to capture packets directly from the machine's network interface. That needs administrator privileges. When they are missing, it falls back to generated traffic so the live view keeps working. That fallback is meant for demos, not as real capture.

Detected threats appear on a React dashboard through a WebSocket connection (/ws/threats), so new alerts arrive without refreshing the page. The dashboard includes alert tables and a global threat map that plots where attackers appear to come from.

The dataset, and an honest caveat

Training a detection model needs labelled traffic. I generated a dataset of 12,000 records with 22 features, designed to follow the CIC-IDS2017 schema, and included attacker locations and MITRE ATT&CK labels. The data is synthetic. That means the accuracy numbers below show the pipeline works from end to end, but they are not a claim about performance on real-world traffic.

Choosing a model

I needed a classifier that is accurate, fast, and explainable, because analysts will only act on alerts they trust. I benchmarked four on an 80/20 split of the data (2,400 test samples):

  • Gradient Boosting matched the accuracy but was about 1.8 times slower, roughly 30 microseconds per prediction against 17.
  • The neural network was faster but less accurate, and hard to explain.
  • Logistic Regression was the fastest but the least accurate.
  • Random Forest gave the best balance.

I deployed Random Forest: about 99.5% accuracy, 99.37% macro-F1, around 17 microseconds per prediction, and explanations that show why each flow was flagged.

Explaining every alert

A label like "DDoS, 98% confidence" is not enough for an analyst, so each alert comes with more:

  • SHAP waterfall charts. SHAP shows which features of a flow, such as the timing between packets or the count of TCP flags, pushed the model toward "attack" or "benign".
  • MITRE ATT&CK mapping. Each threat type is tagged with a standard technique ID. For example, DDoS maps to T1498, port scans to T1046, brute force to T1110, web attacks to T1190 and botnet traffic to T1071.
  • Plain-language summaries. The Gemini API turns an alert into a short root-cause explanation, sent through a backend proxy so the key stays on the server.

From detection to response

CyberCube also helps you act:

  • Firewall rules. One click generates commands to block an attacker's IP: netsh advfirewall for Windows, iptables for Linux, and rules for Suricata and Snort.
  • PDF incident reports. A report contains the severity, attacker location, MITRE technique, all 22 flow metrics, the SHAP-based root cause, and a space for the analyst's signature.

Multi-tenancy and deployment

Several organizations can use the same platform without seeing each other's data. Users sign in with Google OAuth, and every threat record carries a tenant key derived from the user's email using HMAC. Session tokens are signed and expire after 12 hours, and the WebSocket only delivers alerts that match the connected user's key.

The backend is FastAPI with SQLAlchemy, using SQLite by default and PostgreSQL (Neon) in production. A script injects sampled flows from the dataset into the system on a schedule, run by GitHub Actions, which keeps the dashboard populated. The app is deployed on Render and Vercel.

What I would improve next

  • Train and test on real CIC-IDS2017 data and compare it with the synthetic results.
  • Test the live sniffer on real network traffic instead of relying on the demo fallback.
  • Add more attack types beyond the five currently mapped.
  • Write automated tests for the PCAP parser and the prediction pipeline.

Takeaways

A detection model is only useful if an analyst can trust it and act on its output. The explanations, the standard threat labels and the ready-made firewall rules were as much of the project as the classifier itself. And being clear about what synthetic data can and cannot prove makes the results more believable.

About the author

  • Hi, I'm Nartan, a Software Engineer focused on full-stack and AI applications, in my final year of B.E. Computer Science at NIE Mysuru. I came to CSE from a diploma in Automobile Engineering, so I like knowing how systems really work. What I've built: • CreatorLens AI: curates Instagram creator profiles; a staging pipeline gets past Vercel's 10-second limit • Unpack: AI codebase documentation; a custom scanner cuts LLM input by 98% • CyberCube: AI threat detection and SOC platform with explainable alerts Stack: React, Node.js, FastAPI, Flutter, Python, JavaScript, C++, SQL, Firebase, MongoDB, Supabase, PostgreSQL, Docker, GitHub Actions. I write about real project problems: serverless limits, LLM context and cost, API security, and shipping ML into products. Open to Software Engineering internships in India. GitHub: github.com/NartanNaik LinkedIn: linkedin.com/in/nartan-naik-90499a359

No comments yet. Be the first to comment.