1. الفكرة الهندسية للمشروع: إيه هو SentinelAI؟

1. System Architecture Overview: What is SentinelAI?

منصة SIEM & SOAR ذكية قائمة على تتبع سلوك الـ IP التراكمي والرد الفوري

Stateful AI-Powered SIEM & SOAR SaaS Platform for Real-Time Threat Correlation & Active Defense

SIEM + Stateful Redis + 2-Stage AI + SOAR

المفهوم الأساسي للمنصة (Core Concept) Core Architectural Concept

SentinelAI مش مجرد أداة بتقرأ كل سطر Log لوحده وتصنفه؛ دي منصة SIEM & SOAR متكاملة بتسحب الـ Logs لحظياً من 4 طبقات في سيرفر العميل (Firewall، Nginx، Backend App، وLinux OS) عن طريق Fluent Bit، وتوحد شكلها في Unified JSON Schema، وتبني لكل IP كارت متابعة تراكمي حي في Redis، وبعدها تمررها على محرك ذكاء اصطناعي من مرحلتين (Two-Stage AI) عشان يكتشف الهجمات المركبة ويحظر الـ IP المهاجم على الفايروول بضغطة زر أو تلقائياً.

SentinelAI is not a basic single-line log classifier; it is a full-lifecycle SIEM & SOAR SaaS platform. It collects real-time logs across 4 infrastructure layers (Firewall, Nginx, Backend App, and Linux OS) via Fluent Bit, normalizes them into a strict Unified JSON Schema, tracks cumulative attacker behavior in Redis Stateful Profiles, runs a Two-Stage Hybrid AI Engine to synthesize multi-step attack storylines, and executes instant firewall blocks.

1. شق الـ SIEM (الرصد والتوحيد) 1. SIEM (Centralized Telemetry)

Security Information & Event Management

بدل ما كل سيرفر يرمي الـ Logs بتاعته في ملفات متفرقة ومحدش يشوفها، الـ SIEM بيجمع كل الأحداث من الشبكة والسيرفر والتطبيق في مكان مركزي واحد، ويوحّد صيغتها عشان نقدر نحللها مع بعض.

Instead of leaving logs scattered across isolated server files, SIEM aggregates telemetry from network firewalls, web proxies, apps, and OS endpoints into one unified pipeline.

2. الربط الزمني (Stateful Profiling) 2. Stateful Behavioral Correlation

Redis Sliding Window + Two-Stage AI

الهاكر الذكي مبيعملش الهجوم في سطر واحد؛ بيعمل Scan على الفايروول، وبعدين يخمن باسورد الـ SSH، وبعدين يضرب SQLi في الموقع. عن طريق كارت الـ IP في Redis، الـ AI بيشوف القصة كاملة ويرفع الـ Risk Score تدريجياً.

Real attacks span multiple layers over time (Port Scan → Brute Force → SQLi). By maintaining a rolling Redis IP Profile before invoking AI, we catch low-and-slow multi-stage attacks.

3. شق الـ SOAR (الرد الفعلي والحظر) 3. SOAR (Active Firewall Response)

Security Orchestration, Automation & Response

المراقبة لوحدها مش كفاية لو الهجوم شغال الساعة 3 الفجر. شق الـ SOAR بيخلينا نبعت أمر فوري لـ Response Agent على سيرفر العميل يقفل الـ IP المهاجم على الفايروول (ufw / iptables) سواء أوتوماتيك أو بضغطة زر.

Passive alerts aren't enough during active breaches. SOAR closes the loop by dispatching authenticated block commands to the victim server's firewall (ufw / iptables) automatically or via one click.

2. رحلة البيانات من السيرفر لحد الحظر (5 مراحل تفاعلية)

2. End-to-End Data Pipeline (5 Interactive Stages)

اضغط على أي مرحلة عشان تستعرض التراك المسؤول عنها وإزاي بيسلّم المرحلة اللي بعدها

Click any stage below to inspect track ownership, technical logic, and data handoffs

3. عقد البيانات الموحد (Unified Schema) وتقسيمة المهام بين الـ 3 Tracks

3. The Unified Data Contract & Track Scope Boundaries

عشان كل تراك يشتغل بشكل مستقل بدون تعارض، دي شكل الـ JSON الموحد وحدود مسؤولية كل فريق

Strict JSON schemas and clear boundaries so all three tracks can develop and test independently

1. Unified Normalized Log Schema (Output of Normalizer)

{
  "event_id": "evt_99201a8b",
  "timestamp": "2026-11-05T14:21:12.000Z",
  "tenant_id": "org_zagazig_demo",
  "source_layer": "WEB_SERVER",
  "service_name": "nginx-reverse-proxy",
  "actor": {
    "src_ip": "197.55.12.40",
    "src_port": 54321,
    "username": "admin"
  },
  "target": {
    "dst_ip": "10.0.0.5",
    "dst_port": 443,
    "endpoint": "/products?id=1' UNION SELECT username,password FROM users--"
  },
  "event": {
    "action": "HTTP_GET",
    "outcome": "SUCCESS",
    "status_code": 200,
    "raw_message": "GET /products?id=1%27%20UNION%20SELECT..."
  }
}

2. Redis Stateful IP Profile (Sent with Log to AI)

{
  "redis_key": "state:ip:197.55.12.40",
  "ttl_seconds_remaining": 3420,
  "first_seen": "2026-11-05T14:15:00Z",
  "last_seen": "2026-11-05T14:21:12Z",
  "layers_touched": ["FIREWALL", "LINUX_OS", "WEB_SERVER"],
  "counters_1h": {
    "total_events": 42,
    "firewall_blocks": 6,
    "failed_logins": 18,
    "distinct_ports_targeted": 6,
    "web_4xx_5xx_errors": 11
  },
  "current_risk_score": 68,
  "recent_actions_timeline": [
    "14:20:01 [FIREWALL] Blocked TCP scan on ports 21, 22, 3306",
    "14:20:45 [LINUX_OS] 18 failed SSH login attempts for root/admin",
    "14:21:12 [WEB_SERVER] Suspicious SQL keywords in GET /products"
  ]
}

