How to use this network security monitoring requirements checklist
This checklist tells a security lead what a network security monitoring rollout must decide before it is bought or built, and who must sign off on each line. The security owner signs off on detection scope and rule ownership, the network team signs off on tap and span points and sensor placement, the storage or infrastructure owner signs off on packet capture retention, and the compliance lead signs off on whether the evidence matches the framework being assessed. Each requirement is written so that it has a verification step, such as a packet count at the sensor, a retention test on the storage volume or a documented rule owner, so that the answer can be checked rather than assumed.
Most gaps in a rollout appear in three places: sensor placement, packet capture retention and rule ownership. A sensor on a port that does not see east-west traffic produces a clean dashboard that misses lateral movement, and packet capture that is kept for a few days may not cover the window an investigation or an assessor needs. Rule ownership matters because Suricata and Zeek produce output only as useful as the rule sets and tuning behind them, so the checklist asks who approves a suppression and who reviews the rule source on a schedule. Confirm each of these with the network and storage teams in your own environment before the design is fixed.
The checklist is vendor-neutral, so the requirements apply whether the sensors run Suricata and Zeek directly or through a packaged platform. Security Onion is used as the reference packaging for examples because it bundles Suricata, Zeek and the console in one distribution, and its Security Onion architecture documentation describes the deployment roles a production design needs. Where a requirement depends on a feature of a specific product, the checklist says so and asks you to confirm it against that product's current documentation.
Functional requirements: what the sensors must see and store
This table lists what a Security Onion, Suricata and Zeek rollout must capture, parse and keep, with the check that proves each requirement is met. Read each row as a question to answer during design and again during acceptance testing. The main takeaway is that a sensor that looks healthy on a dashboard can still miss traffic at peak, so verify placement and loss under real load before trusting the alerts.
| Requirement | What it asks for | How to verify it |
|---|---|---|
| Tap and span points | Each monitored link needs a passive tap or a switch span (mirror) port that copies traffic to the sensor NIC, placed at the boundaries you need to see, such as internet edge, IT-to-OT or segment crossings | Map every capture point to a traffic path, then confirm with a test flow that the sensor sees traffic in both directions and that the span does not drop frames under load |
| Link speeds and NIC count | Confirm the highest sustained speed on each monitored link and the number of NICs, since a standalone node needs 2 NICs and a sensor needs 2 NICs in the minimum specification | Record link speeds from switch and firewall configs, then run a peak-hour test and compare sensor drop counters against the expected packet rate |
| Sensor hardware platform | Security Onion supports only x86-64 processors. Minimum sensor specification is 4 cores, 12 GB RAM and 2 NICs, and standalone nodes need 4 cores, 24 GB RAM and 200 GB storage | Check the processor architecture before purchase or image build, then size CPU, memory and storage against the vendor hardware page and your measured traffic, not the minimum alone |
| Protocols Zeek must parse | Zeek needs to see the application protocols you rely on for investigations, such as DNS, HTTP, TLS, SMB, Kerberos and any industrial or clinical protocols in scope, to produce logs | Run a protocol coverage review: list the protocols seen on each sensor over a sample period and confirm each in-scope protocol has a matching Zeek log stream |
| Protocols Suricata must inspect | Suricata needs to see the flows and protocols that your enabled NIDS rule sources target, with rule sets matched to the traffic that actually crosses each sensor | Replay or generate known test traffic for selected rules and confirm alerts appear in the Security Onion Console, then record which rule families have no matching traffic |
| Full packet capture retention | Decide which sensors keep full packet capture, for how long and at what storage location, based on your investigation and legal needs. Confirm the retention period in writing with your policy owner before sizing storage | Check disk growth against the planned retention window, then restore a sample capture to confirm it can be read and searched for a past incident |
| Metadata and log retention | Keep Zeek and Suricata metadata, such as connection, DNS and alert records, for the period your policy and any regulator require, separate from full packet capture | Query a date older than the retention target and confirm the record exists, then confirm deletion jobs run as configured |
| Encrypted traffic visibility | Plan for TLS and other encrypted sessions, where Zeek and Suricata see metadata and certificates but not payload unless decryption is in place. Confirm any decryption design with legal and privacy owners | Review the share of encrypted sessions per sensor and test that expected certificate and handshake logs are present for sample connections |
| Rule sources, tuning and updates | Name each NIDS, Sigma and YARA rule source, who approves changes, and how suppressions and thresholds are documented. Confirm update channels work in your network | Review the detection change log for the last period, confirm each suppression has an owner and reason, and test that a rule update reaches every sensor |
| Offline or air-gapped operation | If sensors must run without internet access, confirm the ISO carries packages and NIDS, YARA and Sigma rules, and that updates arrive as newer ISO media in airgap mode | Disconnect a test sensor from the internet, run a full update from media, then confirm rules and packages reported as current |
Where sensors belong and how to confirm the tap or span works
Place sensors where the traffic you need to see actually crosses, and prove that it does before you trust any alert. The main decision is whether each sensor sits on a network tap or a switch span port between zones, such as the boundary between a corporate network and a server segment. A tap copies traffic passively and keeps copying even when the device it sits beside fails, while a span depends on the switch's mirroring engine and its configured source ports and VLANs. Confirm with your switch and tap vendors which ports can mirror, whether they can mirror a full duplex trunk without dropping frames, and how the mirror behaves under load. Those answers come from their documentation and your own hardware, not from general rules of thumb.
Placement also determines which direction of traffic you can see. A sensor at the perimeter mainly observes north-south traffic, between internal hosts and the outside world. Lateral movement between servers, which is often what an intruder does after a foothold, is east-west traffic that never reaches the perimeter. A sensor behind a NAT device sees the translated address rather than the original client, and a sensor behind a load balancer may see only the balancer's address, so the source of an attack can be hidden. Where that matters, place sensors on the inside of the translation point or on the segments the balancer serves, and document which addresses each sensor can and cannot attribute. Ask your architects to map each sensor's view to the zones in your asset inventory.
Verify every placement with a known test flow before you rely on it. Generate traffic you control from one host to another across the tapped path, such as a benign HTTP request or a DNS lookup to a test domain, and confirm that Zeek logs the connection and Suricata raises the expected test alert in the Security Onion console. Repeat the test in both directions, because a flow seen only outbound often points to asymmetric routing, where replies take a different path that the sensor never sees. Asymmetry produces half-open sessions, missing protocol state and silent gaps in detections, so check it on every sensor and record the results as placement evidence. Repeat the test after any change to routing, VLANs or firewall rules, because those changes quietly move traffic away from a sensor.
Security requirements for the monitoring platform itself
A network security monitoring platform collects some of the most sensitive data in the environment, including full packet captures and every alert an analyst touches. The controls below apply to the monitoring stack itself, so a review of the sensors does not become a new exposure. Each card names a decision to make before the rollout and a check to run against your own policy.
Unique user identity for the Console
Every analyst who opens the Security Onion Console or pivots into stored traffic should sign in with an individual account, not a shared login. Shared accounts break the link between a query, a tuning change and a person, which reviewers ask about first. Decide where identities come from, whether a directory or a federated provider, and who approves access and removes it when someone leaves. Security Onion Pro lists OIDC single sign-on for the Console, so confirm whether your policy requires it or whether local accounts with strong authentication are acceptable.
Audit logging of analyst actions
Record who changed a NIDS rule, suppressed an alert, added a threshold or ran a search over packet data, and when. The Detections interface supports modify, suppress and threshold tuning, so these changes need an owner and a reason attached. Confirm that the audit trail lives outside the platform's own storage, so an analyst with administrative rights cannot quietly edit it. Also decide how long these records are kept, since the retention period is set by your own policy and the framework you are assessed against.
Protection of packet capture data
Full packet capture can contain session tokens, passwords sent over unencrypted protocols, and personal data in application payloads. Treat the capture store as a sensitive data set with its own access list, separate from general alert access. Decide who may retrieve raw packets, how exports are approved and logged, and how the store is purged when the retention window closes. Ask the platform owner which roles can see full content versus metadata only, and document that split before the sensors go live.
Encryption at rest and in transit
Sensor-to-manager traffic, console sessions and stored captures should all be encrypted, and the storage holding packet data should be encrypted at rest. Security Onion Pro lists LUKS data-at-rest encryption and FIPS mode, which may matter if your policy names specific cryptographic modules. Confirm with your security team whether FIPS validation is required or whether standard encryption meets the requirement. Map each data flow in the design to a named control, because a reviewer will ask where keys are held and who can rotate them.
Management network separation
Sensor management interfaces, the manager and the console should sit on a dedicated management network, separate from the monitored traffic and from general user networks. Sensors use a capture interface that receives mirrored traffic and should not carry an IP path back into the segments they watch. Confirm which systems may reach the management network, how jump access is controlled, and how the design handles a sensor placed inside a segmented zone. Document the firewall rules as evidence, since they are often the first item a reviewer asks to see.
Compliance questions a reviewer will ask
Frameworks such as the HIPAA Security Rule at 45 CFR 164.312 ask about unique user identification, audit controls, authentication and transmission security. The FTC Safeguards Rule at 16 CFR 314.4 asks about multi-factor authentication, encryption and logging of authorized user activity. These are examples of what a reviewer will examine, not a checklist DeployOpen certifies. Independent auditors and regulators judge compliance, and DeployOpen prepares the systems and evidence for that review. Ask your auditor which controls they will test on the monitoring platform.
Encrypted traffic and rule sources: what changes the design
Most enterprise traffic is encrypted in transit, so a passive sensor usually sees handshake metadata rather than application payloads. Suricata and Zeek can still record TLS details such as server names, certificate fields, versions and cipher choices, which supports detection of unusual destinations, expired or self-signed certificates and outdated protocol use. Inspecting the payload requires decrypting it, which means holding keys or terminating sessions at a point the design must justify and protect.
- Metadata first: Plan for TLS metadata and connection logs as the default visibility level, and confirm which TLS fields your Zeek and Suricata versions log.
- Decryption scope: Decide per traffic class whether decryption is needed, such as inbound traffic to a specific application, rather than enabling it network-wide.
- Risk of decryption: Decrypted payloads may contain credentials, personal data or ePHI, so the sensor becomes a high-value target with its own access controls.
- Key handling: If keys are copied to a sensor, confirm who can read them, how they rotate and where they are logged.
- Alternatives: Compare endpoint telemetry or application logs for the same risk before accepting decryption.
Before approving any decryption, ask the implementation partner to document the scope, the data stored, the key custodian and the retention period in writing.
Detection quality depends on where rules come from and how often they change. In Security Onion, NIDS rules load into Suricata, Sigma rules load into ElastAlert and YARA rules load into Strelka, all managed from the Detections interface. The supplied documentation describes modify, suppress and threshold tuning for NIDS rules and custom filters for Sigma. Air-gapped sites must bring rule updates across the gap through ISO media, which changes the cadence.
- Rule sources: Confirm which feeds the deployment uses for NIDS, Sigma and YARA rules, their licenses and whether they permit use in your environment.
- Update cadence: Ask how often rules refresh on connected sites and how new rule sets reach isolated sensors.
- Change approval: Define who may modify, suppress or set thresholds, and require a ticket or peer review for each change.
- False positive records: Log each suppression with the rule ID, the reason, the scope, the approver and an expiry or review date.
- Testing: Stage rule changes on a non-production sensor before enabling them in the production SOC queue.
Ask the partner to show the change log format and a sample suppression record, since auditors typically ask for both.
Encryption and rule governance both produce evidence that an assessor may request. For HIPAA, the Security Rule at 45 CFR 164.312 requires audit controls that record and examine activity in systems containing ePHI, and transmission security. For the FTC Safeguards Rule, 16 CFR 314.4 requires encryption of customer information in transit and monitoring of authorized user activity. A sensor design that decrypts traffic must show how that data is protected under those same obligations.
- Encryption record: Keep a current inventory of which traffic classes are decrypted, by whom and why.
- Rule baseline: Keep dated snapshots of the rule set in use, so you can show what detected activity at a given time.
- Approval trail: Retain change approvals and false positive decisions alongside the alert data they affected.
- Access logs: Record who views decrypted content or edits rules in the Console.
- Scope boundary: Confirm with your assessor which systems count as in scope before finalizing the evidence set.
This tab describes what to prepare. Independent auditors decide whether the evidence meets a specific requirement.
Integration requirements: getting alerts and data to the SOC
A sensor that sees everything is only useful if its output reaches analysts, enrichment and response tooling on time. The cards below cover the handoffs a network security monitoring rollout usually needs, from the SIEM and SOAR layer to identity for console access and ticketing. Confirm each connector, data format and supported version with the vendor before you commit to a design.
Forwarding alerts to the SIEM
Decide which records leave the sensor tier: Suricata alerts, Zeek logs such as connection, DNS, HTTP and TLS metadata, and any full packet capture references. Confirm whether Security Onion's Elastic-based pipeline forwards to your existing SIEM by syslog, API or another transport, and whether event schemas map cleanly to your correlation rules. Check the volume each sensor produces at peak, because forwarding every Zeek log type can multiply storage and license costs in a SIEM billed by ingest.
Feeding SOAR playbooks
Identify the alert types that should trigger automated enrichment or containment, and keep those decisions out of the sensor itself. Shuffle is an AGPL-3.0 SOAR platform that can sit beside this stack, but confirm its connector for your alert source and the authentication it uses against the Security Onion API. Test playbooks against recorded alerts so a noisy rule does not open hundreds of tickets overnight.
Threat intelligence enrichment
Enrichment adds indicator context to alerts, such as known malicious domains or IP addresses, before an analyst reviews them. MISP and OpenCTI are adjacent open source platforms that can supply and manage these indicators, and both are covered on their own pages. Confirm how indicators reach the sensor rule sets, whether through Suricata rules or a separate lookup, and who owns the update cycle, since stale indicators produce both missed detections and false positives.
Identity source for Console access
Decide how analysts sign in to the Security Onion Console before the first production user logs in. Security Onion Pro adds OIDC single sign-on to the Console according to its product page, while the open source edition should be checked for its own authentication options. Confirm the identity provider you plan to use, group-to-role mapping and whether break-glass local accounts are retained for the case when the identity provider is unavailable.
Ticketing and case handoff
Alerts that never become tickets leave no audit trail, so define the handoff from a Suricata or Zeek detection to your case management system before go-live. Ask the implementation partner whether the connector creates tickets from Security Onion alerts, attaches the originating event and records who closed each one. Confirm the ticket fields that matter for evidence, such as timestamps, sensor identifier and the rule or detection that fired.
Operational requirements and how to verify them
This table lists the operational requirements that most often break a Security Onion rollout after go-live, with the check to run before production. Read each row as a question to answer in a lab or a written design review, not as a feature to assume. The main takeaway is that the manager node, upgrade path and staffing for tuning need tests and named owners before the sensors go live.
| Requirement | What to verify | Evidence to keep |
|---|---|---|
| Manager dependency | Search nodes stop indexing when the manager is down because they cannot reach Redis. Run a failover test that stops the manager and measures how long the gap lasts and how backlog recovers. | Test plan, timing results and the recovery runbook signed by the operations owner |
| Receiver redundancy | Confirm whether receiver nodes are needed to add pipeline redundancy and load balancing for your traffic volume. Test a receiver failure during simulated peak load. | Load test results and the architecture diagram showing receiver placement |
| Upgrade path | Security Onion 2.4 installs on Oracle Linux 9 can move to 3 after full packet capture changes from Stenographer to Suricata. Other distributions need a fresh install. Rehearse the full path in a lab before scheduling production. | Rehearsal log, rollback steps and change record for the production window |
| Operating system constraint | Security Onion 3.x supports only Oracle Linux 9 and x86-64 processors. Confirm the sensor and manager hardware, OS image and approved build against these limits before procurement. | Hardware and OS compatibility sheet approved by the platform owner |
| End-of-life tracking | Version 2.4 reached end of life on October 1, 2026, and 2.3 reached end of life on April 6, 2024. Record the support status of every running version and set a dated plan to move off unsupported releases. | Version inventory and an approved migration plan with owners |
| Backup and restore | Back up the Security Onion configuration, detection rules, tuning filters and alert data according to your retention needs. Restore to a separate host and confirm sensors reconnect and alerts display. | Restore test record and backup schedule with retention periods set by policy |
| Tuning staffing | Assign named analysts to review NIDS suppressions, thresholds and Sigma filters on a fixed cycle. Confirm who approves changes and how false positive rates are tracked over time. | Tuning change log, approval records and a named rota for the SOC |
| Air-gapped updates | Updates in airgap mode come from newer ISO media through the soup tool. Confirm how media is transferred, verified and staged across the boundary, and rehearse one update in a test enclave. | Transfer procedure, media hash checks and the rehearsal record for the enclave |
| Rule source currency | Confirm how NIDS, Sigma and YARA rules are refreshed on connected sensors and on isolated networks, and who signs off each rule set before it reaches production. | Rule update procedure and dated records of each rule set deployed |
Sequence the requirements into a rollout
The sequence turns the requirements into a working sensor layer in a fixed order, so each step proves something before the next one depends on it. Scope and placement come first, then hardware and storage, then a staged deployment, rule tuning and a final acceptance test that shows alerts reach the people who act on them.
Confirm scope and network zones
The security architect and the network owners agree which segments, sites and cloud accounts are in scope, and which zones hold regulated data or industrial equipment that may need separate handling. The output is a written zone map that lists each monitored segment, its owner, its traffic direction and any restrictions on packet capture. Done means every in-scope segment has a named owner and an agreed sensor location on the map.
Validate tap and span points with a test flow
The network team places a test flow across each candidate tap or mirror port and confirms that Suricata and Zeek see the expected packets in both directions. The team checks for dropped frames, asymmetric paths and VLAN tags that the sensor does not parse. Done means each sensor location has a recorded test result, and any location that misses traffic is either fixed or removed from the design.
Size sensors and storage against measured traffic
The engineering lead measures peak throughput on each monitored link and compares it with the sensor hardware minimums published for Security Onion, then sets the packet capture and metadata retention periods the compliance owner requires. Ask the vendor or partner for a written sizing method, not a single number. Done means each sensor has a signed sizing sheet that shows link speed, peak load, NIC count, CPU, memory and disk for the retention target.
Deploy in Evaluation or Standalone before Distributed
The implementation team installs one pilot node in Evaluation or Standalone mode on a single segment, then confirms that logs, alerts and full packet capture flow through the console. Only after the pilot passes does the team build the production layout. Distributed, with a manager node, sensor nodes and search nodes, is the recommended production design. Done means the pilot runs end to end and the production build plan lists the manager, sensor and search node roles, and how the manager failure behavior is handled.
Tune rules against a measured baseline
The detection engineers record normal traffic for an agreed period, then load the chosen NIDS, Sigma and YARA rule sources and review the alerts the baseline produces. They apply suppressions and thresholds in the Detections interface and document each change with a reason. Done means the false positive list is reviewed, every suppression has an owner and a justification, and the rule set version is recorded.
Run an acceptance test through the SOC
The security operations lead triggers test detections on each monitored segment and confirms that each alert reaches the SOC queue, the on-call contact and the ticketing or SIEM system within the response process the organization set. The team also checks that the analysts can pivot from an alert to the stored packet capture. Done means every test case has a signed result, and any missed alert is logged as a defect with a retest date.
Plan updates for connected and air-gapped zones
The platform owner documents how rule sets and software updates reach each sensor, including the online update path and the offline path for zones without internet access, where Security Onion supports updates from newer ISO media. Done means the update procedure is written, tested once on a non-production node, and assigned to a named owner who will run it on schedule.
Questions buyers ask before choosing a network monitoring partner
What does a network security monitoring requirements project cost, and what drives it up?
The cost has four main parts: sensor hardware and taps for each monitored site, storage for packet capture and metadata, analyst and tuning time, and any paid edition of the platform. Hardware scales with link speed and the number of sites. Security Onion's published minimums are 4 cores, 24 GB RAM, 200 GB storage and 2 NICs for a standalone node, and 4 cores, 12 GB RAM and 2 NICs for a sensor, but production traffic usually needs more than the minimum, so ask the partner to size each sensor against measured peak throughput. Storage for full packet capture is the largest recurring cost and grows with retention. Security Onion Pro is sold on 1 to 5 year terms, so it is a recurring license cost if you need its OIDC single sign-on, FIPS mode or STIG compliance features. Ask for a quote that separates one-time work from recurring items, names the hardware and storage assumptions, and states what tuning hours are included.
How long does a scoped network monitoring rollout take?
The timeline depends on how many sites you have, how many sensors each site needs, how fast your change process moves, and how much rule tuning you accept before go-live. A single-site standalone deployment is far simpler than a distributed design with a manager, sensor nodes and search nodes, which Security Onion recommends for production. Hardware lead time, tap installation windows and access approvals often take longer than the software work. Ask your partner for a written milestone plan that lists each dependency, and treat any duration you are given as a plan to verify, not a promise. Fixed-scope engagements are agreed in writing before work starts, so the scope document is where timing assumptions should be recorded.
What must our team provide before a sensor deployment starts?
Your team needs to supply current network diagrams, the list of switches and the span or tap points they can support, administrative access to those switches, and the change windows when production links can be touched. Also provide the segmentation policy for any OT, clinical or cardholder zones, the retention period your regulator or policy requires for packet capture, and the names of the analysts who will receive alerts. Missing switch access or unclear change windows are the most common causes of delay. Confirm with the partner which items they need in writing before the kickoff, and ask who approves physical changes at each site.
Can our own team run network security monitoring without an outside partner?
A capable internal team can run Security Onion, but the work is larger than installing an ISO. The platform combines the Console, Elasticsearch, Suricata, Zeek, Elastic Fleet agents and full packet capture, and it requires ongoing tuning of NIDS rules, Sigma rules and YARA rules through the Detections interface. Someone must also own upgrades, since Security Onion 2.4 reached end of life on October 1, 2026 and the 3.x line supports only Oracle Linux 9. Assess whether you have staff for sensor design, rule tuning, patching and on-call alert handling. Many teams split the work, keeping alert triage in-house while a partner handles design, build and hardening.
Is Security Onion the right base given its Elastic License 2.0 and Oracle Linux 9 limit?
It fits well when you run x86-64 hardware, can standardize on Oracle Linux 9, and accept that the license is source-available rather than OSI-approved open source. The Elastic License 2.0 allows use, but review it with your legal team if you plan to offer the platform as a managed service to others or embed it in a product. The Oracle Linux 9 requirement matters if your standard build is another distribution, because the 3.0.0 release supports only that OS, and 2.4 installations on other distributions need a fresh install. Compare this with a stack of Suricata and Zeek deployed directly, which gives more control over the operating system but leaves you to build the console, storage and detection workflow yourself.
Can DeployOpen provide evidence for a compliance assessment?
DeployOpen prepares systems, controls and evidence for compliance assessments, including monitoring configurations, sensor placement records, rule-update logs and alert-handling records. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make that determination. The evidence you can expect depends on the framework, so ask the partner to map each requirement you must meet to the artifact that will be produced and the owner who maintains it. Confirm with your assessor, before work begins, which evidence they will accept and how long they expect it to be retained.
What should we ask a partner for a quote on this work?
Ask for a written scope that lists the sites, the monitored links and their speeds, the sensor count and hardware specification, the packet capture retention period, and the rule sources and tuning hours included. Request a separate line for any Security Onion Pro license term, a statement of which items are one-time and which recur, and the support and upgrade terms after go-live. Also ask how the partner will handle air-gapped sites, if any, and what acceptance tests will prove the sensors see the traffic you specified. DeployOpen does not publish a price list, and a quote follows from the written scope, so compare proposals on the same scope rather than on headline numbers.
What compliance evidence this checklist produces
Completing this checklist produces a set of records an assessor can test, and most of them should exist before anyone asks. The core artifacts are sensor placement records that show which tap or span point feeds each Suricata and Zeek sensor, the link it watches, and the network zone it sits in; a rule change log that records every NIDS, Sigma and YARA rule added, modified, suppressed or threshold-tuned in the Security Onion Console Detections interface; and tuning decisions that state why a suppression was made, who approved it and when it expires. Keep these in version control or a ticketing system so that each entry has a timestamp and an owner.
Access evidence is the second group. An access review for Console users, with the role each person holds and the date it was last confirmed, shows who can change detections and read packet capture. Retention settings for metadata and full packet capture should be written down with the value in force on each sensor and the date it changed. Upgrade records matter here too: a dated log of each Security Onion update, including whether it ran from the online repositories or from ISO media in airgap mode, shows that the monitoring stack was maintained rather than left to drift. Confirm with your auditor whether they want exports from the platform, screenshots, or a signed narrative, and which framework's control wording they will test against.
DeployOpen prepares these artifacts and the procedures that generate them, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Before the rollout starts, agree the evidence format and sampling approach with your assessor, then set the review cadence for each artifact in the written scope. Those decisions determine whether the checklist output is useful in an assessment or only useful to the engineering team.
How DeployOpen scopes and delivers network security monitoring
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the sensor, storage and rule layers a network security monitoring requirements checklist defines. Each engagement starts with a written scope that turns your traffic, link, retention and air-gap requirements into agreed deliverables before any hardware or software is deployed.
How we scope
- Map every tap and span point, link speed and sensor location against your network diagrams before naming hardware.
- Record which protocols Zeek and Suricata must see, and which traffic is encrypted or out of reach.
- Agree in writing whether sensors must run without internet access, and how rules and updates cross that boundary.
How we build
- Deploy Security Onion in the topology your requirements support, with sensors, manager and search nodes defined in advance.
- Configure full packet capture retention and storage sizing to match the retention period agreed in the scope.
- Load and tune NIDS rule sources, suppressions and thresholds, then test detections against traffic your team can reproduce.
How we hand over
- Deliver architecture, sensor placement, rule source and update procedure documentation tied to the requirements checklist.
- Provide runbooks for air-gapped updates, sensor health checks and packet capture retention management.
- Walk your security operations and platform teams through alert handling and the evidence each control produces.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan Security Onion upgrades, including version end-of-life dates and the distribution changes they may require.
- Confirm with your team which Security Onion Pro features, if any, are needed, since they are paid and separate from the open-source install.
