SIH26157/Blockchain & Cybersecurity

Offline SOC alert analysis software tool

A software tool that helps human supervisors analyze security operations center alert data offline to detect execution gaps, negative space, and prioritize entities for manual review.

National Technical Research Organisation (NTRO) · Software

Teams already in: Not read yet
Buildable in 36 hours: ModerateOur estimate, from their wording
Hard blockers: NoneNothing you must source first
Submissions close: 15 Sept9 days left

Make this one of our two Compare with others

Signing in saves it for your whole team — everyone on your invite link sees the same two entries. Anything you shortlisted while signed out comes with you.

Submit on sih.gov.in

Whether this suits your team

Why this fits you

This organisation declared winners on 13 problem statement(s) in SIH 2025 and on 13 in SIH 2024. It has awarded 4 joint winner(s), so it sometimes splits a prize between two teams.

What you would have to build

Decomposed from what the description asks for. Nothing added.

01
Data Ingestion Module
Ingests structured data such as CSV, JSON, and database exports from multiple entities.
02
Supervisory Analytics Engine
Detects execution gaps, negative space, anomalies, and performs peer comparisons across entities.
03
Explainability Engine
Provides clear rationale, supporting evidence, and traceability for all flagged findings.
04
Dashboard and Reporting
Generates supervisory dashboards, trend analysis, and drill-down capabilities into underlying evidence.
05
Offline Deployment Support
Operates fully in an air-gapped, local environment with no cloud or internet dependencies.

What they ask for, and what they leave open

Both columns are read off the brief's own wording. Nothing here is inferred from the ministry's name.

They state

The jury will check whether your tool can run completely offline without internet or cloud services, explain the rationale behind its findings, and successfully detect execution gaps and missing data using sample datasets.

They never say

Exact schema formats for alert and case-management records
Sample synthetic dataset for testing

A jury can still ask about these. Decide them deliberately rather than by accident.

What they'll ask you

Generated from the brief's own wording and the competition's published rules — never from a guess about what this ministry prefers.

Exact schema formats for alert and case-management records?
The brief never answers this, so a panel will. Whatever you decide, say it the same way twice.
Sample synthetic dataset for testing?
The brief never answers this, so a panel will. Whatever you decide, say it the same way twice.
Has any part of this been shown at a previous event, hackathon or college project?
The guidelines are explicit: your solution must not have appeared in any previous event or programme, of any sort. A recycled project is what a team under time pressure reaches for.

9 more— the ones a panel gets to if there is time

The brief asks for data ingestion module. How would you build that?
Decoded from SIH26157 itself — Ingests structured data such as CSV, JSON, and database exports from multiple entities. The brief asks for it by name.

The data

What the organisers attached, and what the brief assumes you can get.

Dataset from the organisers: None attached
Does the brief need data?: Nothing in the text says it depends on a dataset we would have to find.

Also from National Technical Research Organisation (NTRO)

Same organisation, same year. Reading two of theirs tells you more about what they care about than reading one.

Take this to an AI

Pick what you are about to do and copy the prompt. It carries the organisers' own wording, the constraints they never spell out, and an instruction not to invent requirements they never set.

Who has this problem, what already exists, and what you would have to find out.

# Context: India's Smart India Hackathon 2026

I am on a student team entering SIH 2026. Problem statement SIH26157, set by National Technical Research Organisation (NTRO).
Its official title, word for word: "Supervisory Analytics Tool for SOC Assessment (SAT-SA)"
Theme: Blockchain & Cybersecurity. Category: software.

In plain terms: A software tool that helps human supervisors analyze security operations center alert data offline to detect execution gaps, negative space, and prioritize entities for manual review.

## The organisers' full description, verbatim