الـ Track Team Track	المهام المطلوبة منك بالتحديد (Your Exact Scope) Core Deliverables (In Scope)	حاجات ملكش دعوة بيها (Out of Scope) What You Ignore (Out of Scope)
Web Track (Front + Back) Web Track (Front + Back)	استقبال الـ Logs على `POST /api/v1/ingest`، وتحويلها للـ Unified Schema، وتحديث كارت الـ IP في Redis، ومكالمة سيرفر الـ AI، وعرض التنبيهات وقصة الهجوم لحظياً في الداشبورد بـ WebSockets مع زرار حظر الـ IP. Expose `POST /api/v1/ingest`, normalize logs into the Unified Schema, maintain rolling IP profiles in Redis, call the AI microservice, stream real-time alerts to the React dashboard via WebSockets, and trigger firewall blocks.	تثبيت Fluent Bit على لينكس، أو تنفيذ هجمات Kali، أو تدريب موديلات الـ Machine Learning. Configuring Linux Fluent Bit agents, launching Kali attacks, or training ML/DL weights.
Cybersecurity Track Cybersecurity Track	بناء شبكة الشركة الضحية (Docker/VMs)، وضبط Fluent Bit / Syslog لسحب الـ Logs من الـ 4 طبقات، وتنفيذ سيناريوهات الهجوم (Nmap, Hydra, SQLMap)، وكتابة Python Response Agent اللي بينفذ الحظر الفعلي بـ `ufw` / `iptables`. Build the victim enterprise lab (Docker/VMs), configure Fluent Bit & Syslog across all 4 layers, execute live multi-stage attacks from Kali Linux, and build the Python SOAR Responder that blocks attacker IPs via `ufw` / `iptables`.	بناء شاشات React، أو إدارة الـ Redis في الباك إند، أو كتابة كود الـ Neural Networks والـ RAG. Frontend UI development, Redis state management in Node.js, or training AI models.
AI & ML Track AI & ML Track	بناء سيرفر `FastAPI` يستقبل الـ Log وكارت الـ Redis، وتشغيل Stage-1 (موديلات `XGBoost` + `Isolation Forest` + `SecBERT` المدربة محلياً)، وتشغيل Stage-2 (Cloud LLM API + `MITRE ATT&CK RAG`) لما الخطر يعدي 75%. Build the `FastAPI` service receiving normalized logs + Redis IP profiles, run custom-trained Stage-1 models (`XGBoost`, `Isolation Forest`, fine-tuned `SecBERT`), and trigger Stage-2 (Cloud LLM API + `MITRE ATT&CK RAG`) when Risk ≥ 75%.	إزاي اللوجز اتسحبت من لينكس، أو إزاي اتخزنت في Redis وPostgreSQL، أو إزاي بتتعرض في الفرونت إند. Linux log shipping, Redis/PostgreSQL database operations, or React UI components.

4. نقاط الربط الثلاثة بين التراكات (The 3 Integration Handoffs)

4. The Three Inter-Track API Handoffs

الـ 3 Endpoints الوحيدة اللي بيتقابل فيها شغل تراك مع شغل تراك تاني

The exact 3 HTTP endpoints connecting Cyber, Web Backend, and AI

1. Cyber ➔ Web Backend

POST /api/v1/ingest

أداة Fluent Bit على سيرفر الضحية بتجمع السطور الجديدة من الـ 4 طبقات كل ثانيتين وتبعتها في JSON Batch مع هيدر x-api-key، والباك إند بيرد فوراً بـ 202 Accepted ويبدأ معالجتها.

Fluent Bit on the client server tails all 4 log layers, batches new lines every 2 seconds with an x-api-key header, and ships them to the Backend, which responds with 202 Accepted.

Auth: Header x-api-key

2. Web Backend ➔ AI Service

POST /ai/v1/analyze

الباك إند (بعد ما يحدث كارت الـ IP في Redis) بيبعت الكارت + أحدث Normalized Logs لسيرفر FastAPI. الـ AI بيشغل Stage-1 (ولو الخطر ≥ 75% بيشغل Stage-2) ويرجع الـ risk_score وقصة الهجوم.

After updating the Redis IP Profile, the Backend sends the profile + normalized log to FastAPI. The AI runs Stage-1 (and conditionally Stage-2 if Risk ≥ 75%) and returns the updated score and storyline.

Payload: Unified Log + Redis IP Profile

3. Web Backend ➔ Cyber Agent

POST /agent/v1/mitigate

لما الأدمن يدوس Block IP من الداشبورد (أو لما الـ Auto-Block يشتغل عند Risk ≥ 90%)، الباك إند بيبعت أمر موثق لـ Python Response Agent على سيرفر العميل عشان ينفذ ufw deny أو iptables DROP فوراً.

Triggered either manually via the dashboard's Block IP button or automatically via SOAR Playbook (Risk ≥ 90%). The Backend instructs the client's Python Response Agent to drop the attacker IP on the firewall.

Action: sudo ufw insert 1 deny from

5. سيناريو العرض العملي يوم المناقشة (Live Defense Demo)

5. Graduation Defense Live Demo Walkthrough

عرض عملي في 3 دقايق يربط شغل السايبر والويب والـ AI قدام لجنة التحكيم

A 3-minute live attack-and-defense demonstration showcasing all 3 tracks in action

STEP 01

حالة الاستقرار (Normal Traffic)

Baseline Green State

بنعرض الداشبورد قدام اللجنة والموقع التجريبي شغال طبيعي؛ الـ Logs بتدخل وتتصنف كـ Normal والـ Risk Score أقل من 10%.

Show the live SentinelAI dashboard monitoring normal user traffic with baseline Risk Scores below 10%.

STEP 02

تنفيذ هجوم مركب (Multi-Stage)

Launch Multi-Stage Attack

مهندس السايبر يبدأ هجوم من Kali Linux على 3 مراحل: فحص بورتات بـ Nmap، ثم تخمين باسورد SSH بـ Hydra، ثم SQL Injection على الموقع.

Cyber engineer runs a 3-stage attack from Kali: Nmap port scan → Hydra SSH brute force → SQL Injection on the web app.

STEP 03

الـ Redis والـ AI يربطوا القصة

Stateful AI Correlation

كارت الـ IP في Redis يجمع الـ 3 حركات مع بعض، وموديل Stage-1 يرفع الـ Risk لـ 94%، فيشتغل Stage-2 (LLM + MITRE RAG) ويكتب قصة الهجوم كاملة.

Redis aggregates all 3 layers under one IP profile. Stage-1 scores it at 94%, triggering Stage-2 LLM RAG to generate the full MITRE attack storyline.

STEP 04

تنبيه لحظي وحظر الـ IP

Live Alert & Firewall Block

التنبيه يظهر فوراً في الداشبورد بالـ WebSockets، ومهندس الويب يضغط على Block Attacker IP قدام اللجنة فيتبعت الأمر لـ Response Agent.

A critical alert pops up live via WebSockets. The Web engineer clicks Block Attacker IP, dispatching the block command to the Responder Agent.

STEP 05

إثبات الحظر الفعلي (Live Proof)

Verify Connection Dropped

مهندس السايبر يحاول يفتح الموقع أو يعمل Ping/SSH تاني من جهاز Kali Linux، فيظهر قدام اللجنة Connection Timed Out لأن الفايروول حظره فعلياً!

Cyber engineer attempts to access the web app or SSH from Kali Linux again and gets Connection Timed Out, proving the firewall rule is active!

Web Track فقط (Frontend & Backend) Web Engineering Track Only (Frontend & Backend) Node.js / NestJS / Express + Redis + React / Next.js + WebSockets

Technical Docs لـ Web Track (Backend & Frontend)

Web Engineering Track Specification (Backend & Frontend)

الصفحة دي فيها بس المهام الهندسية بتاعة مطوري الـ backend والـ frontend في Secura: استقبال دفعات الـ logs، وعمل normalization ليها، وإدارة حالة كل IP في Redis، وعرض قصص الهجوم live.

This page contains only the engineering deliverables for the Frontend and Backend developers: ingesting log batches, normalizing heterogeneous formats, maintaining stateful IP profiles in Redis, and streaming incident storylines in real time.

شغلك في الـ track ده: What You Focus On:

بناء API سريع للاستلام (Batch Ingestion + Queue)، وبناء Log Normalization Engine، وإدارة الـ IP profile في Redis، وبناء dashboard تفاعلي لحظي بالـ WebSockets.

Async batch ingestion API & Queueing, Log Normalization Engine (Regex + Smart Field Mapper), Redis Stateful IP Context Profile, Real-Time WebSockets Dashboard, and triggering the SOAR Block webhook.

مش مسؤوليتك: What You Ignore:

