ISMS

Intrusion Detection and Prevention (IDS/IPS) for Mid-Market Companies

TL;DR
  • An IDS (Intrusion Detection System) detects attacks and raises alerts. An IPS (Intrusion Prevention System) detects attacks and actively blocks them. Most modern systems combine both functions.
  • Signature-based detection identifies known attack patterns. Behaviour-based detection (anomaly detection) identifies deviations from normal behaviour and can also detect unknown attacks.
  • For SMEs, the IPS function of the next-generation firewall is often the most pragmatic starting point. It requires no additional hardware and is included in most NGFW licences.
  • Dedicated IDS/IPS systems like Suricata or Snort offer more flexibility and deeper analysis capabilities but require more expertise to operate.
  • An IDS/IPS without tuning produces masses of false positives and is quickly ignored. Regular tuning and adaptation to your own environment are mandatory.

What IDS and IPS deliver

Firewalls control which traffic is allowed to pass. IDS and IPS go one step further: they analyse the permitted traffic for malicious content. A firewall allows HTTPS traffic on port 443. The IDS/IPS checks whether this HTTPS traffic contains an SQL injection, matches a known exploit pattern, or exhibits suspicious behavioural patterns.

The difference between IDS and IPS lies in the response:

IDS (Intrusion Detection System): Detects suspicious traffic and generates an alert. Traffic is not interrupted. The IDS is a passive monitoring system, comparable to an alarm that reports a break-in but does not lock the door.

IPS (Intrusion Prevention System): Detects suspicious traffic and blocks it in real time. The IPS sits inline in the data path and can drop individual packets or entire connections. It is the alarm that simultaneously locks the door.

In practice, the boundary is blurred: most modern systems offer both modes and can be configured per rule whether to alert only or actively block.

Detection methods

Signature-based detection

The foundation of every IDS/IPS. Signatures are patterns that describe known attacks: a specific byte sequence in an HTTP request (SQL injection), a known exploit payload (CVE-2024-xxxx), a suspicious user-agent string (Metasploit, Cobalt Strike).

Advantages:

  • Reliable detection of known attacks with low error rate
  • Low computational power per signature
  • Every alert is mapped to a concrete attack pattern and thus easy to evaluate

Disadvantages:

  • Only detects known attacks (no zero-days)
  • Requires regular signature updates (daily to hourly)
  • Polymorphic or obfuscated malicious code can evade signatures

The quality of a signature-based IDS/IPS stands or falls with the quality and currency of its signatures. Established rule sets:

  • ET (Emerging Threats) Open: Free rules, good coverage, community-maintained
  • ET Pro: Paid extension with faster updates and additional rules
  • Snort Community Rules: Free base rules for Snort
  • Snort Subscriber Rules: Paid rules with faster updates (Cisco Talos)

Behaviour-based detection (anomaly detection)

Instead of looking for known attack patterns, a behaviour-based system learns the "normal" behaviour on the network and alerts on deviations. Examples:

  • A server that normally only responds to HTTPS requests suddenly sends large data volumes over DNS (possible exfiltration)
  • A client PC establishes connections to hundreds of different IP addresses (possible malware activity or port scanning, a typical scenario of a compromised account)
  • A user accesses systems outside business hours that they do not normally use (possible compromised account)

Advantages:

  • Can detect unknown attacks (zero-days)
  • Detects insider threats and compromised accounts
  • No signature updates required

Disadvantages:

  • High rate of false positives, especially after network changes
  • Requires a learning phase in which the system captures normal behaviour
  • More computationally intensive than signature-based detection
  • Harder to configure and tune

Hybrid detection

Most modern IDS/IPS systems combine both methods: signature-based detection for known attacks and behaviour-based detection for anomalies. This combination provides the best protection but also requires the highest configuration effort.

Deployment options for SMEs

Option 1: IPS in the next-generation firewall

The simplest option for SMEs. Most NGFWs (Fortinet, Sophos, Palo Alto, WatchGuard) have an integrated IPS that can be activated with a single click.

Advantages:

  • No additional hardware required
  • Central management via the firewall interface
  • Automatic signature updates from the vendor
  • IPS rules can be combined directly with firewall rules

