01
Scope and design
We agree services, zones, encryption, traffic volumes and documentation requirements. We select sensor locations, alert handling, retention and criteria for stopping a change if it affects services.
Network threat detection
IDS and IPS deployment
We design traffic monitoring and alert handling for business networks. IDS detects suspicious activity; IPS can block selected traffic. Observation, rule tuning and service-impact tests come before blocking is enabled. Detection coverage and response responsibilities are agreed with your business.
Trusted by
Companies and institutions that need stable IT.
What needs to be visible in your network
We start with important services and places where traffic can be observed: internet connections, public-facing service zones, servers, VPN, branches, cloud and internal traffic. We select scenarios relevant to your business: scanning, vulnerability exploitation, communication with an attacker’s server, access compromise, movement between systems and data theft, including transfers concealed in DNS queries. We include signs of malicious software, including ransomware, and longer-running attack campaigns. IDS/IPS complements firewall and endpoint protection; it does not replace them or provide complete visibility into every connection.
Risk reduction What needs to be visible in your network
Connecting network detection to response
Network events should reach people and systems able to investigate them. Integrations and actions following an alert are agreed separately.
SOC, SIEM and SOAR
Event correlation, alert assessment, escalation and agreed response automation. We define who handles incidents and when.Endpoint protection with EDR
Linking network alerts to events on computers and servers, with agreed device isolation.Firewall deployment
Access rules and network separation. Firewall IPS functions are selected for the device, licences and acceptable traffic impact.Network penetration testing
Separately agreed checks of vulnerabilities and attack paths. Findings help select detection test scenarios.ISO 27001 · TÜV NORD Polska
TÜV NORD Polska has certified Virtline’s information security management system to PN-EN ISO/IEC 27001:2023-08. The published certificate states its scope and validity.
View Virtline’s certificateIDS/IPS implementation process
The key decision is what to observe and what may be stopped. A tool’s blocking capability is not, by itself, a reason to enable it.
02
Installation and integration
We configure sensors, rule sources, traffic copies and log forwarding. We check performance, sensor health, time consistency, redundancy and the path of a test alert to its owner.
03
Observation and tuning
We first establish normal traffic patterns without blocking. Rules based on known attack patterns, unusual behaviour and source reputation are assessed separately. We investigate false alerts and agree thresholds and exceptions. Observation lasts as long as the network’s activity requires, not a fixed period.
04
Blocking and handover
Where included, selected IPS rules are enabled after approval of test results and service impact. We agree rollback arrangements and hand over results and instructions. Ongoing tuning and incident handling require a separate scope.
Practical scope
What you receive
Acceptance covers agreed observation points, rules and the path from alert to ticket. We record blind spots, missed scenarios and risks.
A sensor and traffic map, high-level and detailed architecture, and detection or blocking mode. We document traffic copies through TAP/SPAN, any aggregation, throughput, redundancy and latency. Failure behaviour is agreed: allow traffic without inspection or stop it.
A register of rules, custom detections, update sources, thresholds and exceptions for legitimate activity. Results show detected events, false alerts and the effect of blocking on applications. We measure detection time against the baseline rather than assuming a fixed improvement.
Parsing and normalising logs and linking them to firewall, EDR, Active Directory and server events. We define priorities, owners, escalation and ticket creation. Response instructions identify who approves address blocking, device isolation or evidence collection for incident investigation.
Secure sensor configuration, time synchronisation, configuration backups and sensor health checks. The plan covers retention of metadata and optional packet captures, storage costs, reviews and reports on alerts, rule changes and open risks.
Limitations and sources
Effectiveness depends on sensor placement, rules, encryption and capacity. For production networks, we primarily plan passive monitoring of industrial device traffic and cooperation with plant maintenance teams. In AWS, Azure and GCP, the scope may use flow records and available security signals rather than the same sensor as an office. Documentation and scenario coverage are mapped to company requirements and relevant sources, such as MITRE ATT&CK. References to NIS2, ISO 27001, DORA, PCI DSS, HIPAA or sector supervision require an agreed scope; installation does not establish compliance. Reports may support audits or insurance reviews, but policy terms remain subject to the insurer’s assessment. NIST SP 800-94 is a 2007 guide, not a current product catalogue.
Source
NIST SP 800-94 — IDPS systems
NIST's official guide to intrusion detection and prevention systems.
Open sourceSource
MITRE ATT&CK — Enterprise matrix
The official tactics and techniques knowledge base used to design and assess detection coverage.
Open sourceSource
Regulation (EU) 2022/2554 — DORA
The official text of the DORA Regulation in EUR-Lex.
Open sourceSource
PCI SSC — PCI DSS
The official page for the current payment-card data security standard.
Open sourceSource
e-CFR — 45 CFR 164.308
The official US text of the HIPAA Security Rule administrative safeguards.
Open sourceIDS and IPS questions
Can IPS block a legitimate connection?
+
Yes. False alerts can occur even after tuning. A passive IDS observes a copy of traffic and reports events. An IPS in the traffic path can stop it, so we test rules, exceptions, load, latency and failure behaviour. Blocking and rollback arrangements require your approval; we do not promise interruption-free deployment.
How do you select an IDS/IPS platform?
+
We work with Suricata and Snort 3 and IPS functions in platforms including Cisco, Palo Alto, Fortinet, Check Point and Trellix. Zeek analyses traffic passively and produces logs; it is not an IPS blocking engine. NDR can add behavioural analysis and support targeted threat investigations. Selection considers traffic, rule licences, resources and the operations team; it is not a fixed package per employee count. The solution does not replace backups protected against alteration or recovery procedures.
What can be seen in encrypted traffic?
+
Without access to decrypted content, analysis is limited. We use available TLS connection information, DNS names and flow records, not as a substitute for full communication content. Inspection of decrypted traffic is considered after legal and architectural requirements are agreed. Full packet capture (PCAP) is a separate decision about purpose, retention, compression, capacity and cost; it is not the same as logs or metadata.
Who handles alerts after deployment?
+
It may be your IT team, your SOC, Virtline or a shared model. We agree hours, response times, escalation, rule updates and review of new threats. Reports, for example monthly, cover sensor health, false alerts, detection time and risks. Reviews also check visibility of new devices, zones, VPN, cloud and production networks. Tools such as Sentinel, Splunk, Elastic, Wazuh or Graylog are selected for existing logs and operations, without automatically promising 24/7 on-call support.
Define monitoring and response scope
Tell us your critical services, sites, link capacity and existing firewalls and event analysis tools. Explain who handles alerts and whether you are considering traffic blocking. We will agree a channel for sharing a confidential network plan.
Discuss IDS/IPS deployment