إزاي الـ AI models بتتدرب (إنت بس بتبعت JSON للـ endpoint بتاعتهم)، ولا إزاي الـ firewall متظبط أو إزاي الهجمات بتتنفذ على Linux.

How AI models are trained or fine-tuned (you simply send JSON to their FastAPI endpoint), and how Linux firewalls, Suricata, or Kali attack scripts are configured internally.

1. استقبال الـ logs من غير ما تعطّل العميل (Batch Ingestion & Queueing)

1. Non-Blocking Batch Ingestion & Queueing

ليه مش بنستخدم fetch متزامن لكل log؟ وإزاي صممنا الـ endpoint؟

Why synchronous per-event fetch calls fail in production, and how our ingestion pipeline works

عشان سيرفر العميل مايتعطلش وهو بيبعت الـ logs، الـ Agent أو الـ logger (زي Pino/Winston Transport) بيعمل Collect للـ logs في batch كل 3-5 ثواني وبيبعتهم في request واحد على POST /api/v1/ingest.

Client servers never block user requests waiting for Secura. Instead, Fluent Bit or a logger transport (Pino/Winston) buffers logs in memory and sends a batch array every 3–5 seconds to POST /api/v1/ingest.

1. التحقق من الـ API Key

1. API Key Validation

بنقرأ هيدر x-api-key ونتأكد من المشروع صاحب المفتاح ده عن طريق Redis Cache.

Validate the x-api-key header against Redis cache to resolve the tenant project_id.

2. نرمي الـ batch في الـ Queue

2. Enqueue Batch

أول ما الـ backend يستلم الـ array of logs، بيرميها في BullMQ / Redis Queue ومايستناش تحليل الـ AI.

Push the incoming batch directly into BullMQ / Redis Streams without waiting for AI inference.

3. رد فوري بـ 202 Accepted

3. Instant 202 Accepted

الـ backend بيرد في أقل من 5ms بـ 202 Accepted، عشان أداء سيرفر العميل مايتأثرش خالص.

Return HTTP 202 Accepted in <5ms so the client's application experiences zero latency impact.

Request Body Expected at POST /api/v1/ingest

// Headers: { "x-api-key": "dv7_live_99a8b7c6d5", "Content-Type": "application/json" }
{
  "source_type": "custom_app", // or "nginx" | "firewall" | "linux_auth"
  "host": "prod-backend-01",
  "logs": [
    { "level": 30, "time": 1762352530000, "msg": "User viewed products", "client_ip": "197.55.12.40" },
    { "level": 50, "time": 1762352532000, "msg": "Failed login for user: admin", "client_ip": "197.55.12.40", "user": "admin" }
  ]
}

2. Log Normalization Engine في الـ backend

2. Backend Log Normalization Engine

إزاي الـ backend بيحوّل الـ logs المختلفة للـ Unified Schema؟

How we transform arbitrary developer JSON and standard server logs into the Unified Schema

الحالة أ: logs قياسية معروفة (Nginx / UFW Firewall / Linux Auth)

Case A: Standard Infrastructure Logs (Nginx / UFW Firewall / Linux Auth)

بنستخدم Regex جاهزة في الـ backend عشان نطلع الـ IP والـ timestamp والـ message ونحطهم في الحقول الموحدة.

Parsed via pre-built deterministic Regex extractors that pull out the IP, timestamp, and message.

الحالة ب: JSON جاي من المبرمجين (Pino / Winston / Custom JSON)

Case B: Custom Developer JSON (Pino / Winston / Morgan)

بنستخدم Smart Field Mapper (قاموس synonyms) بيدور أوتوماتيك على أشهر الأسماء ويحولها للحقل الموحد، وكمان فيه Custom Field Mapping UI في إعدادات الـ dashboard.

Handled via a Smart Field Synonym Mapper that automatically resolves common key variations, plus a Custom Field Mapping UI in Project Settings.

Smart Field Mapper (Node.js / TypeScript)

const FIELD_SYNONYMS = {
  source_ip: ['source_ip', 'ip', 'client_ip', 'remoteAddress', 'src_ip', 'x_forwarded_for'],
  message:   ['message', 'msg', 'err', 'error_message', 'log'],
  severity:  ['severity', 'level', 'log_level', 'lvl']
};

function mapCustomJsonToUnified(rawObj, projectId) {
  const findField = (keys) => keys.map(k => rawObj[k]).find(val => val !== undefined) || null;
  
  // Convert numeric Pino levels (30 -> INFO, 40 -> WARN, 50 -> ERROR)
  let sev = findField(FIELD_SYNONYMS.severity);
  if (typeof sev === 'number') sev = sev >= 50 ? 'ERROR' : sev >= 40 ? 'WARN' : 'INFO';

  return {
    project_id: projectId,
    timestamp: new Date(rawObj.time || rawObj.timestamp || Date.now()).toISOString(),
    source_type: 'custom_app',
    severity_initial: String(sev || 'INFO').toUpperCase(),
    source_ip: findField(FIELD_SYNONYMS.source_ip) || '0.0.0.0',
    message: findField(FIELD_SYNONYMS.message) || JSON.stringify(rawObj),
    raw_data: rawObj
  };
}

3. Stateful IP Profile في Redis

3. Stateful IP Context Profile in Redis

الحل لمشكلة الـ Low & Slow Attacks اللي بتحصل على مدار نص ساعة أو ساعة

Solving Low-and-Slow attacks across 30–60 minute windows without overloading the AI model

بدل ما نبعت للـ AI آلاف أسطر الـ log القديمة عشان نكتشف هجمات بتحصل على مدار 30 أو 60 دقيقة، الـ backend بيحتفظ في Redis بـ IP profile لكل source_ip (بـ TTL ساعة). مع كل batch جديد من الـ IP ده، الـ backend بيحدّث العدادات في Redis وبعدين يبعت (ملخص الـ profile + أحدث الـ logs) لسيرفر الـ AI.

Instead of sending 10,000 historical log lines to the AI every time an IP makes a new request, the Backend maintains a compact Stateful IP Profile in Redis (TTL = 3600s). Whenever new logs arrive from source_ip, the worker updates the Redis counters and sends (IP Profile Summary + Latest Normalized Logs) to the AI service.

Redis Key: ip_profile:{project_id}:{source_ip} (TTL = 3600s)

{
  "ip": "197.55.12.40",
  "first_seen_at": "2026-11-05T13:50:00Z",
  "last_seen_at": "2026-11-05T14:22:10Z",
  "window_duration_minutes": 32,
  "counters": {
    "total_requests": 145,
    "failed_logins": 18,
    "firewall_blocks": 42,
    "error_4xx_5xx_count": 39
  },
  "distinct_ports_targeted": [21, 22, 80, 443, 3306, 8080],
  "sensitive_paths_visited": ["/admin", "/.env", "/wp-login.php"],
  "layers_touched": ["firewall", "nginx", "linux_auth"],
  "cumulative_risk_score": 78,
  "timeline_digest": [
    "13:50 - Firewall blocked 42 connection attempts on 6 ports (Port Scan)",
    "14:10 - Nginx logged requests to /.env and /admin (Reconnaissance)",
    "14:22 - 18 failed SSH & Web login attempts on user 'admin' (Brute Force)"
  ]
}

4. Architecture الـ Frontend والـ Dashboard والـ DB

4. Frontend Dashboard, WebSockets & Core Database Tables

عرض قصص الهجوم بشكل تفاعلي والاستجابة اللحظية

Actionable storyline visualization and real-time response

