Network security monitoring RFP questions to ask before you hire a partner
A security or infrastructure lead who must choose a partner to deploy Suricata, Zeek and Security Onion needs to separate two kinds of firms: those who can design sensors and those who can only install software. The first group answers questions about where traffic is seen, how sensors are sized and how alerts become work. The second group answers with product names and a delivery date. Ask the questions below in writing, and treat vague answers as a signal about the design work you will receive.
Run the evaluation in three steps. Send the written questions together with a sample network diagram that marks the zones, the uplinks and any segments that cannot reach the internet. Require written answers that name the tap or span points they would use, how they would size each sensor for your peak load, how they would confirm no packet loss at that peak, and which rule sources they would load into Suricata and Security Onion. Then ask for a scoped plan with deliverables and acceptance tests before any fee discussion. DeployOpen does not publish prices, and a quote follows from the written scope, so a comparable quote is only meaningful when every bidder answered the same scope.
Ask each candidate how they would handle a Security Onion upgrade in a segmented or air-gapped zone. Security Onion 3.0.0 supports only Oracle Linux 9, and 2.4 reached end of life on October 1, 2026, so a partner must state which path applies to your installed base. Ask how they would move rule sets and the ISO across the gap, who approves each change and how they would roll back. Confirm the answers against the Security Onion airgap documentation and your own change process before you accept a plan.
Sensor placement and sizing questions
Where should network sensors be placed to see north-south and east-west traffic?
A good partner names each tap or span location by segment, such as the internet edge, the data center core, the server VLANs and the user access layer, and explains which direction of traffic each point sees. North-south sensors at the perimeter show traffic entering and leaving the organization, while east-west visibility needs sensors or taps inside the data center, between server zones and at segment boundaries where lateral movement would cross. The answer should include a list of the tap or span points with the reason for each and the traffic they will not see. A weak answer says "we put sensors at the perimeter" and stops there, with no mention of internal segments or of blind spots.
How do you handle asymmetric routing when you tap or span traffic?
Asymmetric routing happens when the outbound and return packets of one session cross different links, so a sensor on one link sees only half the conversation and session-based detections fail. A strong answer names the links where asymmetry is likely, such as dual-homed internet connections or load-balanced firewalls, and describes how traffic is captured on both paths or aggregated before the sensor. It should also explain how Suricata and Zeek will be configured to handle partial sessions and what alerts will flag incomplete flows. A weak answer assumes traffic is symmetric without checking the routing design.
What is the difference between a tap and a span port for a sensor?
A network tap copies traffic passively in hardware and keeps copying even when the sensor or switch is busy, while a span (mirror) port is configured on a switch and can drop frames when the switch is under load. Taps usually give more reliable capture, but they need a physical insertion point and a budget for hardware per link. The partner should say which option fits each location, who installs and documents the cabling change, and how a change window will be scheduled on production links. A weak answer treats span ports as equivalent to taps without discussing drops or change control.
How does the partner size a sensor from link speed and traffic profile?
Sizing starts with measured throughput, not the nominal link speed: the partner should collect peak and sustained bits per second, packets per second, connection counts and the mix of protocols on each link over a representative period. Those figures feed the sensor's CPU, memory, NIC and storage choices, and the retention target sets how much data must be kept for full packet capture and metadata. The answer should show the calculation, state the assumptions and say which numbers were measured at each site. Security Onion hardware minimums act as a floor, not the design target. A weak answer quotes a single appliance model without traffic data.
Do the Security Onion hardware minimums hold for a busy sensor?
The published minimums are a starting floor: a sensor needs at least 4 cores, 12 GB RAM and 2 NICs, a manager or search node needs at least 4 cores and 16 GB RAM, and a standalone node needs 4 cores, 24 GB RAM, 200 GB storage and 2 NICs, all on x86-64 processors. A busy sensor will usually need more cores, more memory and faster capture NICs than these floors, and the partner should show which measured load justifies each upgrade. The answer should also confirm the storage plan for full packet capture separately from the search cluster. A weak answer says the minimums are enough without checking the traffic on that link.
How much hardware and time will the sensor design cost us?
Cost depends on the number of sites, the link speeds, the taps or span configuration, the sensor hardware, the storage for capture and metadata, and the time spent on site surveys and tuning. Hardware and taps are usually one-time costs, while storage growth, support, rule updates and analyst time recur. A quote from a partner should itemize the sensor count per site, the tap model per link, the storage sizing with its retention assumption and the change window effort. DeployOpen issues quotes from a written, fixed scope rather than a price list, so ask for the assumptions behind every line.
Should we validate sensor coverage before buying hardware for every site?
Yes, a short proof of coverage on a few representative links usually shows whether the planned placement sees the traffic that matters before hardware is bought for every site. The partner can capture traffic for a defined period, compare the protocols and hosts seen against the asset inventory, and identify missing segments or drops. The output should be a written coverage map and a list of unresolved gaps, with the decision on sensor count tied to that evidence. A weak answer skips validation and proposes the same design for every site.
Which rule sets they load and how they cut false positives
Ask which rule sets are loaded for each detection engine before discussing tuning. In Security Onion, the Console Detections interface manages NIDS rules loaded into Suricata, Sigma rules loaded into ElastAlert and YARA rules loaded into Strelka. A good partner names each source, states the license terms that allow your use, and explains who decides whether a source is enabled. Source choice should follow your environment, since a rule set built for general enterprise traffic may not match an industrial or clinical network.
- Named NIDS sources: Ask which Suricata rule feeds are enabled, how often they update, and whether any vendor feed requires a paid subscription.
- Sigma and YARA coverage: Ask which Sigma rules run through ElastAlert and which YARA rules run through Strelka, and which log sources each one needs.
- Local rules: Ask how site-specific rules for internal addresses, known applications and business processes are written and stored.
- Air-gapped rule delivery: Ask how rule sets reach isolated zones, since Security Onion's airgap mode updates from newer ISO media.
- Source ownership: Ask who reviews a new source before it is enabled.
Confirm with the partner which feeds are included in the scope, which are optional, and who pays for any licensed content.
Tuning changes how a rule behaves for your traffic. The Console supports modify, suppress and threshold actions for NIDS rules, and custom filters for Sigma rules. Each method has a different risk. A modification changes the rule logic, a suppression hides alerts for a defined match, and a threshold limits how many hits are needed before an alert is raised. A partner should choose the narrowest method that stops the noise and should record why it was chosen.
- Baseline first: Ask for a baseline period in which rules run without suppressions so the team can see real volume by signature and host.
- Suppress by scope: Suppressions should match a specific source, destination, or sensor, not an entire signature.
- Threshold for scanners and bursts: Thresholds suit noisy but low-risk patterns such as vulnerability scanners or backup jobs.
- Modify with care: Changes to rule logic should be tested against captured traffic before they reach production sensors.
- Sigma filters: Ask how custom filters are checked against the log sources they were written for.
Ask the partner to show a sample tuning record with the signature, the change, the reason and the expected effect on alert volume.
Rule updates and tuning changes affect what the SOC sees, so they need the same discipline as configuration changes. Change control should define who proposes a change, who approves it, how it is tested, and how it is rolled back. It should also set a review date for each suppression, so temporary exceptions do not become permanent blind spots. Suppressions and rule changes should be traceable to a ticket and an owner.
- Documented suppressions with owners: Every suppression should name an owner, a reason and an expiry or review date.
- Test before production: Ask whether changes are tested on a non-production sensor or against saved packet captures first.
- Approval path: Ask who signs off on changes that affect high-severity detections or regulated networks.
- Rollback: Ask how a rule change is reverted and how quickly the partner can do it.
- Periodic review: Ask how often suppressions are reviewed and whether the review covers detection coverage as well as volume.
Request a copy of the change log format and confirm whether the partner's process matches your own change management and audit requirements.
Turning rules off is the fastest way to reduce alert volume and the most common way to lose detection coverage. A partner who answers a noise problem by disabling signatures, without a documented reason, has made the SOC blind to whatever those rules were meant to catch. Ask how many rules are disabled today and why. Disabled rules should be counted, reviewed and tied to a specific justification, not left in place after the original noise has passed.
- Large disabled sets: Ask for the count of disabled rules and the reason for each group, since a large unexplained set is a warning sign.
- No baseline: A partner who tunes without measuring volume before and after cannot show that tuning worked.
- Suppressions with no expiry: Permanent exceptions with no owner become invisible over time.
- Undocumented edits: Changes made directly on sensors without a ticket break traceability.
- No coverage check: Ask how the partner confirms that tuning did not remove detection for attacks the rule was meant to catch.
If a partner cannot show a tuning record, a baseline and a list of owned suppressions, treat that as a gap to resolve before contract signature.
How alerts reach the SOC
This sequence shows how a detection made on a sensor becomes a triaged, owned and documented case in the SOC. Each handoff should leave evidence an analyst can use without re-collecting data from scratch.
Generate alerts on each sensor
Suricata raises alerts from enabled rule sets, and Zeek writes protocol and file logs for the same traffic. Ask the partner which rule sets are enabled on each sensor, how sensor health is monitored, and how a silent sensor (one that stops producing alerts or logs) is detected. The step is complete when each sensor's alert and log output is confirmed against a test event that the partner can show you.
Forward events through receiver nodes
In a distributed Security Onion design, sensor output is handled by manager, receiver and search nodes. Ask whether receiver nodes are deployed for pipeline redundancy and load balancing, and what happens to indexing if the manager is unavailable, since the architecture documentation notes that search nodes stop indexing when they cannot reach Redis. The step is complete when the partner documents the data path from each sensor to the search tier and a failover test has been run.
Route notifications to the right queue
Alerts are filtered by severity, rule source and asset so that only actionable items reach analysts. Ask how the partner routes notifications through Security Onion's external notification options or a SOAR tool, which channels are used, and who approves changes to routing rules. The step is complete when a sample alert from each severity class lands in the intended queue.
Assign triage ownership
Each alert class needs a named owner, a first-response expectation and an escalation path to the incident lead. Ask the partner to produce the RACI or on-call matrix for alerts, and to show how ownership is recorded when an alert moves between tiers. The step is complete when the matrix has been agreed with your SOC and any gaps in staffing coverage are written down.
Create tickets with linked evidence
The ticketing or case system should receive the alert, a link to the Security Onion event, and the relevant Suricata alert record, Zeek log entries and any full packet capture that covers the time window. Ask the partner which fields are populated automatically and which an analyst must complete. The step is complete when a test ticket can be traced back to the original packet data and sensor identifier.
Hand off evidence to analysts
Analysts need the alert context, the protocol transcript from Zeek, the signature that fired and the packet capture window to decide whether an event is benign or malicious. Ask the partner to describe what a typical handoff package contains and how long packet capture is retained in the platform, which you should confirm against the deployed retention settings. The step is complete when an analyst can reproduce the investigation from the package alone during a walkthrough.
Record triage decisions for audit
Every close, escalation, suppression or rule change should be logged with the analyst, the reason and the time. Ask how suppressions and threshold changes made in the Detections interface are reviewed and how those records are kept for assessors. The step is complete when a sample of closed alerts can be traced from ticket to decision to rule version.
How Security Onion upgrades work in segmented and air-gapped zones
Security Onion upgrades depend on the version a zone already runs, the Linux distribution underneath it, and whether the zone can reach the internet. The cards below cover the decisions a partner should explain before touching a production sensor or manager.
Version and end-of-life position
Security Onion 2.4 reached end of life on October 1, 2026, and 2.3 reached end of life on April 6, 2024. Ask the partner which version each zone runs today, and whether any zone is still on an unsupported release. Confirm the target version and the date of the last supported patch before planning the change window, because an end-of-life sensor keeps collecting data without vendor fixes.
Oracle Linux 9 upgrade path to 3
Installations on 2.4 running Oracle Linux 9 can upgrade to 3 after full packet capture moves from Stenographer to Suricata. Other distributions need a fresh install rather than an in-place upgrade. Ask the partner to inventory each node's operating system before committing to a method, and to document how packet capture history and detection tuning carry across the move.
Fresh installs on other distributions
Where a node cannot move to Oracle Linux 9, the practical route is a rebuild with new hardware or a new image, followed by re-enrollment of sensors and restoration of rules and configuration. Ask how the partner plans sensor replacement without losing visibility during cutover, which tap or span feeds stay live, and how overlapping sensors or a parallel run will be used to confirm coverage.
Airgap updates with the soup tool
In airgap mode, the soup update tool applies updates from newer ISO media rather than pulling from the internet. Ask who builds and verifies the ISO, how it crosses the gap under the zone's media transfer rules, and how the partner confirms that the NIDS, YARA and Sigma rule content on the new media matches the release notes before it is applied.
Change windows and rollback
Each zone needs a documented change window, a backup of manager and search node configuration, and a tested rollback path. Ask the partner how they define a go or no-go check after each node updates, how long monitoring is allowed to be degraded, and who can authorize a rollback. Monitoring gaps should be recorded as incidents in their own right for audit purposes.
Non-production testing and zone sign-off
Ask how the partner rehearses each upgrade in a non-production copy built from the same ISO and configuration, including a copy of the manager and at least one sensor. Then ask who signs off for each zone, such as the OT or clinical owner, the SOC lead and the change board, and whether that approval is written into the change record before work starts.
What to get in writing before work starts
Before any sensor is racked, the written scope should name every site, network segment and tap or span point in play, the Security Onion deployment type (Distributed is the design the vendor recommends for production), the sensor count per zone, and the rule sources that will be loaded into Suricata and Sigma. Each deliverable should carry an acceptance test that the two parties can run: for example, confirmation that the manager, search nodes and sensors report in the Console, that Suricata and Zeek logs reach the search tier, and that a agreed set of test traffic produces the expected alerts. Ask the partner to state which items are fixed-scope and which are retainer work, such as tuning reviews after go-live, so that neither side assumes ongoing effort is included.
The documentation handover is where most NSM engagements lose value, so ask for it by name. Request sensor build records (hardware, NIC mapping, OS and Security Onion version, and the configuration used), a rule baseline showing which NIDS, YARA and Sigma sets were active on the acceptance date, a tuning log recording every modify, suppress and threshold change in the Detections interface with its reason, and alert triage records for the first operating period. Confirm who holds the administrative keys and where these records are stored, because your own team must be able to operate the platform after the engagement closes.
Ask the partner to describe how it supports evidence for assessments without claiming outcomes. Evidence packs can show configuration, logs and change history, but only an independent auditor or certification body issues an opinion, so the written scope should say that DeployOpen prepares evidence and does not attest to compliance. If you need Security Onion Pro features such as OIDC single sign-on to the Console, LUKS data-at-rest encryption or FIPS mode, scope them as separate line items with the license term (Security Onion Pro is sold on 1 to 5 year terms), the identity provider to be integrated, and the hardening baseline to be verified. Confirm the exact feature availability with the vendor before quoting.
Answers that should worry you
A partner's answer to an NSM question often reveals more than the answer itself. The six answers below are common warning signs in network monitoring proposals, and each one points to a follow-up question that separates a measured design from a sales promise.
Promising no packet loss
A partner who says sensors will not drop packets at peak, without naming a measured throughput, is making an untested claim. Packet loss depends on link speed, average packet size, rule load and disk write speed under real traffic. Ask for the test method, the peak load used, and the drop counters they will monitor after go-live. Ask how they will show zero loss on your own traffic, not a lab replay.
Sizing sensors without traffic data
Sensor hardware chosen from a generic catalog, before anyone has measured your uplink speeds, peak connection rates or flow volumes, will be wrong in one direction or the other. Published minimums for Security Onion are starting points, not sizing. Ask what traffic baseline they need from you, which tap or span points they will measure, and how they will document the headroom they chose and why.
Tuning by disabling rules
If the answer to false positives is to turn off noisy rules, detection coverage shrinks without anyone recording the decision. Security Onion provides modify, suppress and threshold options for NIDS rules, which allow tuning that keeps the rule active. Ask who approves each suppression, how it is recorded, when suppressions are reviewed, and how the rule source and update cadence are documented for audit.
A fixed upgrade path
A claim that every installation can move to the next major release in place ignores platform-specific rules. Security Onion 3.0.0 supports only Oracle Linux 9, and installations on other distributions need a fresh install. Security Onion 2.4 has reached end of life, so its upgrade timing matters. Ask which operating system the partner will deploy, whether an in-place path exists for it, what the rollback plan is, and how upgrades will run in segmented or air-gapped zones.
Ignoring manager outage behavior
In a distributed deployment, the manager coordinates the search nodes, and Security Onion's architecture documentation notes that search nodes stop indexing when they cannot reach Redis on the manager. A partner who has not discussed this failure mode has not designed for it. Ask how they will monitor manager health, whether receiver nodes will add pipeline redundancy in your design, how sensors buffer data during an outage, and how the team will be alerted when indexing stops.
Vague SOC handoff
Proposals that say alerts will be sent to the SOC without naming the path leave the most important operational question open. Ask which alert channel is used, which fields and severity levels are forwarded, how duplicate alerts are grouped, who triages them at night, and how a missed alert would be detected. Request a written runbook and a test alert that travels the full path into your ticketing or SIEM system before acceptance.
How to score partner responses
This table compares each question area in the RFP across four scoring criteria: specificity, measurement method, evidence produced, and handling of segmented or air-gapped zones. Score each partner on a scale of 0 to 3 for every cell, recording the results against the same written inputs so that answers can be compared fairly.
| Question area | Specificity | Measurement method | Evidence produced | Segmented or air-gapped handling |
|---|---|---|---|---|
| Sensor placement and sizing | Names the tap or span points per zone, link speeds and the sensor hardware class chosen | States how placement was validated, such as traffic baselines per segment and a written sizing basis | Placement diagram, sizing worksheet and sign-off on each sensor location | Explains how sensors in isolated zones receive packages and whether they can reach the manager node |
| Packet loss at peak | Gives the peak throughput assumed and the headroom planned above it | Describes how drop counters and capture statistics are collected and reviewed at busy periods | Sample loss reports, test results under load and a documented response threshold | Shows how loss is measured where no outbound reporting path exists |
| Rule sets and sources | Lists which NIDS, Sigma and YARA rule sources are loaded and who selects them | Explains how rule versions are tracked and how changes are tested before production | Rule inventory, change log and a record of approved sources | Describes how rule updates are carried across the gap from newer media |
| False positive reduction | Describes tuning steps for suppressions, thresholds and custom filters | Defines how false positive rate is measured per rule and reviewed over time | Tuning records with reasons for each change and review sign-off | Confirms that tuning can be done locally without external services |
| Alert routing to the SOC | Names the paths alerts take to ticketing, case tools or a SIEM and the fields passed | States how delivery failures are detected and how alert volume is tracked | Routing diagram, test alert results and delivery monitoring logs | Explains how alerts leave an isolated zone and what is held locally if the path fails |
| Security Onion upgrades | Identifies the current release line, the supported operating system and any end-of-life dates involved | Describes the upgrade test process and rollback approach before production change | Upgrade plan, test records and a change record for each applied release | Explains how upgrades are applied from newer ISO media in airgap mode and how the sequence is controlled across zones |
| Packet capture and data handling | States retention periods, storage sizing basis and who can access captured traffic | Describes how storage use is measured and how capacity alerts are set | Retention settings, access records and capacity reports | Shows where capture data is stored and how it is protected inside each zone |
| Staffing and handover | Names the roles that operate, tune and respond, with expected skills | Describes how the partner measures tuning backlog and response quality | Runbooks, training records and a handover plan for the client team | Confirms which tasks require on-site or cleared personnel in restricted zones |
How DeployOpen scopes and delivers NSM evaluations
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including security testing and private cyber ranges. For network security monitoring, the work starts with a written scope that answers the questions in this RFP before any sensor is installed.
How we scope
- Written scope covers tap and span points, sensor count, link speeds and sizing assumptions for each zone.
- Protocol visibility, encrypted traffic handling and packet capture retention are agreed as named deliverables.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Distributed Security Onion deployments are built to the scoped manager, sensor and search node layout.
- Suricata and Zeek rule sources, suppression and threshold tuning are configured and documented against the agreed baseline.
- Load and packet loss are tested at expected peak traffic before the sensors are accepted into service.
How we hand over
- Handover includes architecture diagrams, sensor placement records, rule source inventory and tuning decisions.
- Alert routing to the SOC, escalation paths and runbooks for Security Onion upgrades are documented and walked through with your team.
- Evidence for monitoring controls is prepared for your auditors, who make the assessment and issue any reports.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrade planning covers whether a fresh install or in-place move applies, and how airgap media is handled.
- Your team confirms support terms, response expectations and ownership of rule changes in the written scope.
