Supervisory Analytics Tool for SOC Assessment (SAT-SA)

1. Executive Snapshot

Summary

The Supervisory Analytics Tool for SOC Assessment (SAT-SA) is an air-gapped, supervisory intelligence platform designed for the National Critical Information Infrastructure Protection Centre (NCIIPC) [PS]. While Critical Sector Entities (CSEs) maintain operational Security Operations Centres (SOCs) and report compliance metrics, manual audits repeatedly reveal operational weaknesses—specifically Execution Gaps (superficial or gaming behaviour despite policy compliance) and Negative Space (absent security telemetry or missing alert categories) [PS]. SAT-SA ingests batch-submitted, multi-entity SOC metadata (alert metadata, case records, escalation logs, asset inventories) without collecting raw logs or packet captures [PS]. Operating 100% offline within NCIIPC’s controlled environment [PS], SAT-SA leverages statistical benchmarking, vector-based natural language processing (NLP), machine learning anomaly detection, and a localized quantized Small Language Model (SLM) to prioritize high-risk CSEs, flag superficial investigation templates, detect coverage blind spots, and generate fully traceable, explainable supervisory evidence for human examiners [PS, INFERENCE].

Metadata Table

2. Problem Deconstruction

Explicit Requirements

• Primary Mandate: Provide a deployable Supervisory Analytics Tool for SOC Assessment (SAT-SA) that assists NCIIPC human examiners in analyzing SOC alert and case-management data at scale [PS].
• Core Capabilities [PS]:
  1. Identify entities requiring supervisory attention.
  2. Prioritize alert samples and investigations for manual review.
  3. Detect operational weaknesses and cyber resilience concerns.
  4. Improve efficiency, consistency, and scalability of supervisory assessments.
  5. Support human examiners without replacing supervisory judgment.

Out of Scope Exclusions [PS]

• The tool shall NOT function as or replace a SOC for CSEs [PS].
• The tool shall NOT perform real-time monitoring [PS].
• The tool shall NOT act as a SIEM platform [PS].
• The tool shall NOT act as a centralized SOC for multiple entities [PS].
• The tool shall NOT continuously collect logs or telemetry from CSEs [PS].
• The tool shall NOT serve as a national cyber monitoring platform [PS].

Data Environment Explicit Guidelines [PS]

• Periodic submission ingestion of:
  • (i) Alert metadata [PS]
  • (ii) Case management records [PS]
  • (iii) Investigation workflow data [PS]
  • (iv) Escalation records [PS]
  • (v) Alert disposition and closure information [PS]
  • (vi) Asset and system inventory information (where available) [PS]
• Tool must minimize dependence on raw logs, packet captures, customer information, or sensitive operational data [PS].

Core Supervisory Conditions to Detect [PS]

• Category A: Execution Gaps [PS]: Documented controls look effective, but operational evidence shows failure:
  • (i) Alerts acknowledged but not meaningfully investigated [PS].
  • (ii) Cases closed unusually quickly [PS].
  • (iii) Critical alerts closed without escalation [PS].
  • (iv) Repetitive or template-driven investigations [PS].
  • (v) Controls deployed but not effectively monitored [PS].
  • (vi) Operational behavior designed to satisfy metrics without reducing risk [PS].
• Category B: Negative Space [PS]: Absence of expected operational evidence:
  • (i) Missing telemetry from critical systems [PS].
  • (ii) Absence of expected alert categories [PS].
  • (iii) Missing investigations or escalation records [PS].
  • (iv) Unexpectedly low activity levels [PS].
  • (v) Monitoring blind spots [PS].
  • (vi) Absence of evidence expected in comparable environments [PS].

Functional Requirements (1–17) [PS]

• Data Ingestion:
  1. Ingest structured data from multiple CSEs [PS].
  2. Support common formats: CSV, JSON, database exports, and APIs where available [PS].
  3. Support analysis of large datasets spanning multiple entities and time periods [PS].
• Supervisory Analytics:
  4. Identify indicators of detection, investigation, and escalation weaknesses [PS].
  5. Detect potential execution gaps [PS].
  6. Detect potential negative space [PS].
  7. Identify anomalies, outliers, and suspicious operational patterns [PS].
  8. Perform peer comparison and benchmarking across entities [PS].
  9. Generate entity-level supervisory risk indicators [PS].
  10. Prioritize entities, controls, processes, and alert samples for manual review [PS].
