Request for Technical Guidance and Collaboration – AI-driven Monitoring System using Wazuh Architecture

20 views
Skip to first unread message

SANTHOSH S

unread,
Nov 4, 2025, 2:00:54 AM (23 hours ago) Nov 4
to Wazuh | Mailing List

Dear Wazuh Team,

We are a team of pre-final year students from Thiagarajar College of Engineering, Madurai (India), currently developing an AI-driven Monitoring System aimed at ensuring fairness, transparency, and data security during digital examinations conducted in college lab environments.

Our proposed system — powered by a Cross-App Behaviour Engine (CABE) integrated with Explainable Artificial Intelligence (XAI) — aims to continuously observe and analyze system and network-level activities of student devices. The system will identify and flag suspicious behavior (e.g., accessing prohibited applications, unapproved websites, performing external data transfers) and report these in real time to an invigilator/Professor dashboard.

 

We have studied the Wazuh architecture and believe that its open-source SIEM and XDR capabilities provide a strong foundation for building this project. We wish to leverage Wazuh’s framework for endpoint monitoring, rule-based alerting, and dashboard extensibility.

 

To successfully design and implement our project, we seek technical guidance, documentation access and possible internship/training opportunities from the Wazuh team /community.

 

An AI-driven Monitoring System for digital examination security in college labs, inspired by the Wazuh architecture and enhanced with a Cross-App Behaviour Engine (CABE) and Explainable AI (XAI)

1.     The Wazuh architecture is scalable and agent-based.it has central components for data collection (from endpoints), analytical processing, and dashboard visualization. This makes it flexible for custom integrations and extensions to fit our college lab scenario

2.     A cross-app engine tracking both system and network-level activities is achievable, as Wazuh already supports log aggregation and event monitoring across endpoints, applications, and network devices, with agentless monitoring where needed.

Agent layer (student Machine)
→ Wazuh Agents collect: logs, process list, FIM events, DNS/HTTP logs, network connection metadata, clipboard/file transfer hooks (where permitted)
→ Wazuh Manager / Indexer (central ingestion, normalization, indexing)
→ CABE (separate analytics service sitting adjacent to indexer; consumes indexed events)
 Feature extractor (per-device & cross-device)
 Behaviour models (statistical + ML)
 Correlation & rule engine (temporal correlation, SIEM rules)
 XAI & decision explanation module
→ Invigilator dashboard (integrates Wazuh Dashboard + custom CABE panels)
→ Audit & secure storage (encrypted), Incident response & feedback loop to update rules/models

COMPONENTS AND RESPONSIBILITIES

A. Collection (Wazuh agents)

  1. Endpoint data: running processes, open ports, active windows (title + PID — careful with PII), active browser tabs (domain + hashed URL fragment), clipboard events (only metadata), USB mount/unmount events, file writes to shared locations.
  2. Network metadata: DNS resolution logs, HTTP hostnames, TLS SNI, external IP connections (no full packet capture unless authorised).
  3. FIM (file integrity monitoring) for exam files/folder.
  4. Syscalls / process events for suspicious child processes (e.g., launching browser devtools, screen sharing apps).

B. Central ingestion & normalization

  1. Use Wazuh Manager + indexer (OpenSearch/Elasticsearch-like) to index events; normalize schema with fields: device_id (pseudonym), user_id (pseudonym), timestamp, event_type, process, parent_process, network_destination, extra_meta.

C. Cross-App Behaviour Engine (CABE)

a.      Collectors/Streamers: Subscribe to event streams from indexer.

b.     Feature extractor: sliding windows (e.g., last N minutes) to compute behavioral features per session and cross-device aggregates:

a.      App-switching frequency, new process launches, CPU spikes, clipboard-to-network ratio, unexpected outbound connections, file transfer attempts, browser tab changes to unapproved domains, time-of-day activity patterns.

c.      Models:

a.      Rule-based: immediate critical rules (e.g., “exam app terminated”, “external display connected”).

b.     Anomaly detection (unsupervised): isolation forest, autoencoders, LSTM-based sequence anomaly detectors for time-series of events.

c.      Supervised classifiers: if you have labelled historical exam sessions (allowed vs cheating), use XGBoost / RandomForest / small CNN/RNN ensembles.

d.     Graph-based correlation: link suspicious events across devices (e.g., same external IP used across many students).

d.     Correlation engine: temporal logic to combine signals (e.g., clipboard copy → suspicious outbound connection → file write → high confidence alert).

e.      Scoring & confidence: probability or score per alert, plus contributing features.

D. XAI & Explanation Layer

A)Provide explanations for each alert:

    1. Feature contribution (SHAP or integrated gradients for neural models).
    2. Rule trace (which rules fired, timestamps).
    3. Example counterfactual: “If browser was not connected to domain X at time Y, score drops from 0.92 → 0.12.”
    4. Confidence and suggested invigilator action (e.g., “Check device screen share”, “Request student clarification”).

B)Explanations must be concise and human-friendly (one sentence + expandable evidence view).

E. Dashboard & Workflow

a.      Integrate CABE alerts into Wazuh Dashboard or a custom web UI: timeline, per-student view, alert queue, evidence panel (logs, screenshots if permitted, process list), explainability card.

b.      Support triage: acknowledge, mark false positive, append notes (used to retrain models).

 

 IMPLEMENTATION:

A)Prototype on a small lab:

  1. Deploy Wazuh agents to a handful of test devices.
  2. Ingest logs into manager/indexer.
  3. Implement basic rule-based alerts (exam app focus, process launches).
  4. Build simple CABE feature extractor and a baseline anomaly detector (isolation forest).
  5. Add a dashboard view for invigilators.

