Network security monitoring for healthcare

Suppress only the specific, documented pattern, never the whole device class or subnet. Clinical devices such as infusion pumps, patient monitors and imaging modalities often repeat the same handshakes, polling and time-sync traffic, and those repeats fill the queue with noise. In Security Onion, a suppression on a NIDS rule can be scoped by source, destination, or both, so match the exact host pair and port the vendor documents. Review each suppression against the device's expected behavior before approving it, and set a review date so that temporary exceptions do not become permanent blind spots.

Use thresholds to reduce repeated alerts from the same benign source while keeping the first occurrence and any escalation. Security Onion's Detections interface supports modify, suppress and threshold tuning for NIDS rules loaded into Suricata, so a rule that fires on every scheduled backup or device heartbeat can be limited to a set count per time window. Start with the noisiest rules in a monitor-only period, record the baseline, and then set thresholds. Keep thresholds off rules that detect exploitation of medical or legacy systems, because those are the alerts a clinical network most needs to see.

Yes, Sigma filters can exclude known hospital activity from log-based detections, provided each filter is narrow and written to a named system. Security Onion's Detections interface supports custom filters for Sigma rules loaded into ElastAlert, which lets the team exclude, for example, a scheduled reporting job from an electronic health record host. Tie each filter to a specific account, host or time window and avoid broad exclusions such as all service accounts. Test the filter against historical events to confirm that a real attack pattern from the same host would still match.

Treat scanning from biomedical engineering and vendor service tools as a known, scheduled activity that is identified, documented and watched, not ignored. Ask biomedical engineering and each imaging vendor for the source addresses, tools, ports and schedules their work uses, and for who approves a service session. Build alerts for that traffic that fire when it occurs outside those windows or from unexpected hosts. Scanners that run during a maintenance window should be recorded in the change log with the ticket number, so an analyst can confirm the scan was expected when it appears in the data.

Tuning must never hide traffic that a clinical protocol or a vendor remote-access path would reveal. Medical device protocols such as DICOM, HL7 and vendor-specific maintenance channels are where lateral movement or unauthorized remote sessions can look like routine traffic. Before suppressing anything in these flows, confirm with the vendor which ports and sessions are legitimate, and keep at least one detection on every remote-access path, including unexpected sessions outside approved windows. Suppressions should narrow what is ignored, never widen the blind spot.

Record each suppression, threshold and filter as a change request with a named owner, a stated reason, the exact rule and scope, an approval, and a review date. Keep these records in the same change system used for the rest of the environment so that an auditor can trace what was ignored and why. Security Onion keeps the rule changes in its configuration, but the business justification must live in your ticketing or governance tool. Reviewing the change log on a regular schedule shows whether tuning is still justified after devices, vendors or network layouts change.

The security operations team should own the detection logic, but clinical engineering and biomedical engineering must approve any change that affects a device they support. Security staff understand the alert, while clinical and biomedical teams know which devices are safety-critical and when they are serviced. Set a rule that no suppression goes live without both sign-offs for clinical scope. Confirm the approval path with your own governance structure, since reporting lines differ between hospitals and health systems.

Tuning effort is mostly ongoing analyst time, and it rises with the number of device types, vendors and sites. The first tuning cycle is the heaviest because the team must build a baseline and review the noisiest rules, and later cycles shrink as the baseline stabilizes, unless new devices or vendors arrive. Ask any implementation partner to estimate the initial tuning window and the recurring review load in writing, and to show how each suppression is documented. Your own analyst capacity and the number of monitored segments are the main inputs to that estimate.

The biggest drivers are the number of monitored segments, the sensor count and hardware per site, how much traffic each sensor must inspect, how long packet capture is retained, and how much analyst time goes into tuning alerts for clinical traffic. Sensor hardware and storage are one-time or refreshed costs, while tuning, alert review and upgrades recur. Ask any implementation partner for a quote that lists sensor locations, capture scope, storage sizing and tuning hours as separate line items. Security Onion hardware minimums for a sensor, manager and search node are published in its documentation, so the hardware baseline can be checked early. Your clinical network size will decide the rest.

Useful alerts depend on sensor placement being approved, taps or span ports being installed in change windows, and the first tuning cycle being completed. Sensors can often produce output soon after they see traffic, but the early alert queue on clinical networks is noisy until medical device protocols and known-good flows are suppressed or baselined. Ask a partner to name the milestones in the written scope: placement approval, sensor build, first tap validation, and a tuning checkpoint. Confirm the duration of each step with the partner, because it depends on change control and vendor maintenance windows in your facility.

Plan to provide current network diagrams showing VLANs, clinical and medical device segments, firewalls and uplinks, a device inventory or export from your asset tools, and a list of approved change windows. You should also name the clinical and biomedical engineering contacts who can confirm which devices are time-sensitive. A partner will also need access rules for the packet capture locations and a decision on where ePHI-bearing captures will be stored. Ask the partner to list these inputs in writing so that gaps are found during scoping rather than during deployment.

A small internal team can run Security Onion if it has Linux administration skills, time for daily alert review, and a documented process for tuning clinical traffic. The harder part is usually not installing sensors but maintaining suppressions, change records and rule updates across clinical and administrative zones. Many hospitals split the work: internal staff own alert triage and access decisions, while a partner handles initial deployment, hardening, documentation and upgrades. Define that split in the statement of work so responsibilities after handover are clear.

Pro is not required to run Security Onion, but it is worth evaluating if your requirements include specific features. According to the Security Onion Pro page, the paid edition adds OIDC single sign-on to the Console, LUKS data-at-rest encryption, FIPS mode, OS STIG compliance, the Security Onion API and professional support, among other features. Pro is sold on 1 to 5 year terms, so compare that recurring cost with what your team would otherwise build. Confirm current feature availability and pricing directly with the vendor, since editions can change.

No. HHS states that no Security Rule standard requires certifying compliance, and private certifications do not prevent HHS from later finding a violation. The HHS Office for Civil Rights enforces the rule through complaints, compliance reviews and audits. Monitoring supports the audit controls and access control expectations in 45 CFR 164.312, but the evidence you keep, such as configuration records, alert review logs and access reviews, is what an assessor or regulator will examine. Keep packet capture that may contain ePHI under the same safeguards as other ePHI, and make sure any partner that handles it is covered by a business associate agreement.

Passive taps and span ports are designed to observe traffic without sitting inline, which reduces the risk of disrupting clinical devices, but installation still needs careful planning. Ask the partner how they validate tap or span placement, how they avoid packet loss at peak, and how they test changes in a window agreed with clinical engineering. Confirm with your biomedical engineering team which devices must not see any change in network conditions, and document that constraint before sensor placement is finalized.