• Explainability:
  11. Provide clear rationale for findings [PS].
  12. Present supporting evidence [PS].
  13. Support traceability and auditability of results [PS].
  14. Allow supervisors to understand why an entity or activity was flagged [PS].
• Reporting:
  15. Generate supervisory dashboards and reports [PS].
  16. Support trend analysis across entities and time periods [PS].
  17. Enable drill-down from supervisory findings to underlying evidence [PS].

Deployment Requirements (Air-Gapped Environment) [PS]

• Fully air-gapped network under NCIIPC control [PS].
• No Internet connectivity [PS].
• No dependency on cloud services or SaaS platforms [PS].
• No dependency on externally hosted AI models or APIs [PS].
• Support local deployment and local data processing [PS].
• Required AI specifications if used: Model architecture, hardware requirements, offline training/inference approach, model update mechanism, explainability controls, auditability controls [PS].

3. Stakeholders & User Needs

4. Requirements Traceability

5. Constraints & Environment Realities

1. Air-Gapped Physical & Network Security: NCIIPC operates in high-security, network-isolated environments [PS, KNOWN]. The system cannot rely on external DNS, cloud storage (AWS, Azure), SaaS platforms, or remote AI APIs (OpenAI, Anthropic) [PS].
2. Hardware Constraints: Supervisory laptops or local workstations utilized by examiners may range from mid-tier laptops (16 GB RAM, 8-core CPU, no discrete GPU) to dedicated audit workstations (64 GB RAM, NVIDIA RTX GPU) [ASSUMPTION]. AI models must run efficiently on CPU-only or modest GPU setups [INFERENCE].
3. Data Heterogeneity & Quality: CSEs use diverse SIEM/SOAR platforms (Splunk, Elastic, IBM QRadar, Sentinel, ArcSight) with varying field naming conventions [KNOWN, INFERENCE]. Ingested data may have missing fields, inconsistent time formats, or sanitized asset identifiers [INFERENCE].
4. Confidentiality & Non-Attribution: Sectoral peer benchmarking must maintain operational privacy across competing or strategic CSEs [INFERENCE]. Raw asset identifiers must be hash-anonymized in supervisory cross-entity views while remaining traceable within single-entity audits [INFERENCE].
5. Human-in-the-Loop Imperative: The system must not act as an automated decision-maker or enforcement tool [PS]. All outputs are advisory evidence artifacts to augment human examiner judgment [PS].

6. Research Questions

1. Schema Standardization: How can heterogeneous alert/case formats from Splunk, Elastic, and custom SOARs be mapped to a unified supervisory schema without losing domain-specific context? [INFERENCE]
2. Template Detection Algorithm: What combination of TF-IDF, N-gram cosine similarity, and vector embeddings yields the best precision in detecting copy-paste or superficial analyst investigation notes in an offline environment? [RESEARCHED, INFERENCE]
3. Negative Space Statistical Modeling: How can negative space (missing telemetry or missing threat categories) be differentiated from actual low-threat operational tranquility without generating excessive false positives? [INFERENCE]
4. Offline Explainability: How can a small, quantized language model (e.g., Llama-3-8B-Instruct GGUF) be constrained to generate strictly factual supervisory audit reports without introducing hallucinations or ungrounded claims? [RESEARCHED, INFERENCE]
5. Evaluation against Human Expert Baseline: How can the tool prove its effectiveness is equal to or superior to expert manual review during hackathon judging? [PS, INFERENCE]

7. Data Requirements & Sources

8. Existing Solutions & Gap Analysis

9. Candidate Solution Approaches

Approach 1: Deterministic Rule-Based & Statistical Heuristic Engine

• Mechanism: A suite of SQL queries, REGEX rules, and hardcoded threshold checks (e.g., Alert Closure Time < 30 seconds = Flagged; Critical Severity + Escalation False = Flagged) [INFERENCE].
• Architecture: Python backend parsing CSV/JSON files into an SQLite database, executing rule triggers, and outputting static HTML/PDF audit reports [INFERENCE].
• Complexity: Very Low [INFERENCE].
• Cost: $0 [INFERENCE].
• Explainability: 100% deterministic and easy to audit [INFERENCE].
• Scalability: High performance, low computational overhead [INFERENCE].
• Hackathon Feasibility: 100% buildable in 48 hours [INFERENCE].
• Production Feasibility: Poor flexibility; fails to detect novel/unknown execution gaps or subtle semantic metric gaming [INFERENCE].
• Risks: High false-positive rate; rigid thresholds can be easily gamed if CSEs learn the exact rules [INFERENCE].

Approach 2: Pure Unsupervised Machine Learning Anomaly Detection