1. Incident Storyline Cards 1. Incident Storyline Cards

الـ dashboard بتعرض Incident Cards مرتبة حسب الـ Risk Score. لما تفتح أي card، بيظهر timeline تفاعلي (firewall ⬅ Nginx ⬅ backend) مع شرح الـ AI وتصنيف MITRE ATT&CK.

The dashboard highlights correlated Incident Cards sorted by Risk Score. Expanding a card displays an interactive Attack Timeline (Firewall ➔ Nginx ➔ App ➔ OS) alongside the AI summary and MITRE ATT&CK badge.

2. زر Block IP بضغطة واحدة 2. One-Click Block IP (SOAR Trigger)

جنب كل incident خطير فيه زر Mitigate / Block IP. لما تدوس عليه، الـ frontend بيبعت POST /api/v1/incidents/:id/block للـ backend، والـ backend بيبعت أمر للـ Agent على سيرفر العميل عشان يحظر الـ IP.

Each critical incident features a Mitigate / Block IP button. Clicking it calls POST /api/v1/incidents/:id/block, which instructs the Cyber Responder Agent to block the IP and updates the UI via Socket.io.

الجداول الأساسية في الـ database (PostgreSQL / MongoDB) Core Database Collections / Tables (PostgreSQL or MongoDB)

1. projects & api_keys

بيانات الشركات، مفاتيح الـ API، والـ Agent webhook URL بتاع الحظر.

Tenant organizations, active API keys, custom field mappings, and Responder webhook URLs.

2. normalized_logs

الـ logs بعد الـ normalization بالـ Unified Schema، مع indexing على source_ip وtimestamp.

Unified Schema logs indexed by (project_id, source_ip, timestamp).

3. incidents

الحوادث المكتشفة، الـ Risk Score، ملخص الـ AI، تكتيك MITRE، وأرقام الـ logs المرتبطة بيها.

Correlated incidents, cumulative Risk Score, AI storyline report, MITRE tactic ID, and linked log IDs.

4. mitigation_actions

سجل بكل عمليات الحظر (مين حظر، امتى، وهل اتطبق على الـ firewall ولا لأ).

Audit log of all manual and automated IP blocks executed on client firewalls.

Cyber Track فقط (Infrastructure, Logs & SOAR) Cybersecurity Track Only (Infrastructure, Logs & SOAR) Docker Lab + Suricata/UFW + Nginx + Fluent Bit + Kali Attack Scripts + SOAR

Technical Docs لـ Cybersecurity Track (الـ Lab والـ Logs والاستجابة)

Cybersecurity Track Specification (Lab, Collectors & Active Response)

الصفحة دي مخصصة بس لمهندسي السايبر في الفريق. مهمتك تبني lab صغير بيحاكي شركة حقيقية، وتعمل Collect للـ logs من الـ 4 layers، وتبعتها للـ backend، وتنفذ سيناريوهات الهجوم، وتبني أداة الحظر التلقائي على السيرفر.

This page is dedicated exclusively to the Cybersecurity engineers. Your responsibility is designing a realistic enterprise network topology, collecting logs across all 4 infrastructure layers, executing multi-stage attacks, and building the active firewall blocker script.

شغلك في الـ track ده: What You Focus On:

تصميم network الـ lab (Docker/VMs)، وعمل Collect للـ logs من الـ 4 layers عن طريق Collector مركزي (Fluent Bit + Syslog)، وتوليد هجمات حقيقية للتدريب والـ demo، وكتابة سكريبت الـ Active Response اللي بينفذ الحظر على الـ firewall.

Enterprise Docker/VM network topology, central log collection from 4 layers (Fluent Bit / Syslog), realistic attack simulation (Nmap, Hydra, SQLMap), and the Python SOAR Responder that blocks attacker IPs via ufw / iptables.

مش مسؤوليتك: What You Ignore:

تصميم واجهات الـ frontend أو إدارة Redis في الـ backend، ولا بناء architecture الـ Neural Networks أو الـ RAG بتاعة الـ AI track.

Frontend UI styling, Redis state windowing logic in the Backend, or training ML/DL weights and RAG vector databases in the AI track.

1. Lab Network Topology وإزاي بنسحب الـ Logs من سيرفر العميل؟

1. Enterprise Lab Topology & How Log Collection Works

محاكاة شبكة شركة حقيقية وسحب الـ Logs من الـ 4 Layersعملياً

Simulating a real company infrastructure and collecting logs across all 4 layers

Kali Linux (Attacker)

197.55.12.40

Nmap / Hydra / SQLMap

Attack Traffic

شبكة الشركة الضحية (4 layers مراقبة) Company DMZ & Internal Network (4 Monitored Layers)

1. Perimeter Firewall

UFW / pfSense / Suricata (Syslog & ufw.log)

2. Web Reverse Proxy

Nginx (access.log & error.log)

3. App & Database

Node/Python App (app.log / Pino)

4. Linux OS Endpoint

SSH & sudo (/var/log/auth.log)

Tail / Syslog

Fluent Bit + Responder

Log Shipper & SOAR

POST /api/v1/ingest

أي برنامج شغال على أي سيرفر في الدنيا (سواء موقع، داتابيز، فايروول، أو لينكس نفسه)، كل ما يحصل فيه حدث، البرنامج ده بيفتح ملف نصي (Text File) على الهارد ديسك ويكتب فيه سطر جديد في آخر الملف. يعني المشكلة كلها بتتلخص في السؤال ده: "إزاي ناخد السطر اللي اتكتب في ملف على سيرفر العميل، ونوصله للـ Backend API بتاعنا؟" — ده بيحصل بـ 3 طرق عملية، وفي مشروعنا بنقدر ندمج بينهم حسب نوع المصدر:

Every service running on a server (web server, database, firewall, or Linux OS) records events by appending a new line to a local text file on disk. The core engineering question is: "How do we capture that newly written line on the client server and deliver it to our Backend API?" — This is achieved via 3 practical methods that we combine depending on the log source:

الطريقة الأولى (الأهم والأعم) Method 1 (Primary)

1. الـ Log Agent (Fluent Bit)

1. Log Agent (Fluent Bit File Tailing)

بدل ما نعدل في كود البرامج أو السيرفر، بنحط برنامج صغير في الخلفية يعمل File Tailing (يقف عند آخر سطر في الملف، وأول ما السيرفر يكتب سطر جديد يلقطه في نفس اللحظة).

Instead of modifying server applications, a lightweight background agent performs File Tailing (watching the end of log files and capturing new lines in real time).

بنستخدم أداة جاهزة ومجانية اسمها Fluent Bit، بنسطبها بأمر واحد ونديلها ملف إعدادات (fluent-bit.conf) نقوله فيه يراقب ملفات زي /var/log/nginx/access.log و /var/log/auth.log، ويعلم كل سطر هو جاي منين (مثلاً source_type: nginx)، ويجمع كل ثانيتين السطور اللي جت ويبعتهم كـ JSON HTTP POST Request للينك الباك إند بتاعنا POST /api/v1/ingest مع الـ Header x-api-key.

We use Fluent Bit configured via a 15-line fluent-bit.conf file to watch files like /var/log/nginx/access.log and /var/log/auth.log, tag each line with its source_type, batch new lines every 2 seconds, and ship them via JSON HTTP POST to POST /api/v1/ingest with the x-api-key header.

* مابتكتبش كود هنا خالص؛ ملف إعدادات من 15 سطر و Fluent Bit بيتكفل بكل حاجة.