Background: The National Critical Information Infrastructure Protection Centre (NCIIPC) assesses the cyber resilience of Critical Sector Entities (CSEs). As part of these assessments, NCIIPC performs manual reviews of samples of security alerts and case-management records generated by Security Operations Centres (SOCs). These reviews have consistently produced valuable supervisory findings that were not evident through policies, audits, self-assessments, management reports, KPI dashboards, or compliance documentation. The purpose of these reviews is not to assess individual alerts. Rather, alert and case-management data are used as operational evidence to assess whether a CSE possesses effective capabilities relating to: (i). Threat Detection (ii). Investigation (iii).Escalation (iv). Incident Response (v).Security Operations (vi).Governance and Oversight (vii).Operational Discipline (viii).Cyber Resilience While effective, manual review is resource-intensive and difficult to scale across a growing number of CSEs and increasing volumes of security data. • Description: NCIIPC seeks a deployable Supervisory Analytics Tool for SOC Assessment (SAT-SA) that assists supervisors in analysing SOC alert and case-management data at scale.The tool should help supervisors: (i). Identify entities requiring supervisory attention. (ii).Prioritise alert samples and investigations for manual review. (iii).Detect operational weaknesses and cyber resilience concerns. (iv).Improve the efficiency, consistency and scalability of supervisory assessments. The tool is intended to support human examiners and supervisory decision-making. It is not intended to replace supervisory judgement. 1. Out of Scope The proposed solution is not intended to: (i). Function or replace as a Security Operations Centre (SOC) of CSEs. (ii).Perform real-time monitoring. (iii).Act as a SIEM platform. (iv).Act as a centralized SOC for multiple entities. (v).Continuously collect logs or telemetry from CSEs. (vi).Serve as a national cyber monitoring platform. The solution should be viewed as a supervisory analytics capability, not an operational security capability. 2. Data Environment Participants may assume access to periodic submissions including: (i). Alert metadata (ii).Case management records (iii).Investigation workflow data (iv).Escalation records (v). Alert disposition and closure information (vi). Asset and system inventory information (where available) Solutions should minimise dependence on raw logs, packet captures, customer information, or other sensitive operational data unless clearly justified. 3. Core Supervisory Problem Manual reviews often uncover weaknesses that are not visible through conventional reporting mechanisms.These weaknesses generally fall into two categories: A. Execution Gaps Situations where documented controls, governance arrangements, policies, procedures, metrics or reported capabilities suggest effective operation, but operational evidence indicates otherwise. • Examples: (i).Alerts acknowledged but not meaningfully investigated. (ii).Cases closed unusually quickly. (iii).Critical alerts closed without escalation. (iv).Repetitive or template-driven investigations. (v).Controls deployed but not effectively monitored. (vi).Operational behaviour designed to satisfy metrics without reducing risk. B. Negative Space Situations where expected evidence is absent. Examples: (i).Missing telemetry from critical systems. (ii).Absence of expected alert categories. (iii).Missing investigations or escalation records. (iv).Unexpectedly low activity levels. (v).Monitoring blind spots. (vi).Absence of evidence that would normally be expected within comparable environments. The tool should help supervisors identify both known and previously unknown indicators of these conditions. 4. Functional Requirements Data Ingestion: The tool shall: 1. Ingest structured data from multiple CSEs. 2. Support common formats such as CSV, JSON, database exports and APIs where available. 3. Support analysis of large datasets spanning multiple entities and time periods. Supervisory Analytics: The tool shall: 4. Identify indicators of detection, investigation and escalation weaknesses. 5. Detect potential execution gaps. 6. Detect potential negative space. 7. Identify anomalies, outliers and suspicious operational patterns. 8. Perform peer comparison and benchmarking across entities. 9. Generate entity-level supervisory risk indicators. 10. Prioritise entities, controls, processes and alert samples for manual review. Explainability: The tool shall: 11. Provide clear rationale for findings. 12. Present supporting evidence. 13. Support traceability and auditability of results. 14. Allow supervisors to understand why an entity or activity was flagged. • Reporting: The tool shall: 15. Generate supervisory dashboards and reports. 16. Support trend analysis across entities and time periods. 17. Enable drill-down from supervisory findings to underlying evidence. • Illustrative Supervisory Use Cases The following examples are illustrative and not exhaustive. The tool may assist in identifying: (i). High-severity alerts closed unusually quickly. (ii). Repeated alerts on the same asset without evidence of root-cause remediation. (iii). Critical alerts closed without appropriate escalation. (iv). Critical systems generating little or no security telemetry. (v). Significant deviations from peer entities. (vi).Missing monitoring coverage for critical environments. (vii).Repetitive investigation patterns suggesting superficial review. (viii).Operational behaviours that satisfy performance metrics without effectively managing cyber risk. (ix).Investigation or escalation workloads inconsistent with expected activity levels. Participants are encouraged to identify additional supervisory signals beyond these examples. 5.Deployment Requirements The solution shall operate within an NCIIPC-controlled environment. The solution must: (i).Operate in a fully offline (air-gapped) network. (ii).Require no Internet connectivity. (iii).Have no dependency on cloud services. (iv).Have no dependency on SaaS platforms. (v).Have no dependency on externally hosted AI models or APIs. (vi).Support local deployment and local data processing. Where AI or machine learning is proposed, participants shall specify: (i).Model architecture. (ii).Hardware requirements. (iii).Offline training and inference approach. (iv).Model update mechanism. (v).Explainability controls. (vi).Auditability controls. 6. Deliverables Participants should provide: (i). Solution architecture. (ii). Functional design. (iii).Analytics methodology. (iv).Data requirements. (v).Tool or Prototype (vi).Infrastructure requirements. (vii).Validation methodology. (viii).Estimated deployment and operational requirements. 7. Performance Criteria Criterion Weight. Ability to Support Supervisory Assessment, Detection of Execution Gaps, Detection of Negative Space, Explainability and Auditability, Scalability and Performance, Innovation and Additional Supervisory Insights 8. Validation Requirement Participants shall explain how the proposed solution will be validated against findings derived from expert manual review. Solutions should demonstrate their ability to identify supervisory signals, operational weaknesses and areas requiring attention with effectiveness comparable to or better than current manual sampling approaches. 9. Success Criterion A successful solution will enable NCIIPC to efficiently analyse large volumes of SOC alert and case-management data from multiple CSEs, identify entities and operational areas requiring supervisory attention, prioritise manual review effort, and preserve the quality of supervisory assurance currently obtained through expert human examination. • Expected Solution/Deliverables for Evaluation • Source Code Link (GitHub/Drive Link) • Readme with Setup Instructions • Architecture Document (Max 2 Pages) • Demo Video (Max 2 Minutes) • Technical Presentation (Max 5 Slides)