• Mechanism: Ingests numerical features extracted from alerts/cases (closure speed, alert frequency, word count, escalation ratios) into unsupervised ML algorithms (Isolation Forest, DBSCAN, Autoencoders) [RESEARCHED, INFERENCE].
• Architecture: Python data pipeline (scikit-learn, PyTorch) vectorizing data, running multi-dimensional outlier detection, and clustering suspicious behaviors [INFERENCE].
• Complexity: Medium-High [INFERENCE].
• Cost: Low (Runs on local CPU/GPU) [INFERENCE].
• Explainability: Poor (Black-box anomaly scores; difficult to explain to a human examiner why an alert was flagged) [INFERENCE].
• Scalability: Moderate (Scales with feature dimensionality) [INFERENCE].
• Hackathon Feasibility: Feasible for a student team [INFERENCE].
• Production Feasibility: Fails NCIIPC’s mandatory explainability and auditability requirement (FR-11 to FR-14) [PS, INFERENCE].
• Risks: High false alarm rate; examiners cannot verify evidence without interpretable feature attribution [INFERENCE].

Approach 3: Hybrid Supervisory Intelligence Engine (Deterministic Rules + Vector NLP + Anomaly Detection + Local SLM)

• Mechanism: Combines deterministic rules (for clear violations), vector similarity + NLP embeddings (for copy-paste investigation template detection), statistical peer-group benchmarking (for negative space and low telemetry), and a locally hosted quantized Small Language Model (e.g., Llama-3-8B-Instruct GGUF) for natural language rationale synthesis [RESEARCHED, INFERENCE].
• Architecture: React/Tailwind frontend, FastAPI Python backend, SQLite/DuckDB local analytical database, ChromaDB vector store for sentence embeddings, and llama-cpp-python for local offline SLM inference [INFERENCE].
• Complexity: Moderate-High [INFERENCE].
• Cost: $0 open-source stack running 100% air-gapped on standard hardware [INFERENCE].
• Explainability: Extremely high (Combines explicit rule/vector evidence with clear text summaries grounded in exact case numbers) [INFERENCE].
• Scalability: Excellent for batch supervisory uploads [INFERENCE].
• Hackathon Feasibility: High (Core modules buildable within hackathon timeframe) [INFERENCE].
• Production Feasibility: Excellent; fully compliant with all deployment, explainability, and air-gapped constraints [PS, INFERENCE].
• Risks: SLM inference latency on CPU-only hardware (mitigated by quantized 4-bit GGUF models and caching) [INFERENCE].

10. Recommended Approach & Why

Selection: Approach 3 (Hybrid Supervisory Intelligence Engine)

Approach 3 is selected as the winning architecture because it uniquely satisfies all functional, explainability, and deployment requirements set by NCIIPC [PS, INFERENCE].

                                +-------------------------------------------------------+
                                |      SAT-SA HYBRID ANALYTICS SELECTION MATRIX        |
                                +-------------------------------------------------------+
                                                                |
         +----------------------------------+-------------------+----------------------------------+
         |                                  |                                                      |
[Deterministic Rules Engine]    [Vector NLP & Anomaly ML Engine]                        [Local SLM Engine]
- Catches explicit violations   - Uncovers repetitive text templates                    - Synthesizes examiner audit
- 100% traceable evidence       - Flags statistical negative space                      - Explains "Why Flagged"
- Zero false logic              - Benchmarks peer entities                              - 100% offline & air-gapped
         |                                  |                                                      |
         +----------------------------------+-------------------+----------------------------------+
                                                                |
                                                                v
                                                [Unified Supervisory Evidence Graph]

Why Alternatives Were Rejected

1. Approach 1 (Pure Rules) was rejected because hardcoded thresholds cannot catch subtle metric gaming (e.g., an analyst waiting exactly 31 seconds before auto-closing to bypass a 30-second rule) or identify semantically repetitive investigation notes written in different words [INFERENCE].
2. Approach 2 (Pure Unsupervised ML) was rejected because black-box anomaly scores fail NCIIPC's explicit requirement for trace-back auditability and clear rationale (FR-11 to FR-14) [PS]. Examiners cannot issue regulatory warnings based purely on an unexplained Isolation Forest distance score [INFERENCE].

11. Technical Architecture

Layered System Architecture