* Zero custom code needed—just a 15-line config file with built-in buffering & retry.

الطريقة التانية Method 2

2. من جوه كود الباك إند (SDK / Logger Transport)

2. Application Backend (File or Logger Transport)

لو العميل عنده موقع مكتوب بـ Node.js (Express/Nest) أو Python وعايز يبعت Logs خاصة بالبيزنس (زي محاولة شراء بفيزا مسروقة أو باسورد غلط)، الحاجات دي مبتتكتبش في ملفات لينكس ولا Nginx.

When a client's custom Node.js or Python application needs to log business-logic events (e.g., failed login attempts or payment fraud) that don't appear in OS or Nginx logs:

الطريقة الأضمن: كود الباك إند يطبع الـ Log في ملف عادي على السيرفر (app.log)، وFluent Bit يقرأ الملف ده مع باقي الملفات ويبعتهولنا.
أو بـ Logger Transport: المبرمج يستخدم مكتبة زي Pino أو Winston تجمع الـ Logs كل 5 ثواني في الرامات وتبعتها في الخلفية بـ POST Request للـ API بتاعنا من غير ما تعطل اليوزر.

File + Fluent Bit (Recommended): The app writes JSON lines to app.log, and Fluent Bit tails and ships it alongside system logs.
In-Code Logger Transport: Using libraries like Pino or Winston to batch logs in memory every 5 seconds and asynchronously POST them to our API.

Pino / Winston -> app.log -> Fluent Bit

الطريقة التالتة Method 3

3. بروتوكول الشبكة (Syslog للأجهزة المقفولة)

3. Network Protocol (Syslog for Appliances)

لو الشركة عندها جهاز Firewall حقيقي أو راوتر (أو برنامج فايروول شبكات مستقل زي pfSense / Suricata على VM لوحدها)، الأجهزة دي مبنقدرش ندخل نسطب عليها حاجة.

For dedicated network appliances, hardware routers, or standalone firewall VMs (like pfSense or Suricata) where you cannot install custom agents:

الأجهزة دي بيبقى جواها في الإعدادات صفحة اسمها Remote Logging (Syslog).
بندخل نكتب فيها الـ IP والبورت بتاع جهاز الـ Fluent Bit.
الفايروول بيحدف السطور في الشبكة أوتوماتيك أول بأول لـ Fluent Bit، وهو ياخدها يبعتها للباك إند بتاعنا بـ HTTP POST زي إخواتها بالظبط.

Enable Remote Logging (Syslog) inside the appliance settings.
Point it to the IP and UDP/TCP port where Fluent Bit is listening.
Fluent Bit receives the Syslog stream over the network and forwards it to our Backend via HTTP POST.

pfSense / Suricata --(Syslog UDP/514)--> Fluent Bit

خلاصة مشهد تجميع الـ Logs يوم المناقشة: Putting It All Together for the Graduation Demo:

في "بيئة الشركة الضحية" عندنا 4 مصادر: فايروول (/var/log/ufw.log أو pfSense بيبعت بالـ Syslog)، ويب سيرفر (/var/log/nginx/access.log)، نظام لينكس (/var/log/auth.log)، وباك إند الموقع (app.log أو Pino Transport). بنحط في البيئة دي برنامج واحد بس (Fluent Bit) يلم من الملفات دي كلها ومن الـ Syslog في نفس الوقت، وأول ما أي سطر جديد يظهر في أي مصدر من الأربعة، بيلقطه ويحطه في Array صغير في JSON، ويخبط على الـ API بتاع الباك إند بتاعنا (POST /api/v1/ingest). يعني من وجهة نظر الباك إند: هو مبيعرفش لا ملفات ولا لينكس ولا Syslog، هو عامل Endpoint واحدة عادية جداً بتستقبل JSON جاهز!

In our victim enterprise lab, we have 4 sources: Firewall (/var/log/ufw.log or pfSense via Syslog), Web Server (/var/log/nginx/access.log), Linux OS (/var/log/auth.log), and the App Backend (app.log or Pino). A single Fluent Bit instance watches all files and Syslog streams simultaneously, batches any new lines into a JSON array, and sends them to POST /api/v1/ingest. From our Backend's perspective, it never touches Linux files or Syslog—it simply exposes one clean REST endpoint receiving structured JSON batches.

Real Raw Log Lines Collected Across the 4 Layers

# 1. Firewall Layer (/var/log/ufw.log or Syslog)
Nov  5 14:20:01 gateway kernel: [UFW BLOCK] IN=eth0 SRC=197.55.12.40 DST=10.0.0.5 PROTO=TCP SPT=49211 DPT=3306

# 2. Web Server Layer (/var/log/nginx/access.log)
197.55.12.40 - - [05/Nov/2026:14:21:12 +0000] "GET /products?id=1%27%20UNION%20SELECT%20username,password%20FROM%20users-- HTTP/1.1" 200 1420

# 3. Application Layer (app.log - Pino JSON)
{"level":40,"time":1762352490000,"client_ip":"197.55.12.40","user":"admin","msg":"Invalid password attempt #15"}

# 4. Linux OS Layer (/var/log/auth.log)
Nov  5 14:22:10 prod-srv sshd[2140]: Failed password for invalid user root from 197.55.12.40 port 54321 ssh2

2. إزاي بنعمل Block للـ IP في الفايروول؟ (Active Response / SOAR)

2. How We Block Attacker IPs on the Firewall (Active Response / SOAR)

شرح تنفيذ أمر الحظر الفوري أو التلقائي من الباك إند لسيرفر العميل

How manual or automatic block commands travel from our Backend to the client's firewall

نقطة جوهرية: أداة Fluent Bit اللي حطيناها على سيرفر العميل هي أداة "اتجاه واحد" (تقرأ Logs وتبعتها لنا بس)، مبتعرفش تستقبل أوامر ولا تنفذ أوامر حظر على اللينكس. بالتالي لما الأدمن يدوس على زرار "Block IP" في الداشبورد (أو لما الباك إند ياخد القرار أوتوماتيك لما الـ Risk Score يعدي 90%)، السيستم بتاعنا محتاج يوصل أمر لسيرفر العميل يقوله: "شغّل أمر الحظر ده في الفايروول عندك دلوقتي!".

Crucial Note: Fluent Bit is strictly a one-way log shipper (it only reads and forwards logs; it cannot receive commands or execute firewall blocks). Therefore, when an admin clicks "Block IP" on the dashboard (or when the Backend triggers an auto-block because risk_score >= 90%), our platform needs a dedicated mechanism to execute the block command on the client's server.

الطريقة الأولى (الأشهر والأسهل للمشروع) Method 1 (Recommended for Demo)

1. سكريبت صغير على سيرفر العميل (Python Response Agent)

1. Lightweight Python Response Agent (Webhook / Polling)

جنب Fluent Bit اللي بيبعت اللوجز، مهندس السايبر بيحط سكريبت بايثون صغير جداً (أقل من 40 سطر بـ Flask أو FastAPI) شغال في الخلفية بصلاحيات sudo على سيرفر العميل، مستني أوامر الحظر من الباك إند بتاعنا.

Alongside Fluent Bit, the Cybersecurity engineer runs a lightweight Python script (<40 lines using Flask or FastAPI) with sudo privileges on the client server that listens for signed block commands from our Backend.