Disadvantages:

  • Performance impact on the firewall (especially with SSL inspection + IPS)
  • Less flexibility than a dedicated system
  • Dependence on the firewall vendor for signatures and updates
  • Limited analysis and reporting capabilities

Recommendation: For SMEs with up to 200 employees, the NGFW-integrated IPS is an excellent starting point. Ensure the firewall is sized for the additional IPS load (IPS + SSL inspection can reduce throughput by 40 to 60%).

Option 2: Dedicated IDS/IPS with Suricata or Snort

Suricata and Snort are the two leading open-source IDS/IPS engines.

Snort was developed in 1998 by Martin Roesch and is the pioneer of network-based intrusion detection. Since its acquisition by Cisco (2013), Snort has been further developed as the foundation for Cisco Firepower IPS. Snort 3 is the current version with improved performance and a new plugin architecture.

Suricata was developed in 2009 by the Open Information Security Foundation (OISF) as an alternative to Snort. Suricata supports multi-threading (better performance on modern servers), has native protocol decoding for more than 40 protocols and integrates seamlessly with the Elastic Stack (ELK) for analysis and visualisation.

Typical deployment:

  1. Install Suricata/Snort on a dedicated server or virtual machine
  2. Route network traffic to the IDS via a mirror port (SPAN) on the switch or via a network TAP
  3. Load and activate rule set (ET Open/Pro)
  4. Forward alerts to central log management or SIEM (e.g. Elastic Stack, Graylog, Wazuh)
  5. Perform regular tuning: suppress false positives, add missing rules

When is a dedicated system worthwhile? When you need deeper analysis, when NGFW performance is insufficient, when you want to monitor specific network segments separately, or when regulatory requirements mandate a dedicated IDS.

Option 3: Host-based IDS (HIDS)

Alongside network-based systems, there are host-based IDS that run on the endpoints (servers, clients) and detect suspicious activity there: file changes, registry manipulations, suspicious processes, login anomalies.

OSSEC/Wazuh: Open-source HIDS with file integrity checking, log analysis, rootkit detection and active response. Wazuh is the active fork of OSSEC and offers a modern web interface, Elastic integration and cloud compatibility.

Recommendation: A HIDS meaningfully complements a network-based IDS/IPS. The combination of NIDS (Suricata) and HIDS (Wazuh) provides good detection depth for SMEs.

Option 4: Managed IDS/IPS (MDR)

If you lack the resources to operate and tune an IDS/IPS yourself, you can engage a Managed Detection and Response (MDR) provider. The MDR provider installs sensors in your network, monitors alerts around the clock and escalates relevant incidents to you.

Advantages: Professional monitoring without your own SOC team, fast response, 24/7 coverage. Disadvantages: Ongoing costs, dependence on the provider, sensitive network data (partially) leaves the company.

Signature tuning: from alert tsunami to relevant notification

A freshly installed IDS with default rules produces hundreds to thousands of alerts per day. Most of them are false positives: legitimate traffic that happens to resemble an attack pattern, or rules that are not relevant for your specific environment.

If you do not tune, the following happens: the responsible team is flooded with alerts, begins to ignore them, and when a real attack occurs, it is lost in the noise. This is worse than having no IDS at all because it creates a false sense of security.

Tuning process

Phase 1: Establish baseline (weeks 1 to 2). Operate the IDS in pure detection mode (no blocking). Collect all alerts and analyse the most frequent ones.

Phase 2: Identify false positives (weeks 2 to 4). Review the most frequent alerts and check whether they are actual threats or false positives. Common false positives:

  • DNS queries to legitimate services that look like C2 communication
  • HTTP requests with special characters (that look like SQL injection but are legitimate parameters)
  • Internal scans from vulnerability scanners or monitoring tools
  • Protocol anomalies from older devices or proprietary protocols

Phase 3: Adjust rules (ongoing). For confirmed false positives:

  • Suppress rules: suppress the alert for specific source or destination IPs
  • Threshold rules: alert only when a pattern occurs n times within x seconds
  • Deactivation: disable rules that are not relevant for your environment (e.g. SCADA rules if you have no OT systems)

Phase 4: Activate prevention (from weeks 4 to 6). Once the false positive rate has dropped to a manageable level, switch critical rules from detection to prevention mode. Start with the safest rules (known exploits, C2 communication to known malware domains) and expand gradually.