+-------------------------------------------------------------------------------------------------------------------+
|                                            1. PRESENTATION LAYER (UX)                                            |
|   +---------------------------------------+  +----------------------------------+  +--------------------------+   |
|   | Executive Supervisory Dashboard       |  | Entity Peer Benchmarking Heatmap|  | Audit Sample Reviewer    |   |
|   +---------------------------------------+  +----------------------------------+  +--------------------------+   |
|   | Negative Space Topology Explorer      |  | Execution Gap Investigation View |  | PDF/HTML Report Generator|   |
|   +---------------------------------------+  +----------------------------------+  +--------------------------+   |
+-------------------------------------------------------------------------------------------------------------------+
                                                          | REST APIs / WebSocket (Localhost)
+-------------------------------------------------------------------------------------------------------------------+
|                                          2. APPLICATION & SERVICE LAYER                                          |
|   +---------------------------------------+  +----------------------------------+  +--------------------------+   |
|   | API Gateway (FastAPI / Python 3.12)   |  | Prioritization & Ranking Module  |  | Evidence Traceability Bus|   |
|   +---------------------------------------+  +----------------------------------+  +--------------------------+   |
+-------------------------------------------------------------------------------------------------------------------+
                                                          |
+-------------------------------------------------------------------------------------------------------------------+
|                                         3. ANALYTICS & DETECTION CORE LAYER                                       |
|   +---------------------------------------+  +----------------------------------+  +--------------------------+   |
|   | Rule-Based Execution Gap Analyzer     |  | Vector Similarity Engine         |  | Negative Space Engine    |   |
|   | - Fast Closure (<30s)                 |  | - TF-IDF & Cosine Distance      |  | - Asset vs Alert Cross-Ref|   |
|   | - Unescalated Criticals               |  | - Template Investigation Detection|  | - Missing ATT&CK Tactics |   |
|   +---------------------------------------+  +----------------------------------+  +--------------------------+   |
|   | Statistical Peer Benchmarking Engine  |  | Local SLM Explainability Engine  |  | Anomaly Scoring Engine   |   |
|   | - Gini Index & MTTR Skewness          |  | - Llama-3-8B-Instruct (GGUF 4-bit)|  | - Isolation Forest       |   |
|   +---------------------------------------+  +----------------------------------+  +--------------------------+   |
+-------------------------------------------------------------------------------------------------------------------+
                                                          |
+-------------------------------------------------------------------------------------------------------------------+
|                                          4. DATA & LOCAL INFERENCE LAYER                                          |
|   +---------------------------------------+  +----------------------------------+  +--------------------------+   |
|   | DuckDB / SQLite Analytical Database   |  | ChromaDB Vector Store            |  | llama-cpp-python Engine  |   |
|   | (Structured Metadata & Schema Maps)   |  | (Investigation Embeddings)       |  | (Local Offline CPU/GPU)  |   |
|   +---------------------------------------+  +----------------------------------+  +--------------------------+   |
+-------------------------------------------------------------------------------------------------------------------+
                                                          |
+-------------------------------------------------------------------------------------------------------------------+
|                                      5. INGESTION & SCHEMATIZATION LAYER                                          |
|   +---------------------------------------+  +----------------------------------+  +--------------------------+   |
|   | Universal File Parsers (CSV/JSON/DB)  |  | S3S Normalizer & Field Mapper    |  | Pseudonymization Pipeline|   |
|   +---------------------------------------+  +----------------------------------+  +--------------------------+   |
+-------------------------------------------------------------------------------------------------------------------+

Data Flow Narrative

1. Ingestion & Normalization: The examiner uploads periodic SOC export batches (CSV/JSON/SQLite) via the local web UI [PS, INFERENCE]. The Ingestion Pipeline parses heterogeneous fields into the Standardized Supervisory SOC Schema (S3S) and generates salted cryptographic hashes for sensitive asset/analyst names [INFERENCE].
2. Deterministic & Vector Processing: Data is routed concurrently to:
   • Rule Engine: Evaluates time-to-close metrics, severity escalations, and SLA compliance [INFERENCE].
   • Vector NLP Store (ChromaDB): Embeds investigation text notes using a local sentence-transformer model (all-MiniLM-L6-v2) to detect cluster density of identical/templated responses [RESEARCHED, INFERENCE].
   • Negative Space Engine: Cross-references asset inventory lists against alert streams to pinpoint zero-telemetry assets and absent ATT&CK categories [INFERENCE].
