Eagles
Target User: Level 1 / Junior SOC Analysts and small to mid-sized IT/Security Teams who handle high volumes of security alerts daily. The Problem: 1. Alert Fatigue & High Workload: Junior SOC analysts are overwhelmed by hundreds of raw server logs (e.g., Nginx, SSH, firewall) every day, leading to missed threats and critical delays in response. 2. Context Switching & Manual Analysis: Analyzing log entries manually requires cross-referencing multiple tools, causing slow Incident Response (IR) execution times. 3. Lack of Automated Remediation: Small teams often lack dedicated resources to write immediate detection/blocking rules (e.g., iptables, firewall policies) during live cyber attacks. Our Solution: Our AI SOC Analyst automatically ingests raw logs, filters noise, classifies attack severity with precise context, and instantly generates ready-to-deploy mitigation scripts—reducing analysis time from hours to seconds.
Preliminary score
- Value for the user16.5 / 25
A specific problem and a clear outcome from solving it.
- Prototype and use of AI16.0 / 30
A working core scenario, and what AI actually contributes to the result.
- Quality testing9.5 / 20
Tests, examples of failures, and comparison with the current approach.
- Feasibility7.0 / 15
Data requirements, running costs and a clear next step.
- Originality4.5 / 10
A meaningful difference from common solutions.
What the judges wrote
- GPT-6 AstraPreliminary53/100
- Strengths
- Your focus on junior SOC analysts and resource-constrained IT teams identifies a concrete triage and reporting problem. Your local pre-parser plus Gemini design assigns AI a meaningful contextual-analysis role while limiting unnecessary log volume. Your descriptions of quote-related false positives, encoded-payload misses, and token overhead provide useful, specific failure analysis.
- To improve
- Your prototype evidence would be stronger with a captured log-to-report-to-script run showing actual outputs; reconcile the Streamlit and rule-based detection deck with the FastAPI/Next.js and Gemini-based assessment described elsewhere. Your testing needs labeled case counts, false-positive and false-negative results, and timed baseline comparisons; HTTP status codes alone cannot establish exploit success or justify claiming false positives are eliminated. Your generated remediation scripts need validation and analyst approval, while uploaded logs should be treated as untrusted model input. Your feasibility plan should specify per-analysis costs, sensitive-log handling, and one scoped next milestone.
- Claude Opus 5.5Preliminary54/100
- Strengths
- You name a concrete user: junior SOC analysts and small teams without a SIEM budget. You also tie the pain to real log formats (Apache, Nginx, SSH auth.log). Your two-stage design is sensible: a local heuristic pre-parser aggregates brute-force counts and filters noise, so Gemini only sees suspicious lines, which cuts token cost and latency. Your failure write-up is specific and credible: regex flagging apostrophes in normal searches as SQLi, URL-encoded payloads slipping through, and single failed logins weighted too heavily. Your deck is also refreshingly honest that no speed or accuracy figures are claimed.
- To improve
- Your deck and your submission describe different products. The deck shows a Streamlit app, a 'conceptual dashboard mockup' and AI that only explains rule-based results; the submission and README describe FastAPI/Next.js and Gemini doing correlation and remediation. Add real screenshots of the deployed app and align the story. Turn testing into numbers: run a labeled set of benign and attack log lines through regex-only and regex+Gemini, and report false positives, misses and time-to-report versus a manual review. Add a rough cost per 10k log lines and a concrete pilot step, such as one SMB server for two weeks, and validate that generated iptables/Nginx rules are safe before anyone runs them.
The team
Rasul MammadliLead
developer
Nicat Safarov
data
Yusif Babayev
product