Phase 5: Continuous tuning (permanent). Tuning is never finished. New services, new applications, new network segments generate new alerts that must be reviewed and evaluated. Plan one hour per week for evaluating IDS alerts.

IDS/IPS and encrypted traffic

A network-based IDS/IPS can only analyse unencrypted traffic. In a world where over 90% of web traffic is encrypted (HTTPS), an IDS without SSL inspection has a massive blind spot.

Solution approaches

SSL inspection on the firewall. The NGFW decrypts HTTPS traffic, inspects it (including IPS checks) and re-encrypts it before forwarding to the client. This requires installing an internal CA certificate on all clients.

SSL inspection before the IDS. An SSL proxy (e.g. PolarProxy) decrypts the traffic and forwards it to the IDS. The IDS analyses the plain-text traffic.

Metadata analysis. Even without decryption, IDS/IPS systems can analyse the metadata of encrypted connections: JA3 fingerprints (TLS client fingerprinting), Server Name Indication (SNI), certificate details, connection patterns. Suricata has extensive TLS analysis capabilities.

Endpoint detection. As a complement to the network-based IDS: EDR solutions on the endpoints analyse traffic after decryption and detect malicious content at the operating system level.

ISO 27001 and NIS2: requirements for IDS/IPS

ISO 27001 requires the detection and handling of security incidents in several controls:

  • A.8.16 (Monitoring activities): Networks, systems and applications must be monitored for anomalous behaviour -- a core building block of the logging and monitoring strategy. An IDS/IPS is a direct implementation of this requirement.
  • A.8.20 (Network security): Networks and network services must be secured.
  • A.5.25 (Assessment and decision on information security events): Security events must be evaluated to determine whether they should be classified as security incidents.

NIS2 requires in Article 21 "measures for the handling of security incidents" and "security in the acquisition, development and maintenance of network and information systems, including vulnerability management". An IDS/IPS is an appropriate technical measure for meeting these requirements.

Practical example: IDS/IPS for an SME with 120 employees

Starting situation: Mid-market company, 120 employees, a FortiGate 100F as the firewall, two locations with site-to-site VPN, 30 employees working from home.

Solution:

  1. Activate IPS on the FortiGate: FortiGate IPS with FortiGuard signatures, "Default" profile as the starting basis, SSL inspection for outbound web traffic.

  2. Suricata on a dedicated server: For deeper analysis and an additional detection layer. Network traffic via SPAN port from the core switch. ET Open as the rule set, supplemented with custom suppress rules.

  3. Wazuh as HIDS: On the servers (domain controller, file server, ERP server). File integrity checking, log analysis, rootkit detection.

  4. Elastic Stack for central analysis: Suricata alerts, Wazuh alerts and FortiGate logs flow into Elasticsearch. Kibana dashboards for overview and drill-down.

  5. Weekly alert review: An IT employee reviews the top alerts weekly, evaluates false positives and adjusts the rules. In ISMS Lite, you document the IDS/IPS as a technical control and track alert reviews as a recurring task in the action plan.

Costs: Hardware for the Suricata server (approx. EUR 1,500 to 2,000), FortiGate IPS licence (included in the UTM licence, approx. EUR 800/year), Suricata/Wazuh/Elastic are open source (free). Personnel effort: approx. 2 to 4 hours per week for monitoring and tuning.

Results after three months: The false positive rate has dropped from several hundred alerts per day to fewer than ten relevant notifications per week. The IPS on the FortiGate blocked three actual attack attempts in the first 90 days: an exploit attempt against a known Exchange Server vulnerability, a port scan from an Eastern European IP range, and a command-and-control communication attempt by a malware infection on a client.

Further reading

An IDS/IPS is not a silver bullet. It does not detect every attack, it produces false positives, and it requires continuous maintenance. But as part of a layered security architecture -- together with the firewall, segmentation, endpoint protection and logging -- it closes a critical gap: the detection of attacks that have bypassed all other defences.

Document IDS/IPS as an ISMS control

ISMS Lite supports you in documenting IDS/IPS controls, managing alerts and integrating them into your risk management.

Install now