3. Statistical Benchmarking & Risk Scoring: The Benchmarking Engine clusters CSEs by peer group (e.g., Banking vs. Power) and calculates z-scores for alert distribution, MTTR variance, and Gini coefficients of investigation depth [INFERENCE]. A composite Supervisory Risk Score (0-100) is computed per entity [INFERENCE].
4. Offline SLM Rationale Generation: For top-ranked suspicious samples, structured finding parameters (e.g., Entity: PowerCorp_01, Finding: 45 critical alerts closed in <20s with template text X) are passed into llama-cpp-python running a quantized Llama-3-8B-Instruct model [INFERENCE]. The SLM outputs a concise, factual supervisory summary [INFERENCE].
5. Presentation & Audit Trail: Findings populate the Supervisory Dashboard [PS]. Examiners click on any flagged metric to inspect the exact underlying case IDs, original text, and timestamp evidence chain [PS, INFERENCE].

12. Technology Stack

13. AI/ML Justification

Explicit Non-AI Component

• Negative Space Asset Coverage Engine: DOES NOT USE AI. Uses deterministic SQL outer-joins and set-difference logic (Asset_Inventory EXCEPT Alert_Generating_Assets) combined with MITRE ATT&CK coverage mapping matrices [INFERENCE]. Using AI here would introduce non-deterministic hallucination into asset presence/absence auditing [INFERENCE].

14. Data Architecture & Offline/Low-Network Design

Standardized Supervisory SOC Schema (S3S)

The system normalizes incoming heterogeneous CSE exports into a local DuckDB schema:

-- Core Table: Ingested Alerts Metadata
CREATE TABLE s3s_alerts (
    alert_id VARCHAR PRIMARY KEY,
    cse_id VARCHAR NOT NULL,
    timestamp TIMESTAMP NOT NULL,
    rule_name VARCHAR NOT NULL,
    severity VARCHAR CHECK (severity IN ('LOW', 'MEDIUM', 'HIGH', 'CRITICAL')),
    mitre_tactic VARCHAR,
    mitre_technique VARCHAR,
    source_asset_id VARCHAR,
    dest_asset_id VARCHAR,
    raw_status VARCHAR
);

-- Core Table: Case Management & Investigations
CREATE TABLE s3s_cases (
    case_id VARCHAR PRIMARY KEY,
    alert_id VARCHAR REFERENCES s3s_alerts(alert_id),
    cse_id VARCHAR NOT NULL,
    created_at TIMESTAMP NOT NULL,
    closed_at TIMESTAMP,
    resolution_time_seconds INTEGER,
    assigned_analyst_hash VARCHAR,
    escalation_status VARCHAR CHECK (escalation_status IN ('NONE', 'TIER_2', 'CISO', 'NCIIPC', 'CERT_IN')),
    disposition VARCHAR CHECK (disposition IN ('TRUE_POSITIVE', 'FALSE_POSITIVE', 'BENIGN_ANOMALY', 'UNRESOLVED')),
    investigation_notes TEXT
);

-- Core Table: Critical Asset Inventory
CREATE TABLE s3s_asset_inventory (
    asset_id VARCHAR PRIMARY KEY,
    cse_id VARCHAR NOT NULL,
    asset_name_hash VARCHAR NOT NULL,
    asset_type VARCHAR, -- e.g., 'OT_SCADA', 'DOMAIN_CONTROLLER', 'SWIFT_GATEWAY'
    criticality_tier INTEGER CHECK (criticality_tier IN (1, 2, 3)),
    ip_subnet VARCHAR
);