إصدار الأمر: الأدمن يدوس Block IP 197.55.12.40 في الداشبورد ← الفرونت إند يكلم الباك إند بتاعنا.
إرسال الطلب (Webhook): الباك إند يبعت HTTP POST Request لسكريبت البايثون على سيرفر العميل ومعاه مفتاح سري (Secret Token) عشان الأمان.
التنفيذ الفعلي على اللينكس: السكريبت يتأكد من التوكن وينفذ أمر الحظر مباشر على الفايروول (ufw أو iptables) عن طريق مكتبة subprocess.
تأكيد التنفيذ: السكريبت يرد بـ 200 OK، والداشبورد تنور أخضر: Status: IP Blocked on Firewall ✅.

Trigger: Admin clicks Block IP 197.55.12.40 on the dashboard → Frontend calls our Backend.
Webhook Dispatch: Our Backend sends an authenticated HTTP POST request (with a secret token) to the Python Response Agent.
Firewall Execution: The script verifies the token and executes the Linux firewall command (ufw or iptables) via Python's subprocess module.
Confirmation: The agent responds with 200 OK, and the dashboard updates live to Status: IP Blocked on Firewall ✅.

// 1. JSON Webhook sent from our Backend to the Python Agent:
{
  "action": "BLOCK_IP",
  "target_ip": "197.55.12.40",
  "duration_minutes": 60
}

# 2. Linux Firewall Command executed by the Python Agent:
sudo ufw insert 1 deny from 197.55.12.40 to any
# Or via iptables:
sudo iptables -I INPUT -s 197.55.12.40 -j DROP

💡 ملحوظة احترافية للمناقشة: لو سيرفر العميل ورا NAT أو مقفول ومينفعش الباك إند يكلمه مباشر، بنخلي سكريبت البايثون يفتح WebSocket مع الباك إند أو يسأله كل ثانيتين: "فيه أوامر بلوك جديدة؟" (ودي اسمها Agent Polling). 💡 Pro Tip for Defense: If the client server sits behind NAT and cannot receive inbound webhooks, the Python script maintains an outbound WebSocket connection or polls the Backend every 2 seconds (Agent Polling).

الطريقة التانية (بديلة) Method 2 (Alternative)

2. التنفيذ المباشر عبر SSH بدون سكريبت (Agentless Response)

2. Agentless Execution via SSH (Ansible Style)

لو مش عايزين نحط سكريبت بايثون على سيرفر العميل، بنستخدم طريقة Agentless:

If we prefer not to install a Python responder script on the client server, we can use an Agentless approach:

العميل وهو بيسجل السيرفر بتاعه في منصتنا، بيدينا صلاحية SSH Key محدود الصلاحيات.
لما الأدمن يدوس Block IP (أو يحصل Auto-Block)، كود الباك إند بتاعنا (بمكتبة ssh2 في Node.js أو Paramiko في بايثون) بيفتح اتصال SSH سريع في جزء من الثانية مع سيرفر العميل.
الباك إند يرمي أمر الحظر (sudo ufw deny from 197.55.12.40) ويقفل الاتصال فوراً.

When onboarding a server, the client provides a restricted SSH Key.
When a block is triggered, our Backend (using ssh2 in Node.js or Paramiko in Python) opens an instant SSH session to the client server.
It executes sudo ufw deny from 197.55.12.40 and closes the connection immediately.

إيه الفرق بين الـ Manual Block والـ Auto Block في الكود؟ Manual Block vs. Automatic Block (SOAR Playbook)

في الحالتين طريقة التنفيذ واحدة تماماً (نفس الـ Function في الباك إند اللي اسمها مثلاً executeFirewallBlock(ip) هي اللي بتبعت الأمر للـ Agent)، الفرق بس في "مين اللي نادى الـ Function دي؟":

In both cases, the execution mechanism is identical (the exact same Backend function executeFirewallBlock(ip) sends the command to the Agent). The only difference is what triggers that function:

1. لو Manual (من الداشبورد): 1. Manual Block (Dashboard Button):

الباك إند لما يلاقي الخطر عالي يعمل Incident ويبعت إشعار للأدمن ويستنى. لما الأدمن يدوس بإيده على زرار Block IP، الزرار بينادي POST /api/v1/incidents/:id/mitigate اللي بتشغل الـ Function.

The Backend creates a high-risk Incident and alerts the admin via WebSockets. When the admin clicks Block IP, it calls POST /api/v1/incidents/:id/mitigate, which invokes executeFirewallBlock(ip).

2. لو Automatic (SOAR Playbook): 2. Automatic Block (Zero-Touch SOAR Playbook):

الباك إند بعد ما يسأل الـ AI ويحدث الـ Redis، لو لقى الشرط ده اتحقق: if (incident.risk_score >= 90 && clientSettings.autoBlockEnabled)، بينادي executeFirewallBlock(ip) فوراً من غير ما يستنى الأدمن، ويبعتله إشعار على الداشبورد إن الهجوم اتصد والـ IP اتعمله بلوك خلاص!

Right after AI scoring, if incident.risk_score >= 90 && clientSettings.autoBlockEnabled is true, the Backend automatically invokes executeFirewallBlock(ip) without waiting for human intervention and notifies the dashboard that the IP has already been blocked.

الخلاصة: إيه اللي بيكون شغال على سيرفر العميل؟ Summary: What Runs on the Client Server?

حاجتين خفاف جداً شغالين في الخلفية: (1) Fluent Bit عينه على ملفات الـ Logs يسحبها ويبعتها للباك إند بتاعنا، و(2) Python Response Agent (أو SSH) ودنه مع الباك إند بتاعنا، أول ما يجيله أمر حظر لـ IP معين ينفذه فوراً على الفايروول (ufw / iptables).

Two lightweight background components: (1) Fluent Bit watching log files and shipping batches to our Backend, and (2) Python Response Agent (or SSH) listening for Backend block commands to execute immediately on the firewall (ufw / iptables).

AI & ML Track فقط (Two-Stage Detection & RAG) AI & ML Track Only (Two-Stage Detection & RAG Copilot) FastAPI + XGBoost/IsolationForest + SecBERT + Cloud LLM MITRE RAG

Technical Docs لـ AI & ML Track (Two-Stage Hybrid AI)

AI & Machine Learning Track Specification (Two-Stage Hybrid AI)

الصفحة دي مخصصة بس لفريق الـ AI. التقسيمة دي (Two-Stage Hybrid AI Architecture) هي أنسب وأقوى حل لمشروعنا، مش بس عشان الدرجات في الكلية، لكن لأن ده فعلياً اللي بيحصل في أنظمة الـ SIEM الحديثة في الشركات الكبيرة: بنجمع بين موديل سريع إحنا مدربينه بنفسنا (Stage 1) وبين موديل LLM جاهز مربوط بـ MITRE RAG (Stage 2).

This page is dedicated exclusively to the AI/ML team. Our Two-Stage Hybrid AI Architecture mirrors enterprise SIEM systems: combining a fast custom-trained detection engine (Stage 1) that processes 100% of traffic locally in <20ms with a Cloud LLM + MITRE ATT&CK RAG Copilot (Stage 2) triggered only on critical incidents.

شغلك في الـ track ده: What You Focus On:

تدريب موديلات Stage 1 (XGBoost + Isolation Forest + Fine-tuned SecBERT)، وبناء RAG لـ Stage 2 مع MITRE ATT&CK باستخدام Cloud LLM APIs، وتقديمهم عبر POST /ai/v1/analyze بـ FastAPI.

