Security Onion for PCI DSS intrusion detection

PCI DSS requirement 11.5.1 asks for intrusion detection that monitors all traffic at the CDE perimeter and at critical points inside the CDE, so sensor placement is the central design decision in this deployment. Placement should follow your documented data flow diagram and scope, with each sensor position justified by the traffic it can see. Start by listing every boundary cardholder data crosses: internet ingress, connections to payment processors and other third parties, administrative paths into the CDE, and the segment boundaries between the CDE and the rest of the network. Then identify the internal critical points, such as database segments, authentication services and jump hosts. Assign each location a named owner and a written reason it is monitored, so an assessor can trace every Suricata sensor back to a defined part of scope.

Security Onion's architecture documentation recommends the Distributed deployment type for production. It separates a manager node, one or more sensor nodes and one or more search nodes. Sensors run Suricata inspection at the points you chose, the manager coordinates them, and search nodes hold the indexed output that analysts and the daily log review rely on. Derive the sensor count from the monitored segments in your diagram. The architecture notes also say that if the manager goes down, search nodes stop indexing because they cannot reach Redis. The design therefore has to answer what happens during a manager outage: how quickly you can rebuild or restore the manager, whether its configuration is backed up and tested, how the sensors behave in the meantime, and how you will show an assessor that no monitoring gap went unnoticed. Receiver nodes, which the same documentation describes for pipeline redundancy and load balancing, are a further option to evaluate against your alert volume.

The minimum hardware for a sensor is 4 cores, 12 GB RAM and 2 NICs, and Security Onion supports only x86-64 processors. Treat these figures as a floor. Sensor sizing depends on the traffic each mirror carries at peak, the rule set you enable and how much packet capture you retain, so run capacity testing with representative traffic before any sensor is accepted into production. For the operating system, Oracle Linux 9 is the only supported OS for version 3.0.0 and later. If your build standard uses another distribution, that conflict must be resolved before the design is finalized. Two NICs usually mean one interface receives mirrored traffic and another carries management, but confirm the interface roles and any monitoring-only requirements in the vendor documentation for your version.

Traffic mirroring and tap points are yours to confirm against your network, and the answers decide whether the sensor design works at all. Check whether your switches can mirror every relevant VLAN or port without dropping frames under load, whether network TAPs are available at the perimeter and inside the CDE, and whether encrypted or virtualized paths can be observed at all. In cloud environments, confirm which traffic mirroring features your provider offers for the subnets in scope. Record each mirror source, sensor interface and owner in a placement register that maps back to your data flow diagram. That register becomes evidence for requirement 11.5.1 and the starting point for the daily alert review under requirement 10.4.1.

PCI DSS Requirement 11.5.1 expects your intrusion-detection technique to stay current in three ways: its engines, its baselines and its signatures. In Security Onion, the signature side is managed through the Detections interface in the Security Onion Console, which controls the NIDS rules loaded into the Suricata sensors. Treat rule currency as a recurring operating duty rather than a one-time installation task. Be ready to show an assessor when each rule source was last refreshed, who changed what, and which sensors received the change. Before go-live, confirm in your version how rule sources are updated and whether that update runs automatically or only when an operator starts it.

Your update path depends on whether the deployment can reach the internet. Where it can, confirm which rule sources the manager pulls from, whether those sources are permitted by your network and change policies, and how a failed update is reported. Where the network has no internet access, the Security Onion ISO carries packages and the NIDS, YARA and Sigma rules for a full install. Currency then depends on how often you obtain newer ISO media through your approved transfer and scanning process. Use the soup update tool in airgap mode to apply that media. The rules you deploy can be no newer than the media you imported, so plan the media transfer as a recurring task with a named owner.

Define the operating model before the first rule change. Name who approves NIDS rule changes for production, usually a security engineering lead with sign-off from the change authority that governs the cardholder data environment. Set refresh frequency from your own change policy and risk appetite, and record it in the runbook, not in a vendor default. Require each change to be tested first on a non-production sensor or lab deployment, using representative traffic where you can capture it. Check alert volume, confirm that expected detections still fire, and document a rollback step. Promote the change only with a change record that links the test results to the approval.

Suppressions and threshold changes need the same discipline, because they can hide relevant alerts. Each suppression should have an owner, a written justification, a defined scope such as sensor, host or address, and an expiry or review date. On each review, confirm that the suppressed signature still matters for the traffic it covers and that threshold settings have not quietly reduced visibility at the CDE perimeter or critical points. Suppressed alerts should still reach the daily log review that Requirement 10.4.1 expects for security components such as IDS/IPS. Ask Security Onion how suppression and tuning changes are logged in your version, and confirm that those logs are retained with your other evidence.

PCI SSC FAQ 1074 states that centralized log correlation does not replace intrusion detection, and that IDS/IPS logs should be part of the daily log reviews. For a Security Onion deployment, this means the Suricata alerts from sensors covering the CDE perimeter and critical points under requirement 11.5.1 must reach a named reviewer's daily work, not sit only in the Console for someone to find later. Before the first review runs, decide which sensors and alert categories are in scope for the daily review, which are reviewed on a different cadence, and who owns that decision. Document the mapping between sensor interfaces, network segments and CDE assets so the reviewer can tell at a glance whether an alert touches cardholder data.

A reviewer's daily pass usually starts in the Console's alerts view, filtered to the sensors and segments in scope. For each alert, the reviewer checks the source and destination against the CDE asset inventory, pivots to related Zeek records or Suricata full packet capture for context, and assigns a disposition: benign, expected, tuned, or escalate. Rule changes belong in the Detections interface, where NIDS rules can be modified, suppressed or given thresholds. Treat every suppression or threshold change as a controlled event with a stated reason and an approver, because a suppression that quietly hides a real attack is the failure an assessor is most likely to find. Keep the review checklist short enough to finish within the day, and record anything that could not be completed.

Requirement 10.4.1.1 asks for automated log review mechanisms, which supplement rather than replace the human review. Security Onion's own alerting can flag high-severity or CDE-relevant detections for prompt attention. With Security Onion Pro, external notifications can route those alerts to a messaging or ticketing destination. Confirm with your QSA whether a given notification design satisfies your reading of 10.4.1.1, and confirm the Pro feature set and terms with the vendor before you design around them. One operational risk needs a plan: the architecture documentation notes that if the manager goes down, search nodes stop indexing because they cannot reach Redis. A silent manager outage would stop new alerts from appearing, so add a health check that proves alerts are still arriving each day.

Every review should leave a record: the date, the reviewer, the sensors and alert categories covered, dispositions, tuning changes with approvals, and links to any escalation tickets. Escalations should follow a defined path into your incident response process, with a named backup reviewer for absences. The procedure, roles and sign-off are the organization's to define, and the QSA will not write them for you. The assessor will also test whether the reviews actually happen, typically by sampling dates and checking for gaps, reviewing the tuning audit trail, and following a sample alert through to its disposition. Confirm with your assessor which evidence format and retention they expect before the first assessment period begins.