Implementing an API key to fetch incidents from an Elastic index is highly advantageous: it helps avoid exposing plain-text passwords in configuration files. This method streamlines security protocols and simplifies access management when integrating incident data.
At Grenoble Alpes University, the IT team within the DGDSI (Delegated General Directorate for Information Systems) team appreciated Cortex XSOAR’s feature that supports API key authentication. However, due to budget constraints, the university opted not to pursue Palo Alto’s licensing solutions, which were beyond their financial reach.
Background: The Initiative to Deploy a SIEM System
Since 2020, the university has been working on establishing a Security Information and Event Management (SIEM) system. The primary goal was to enhance the security of its Active Directory environment, which manages over 100,000 user accounts. Historically, event logs were collected centrally on syslog servers, with analysis carried out via command-line tools such as grep and Bash scripts scheduled automatically through cron jobs.
A Shortlist of 10 Open Source SIEM Solutions
The project aimed to develop a graphical and dynamic representation of security activities. Particular attention was given to data standardization and enrichment—such as geolocating IP addresses and assessing the likelihood of a machine being compromised. GDPR compliance was also a key consideration, especially concerning the legal data retention periods for logs. The use of machine learning was viewed as an asset to improve alerting accuracy, complementing traditional threshold-based systems or rule-based detections.
The system team sought a solution that was:
- Open source with an active community for ongoing support
- Deployed on-site to maintain full control over log data
- Easy to maintain and adaptable to future needs
- Regularly updated with security patches and features
- Capable of data redundancy and fault tolerance
- Able to authenticate users within the existing information system
- Equipped with robust access control mechanisms for data security
From this set of criteria, ten solutions were shortlisted: Elasticsearch, Graylog, Apache Metron, MozDef, OSSEC, OSSIM, Prelude SIEM, Sagan, Snort, and Wazuh.
The Power of Elastic’s Modularity
The testing environment included multiple domain controllers, client workstations, and storage on NetApp arrays. The evaluation focused on three core aspects:
- Detecting user and admin login activities within Active Directory
- Identifying mass encryption attempts on storage devices
- Detecting brute-force and denial-of-service attacks, and initiating appropriate responses
Elastic’s ELK stack (Elasticsearch, Logstash, Kibana) was ultimately chosen, primarily because of its modular architecture. It stood out against other candidates like OSSIM and OSSEC, which also showed promising results but lacked the same flexible structure.
Final Architecture and Deployment
The final sandbox setup comprised three Elasticsearch nodes, one Logstash node, and one Kibana instance. This architecture offers the necessary scalability and resilience for an effective SIEM deployment.
Expanding to Network and Cyber Teams
In operational environments, the university’s two data centers support a bifurcated (bizone) architecture. Integration of Active Directory data within Elasticsearch relies on the Winlogbeat agent installed on domain controllers, which collects security logs. Custom alerts are configured to trigger under specific conditions, such as:
- An account being locked more than three times in two hours
- A user being added to a critical security group
- Over 100 password changes executed by the same account within five minutes
Note that the current architecture does not strictly adhere to Elastic’s quorum principle, which ensures cluster stability. If zone A disconnects, the entire cluster could be compromised, highlighting a potential point of vulnerability.
The SIEM’s scope has gradually expanded to include other sources: university websites, Zimbra messaging system, and central authentication services. It also now incorporates logs from network devices (VPN connections, Cisco ISE) and cybersecurity solutions (Vectra, Trend Micro).
Current Limitations in Incident Response Capabilities
While Elastic’s platform offers smooth deployment—particularly on Kubernetes with an effective operator—the visualization and event analysis remain relatively straightforward. Elastic’s concept of ‘space’ allows administrators to delineate different operational zones clearly.
However, resource consumption is significant, as the platform is over 99% Java-based, leading to high memory demands. Free versions lack advanced features such as machine learning, SAML authentication for Kibana, email or webhook alerts, and more. Adding new services or integrations often requires significant development effort unless a pre-existing connector exists. Additionally, the native query language (KQL) has limitations, necessitating learning a more technical Domain Specific Language (DSL).
The most significant shortcoming identified by the DGDSI relates to incident response capabilities. Unlike dedicated Security Orchestration, Automation, and Response (SOAR) platforms, Elastic does not support executing scripts or nuanced responses directly. It’s feasible to isolate an infected machine or terminate processes remotely, but no built-in functionality exists for running scripts or orchestrating complex responses.
Exploration of SOAR Solutions – None Fully Deployed
Three SOAR platforms were tested. Only Palo Alto Networks’ solution proved operational. The Splunk SOAR and Fortinet’s offerings faced integration issues: Splunk’s couldn’t process data due to format errors, while Fortinet’s required creating specific playbooks that relied solely on Elastic’s database cluster. These attempts utilized only Python-based response scripts.
Given budget limitations, the project was not moved into production. The DGDSI concluded that existing SOAR tools are overly complex for their needs. Consequently, they elected to develop an in-house solution that mimics the tested approach: querying Elastic incident indexes in real time and executing Python scripts tailored to specific alerts. The long-term goal includes:
- Leveraging this system to broadcast account hacking alerts across the entire security infrastructure
- Potentially blocking compromised sessions remotely
- Using the platform as a Malware Information Sharing Platform (MISP) to centralize Indicators of Compromise (IOCs) from internal cybersecurity tools like Vectra, Apex One, and HarfangLab