B)Expand analytics & XAI:

  1. Add supervised models if labelled data exists.
  2. Integrate SHAP-based explanations and rule trace.
  3. Add cross-device correlation (network linking).

4.      Implement on-device preprocessing for privacy.

5.      Run pilot exams, gather ground truth, measure metrics and refine thresholds.

6.Conduct fairness & privacy audits; consult legal/ethics committee.

7.Tune UI and triage workflows.

D)Rollout & maintenance:

  1. Harden agents, scale indexer, add RBAC and encryption, establish retention & incident response.
  2. Create continuous feedback loop: triage labels → periodic retraining.

METHODOLOGY FOR PROPOSED PROJECT

 

Our Project Maps to the Wazuh Architecture

 

THE "AI-DRIVEN" ENHANCEMENT:

our  propsed project moves beyond a standard Wazuh deployment. Wazuh provides the data and the alerting framework; your AI/ML models provide the advanced "brain."

1.      Data Feed for AI: The Wazuh agents will stream a rich dataset of system behavior to your central server. This includes:

a.      Process Execution: Every application a student opens.

b.      Network Activity: Every IP address and port they connect to.

c.      File System Activity: Files created, modified, or deleted.

d.      User Logins/Logouts.

2.      Integrating the AI Engine (CABE & XAI):

o   Option A : Build a separate "AI Analysis Microservice" that subscribes to the Wazuh alerts and the raw event data (Wazuh can forward this via its RESTful API or to a message bus like Kafka). Your AI model consumes this data, performs its complex behavioral analysis (e.g., "Student A opened a browser, then quickly switched to a PDF reader, then started a Python script—a sequence indicative of looking up answers"), and then sends a new, enriched alert back to the Wazuh API.

o   Option B: For simpler models, we could write custom Python scripts as Wazuh Active Response scripts. These are triggered by specific Wazuh rules and can perform additional checks.

3.      Explainable AI (XAI) in the Dashboard: This is a crucial part of your project. When your AI model flags a student, the invigilator dashboard shouldn't just say "CHEATING DETECTED." It must explain:

    1. The system detected an anomalous sequence: 1) Process 'cmd.exe' was spawned by 'browser.exe', 2) A connection was made to an unknown external IP, 3) A large volume of data was uploaded within 10 seconds."
    2. This explanation is generated by our XAI layer and must be injected into the alert that Wazuh displays.

 

 

SUPPORT REQUESTED FROM WAZUH

1. Data Collection and Forwarding

  1. Access to real-time event data streams (process, network activity, file integrity events, and custom logs from student endpoints).
  2. Support for extending data collection through agent configuration or custom modules.

2. Integration for AI/Machine Learning

  1. RESTful API or event streaming (Kafka, RabbitMQ, or webhooks) to ingest raw/normalized data into our CABE service.
  2. Documentation and examples for integrating external analytics and XAI services with Wazuh’s alerting pipeline.
  3. Capability to push AI-enriched alerts and interpretability outputs into Wazuh’s dashboard or a custom UI.

3. Custom Rules, Actions, and Workflows

  1. Guidance on creating fine-grained rules for event correlation (process chains, time-based, multi-source).
  2. Examples for Active Response scripting (Python/bash) to automate responses for rule matches.
  3. Configuration options for USB, clipboard, and network activity monitoring consistent with exam policy enforcement.

4. Dashboard and UI Extensibility

  1. Support for integrating custom CABE panels and XAI explanation components within Wazuh Dashboard.
  2. Documentation for API/UI interactions between custom modules and the Wazuh interface.

5. Security, Privacy, and Compliance

  1. Best practices for ensuring data minimization, pseudonymization, and encryption during collection and transmission.
  2. Guidance on secure log retention, RBAC configuration, and compliance documentation for audit readiness.

 We are confident that this collaboration can serve as a meaningful academic and practical exploration of AI-enhanced security monitoring built upon Wazuh’s powerful foundation.

We would deeply appreciate your technical mentorship, documentation references, and any possible internship or training opportunities to further our learning and implementation.


Thank you for your time and consideration.
We look forward to your valuable guidance and feedback.

Warm regards,
HARISH K

AKSHAI S

SANTHOSH S

Pre-final Year Student, Department of Information Technology
Thiagarajar College of Engineering, Madurai – India

 

Md. Nazmur Sakib

unread,
Nov 4, 2025, 3:51:37 AM (21 hours ago) Nov 4
to Wazuh | Mailing List
Hi Santhosh,

I believe I have previously checked the
presentation sent by one of your project mates, named Harish. The ideas you have shared are very interesting. I really appreciate your prepared road map and proposal.

As I have mentioned previously to Harish,

There are different ways you can contribute to Wazuh and collaborate with us.


One of them includes the Wazuh Ambassador Program. If you like Wazuh and want to contribute to the project or share your knowledge about Wazuh with the community, the Ambassador Program can be a good match for you.
But unfortunately, right now, we don’t have any available spots for your country. We’re working on increasing the number of openings per region so we can accept more candidates in the future.

As far as I am aware of currently we do not have any internship opportunities open in India. I will still check with the team and let you know if any opportunities open in the future.

If you need any support with your work, you can ask those queries one by one in this Google group or any other community platforms we have 
https://wazuh.com/community/

The Wazuh team members and the people in the community will guide you on those posts or queries.

We can start with Data Collection and Forwarding in this post.

From the web interface, you can go to  Indexer management > Sample Data and add some sample indexed alerts on the dashboard.

saple_data.png

I will suggest that you review these files to understand how you can collect different logs from the endpoint.

Local configuration (ossec.conf)

Log data collection


Let me know if you need any further information on the log collection and forwarding.

I will also request you to create separate posts on the other topic, so that we can keep track and guide you properly.
Reply all
Reply to author
Forward
0 new messages