## What the brief never says

- Exact schema formats for alert and case-management records
- Sample synthetic dataset for testing
## Constraints that are not negotiable

- The judged build is a prototype demonstrated in roughly 36 hours by students, not a product.
- A jury evaluates it against this problem statement's own wording, not against general merit.
- We submit on sih.gov.in; the problem statement number and title above must match exactly.
- Your solution must not have appeared in any previous event or programme, of any sort.

## What I want from you

1. Who actually has this problem in India, and what they do about it today.
2. What already exists — government systems, open-source projects, published research — that we should not rebuild.
3. For each item under 'what the brief never says', what the realistic answer is likely to be and how I could verify it.
4. The two or three things about this domain that a student team would get wrong without local knowledge.
## How to answer

- Everything above between quotation marks is the organisers' own wording. Treat it as the requirement.
- Do NOT invent requirements the brief does not state. If something matters and is not stated, say so and ask me, rather than assuming.
- Where you are inferring rather than reading, mark it as your inference.
- Do not guess what this ministry wants from its name. Its wording above is the only evidence.

---
Problem statement facts assembled by Wynit from National Technical Research Organisation (NTRO)'s published brief for SIH 2026.
The plain-English summary, the list of parts and the evaluator read are our interpretation of that text; the quoted title and the full description are theirs.

The government's original description (1001 words)