-- Core Table: Derived Supervisory Findings (Audit Trail)
CREATE TABLE s3s_supervisory_findings (
    finding_id VARCHAR PRIMARY KEY,
    cse_id VARCHAR NOT NULL,
    category VARCHAR CHECK (category IN ('EXECUTION_GAP', 'NEGATIVE_SPACE', 'ANOMALY', 'BENCHMARK_DEVIATION')),
    rule_code VARCHAR NOT NULL,
    severity VARCHAR NOT NULL,
    rationale_text TEXT NOT NULL,
    supporting_evidence_json JSON NOT NULL,
    flagged_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Local Storage & Air-Gapped Optimization

• In-Memory Query Engine: DuckDB executes analytical queries directly against local Parquet/SQLite storage, yielding sub-second aggregation across millions of rows without network overhead [RESEARCHED].
• Offline Vector Indexing: ChromaDB indexes investigation note embeddings locally using HNSW (Hierarchical Navigable Small World) graph trees saved to local disk [RESEARCHED].
• Bandwidth & Offline Packaging: The entire system (UI, backend, DuckDB, ChromaDB, GGUF SLM model file) is packaged as a portable 4.8 GB offline bundle that can be transferred via encrypted USB drive to an air-gapped NCIIPC audit workstation [ASSUMPTION].

15. Security, Privacy & Governance

• Personal & Sensitive Data Minimization: Complies with PS Section 2 [PS]. Customer PII, raw packet captures, and cleartext passwords are excluded from ingestion schemas [PS]. Analyst identifiers and internal IP addresses are hash-anonymized (SHA-256(Salt + Asset_IP)) at the ingestion boundary [INFERENCE].
• Air-Gapped Network Enclosure: The application binds exclusively to 127.0.0.1 (localhost) [INFERENCE]. No external network calls, telemetry phone-home scripts, or external CDN dependencies exist [PS].
• Access Control & Role-Based Authorization (RBAC):
  • Supervisory Lead: Full audit creation, cross-entity peer benchmarking view, report sign-off [INFERENCE].
  • Supervisory Examiner: Single-entity audit execution, evidence inspection, finding annotation [INFERENCE].
• Tamper-Evident Audit Logging: Every action taken by an examiner (flagging a case, dismissing an anomaly, generating an executive report) is appended to an immutable, local JSON-lines log file protected with HMAC-SHA256 signatures [INFERENCE].
• Governance & Regulatory Disclaimer: Prominently displays: "SAT-SA is an advisory supervisory tool designed to assist human examiners under Section 70A of the IT Act 2000. Outputs represent operational evidence indicators and do not replace formal regulatory adjudication." [PS, INFERENCE]

16. MVP Scope (Hackathon Build)

+---------------------------------------------------------------------------------------------------+
|                                      SAT-SA HACKATHON MVP SCOPE                                   |
+---------------------------------------------------------------------------------------------------+
|  [MUST BUILD - CORE MVP]                                                                          |
|  * Universal CSV/JSON Ingestion Pipeline for S3S Schema mapping.                                 |
|  * Execution Gap Engine: Fast-closure (<30s), Unescalated Criticals, Template Note Similarity.    |
|  * Negative Space Engine: Zero-telemetry Critical Assets & Missing MITRE Tactics.                  |
|  * Peer Benchmarking: MTTR distribution skewness & Alert Volume variance across 3 CSEs.           |
|  * Local SLM Integration: GGUF 4-bit Llama-3-8B generating plain-language audit rationales.        |
|  * Supervisory Web Dashboard: React UI with Risk Scores, Sample Reviewer, & PDF export.           |
|                                                                                                   |
|  -----------------------------------------------------------------------------------------------  |
|  [SHOULD BUILD - EXTENDED DEMO]                                                                   |
|  * Interactive ATT&CK Heatmap comparing CSE coverage against baseline.                          |
|  * Custom threshold sliders for supervisory sensitivity tuning.                                    |
|  * Hash-anonymization toggle for cross-entity privacy.                                           |
|                                                                                                   |
|  -----------------------------------------------------------------------------------------------  |
|  [DO NOT BUILD DURING HACKATHON - OUT OF SCOPE]                                                   |
|  x Real-time live log ingestion or SIEM connector agents [PS Section 1].                          |
|  x Multi-node distributed cloud cluster deployment [PS Section 5].                               |
|  x Automated incident response or firewall block triggering [PS Section 1].                       |
+---------------------------------------------------------------------------------------------------+

17. Live Demo Simulation Plan

To convince SIH judges without access to classified NCIIPC/CSE live feeds, the team will run a Multi-Entity Synthetic Case Study Simulator:

1. Simulated Environment Dataset Generation:
   • Synthesize batch exports for 3 distinct entities in the Energy and BFSI sectors:
     • Entity A (PowerGrid_Alpha): Compliant operational entity with realistic alert resolution distributions.
     • Entity B (Bank_Beta): Exhibiting Execution Gaps (300 critical alerts closed in <15 seconds; 85% of cases contain identical copy-paste investigation text "Checked logs, false positive").
     • Entity C (Grid_Gamma): Exhibiting Negative Space (Critical OT Domain Controller generating 0 alerts over 90 days; total absence of Lateral Movement / Ransomware detection rules).
2. Live Execution Storyboard (2-Minute Video / Live Judge Demo):
   • Minute 0:00 - 0:30: Examiner launches SAT-SA on a completely disconnected (Wi-Fi OFF) laptop. Uploads batch JSON exports for Entities A, B, and C [INFERENCE].
   • Minute 0:30 - 1:00: Ingestion completes. The Executive Dashboard flags Bank_Beta with a Supervisory Risk Score of 88/100 (Execution Gap) and Grid_Gamma with 79/100 (Negative Space) [INFERENCE].
   • Minute 1:00 - 1:30: Examiner drills into Bank_Beta. Tool displays the vector similarity cluster proving 210 cases used identical template text, and shows the 15-second closure velocity histogram [INFERENCE].
   • Minute 1:30 - 2:00: Examiner clicks "Generate Supervisory Audit Report". The local SLM synthesizes a clean, evidence-backed audit summary citing exact case IDs. PDF export is generated instantly [INFERENCE].

18. Implementation Roadmap

Phase 1: Architecture & Synthetic Data Pipeline (Weeks 1-2 | By Sept 12)
├── Define S3S JSON/CSV schemas
├── Build Synthetic CSE Data Generator (Seeding Execution Gaps & Negative Space)
└── Setup FastAPI backend & DuckDB database schema

Phase 2: Core Analytics & Local AI Engines (Weeks 2-3 | By Sept 20)
├── Implement Rule Engine (Closure speed, unescalated criticals)
├── Integrate SentenceTransformers & ChromaDB for template detection
├── Build Negative Space & Asset Cross-Referencing module
└── Integrate llama-cpp-python with 4-bit GGUF SLM for offline summarization

Phase 3: Supervisory UI & Benchmarking (Weeks 3-4 | By Sept 26)
├── Develop React/Tailwind Supervisory Dashboard
├── Build Entity Peer Benchmarking & Risk Scoring views
├── Implement Evidence Drill-Down modal & PDF Report Generator
└── Conduct air-gapped network testing (100% offline verification)

Phase 4: Optimization, Demo Prep & Deliverables (Final Days | By Sept 30)
├── Finalize 2-page Architecture Document
├── Record & edit 2-minute Demo Video
├── Create 5-slide Technical Presentation Deck
└── Code freeze & GitHub repository cleanup

19. Testing & Validation Plan

20. Risk Register

21. Cost & Scalability

Hackathon Prototype Cost

• Software Costs: $0 (100% open-source stack: React, FastAPI, DuckDB, ChromaDB, SentenceTransformers, Llama-3 GGUF) [INFERENCE].
• Hardware Costs: $0 (Runs on standard student laptops with 16 GB RAM) [INFERENCE].
• Total Hackathon Cost: ₹0 / $0 [INFERENCE].

Production System Requirements (NCIIPC Deployment)

• Dedicated Workstation / Server: Dual 16-Core CPU, 64 GB RAM, 2 TB NVMe Storage, optional NVIDIA RTX A4000 (16GB VRAM) for accelerated local batch processing [ASSUMPTION].
• Estimated Hardware Cost: Approx. ₹2,500,000 – ₹4,000,000 per supervisory audit station [ASSUMPTION].
• Scalability: DuckDB and ChromaDB local indexing scale efficiently to handle 10,000,000+ batch records per entity upload, processing full annual supervisory audits within minutes [RESEARCHED, INFERENCE].

22. Differentiation

23. Future Scope

1. STIX/TAXII 2.1 Native Supervisory Export: Enable seamless supervisory findings exchange with CERT-In and sector regulators via standard cyber threat intelligence formats [KNOWN, INFERENCE].
2. Federated Supervisory Analytics: Allow CSEs to execute local SAT-SA pre-audit self-evaluations without exposing internal sensitive case notes to external parties [INFERENCE].
3. Multi-Year Cyber Resilience Trend Modeling: Longitudinal tracking of CSE SOC operational maturity across multi-year assessment cycles [PS, INFERENCE].
4. OT/ICS Protocol-Specific Negative Space Templates: Specialized audit rule sets for SCADA/MODBUS/DNP3 environments in the Energy and Transportation sectors [KNOWN, INFERENCE].

24. Assumptions & Open Items Log

Consolidated Assumptions

• [ASSUMPTION] Hackathon team will utilize synthetically generated SOC alert and case management data structured after Elastic Common Schema (ECS) and ServiceNow SecOps exports.
• [ASSUMPTION] Examiner workstations possess at least 16 GB RAM and an 8-core CPU capable of executing 4-bit quantized 8B SLM models at 10-15 tokens/sec.
• [ASSUMPTION] Production deployment hardware costs fall within standard government procurement budgets for specialized cyber assessment tools.

Open Items & Validation Needed

• [NEEDS VALIDATION] Exact proprietary export schemas currently mandated by NCIIPC for CSE periodic submissions.
• [NEEDS VALIDATION] Specific sector-level baseline thresholds for MTTR and alert volume expectations across small vs. large CSEs.
• [NEEDS VALIDATION] Formal legal framework governing NCIIPC's evidence retention periods for supervisory audit findings under Section 70A.

Final Recommendation

BUILD SAT-SA USING APPROACH 3 (HYBRID SUPERVISORY INTELLIGENCE ENGINE). This problem statement is a top-tier pick for a high-performing 4-6 student team [INFERENCE]. It is fundamentally a data analytics, NLP, and regulatory framework problem rather than a standard web app [INFERENCE]. By strictly adhering to the air-gapped constraint and focusing on Execution Gaps and Negative Space rather than building a generic SIEM, the team will stand out significantly during SIH judging [INFERENCE].

Recommended Stack

React.js, TailwindCSS, FastAPI, DuckDB, ChromaDB, all-MiniLM-L6-v2 (SentenceTransformers), llama-cpp-python with Llama-3-8B-Instruct (Q4_K_M GGUF), Pandas, Scikit-Learn [INFERENCE].

Biggest Dependency

Constructing a highly realistic, multi-entity synthetic dataset pre-seeded with subtle Execution Gaps and Negative Space indicators prior to writing UI code [INFERENCE].

Biggest Risk

Submitting a solution that looks like a SIEM or real-time monitoring tool, which is explicitly listed as OUT OF SCOPE in Section 1 of the problem statement [PS].

Biggest Technical Challenge

Achieving fast, deterministic, anti-hallucinatory explainability from a locally hosted SLM running on CPU hardware in an air-gapped environment [RESEARCHED, INFERENCE].

First 5 Actions

1. Action 1: Write a Python script to generate a multi-entity synthetic dataset (CSV/JSON) containing 10,000 alerts and 2,000 cases with pre-seeded metric gaming and unmonitored assets [ASSUMPTION].
2. Action 2: Set up DuckDB schema and test SQL queries for fast closure velocity (<30s) and unescalated critical alerts [INFERENCE].
3. Action 3: Test SentenceTransformers + ChromaDB locally to verify detection of copy-paste investigation text templates [RESEARCHED].
4. Action 4: Benchmark llama-cpp-python with a 4-bit Llama-3-8B GGUF model on CPU to verify local generation latency and prompt constraints [RESEARCHED].
5. Action 5: Build the React supervisory dashboard UI focusing on the Entity Risk Score, Execution Gap explorer, and Evidence Drill-Down modal [INFERENCE].

Validation Before Coding

Verify that the synthetic dataset generator successfully embeds statistically detectable anomalies (Execution Gaps & Negative Space) that can be proven via ground-truth labels before building the frontend interface [INFERENCE].

Buildability Score /100

88 / 100. Extremely buildable for a dedicated student team with strong Python, data science, and web development skills [INFERENCE].

Confidence

HIGH (0.92). The problem requirements, scope exclusions, deployment constraints, and domain context are completely clear and actionable [INFERENCE].

Research Sources

1. Title: Information Security Practices and Procedures for Protected System Rules, 2018
   URL: MeitY Notification PDF
   Source Type: Official Government Document
   Supported Claim: NCIIPC mandate under Section 70A of the Information Technology Act 2000 for Protected Systems audit and assessment [PS, KNOWN].
   Reliability: Authoritative / Official Government Source.

2. Title: NCIIPC Critical Information Infrastructure (CII) Audit & Conformity Assessment Framework
   URL: CyberSigma NCIIPC Audit Guide
   Source Type: Technical Cybersecurity Compliance Guide
   Supported Claim: Auditing methodologies and control evaluation expectations across Indian Critical Sector Entities (Power, BFSI, Telecom, Transport) [KNOWN, RESEARCHED].
   Reliability: High (Domain-specific compliance analysis).

3. Title: Agentic SOC Alert Triage & NLP Incident Classification
   URL: Elastic Security Labs Research
   Source Type: Industry R&D Technical Article
   Supported Claim: Use of vector embeddings and sentence similarity for automated investigation template detection and alert triage [RESEARCHED].
   Reliability: High (Leading security vendor technical publication).

4. Title: Policy-Guided Threat Hunting & LLM Enabled SOC Triage Framework
   URL: arXiv:2603.23966 Technical Paper
   Source Type: Peer-Reviewed Academic Preprint
   Supported Claim: Combining reconstruction autoencoders, statistical anomaly scoring, and LLMs for explainable SOC alert triage [RESEARCHED].
   Reliability: High (Academic Research Paper).