When a hotel group's reservation system slowed to a crawl one Friday night, the on-call IT staff opened the dashboard and found hundreds of failed logins. Who was attacking, from where, and against which account? Nobody could say, because the logs were scattered across separate servers. That visibility gap is common in hospitality, where booking data is valuable and IT teams are lean. To close it, the group ran a fast SIEM deployment. Within 24 hours the scattered logs merged into one timeline, and the story of the attack became clear.
A 30-Minute SIEM Deployment
The group's biggest worry was familiar: that setup would take days and disrupt operations. In practice, a well-planned SIEM deployment takes minutes, not days. Here the platform went live in roughly 30 minutes, connecting the firewall, servers, and authentication services to a single panel.
The chosen platform was ERBE SIEM, our on-premises security monitoring product developed entirely in-house. Release 1.0.0 ships 27 modules, 31 dashboard screens, and 111 automated tests, with TÜBİTAK RFC 3161 support for trusted timestamping.
SIEM stands for security information and event management: a system that collects logs from many sources into one place and correlates them. Readers who want the fundamentals can start with our SIEM guide.
The secret to a fast rollout is an ordered source list. The team connected the most-attacked authentication service first, then firewall and web-server logs, then the database records. This order made the most critical traffic visible from the first minute, so useful alerts appeared before the deployment even finished.
The First 24 Hours: 262 Attempts from 104 IPs
The first day was busier than expected: our own monitoring recorded 262 attack attempts over 24 hours from 104 distinct IP addresses. At peak, the rate reached 16 attempts per second. The most striking result: every record was processed on-site, with 0 cloud transfer.
The table below summarizes the first 24 hours.
| Metric | First 24-hour value |
|---|---|
| Total attack attempts | 262 |
| Distinct source IPs | 104 |
| Peak attempt rate | 16 per second |
| Records sent to the cloud | 0 |
| Deployment time | ~30 minutes |
These numbers are a prioritization tool, not just statistics. The dashboard showed at a glance which accounts were targeted and which IPs were persistent, so the team focused on the real threat instead of drowning in scattered alerts. Businesses that would rather not carry this monitoring load in-house can hand 24/7 oversight to our Managed SOC / MDR service.
The geographic spread was instructive too: most attempts came from regions where the hotel does no business. Mapping normal traffic also built a baseline, so unusual moves stood out more sharply afterward.
Anatomy of a Bot Running 16 Attempts per Second
Sixteen attempts per second is far beyond human typing speed; it is the fingerprint of an automated bot. The attempts arrived at short, regular intervals, with usernames pulled from an alphabetical list and passwords tried in dictionary-attack fashion — the textbook signature of a brute-force attempt.
The bot's real goal was to seize a weak administrator account and gain a first foothold on the network. Seen one by one, each attempt looks like an innocent failed login. But 16 repeats per second were instantly linked into a single attack event by the correlation engine, surfacing the incident early.
How Was Bot Traffic Separated from Real Users?
The key is the behavior pattern. A real front-desk employee signs in a few times a minute, and even after a failure the retry is not instant. A bot hammers the same target without pause. ERBE SIEM caught this speed difference with threshold rules: a high count of failed logins from one IP in a short window was automatically flagged as high risk.
This pattern is often the reconnaissance phase of a larger campaign. We cover how attackers stage denial-of-service attempts in our DDoS attack article. Separating bot traffic early multiplies the attacker's cost for every step that follows.
One-Click IP Blocking
Detection alone is not enough; fast response is critical. When the dashboard flagged a persistent IP, the team did not wrestle with long command lines. The block was pushed to the firewall in a single click, cutting response time from minutes to seconds.
The response flow the field team followed can be summarized in three steps:
- Flag: the dashboard highlights an IP that crosses the threshold as high risk.
- Verify: the analyst checks the timeline to confirm the attempt is a genuine threat.
- Block: the approved IP is added to a firewall rule with one click, and its traffic stops at once.
This flow quickly isolated the most aggressive of the 104 IPs, containing the bot before it reached its target. Every block was logged — which IP, when, and why — so a mistaken block can be reversed just as fast. Approved response, rather than fully automatic blocking, kept legitimate guest traffic from being cut by accident.
Keeping Data Inside the Company
For the hotel group, the most sensitive matter was guest and reservation data. Because ERBE SIEM runs on-premises, every log was processed on the company's own server, and the 0 cloud transfer figure over the first 24 hours is the concrete result.
Turkish regulatory context: foreign companies operating in Turkey should note two obligations this architecture helps satisfy. The first is the log-keeping duty under Law No. 5651, whose text is available through the official Legislation Information System. The second is the personal-data protection framework overseen by KVKK, the Turkish data protection authority, with guidance on the KVKK website. Keeping data on-site makes both far easier to demonstrate during an audit.
On-site processing also cuts latency, because logs never travel to an external service and back, so correlation runs in real time. Readers weighing the wider case for a local architecture can read our ERBE SIEM review. There is a reputation dimension too: a guest-data leak damages brand trust beyond any fine, and keeping data in-house reduces that risk at its source.
Conclusion
A hotel group's first 24 hours showed the field value of a well-planned SIEM deployment. Scattered logs merged into one dashboard; 262 attack attempts and 104 IPs became visible. A bot running 16 attempts per second was separated early and blocked with a single click. Most important, sensitive data never left the company's boundary. For similar visibility and response speed in your environment, explore our ERBE SIEM monitoring platform.
Frequently Asked Questions
How long does a SIEM deployment usually take?
It depends on the number of log sources and the size of the network. In this hotel case the core sources went live in about 30 minutes. In small and mid-sized environments the core deployment usually finishes within one business day, while fine-tuning and rule maturing continue gradually over the first weeks. Listing your sources in advance shortens the timeline noticeably.
Can a SIEM really catch a bot running 16 attempts per second?
Yes, because that speed is far above human behavior and forms a clear pattern. ERBE SIEM flags a high number of failed logins from one source in a short window using threshold rules. That density is merged into a single attack event rather than scattered alerts, so the analyst focuses on the threat directly instead of getting lost in records.
How does an on-premises SIEM analyze data without sending it to the cloud?
An on-premises SIEM keeps all processing power on the company's own server. Logs are collected, correlated, and visualized locally. In this hotel case, the 0 cloud transfer figure over the first 24 hours is the direct result of that architecture. On-site processing eases Law No. 5651 compliance and removes the risk of personal data leaving the company.
Tags
- siem deployment
- erbe siem
- attack analysis
