Judge Questions Panel
Qwen was chosen because it natively supports JSON response format, making it ideal for structured security data extraction. Its advanced reasoning capability allows it to perform 4 distinct cognitive tasks sequentially — classification, tool selection, planning, and self-validation — without hallucinating intermediate steps. Running on Alibaba Cloud DashScope International provides low-latency access from our ECS deployment on the same infrastructure.
Sentinel Edge is autonomous in analysis and planning but never autonomous in execution for critical actions. Every high and critical severity incident requires explicit human approval before containment steps execute. This is the Human-in-the-Loop (HITL) design pattern — the system does the cognitive heavy lifting, humans retain final authority. Low severity incidents (network scans, recon) can auto-execute to reduce alert fatigue.
Sentinel Edge never goes down. When Qwen is unavailable, the offline_analyzer module activates automatically. It uses keyword-based classification covering 9 threat types, regex-based IOC extraction, and pre-built containment playbooks. Responses are marked with provider: offline_smart so the dashboard can track fallback rates. This graceful degradation means the system protects infrastructure even during API outages.
SQLite provides persistent cross-session memory. Every incident is stored with its full analysis JSON, reasoning chain, MCP enrichment data, IOCs, and status. This enables the correlation engine to find patterns across incidents that happened days apart. The system remembers every attacker IP, username, domain, and filepath it has ever seen — building a threat intelligence memory that grows with every analysis.
False positives are mitigated at three layers. First, Qwen Step 4 self-validates the analysis and assigns a confidence score — low confidence triggers the human approval gate regardless of severity. Second, AbuseIPDB cross-references extracted IPs against real-world threat data, preventing low-abuse IPs from triggering critical responses. Third, the HITL gate ensures a human reviews every high/critical action before execution.
Evaluation runs on 15 automated edge case tests covering health, malformed input, SQL injection attempts, concurrent load, IOC extraction accuracy, classification accuracy across 4 threat types, and incident persistence. All 15 tests pass at 100%. In addition, the stress test validates 5 concurrent users, campaign correlation detection, and HITL workflow completion end-to-end.
The correlation engine uses a weighted scoring algorithm across three dimensions: time proximity (30%), IOC overlap (50%), and threat type progression (20%). Incident pairs scoring above 0.4 are linked. Connected incidents are then graph-traversed using BFS to identify campaigns. The engine maps detected campaigns against the MITRE ATT&CK kill chain stages to identify attack progression patterns.
When Qwen generates a containment plan requiring approval, the incident is stored with status pending. The dashboard shows the pending count prominently. Security analysts can click Approve on the dashboard or View Chain to review the full AI reasoning before approving. On approval, the action module executes each containment step, timestamps the execution, and updates the incident status to executed with a full execution log.
Sentinel Edge implements defense-in-depth. At the API layer: rate limiting (30 req/min per IP), input sanitization blocking SQL and command injection, schema validation rejecting malformed payloads. At the infrastructure layer: Nginx reverse proxy, no direct port 5000 exposure, systemd service isolation. At the code layer: all secrets in environment variables, .env excluded from git, no hardcoded credentials anywhere in the codebase.
The current deployment handles 20 concurrent requests (5 workers x 4 threads). Horizontal scaling is straightforward — the stateless Flask API can run on multiple ECS instances behind an Alibaba Cloud SLB load balancer. The SQLite database would migrate to Alibaba Cloud RDS (PostgreSQL) for multi-instance deployments. The modular architecture means any module can be swapped independently — e.g., replacing the offline analyzer with a fine-tuned security model.