Training Stage-1 models (XGBoost, Isolation Forest UEBA, Fine-tuned SecBERT), building the Stage-2 MITRE ATT&CK RAG + Cloud LLM Copilot, and serving predictions via FastAPI (POST /ai/v1/analyze).

مش مسؤوليتك: What You Ignore:

إزاي الـ logs بتتسحب من السيرفرات أو بتتخزن في Redis أو بتتعرض بالـ WebSockets في React.

How logs are shipped from Linux servers, how Redis stores IP windows, or how React renders WebSocket alerts.

1. ليه بنعمل 2 AI ومش بنعتمد على واحد بس؟

1. Why Do We Use a 2-Stage AI Instead of Just One Model?

تخيل إن السيرفر بتاع العميل بيبعت للباك إند بتاعنا 1,000 سطر Log في الدقيقة

Imagine the client server streams 1,000 log lines per minute to our Backend

لو اعتمدنا على موديل جاهز (LLM زي Gemini أو GPT أو Claude) لوحده: If We Relied ONLY on a Cloud LLM API (Gemini / GPT / Claude):

بطء شديد: الـ LLM بياخد من ثانية لـ 3 ثواني عشان يرد. لو بعتناله كل سطر Log، السيستم هيتخنق وهيحصل طابور انتظار (Bottleneck) والـ Real-time هيبوظ.
تكلفة و Rate Limits: الـ APIs دي ليها حد أقصى للطلبات في الدقيقة (Rate Limit)، وبتتحاسب بالـ Token. 99% من الـ Logs أصلاً سليمة وعادية، فحرام نحرق Tokens وفلوس عشان نسأل LLM ضخم على زائر عادي فتح الصفحة الرئيسية!
مشكلة مناقشة التخرج: دكتور الـ AI في المناقشة هيقول: "فين شغلك كمهندس AI؟ إنت مجرد باعت Prompt لـ API، وده شغل Backend مش AI!".

High Latency: An LLM takes 1–3 seconds per response. Sending every single log line to an LLM creates a massive bottleneck and breaks real-time detection.
Cost & Rate Limits: Cloud APIs enforce strict RPM/TPM rate limits. Since 99% of logs are benign traffic, burning tokens on normal requests is wasteful.
Academic Evaluation Risk: Examiners will rightly point out that calling an external LLM API with a prompt is Backend integration, not custom AI/ML engineering.

طب لو اعتمدنا على الموديل اللي هندربه بنفسنا لوحده؟ What If We Relied ONLY on Our Custom-Trained Models?

الموديلات اللي بندربها بنفسنا (زي XGBoost أو SecBERT) ممتازة وسريعة جداً في التصنيف والأرقام (تقولك في 10 ملي ثانية: Risk = 92% و Type = SQL_Injection).

Custom-trained models (like XGBoost or SecBERT) are blazingly fast at numerical scoring and classification (returning Risk = 92% and Type = SQL_Injection in 10ms).

لكنها خرساء—مبتعرفش تكتب فقرة تشرح للأدمن "قصة الهجوم" اللي حصل على مدار 3 مراحل ولا تقترح عليه خطوات الحل بلغة بشرية مفهومة.

However, they are silent classifiers—they cannot synthesize a multi-stage chronological attack story or write human-readable remediation steps for the SOC admin.

💡 الحل الهجين (Hybrid): الـ AI الأول (بتاعنا) يشتغل زي "الفلتر السريع والرادار" يفحص 100% من اللوجز ببلاش وفي جزء من الثانية، والـ AI التاني (الـ LLM الجاهز) ميشتغلش غير لما الـ AI الأول يصفر ويقول إن الـ Risk Score عدى 75% (يعني بيشتغل على الـ 1% الخطر بس!). 💡 The Hybrid Solution: Stage 1 acts as a high-speed radar filtering 100% of logs locally in milliseconds, while Stage 2 (Cloud LLM Copilot) wakes up ONLY for the critical 1% of traffic where Risk Score ≥ 75%.

2. إزاي الاتنين بيشتغلوا مع بعض؟ (خط سير الداتا بالتفصيل)

2. How Both Stages Work Together (Step-by-Step Data Flow)

رحلة الـ Log وكارت الـ Redis جوه سيرفر الـ FastAPI بتاع فريق الـ AI

How normalized logs and Redis IP profiles flow through the Python FastAPI microservice

Stage 1: Custom-Trained Fast AI (<20ms) Inspects 100% of Traffic

المرحلة الأولى (Stage 1): الموديل اللي بندربه بنفسنا

Stage 1: Our Custom-Trained ML/DL Detection Models

أول ما الباك إند يعمل Normalization للـ Logs ويحدث كارت الـ IP في الـ Redis، بيبعت الكارت والـ Log لسيرفر بايثون (FastAPI) بتاع فريق الـ AI. السيرفر ده جواه جزئين متدربين:

Once the Backend normalizes incoming logs and updates the Redis IP profile card, it sends both to the AI team's FastAPI server, which runs two custom-trained models in parallel:

1. موديل سلوكي ورقمي (Tabular / Anomaly Model):

1. Behavioral & Tabular Anomaly Model:

بيستخدم خوارزميات زي XGBoost (لتصنيف الهجمات المعروفة من الأرقام زي عدد المحاولات الفاشلة في الدقيقة) + Isolation Forest (لكشف الشذوذ أو الـ Anomaly، زي موظف دخل بباسورد صح بس الساعة 4 الفجر وبيسحب داتا ضخمة). يتم تدريبهم على Datasets عالمية مشهورة زي CIC-IDS2017 و UNSW-NB15.

Combines XGBoost (supervised classification on rate/count features) with Isolation Forest (unsupervised UEBA anomaly detection, e.g., valid credentials used at 4 AM with massive data exfiltration). Trained on CIC-IDS2017 and UNSW-NB15.

2. موديل فحص نص الـ Log نفسه (NLP Payload Model):

2. Deep Learning NLP Payload Classifier:

