Research question
How can a learning platform designed for resource-constrained communities improve security without making educational access impractical?
My completed master’s research at Ateneo de Manila University examined this question through the Edu-Cloud/NearCloud environment. The final manuscript is titled Enhancing Edu-Cloud Security Through Integration of SIEM and XDR: A Cost-Effective Approach to Protecting NearCloud Platform from Cyberthreats and is dated November 2023.
Author: John Donnie I. Celestre
Thesis adviser: Dr. Nathaniel Joseph C. Libatique
Degree: Master of Science in Electronics Engineering
- Edu-Cloud services
Educational applications, web services, authentication, and the host environment.
- Event collection
Bring relevant host and service records into the monitoring system.
- Wazuh analysis
Apply configured rules and surface security-relevant events for review.
- Response and review
Investigate alerts, apply configured responses, and examine the resulting evidence.
Architecture and security assessment
The manuscript examines a Raspberry Pi-based environment with educational, content, communication, and monitoring services. Its software-stack discussion includes Kolibri, Kiwix, Nginx, Nextcloud/OwnCloud, and MariaDB.
The security assessment considers authentication, permissions, network exposure, data protection, and software vulnerabilities. It discusses ReDoS, SSRF, XSS, and CSRF within the platform’s vulnerability review, connecting application risks with the underlying infrastructure.
Selecting monitoring and response capabilities
I evaluated SIEM options and selected Wazuh for its combination of event collection, detection, integrity monitoring, and response capabilities. The research compares alternatives including OSSIM, OSSEC, Splunk Free, and the ELK stack, with attention to the requirements of an educational deployment.
The contribution is the evaluation and integration approach for Edu-Cloud, rather than authorship of the underlying security products.
Simulation scenarios and reported results
The manuscript documents four security scenarios:
| Scenario | Reported outcome in the study |
|---|---|
| Simulated access by a known malicious actor | Detection and blocking through the configured security response. |
| SQL injection attempt | An alert identifying suspicious database-query activity. |
| Repeated SSH login failures | An alert for a brute-force pattern. |
| Malicious command execution | An alert identifying potentially harmful command activity. |
These are the manuscript’s simulation results, not production telemetry or an independently measured detection-rate benchmark. The work connects alerting with operational responsibilities such as rule maintenance, investigation, configuration review, and incident response.
Engineering contribution
The research brings together vulnerability assessment, tool evaluation, monitoring use cases, and security simulations. It treats security as part of the learning platform’s design, alongside accessibility and resilient communications.
See the Near Cloud project overview and the simulated security-operations Lab for related work. The Lab is a separate educational demonstration, not a replay of the thesis experiments.
A worked alert-correlation example
Repeated authentication failures illustrate how individual records become a detection. The following rule is an educational example, not an export of the thesis configuration. Count failures from one source to one host within a trailing time window:
The indicator contributes one only when all conditions match. W is the window length, t the evaluation time, and o the recorded outcome. A candidate alert occurs when the count meets a chosen threshold. The window, grouping, and threshold must be stated; otherwise “ten failures” could refer to unrelated hosts or widely separated events.
# Synthetic records and relative seconds; no live log access.
def failure_count(events, source, host, now, window=60):
return sum(
e['source'] == source and e['host'] == host
and now - window < e['time'] <= now
and e['outcome'] == 'failure'
for e in events
)
records = [dict(source='demo-client', host='demo-host',
time=t, outcome='failure') for t in range(10)]
assert failure_count(records, 'demo-client', 'demo-host', 10) == 10
assert failure_count(records, 'demo-client', 'other-host', 10) == 0An alert is a review trigger, not proof of a malicious operator. Mistyped credentials or a broken service configuration can also produce failures. Investigation adds account context, successful logins, and subsequent process activity.
Archive record
This summary follows the final 123-page manuscript sent to my adviser in May 2024, whose title page is dated November 2023.