Background: The National Critical Information Infrastructure Protection Centre (NCIIPC) assesses the cyber resilience of Critical Sector Entities (CSEs). As part of these assessments, NCIIPC performs manual reviews of samples of security alerts and case-management records generated by Security Operations Centres (SOCs). These reviews have consistently produced valuable supervisory findings that were not evident through policies, audits, self-assessments, management reports, KPI dashboards, or compliance documentation. The purpose of these reviews is not to assess individual alerts. Rather, alert and case-management data are used as operational evidence to assess whether a CSE possesses effective capabilities relating to: (i). Threat Detection (ii). Investigation (iii).Escalation (iv). Incident Response (v).Security Operations (vi).Governance and Oversight (vii).Operational Discipline (viii).Cyber Resilience While effective, manual review is resource-intensive and difficult to scale across a growing number of CSEs and increasing volumes of security data. • Description: NCIIPC seeks a deployable Supervisory Analytics Tool for SOC Assessment (SAT-SA) that assists supervisors in analysing SOC alert and case-management data at scale.The tool should help supervisors: (i). Identify entities requiring supervisory attention. (ii).Prioritise alert samples and investigations for manual review. (iii).Detect operational weaknesses and cyber resilience concerns. (iv).Improve the efficiency, consistency and scalability of supervisory assessments. The tool is intended to support human examiners and supervisory decision-making. It is not intended to replace supervisory judgement. 1. Out of Scope The proposed solution is not intended to: (i). Function or replace as a Security Operations Centre (SOC) of CSEs. (ii).Perform real-time monitoring. (iii).Act as a SIEM platform. (iv).Act as a centralized SOC for multiple entities. (v).Continuously collect logs or telemetry from CSEs. (vi).Serve as a national cyber monitoring platform. The solution should be viewed as a supervisory analytics capability, not an operational security capability. 2. Data Environment Participants may assume access to periodic submissions including: (i). Alert metadata (ii).Case management records (iii).Investigation workflow data (iv).Escalation records (v). Alert disposition and closure information (vi). Asset and system inventory information (where available) Solutions should minimise dependence on raw logs, packet captures, customer information, or other sensitive operational data unless clearly justified. 3. Core Supervisory Problem Manual reviews often uncover weaknesses that are not visible through conventional reporting mechanisms.These weaknesses generally fall into two categories: A. Execution Gaps Situations where documented controls, governance arrangements, policies, procedures, metrics or reported capabilities suggest effective operation, but operational evidence indicates otherwise. • Examples: (i).Alerts acknowledged but not meaningfully investigated. (ii).Cases closed unusually quickly. (iii).Critical alerts closed without escalation. (iv).Repetitive or template-driven investigations. (v).Controls deployed but not effectively monitored. (vi).Operational behaviour designed to satisfy metrics without reducing risk. B. Negative Space Situations where expected evidence is absent. Examples: (i).Missing telemetry from critical systems. (ii).Absence of expected alert categories. (iii).Missing investigations or escalation records. (iv).Unexpectedly low activity levels. (v).Monitoring blind spots. (vi).Absence of evidence that would normally be expected within comparable environments. The tool should help supervisors identify both known and previously unknown indicators of these conditions. 4. Functional Requirements Data Ingestion: The tool shall: 1. Ingest structured data from multiple CSEs. 2. Support common formats such as CSV, JSON, database exports and APIs where available. 3. Support analysis of large datasets spanning multiple entities and time periods. Supervisory Analytics: The tool shall: 4. Identify indicators of detection, investigation and escalation weaknesses. 5. Detect potential execution gaps. 6. Detect potential negative space. 7. Identify anomalies, outliers and suspicious operational patterns. 8. Perform peer comparison and benchmarking across entities. 9. Generate entity-level supervisory risk indicators. 10. Prioritise entities, controls, processes and alert samples for manual review. Explainability: The tool shall: 11. Provide clear rationale for findings. 12. Present supporting evidence. 13. Support traceability and auditability of results. 14. Allow supervisors to understand why an entity or activity was flagged. • Reporting: The tool shall: 15. Generate supervisory dashboards and reports. 16. Support trend analysis across entities and time periods. 17. Enable drill-down from supervisory findings to underlying evidence. • Illustrative Supervisory Use Cases The following examples are illustrative and not exhaustive. The tool may assist in identifying: (i). High-severity alerts closed unusually quickly. (ii). Repeated alerts on the same asset without evidence of root-cause remediation. (iii). Critical alerts closed without appropriate escalation. (iv). Critical systems generating little or no security telemetry. (v). Significant deviations from peer entities. (vi).Missing monitoring coverage for critical environments. (vii).Repetitive investigation patterns suggesting superficial review. (viii).Operational behaviours that satisfy performance metrics without effectively managing cyber risk. (ix).Investigation or escalation workloads inconsistent with expected activity levels. Participants are encouraged to identify additional supervisory signals beyond these examples. 5.Deployment Requirements The solution shall operate within an NCIIPC-controlled environment. The solution must: (i).Operate in a fully offline (air-gapped) network. (ii).Require no Internet connectivity. (iii).Have no dependency on cloud services. (iv).Have no dependency on SaaS platforms. (v).Have no dependency on externally hosted AI models or APIs. (vi).Support local deployment and local data processing. Where AI or machine learning is proposed, participants shall specify: (i).Model architecture. (ii).Hardware requirements. (iii).Offline training and inference approach. (iv).Model update mechanism. (v).Explainability controls. (vi).Auditability controls. 6. Deliverables Participants should provide: (i). Solution architecture. (ii). Functional design. (iii).Analytics methodology. (iv).Data requirements. (v).Tool or Prototype (vi).Infrastructure requirements. (vii).Validation methodology. (viii).Estimated deployment and operational requirements. 7. Performance Criteria Criterion Weight. Ability to Support Supervisory Assessment, Detection of Execution Gaps, Detection of Negative Space, Explainability and Auditability, Scalability and Performance, Innovation and Additional Supervisory Insights 8. Validation Requirement Participants shall explain how the proposed solution will be validated against findings derived from expert manual review. Solutions should demonstrate their ability to identify supervisory signals, operational weaknesses and areas requiring attention with effectiveness comparable to or better than current manual sampling approaches. 9. Success Criterion A successful solution will enable NCIIPC to efficiently analyse large volumes of SOC alert and case-management data from multiple CSEs, identify entities and operational areas requiring supervisory attention, prioritise manual review effort, and preserve the quality of supervisory assurance currently obtained through expert human examination. • Expected Solution/Deliverables for Evaluation • Source Code Link (GitHub/Drive Link) • Readme with Setup Instructions • Architecture Document (Max 2 Pages) • Demo Video (Max 2 Minutes) • Technical Presentation (Max 5 Slides)