How Leiden University boosted incident handling by 50% and simplified security reporting with TheHive

Leiden University is the oldest and one of the most prestigious universities in the Netherlands, with faculties spanning science, governance, archaeology and beyond. Its Security Operations Center serves the entire institution, tracking threats, managing vulnerabilities and responding to incidents affecting thousands of staff, students and researchers.

Two and a half years ago, the team had no structured incident response process in place. Security incidents were scattered across Confluence pages, Jira tickets, TopDesk tickets and the basic case management module embedded in the Elastic Stack. Five different tools were being used to accomplish, more or less, the same thing—and none of them gave a complete picture.

As a result, every time a new vulnerability surfaced or a patch was released, the team would spend hours chasing down what had been done before—only to discover that no one had a clear record.

The team’s primary goal was to have one place where every security event, case and action would live, with complete transparency.

Roy Kokkelkoren knows this problem better than most. As chairman of SCIRT (a community of incident response professionals within the Dutch education sector), he sees dozens of universities struggle with fragmented tooling and lack the centralized visibility needed for meaningful reporting.

At Leiden, the answer was TheHive. The SOC uses it as its operational hub, which can then be used to inform other relevant parties, such as Information Security Officers across faculties. For everyone involved, TheHive is the single source of truth for everything happening in the university’s cybersecurity environment.

Alerts flow into TheHive from a range of sources, all consolidated through a custom Python tool named “Pollen” (as in what bees bring into a hive). It pulls APIs on different schedules and generates alerts directly in TheHive.

The sources include:

• Microsoft Defender (EDR)
• Splunk and the Elastic Stack (SIEM)
• HaveIBeenPwned (credential exposure monitoring)
• Jamf (Apple device management)
• NCSC publications (national threat intelligence)
• Email (a dedicated email connector handles phishing reports from users)
• EASM platform (External Attack Surface Management)

The email connector aside, all sources feed TheHive via API. The centralized ingestion ensures nothing is missed, even when alert volumes spike.

When an alert arrives, it is picked up by a first- or second-line analyst and assessed. If it requires escalation to a case, the analyst applies a case template and follows a structured playbook.

Playbooks at Leiden cover the full incident taxonomy: malware, intrusion, phishing, vulnerability management, information security events and more. They are both documentation and workflows that guide analysts step by step from identification through containment to closure.

To reduce reliance on external tools and ensure consistent, standardized enrichment, the team has developed a library of custom analyzers within Cortex (the analysis and response engine working closely with TheHive):

• TopDesk analyzer—queries the university’s internal ITSM system
• IPinfo analyzer (enhanced)—enhanced to add VPN detection and other relevant signals
• Microsoft Defender analyzer—tweaked to work reliably with the university’s environment
• Elastic Stack analyzer—searches the university’s firewall logs (approximately 150 million records per day) to surface relevant entries for a given observable
• LDAP analyzer—identifies which faculty or department a user belongs to, enabling automatic case labeling by faculty

Over the past several months, the team has been building SOAR automation using n8n, an open-source workflow automation platform. TheHive sits at the center: it triggers n8n workflows, which then handle enrichment, AI-based extraction, notification routing and more.

One example of this in practice:

1. The team built an AI agent that, when a case is closed, automatically generates a management-level summary of the entire investigation.
2. That summary is written back into TheHive, then distributed by email to the relevant Local Information Security Officers (LISOs)—staff members across faculties who hold responsibility for information security in their departments.
3. The recipient list is determined automatically based on which faculties are tagged in the case.

Response actions also run through TheHive. Among the custom responders the team has built:

• TopDesk integration—for creating and updating tickets in the university’s ITSM platform
• Firewall block list—a responder that pushes IPs and domains directly to the internal firewall’s block list

A recent platform update—bulk responder execution, released in TheHive 5.7—was a significant quality-of-life improvement

All cases are enriched with structured metadata: faculty labels (via the LDAP analyzer), incident category, source, CIA classification and more. This taxonomy feeds directly into PowerBI reports that the team uses to brief the university’s board of directors.

Because everything is labeled consistently and stored in a single platform, producing reports on which faculties are most affected, what types of incidents are occurring and how cases are progressing requires minimal manual effort.

A faculty was hit by malware. The university’s SOC handled the incident—but two days later, another alert came in from a second faculty. Then, two days after that, a third. All were connected to the same underlying vulnerability.

Because every action, timestamp and observable was recorded in TheHive, the analysts were able to produce a complete timeline: what was done, when, by whom, which faculties were involved, and crucially, the quiet periods between alerts that revealed the lateral spread of the issue.

That timeline became further proof that security operations at Leiden should stay centralized. It also answered the question that comes up in almost every post-incident review: “What exactly happened, and when?”

The multiple cases were ultimately merged into a single investigation, with tasks assigned across analysts and progress tracked collectively—the kind of coordinated response that is straightforward in TheHive and difficult to replicate across disconnected ticketing tools.

Since adopting TheHive 2,5 years ago, the team has tripled in size, and its results speak for themselves.

Before, the SOC could properly handle only an estimated 25% of security incidents (meaning incidents where there was a clear identification, a structured response and a documented closure). Today, that figure is approximately 75%.

Two priorities are driving the next phase of development at Leiden:

1. Deeper AI integration. The team already runs AI workflows through n8n (summarization, enrichment, extraction) and plans to go further. The next step is more autonomous behavior: AI agents that can automatically elevate alerts to cases or close false positives without analyst intervention. The team is also evaluating TheHive’s native MCP server, which would allow LLM agents to interact directly with TheHive and remove the need for a custom middleware layer entirely.
2. More automation. Further scaling means more workload and, therefore, the need to automate more of the triage and response process.

Roy regularly speaks about TheHive at sector-wide conferences, making the case for other Dutch universities to adopt centralized IR platforms. When asked what he would tell someone just starting out, he has two pieces of advice.

In a university environment, knowing which faculty is affected by an incident is just as important as knowing what happened—because that information ultimately reaches the board of directors. If cases are labeled consistently from day one, reporting becomes effortless.

At Leiden, TheHive is not just one tool among many—it is the condition for adopting any new tool.