What is a HIDS?
A host-based intrusion detection system (HIDS) is software installed on an individual server or workstation that looks for evidence of attack on that one machine. It is a detective control. When activity matches its rules, it raises an alert for an analyst or forwards it to a SIEM, but it does not stop the activity. Well-known open-source examples are OSSEC and its fork Wazuh, and many commercial endpoint suites include the same functions.
What a HIDS monitors
- Log analysis: it reads the host's own logs, such as the Windows Security log or Linux authentication logs, and matches patterns like repeated failed logons, a new local administrator or a cleared audit log (Windows event 1102).
- File integrity monitoring: it hashes critical files and alerts when one changes. For many organizations this is the main reason to run a HIDS.
- Persistence points: new services, registry Run keys, scheduled tasks and cron entries that malware uses to survive a reboot.
- Rootkit checks: hidden processes, unexpected kernel modules or files that normal system tools cannot see.
- Configuration checks: some products also flag settings that have drifted from the expected values.
Because it runs on the endpoint, a HIDS sees activity that never crosses the network, and it is not blinded by encryption the way a network sensor is.
Example: a HIDS alert
At 2:40 a.m. the agent on a Linux database server reports level=12 host=db01 rule=user-added-to-privileged-group detail=usermod -aG wheel backup2 (uid 0, pts/3). No maintenance was scheduled, and backup2 is a service account that should never hold sudo rights. The alert itself undoes nothing. The analyst traces how the session on pts/3 reached root using the same host's authentication log, removes the account from the group, and decides whether to isolate the server while the investigation continues.
Strengths and limits of host-based detection
- It ties events to a specific user, process and file, which network tools cannot do.
- It needs an agent on every host, and each agent must be deployed, updated and tuned. Noisy rules lead to alert fatigue.
- It sees only its own host, so spotting an attack that moves across many systems requires correlating alerts in a SIEM.
- An attacker with administrator rights may stop or blind the agent, so the central console should alert when an agent goes silent.
HIDS vs. HIPS, NIDS and EDR
| Tool | Watches | Response |
|---|---|---|
| HIDS | One host | Alerts only |
| HIPS | One host | Alerts and blocks |
| NIDS | A network segment, from a copy of the traffic | Alerts only |
| EDR | One host, with full activity recording | Alerts, plus remote isolation and investigation |
Because a HIDS never blocks, a false positive cannot break an application, which is why it suits servers where uptime matters most. EDR has absorbed most HIDS functions on workstations, but standalone HIDS remains common on servers and in compliance programs that require change detection.
HIDS on the CompTIA Security+ exam
SY0-801 objective 4.1 lists host-based intrusion detection and prevention among the endpoint security controls used as mitigations, and HIDS is on the exam's acronym list. Wording such as alert on the server itself, notify the SOC when system files change or detect without interrupting the application points to a HIDS. The usual distractors are a HIPS, which blocks and so could disrupt the service; a NIDS, which watches network traffic rather than the host; antivirus, which matches known malware; and a SIEM, which collects and correlates alerts from many sources but is not the sensor on the host.