بنجيب موديل صغير مفتوح المصدر من HuggingFace زي DistilBERT أو SecBERT، ونعمله Fine-Tuning على Google Colab بحيث يقرأ نص الرسالة أو الـ URL (مثلاً GET /login?user=admin' OR 1=1--) ويكتشف فوراً إن فيها Payload خبيث (SQLi, XSS, Command Injection).

A lightweight HuggingFace transformer (DistilBERT or SecBERT) fine-tuned on Google Colab to inspect raw URLs and log messages (e.g., GET /login?user=admin' OR 1=1--) and detect malicious payloads (SQLi, XSS, Command Injection).

⚡ النتيجة من المرحلة الأولى: بيرد في أقل من 20 ملي ثانية برقم (risk_score: 92) وتصنيف (tags: ["Brute_Force", "SQL_Injection"]). ⚡ Stage-1 Output: Responds in <20ms with a numeric risk_score: 92 and attack tags ["Brute_Force", "SQL_Injection"].

Stage 2: Cloud LLM + MITRE RAG Triggered ONLY if Risk ≥ 75%

المرحلة التانية (Stage 2): الموديل الجاهز للشرح والـ RAG (SOC Copilot)

Stage 2: Pre-Trained Cloud LLM + MITRE ATT&CK RAG Copilot

لو الباك إند لقى إن الـ risk_score اللي راجع من المرحلة الأولى أقل من 75%، بيسيفه ويكمل عادي. أما لو عدى 75%، السيرفر بيشغل المرحلة التانية في 3 خطوات:

If the Stage-1 risk_score is below 75%, execution stops there. If risk_score ≥ 75%, Stage 2 is automatically triggered in 3 steps:

تجميع سياق الحادثة (Context Aggregation): ياخد "ملخص كارت الـ IP من الـ Redis" + "آخر Logs خطيرة عملها الـ IP ده" + "التصنيف اللي طلعه الموديل الأول".
البحث في قاعدة المعرفة الأمنية (MITRE ATT&CK Vector RAG): يدور في Vector Database (زي ChromaDB أو FAISS) حاطين فيها كتاب الـ MITRE ATT&CK (الدليل العالمي الرسمي لتصنيف خطوات الهاكرز وطرق صدها).
توليد القصة والتوصيات (LLM Synthesis): يبعت دول في Prompt للـ Cloud LLM الجاهز ويقوله: "لخصلي قصة الهجوم دي بالترتيب الزمني في 3 سطور، واربطها بـ MITRE ATT&CK، واكتب التوصية وأمر الفايروول المناسب لصدها".

Context Aggregation: Combines the Redis IP profile summary + the latest critical logs + Stage-1 classification tags.
MITRE ATT&CK Vector RAG: Queries a local vector store (ChromaDB / FAISS) indexed with official MITRE ATT&CK tactics, techniques, and mitigations.
Storyline & Remediation Generation: Sends the enriched prompt to the Cloud LLM API to write a concise chronological storyline (in AR/EN), map MITRE IDs, and recommend immediate firewall actions.

🎯 النتيجة من المرحلة التانية: تقرير حادثة كامل (Attack Storyline + MITRE ID + Remediation) جاهز للعرض الفوري في الداشبورد. 🎯 Stage-2 Output: Complete human-readable Incident Storyline + MITRE mapping + SOAR action ready for the dashboard.

3. إيه هي الأوبشنز الجاهزة في المرحلة التانية؟ (Commercial Cloud APIs)

3. Stage-2 Pre-Trained LLM Options (Commercial Cloud APIs)

شركات بتديك API Key تكلم بيه الموديلات الضخمة بتاعتها مباشرة على السحابة من غير أي عبء على جهازك

Zero local hardware overhead—accessed via standard REST API keys on the cloud

الترشيح الأول للمشروع Top Pick for Project

1. Google Gemini API

Gemini 3.1 Pro / Gemini 3.8 Flash / Gemini 4 Argon

نسخة الـ Flash ممتازة جداً لمشروعنا لأنها سريعة جداً، وفيها Free Tier محترم هيشيل مشروع التخرج والتجارب ببلاش، غير إن جوجل نزلت مؤخراً Gemini 4 Argon الموجه خصيصاً للـ Cyber Defenders وتحليل الثغرات.

The Flash tier offers ultra-low latency and a generous Free Tier ideal for graduation demos and testing, alongside Google's specialized Gemini 4 Argon model built for Cyber Defenders and threat analysis.

✓ Fast + Generous Free Tier

Cloud API

2. OpenAI API

GPT-5.4 / GPT-6 Family (GPT-6.1 Terra / Sol)

موديلات قوية جداً وسريعة في فهم الـ JSON المهيكل (Structured Outputs) وتنفيذ الـ Workflows الأمنية المعقدة، بس بتحتاج شحن رصيد مسبق (Credit Card).

Industry-leading structured JSON output enforcement and security workflow reasoning, though it requires prepaid API billing credits.

Structured JSON Outputs (Paid API)

Cloud API

3. Anthropic Claude API

Claude Sonnet 4.6 / Sonnet 5.5 / Haiku 5.5

ممتازة جداً في تحليل اللوجز الطويلة والأكواد وتفكيك الهجمات بدقة عالية بدون هبد (Low Hallucination)، بس برضه مدفوعة.

Exceptional accuracy in parsing long log chains, deconstructing exploit payloads, and minimizing hallucinations (Paid API).

High-Precision Log Analysis (Paid API)

المقارنة Dimension	المرحلة الأولى (Stage-1 AI) Stage-1 AI (Fast Local Detection)	المرحلة التانية (Stage-2 AI) Stage-2 AI (Cloud SOC Copilot)
مين اللي عامله؟ Who Builds It?	إحنا اللي مدربينه وعاملين له Fine-tuning Trained & Fine-Tuned by Our AI Team	موديل LLM جاهز (Cloud API) + RAG من تصميمنا Pre-Trained Cloud LLM API + Our Custom MITRE RAG
إيه الموديلات المستخدمة؟ Models Used	XGBoost + Isolation Forest + SecBERT	Gemini 3.8 Flash / 4 Argon, GPT-5.4 / 6.1, or Claude Sonnet 5.5 + MITRE RAG
متطلبات الهاردوير Hardware Requirements	خفيف جداً: يشتغل على أي لابتوب عادي حتى لو 8GB RAM ومن غير GPU (بيسحب أقل من 300MB RAM) Ultra-Lightweight: Runs on any laptop (even 8GB RAM without GPU, using <300MB RAM)	زيرو استهلاك للجهاز: شغال على السحابة عبر API Key ويشتغل على أي جهاز فيه إنترنت Zero Local Compute: Runs in the cloud via API Key on any internet-connected machine
بيشتغل إمتى؟ When Does It Run?	على كل الـ Logs اللي داخلة (100% من الترافيك) On every incoming log batch (100% of traffic)	على الحوادث الخطيرة بس لما الـ Risk يعدي 75% (1% من الترافيك) ONLY on high-risk incidents when Risk ≥ 75% (~1% of traffic)
سرعة الرد Latency	< 20 ms (Real-Time)	0.5s – 2.0s
وظيفته إيه؟ Primary Role	يطلع الـ `Risk Score` ويكتشف الشذوذ ونوع الهجوم Computes `Risk Score`, detects anomalies, and tags attack types	يقرأ القصة كاملة، يشرحها بالعربي/إنجليزي، ويقترح الحل من MITRE Synthesizes full attack storyline (AR/EN) & suggests MITRE remediation

4. الـ API Contract بين الـ backend وسيرفر الـ AI (FastAPI)

4. FastAPI Microservice Input / Output JSON Contract

شكل الـ request والـ response على POST /ai/v1/analyze

Exact payload sent by the Node.js Backend and returned by Python FastAPI

AI Response Returned to Backend (POST /ai/v1/analyze)

{
  "ip": "197.55.12.40",
  "is_malicious": true,
  "updated_risk_score": 94,
  "severity": "CRITICAL",
  "stage1_metrics": {
    "secbert_payload_class": "SQL_INJECTION",
    "secbert_confidence": 0.982,
    "isolation_forest_anomaly_score": 0.89
  },
  "incident_storyline": {
    "title": "Multi-Stage Reconnaissance, SSH Brute Force & SQL Injection",
    "mitre_tactic": "Initial Access & Credential Access",
    "mitre_technique_id": "T1190 / T1110",
    "summary_ar": "الـ IP 197.55.12.40 عمل scan على 6 ports على الـ firewall، بعدها 18 محاولة باسورد فاشلة لحساب admin، وبعدين بعت SQL Injection نجح في سحب جدول المستخدمين.",
    "summary_en": "IP 197.55.12.40 scanned 6 firewall ports, executed 18 failed SSH/Web login attempts on 'admin', and injected a UNION SELECT SQL payload on /products.",
    "recommended_action": "BLOCK_IP_IMMEDIATELY"
  }
}