# Nozomi Deployment Architecture — Guardian Placement, SPAN vs TAP & Purdue Rollout Source: https://ai.techclick.in/blog_nozomi_deployment_architecture Markdown: https://ai.techclick.in/blog_nozomi_deployment_architecture.md Publisher: Techclick Infosec Pvt Ltd How to deploy Nozomi Networks Guardian sensors across the Purdue model (Levels 0–5), choose SPAN vs TAP, size per zone, connect to CMC or Vantage, and run a phased OT security rollout across multiple sites. Nozomi Deployment Architecture — Guardian Placement, SPAN vs TAP & Purdue Rollout student learning map A visual study map for Nozomi Deployment Architecture — Guardian Placement, SPAN vs TAP & Purdue Rollout showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Nozomi Deployment Architecture — Guardian Placement,... Nozomi · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① The Purdue model — which levels... 4. Practice ② SPAN vs TAP — how Guardian gets... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. Most engineers think… Most people picture OT sensor deployment as 'one box anywhere on the network'. In a Purdue-model OT environment, placement is everything — and getting it wrong means blind spots in the zones that matter most. A Nozomi Networks deployment is a layered topology : Guardian sensors at the right Purdue-level aggregation switches (not everywhere — not on every device), each fed by a SPAN port or a TAP , all feeding up to a CMC or Vantage . Knowing which Purdue level gets a sensor, when to upgrade from SPAN to TAP, and how to roll out without alarming OT operators — that is what the next 16 minutes covers. ## ① The Purdue model — which levels get a Guardian sensor The Purdue Reference Model (Levels 0–5 plus the IT/OT DMZ at Level 3.5) defines the zones of an industrial network. Guardian sensors are not placed on every device — they sit at aggregation switches where traffic from an entire zone crosses one point. The primary Guardian placement zones are: Level 2 (HMIs, SCADA servers, historians, engineering workstations — the richest traffic for asset discovery and anomaly detection); Level 3 (MES, operations servers, site historians — north–south traffic between control and business zones); and Level 3.5, the IT/OT DMZ (firewalls, jump servers, OPC proxies — critical for detecting cross-boundary anomalies and firewall-bypass). Levels 0–1 (PLCs, RTUs, field instruments) are usually covered by the Level 2 SPAN, since field-bus traffic converges at the Level 2 switch anyway. ### Levels 4–5 and beyond The enterprise LAN (Levels 4–5) is normally covered by IT security tooling. A Guardian at the Level 4 switch can catch OT-to-corporate lateral movement, but is optional in most deployments. Guardian Air (the wireless variant) is added wherever Wi-Fi, Bluetooth, or cellular OT devices operate — often outside the standard Purdue wired hierarchy. Legend Guardian sensor / primary monitored zone (royal) network level / pipeline stage diagram heading diagram background panel supporting label / caption Figure 1 — Purdue levels & Guardian placement Guardian sensors sit at aggregation switches — primarily Level 2, Level 3, and the IT/OT DMZ — not on every device. - Purdue levels & Guardian placement Level 4–5 Enterprise LAN — IT tools + optional Guardian Level 3.5 DMZ Firewalls, OPC proxy — Guardian recommended Level 3 MES, historians — Guardian for north–south Level 2 HMI, SCADA — primary Guardian zone Level 0–1 PLCs, RTUs — covered via Level 2 SPAN Guardian sensors sit at aggregation switches — primarily Level 2, Level 3, and the IT/OT DMZ — not on every device. Figure 2 — Traffic flow: field device to Vantage A PLC packet travels from the field bus through the Level 2 SPAN to Guardian, then up to CMC or Vantage. Traffic flow: field device to Vantage PLC / RTU Level 0–1 field Level 2 switch SPAN or TAP Guardian Passive DPI CMC / Vantage Aggregation A PLC packet travels from the field bus through the Level 2 SPAN to Guardian, then up to CMC or Vantage. Quick check · Q1 of 10 · Understand In most Nozomi deployments, the primary Guardian placement zone is… a) Level 0–1, directly at every PLC b) Level 2 (supervisory) — the HMI/SCADA/historian aggregation switch c) Level 5 enterprise data centre only d) Outside the perimeter firewall Correct: b. Level 2 (supervisory) is the primary Guardian zone because the HMI-PLC and HMI-historian traffic converges at the Level 2 switch, giving the richest asset discovery and anomaly detection from the fewest sensor placements. Levels 0–1 field devices are usually covered via the Level 2 SPAN. 👉 So far: Guardian sensors belong at Purdue Level 2 (HMI/SCADA), Level 3 (site operations), and Level 3.5 (IT/OT DMZ) aggregation switches — not on every device. Levels 0–1 are covered via the Level 2 SPAN. ## ② SPAN vs TAP — how Guardian gets its traffic feed Guardian is completely passive : it never injects packets into the OT network. Traffic reaches it one of two ways. A SPAN port (mirror port) is a feature built into most managed switches — the switch copies selected port traffic to a monitoring port. SPAN is free and easy to configure, but many switch models allow only one SPAN destination at a time, and under heavy load the switch may drop mirrored frames before Guardian sees them. A network TAP (Test Access Point) is a dedicated hardware device placed inline on a link. It copies 100% of frames to Guardian with no packet loss, regardless of link utilisation — the physical copy is passive and cannot be saturated by the live traffic. TAPs are recommended for high-value chokepoints: the IT/OT DMZ uplink, the historian server connection, or any link where a packet-dropping SPAN would create blind spots in asset inventory or forensics. ### Sizing per zone Guardian sizing (appliance model or virtual spec) scales with link bandwidth and asset density per zone . The guiding principle is one Guardian per discrete network zone or VLAN . A typical mid-size substation might deploy two Guardians: one for the Level 2 control zone and one for the Level 3/DMZ zone. Virtual Guardians (VMware, Hyper-V, container) are common in sites where rack space is limited. Figure 3 — SPAN port vs network TAP Both feed Guardian passively — SPAN is free but can drop frames; TAP costs more but guarantees full capture. SPAN port vs network TAP SPAN (mirror port) Built into managed switches — no Free to configure; needs switch Can drop mirrored frames under Usually one SPAN destination per Network TAP Dedicated hardware inline on the Zero packet loss at any link Higher upfront cost; requires Recommended for DMZ and critical Both feed Guardian passively — SPAN is free but can drop frames; TAP costs more but guarantees full capture. 📡 Guardian sensor tap to flip Nozomi's core passive network sensor — passive DPI, asset discovery, anomaly and threat detection. Deploys as appliance, VM, or container; never touches OT traffic. 🏭 CMC tap to flip Central Management Console — on-prem or virtual aggregator for multiple Guardians. Ideal for air-gapped, sovereign, and regulated sites that cannot send data to the cloud. ☁️ Vantage SaaS tap to flip Cloud-native SaaS management platform. Aggregates Guardians and Arc across many global sites with no management hardware — adds Vantage IQ (AI analytics) for faster triage. 🖥️ Arc endpoint tap to flip Lightweight host sensor adding user, process, USB, and session context — fills coverage gaps in zones that have no SPAN port and cannot be seen by passive Guardian monitoring. One Guardian per zone, not per device The classic over-deployment mistake is trying to put a sensor on every switch. The right model is one Guardian per discrete network zone or VLAN — placed at the aggregation point where all zone traffic converges. This minimises sensor count while maximising coverage. Quick check · Q2 of 10 · Apply The IT/OT DMZ uplink switch is heavily loaded at peak. Which collection method should you use for the Guardian feed? a) A hardware TAP — guarantees full capture with zero packet loss regardless of load b) A SPAN port — it is built in and costs nothing extra c) An endpoint agent on every server in the DMZ d) No sensor — the DMZ firewall logs are sufficient Correct: a. A heavily loaded switch risks dropping SPAN mirrored frames, creating blind spots in asset inventory and forensics. A hardware TAP copies 100% of frames passively with no packet loss — the right choice for high-value, high-utilisation links like the IT/OT DMZ uplink. 👉 So far: SPAN is free but can drop frames under load; a TAP is hardware-cost but guarantees 100% capture. Use TAPs on high-value, high-utilisation chokepoints like the IT/OT DMZ uplink. ## ③ CMC & Vantage — the management topology above Guardian Individual Guardians are powerful, but multi-site OT programmes need a central management layer. Nozomi offers two paths. The Central Management Console (CMC) is an on-prem or virtual appliance that aggregates data from many Guardians across one or more sites — ideal for air-gapped, sovereign, or heavily regulated environments (power utilities, defence, water) where OT metadata cannot leave the site perimeter. CMC provides centralised policy, cross-site alerts, and consolidated reporting without any cloud dependency. Vantage is Nozomi's cloud-native SaaS alternative: Guardians (or a CMC) send data to Vantage over encrypted HTTPS. Vantage scales effortlessly across dozens of global sites, adds Vantage IQ (AI-assisted triage and correlation), and requires no management-layer hardware. For hybrid estates — some sites air-gapped, some cloud-connected — CMC aggregates air-gapped Guardians and forwards summary/alert data on to Vantage, giving a single pane of glass globally. ### Arc fills the coverage gaps Arc , Nozomi's lightweight host sensor, complements Guardian by reaching segments that have no SPAN port — micro-segmented zones, isolated workstations, or point-to-point serial links visible only from the host. Arc adds user, process, USB, and session context that passive network monitoring cannot see. Figure 4 — Guardian topology — sensors to management Each Guardian reports to CMC (on-prem) or Vantage (SaaS), with Arc filling host-visibility gaps. Guardian topology — sensors to management CMC / Vantage Central management Guardian (L2) Guardian (L3) Guardian (DMZ) Guardian Air Arc (host) Site 2 CMC Each Guardian reports to CMC (on-prem) or Vantage (SaaS), with Arc filling host-visibility gaps. 'We will just use Vantage everywhere' Vantage SaaS is ideal for cloud-connected sites, but air-gapped OT environments (power substations, nuclear, water treatment, defence) cannot send traffic metadata to the cloud. CMC is the correct on-prem aggregation layer for those sites. Always confirm cloud-connectivity policy before choosing Vantage. ### ▶ Watch a rogue device get discovered passively by Guardian How a new unauthorised PLC is discovered through the Level 2 SPAN, identified by Guardian, and surfaced in Vantage. Press Play for the healthy path, then Break it to see the classic SPAN failure. ① PLC connects An unauthorised PLC is cabled into the Level 2 switch and starts broadcasting its protocol identity (e.g. Modbus/TCP) to the HMI. ▼ ② SPAN mirrors The managed Level 2 switch mirrors the new PLC traffic to Guardian's monitoring interface via the SPAN port. ▼ ③ Guardian DPI Guardian's passive DPI engine parses the Modbus/TCP frames, extracts the device identity (vendor, model, IP, MAC) and classifies it as a new Level 2 OT asset. ▼ ④ Alert in Vantage Guardian raises a 'new unauthorised device' alert in Vantage with full asset profile — operator reviews and either authorises or quarantines. Press Play to step through the healthy discovery path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Quick check · Q3 of 10 · Analyze A power utility operates three substations that are fully air-gapped — no internet or cloud access. Which management topology fits? a) Vantage SaaS — it scales better than CMC b) Guardian Air only — no management layer needed c) CMC on-prem at each site aggregating local Guardians, with no cloud dependency d) Arc endpoints replacing Guardian in air-gapped zones Correct: c. CMC is the on-prem/virtual aggregation layer designed for air-gapped, sovereign, and regulated environments. Vantage SaaS requires cloud connectivity that the substations do not have. CMC consolidates the Guardians at each site with no internet dependency. 👉 So far: CMC aggregates Guardians on-prem for air-gapped/sovereign sites; Vantage SaaS scales across cloud-connected sites. Arc fills host-visibility gaps in zones without a SPAN port. ## ④ Multi-site & phased rollout — deploying without alarming OT A successful Nozomi rollout follows four phases. Phase 1 — Passive discovery : deploy Guardian in monitor-only mode; let it build a complete asset inventory and learn the network baseline over 2–4 weeks. Zero alerts, zero OT impact — operators do not notice it. Phase 2 — Baselining & tuning : review the discovered asset list, map assets to Purdue levels and zones in CMC/Vantage, tune detection thresholds, suppress known-good behaviour, and reduce false positives before any alerting is enabled. Phase 3 — Operational alerting : enable active alert policies. Integrate with SIEM/SOAR (Splunk, Microsoft Sentinel, IBM QRadar) and ticketing (ServiceNow, Jira). At this point the SOC begins receiving OT alerts in the same console as IT alerts. Phase 4 — Site expansion : replicate the pattern to additional sites and zones, onboard new Guardians to the existing CMC or Vantage instance, and add Arc for host-visibility gaps. Each new site repeats Phases 1–3 before going live with alerting. ### Integration hooks Nozomi integrates with firewalls (Palo Alto, Fortinet), identity platforms, and vulnerability scanners via syslog, REST APIs, and certified connectors — the SOC correlation layer gets richer OT asset context without re-architecting the security stack. Figure 5 — Phased Nozomi rollout — 4 phases Each phase adds capability without touching OT operations until the baseline is stable. Phased Nozomi rollout — 4 phases Phase 1 Passive discovery Phase 2 Baseline & tune Phase 3 Live alerting Phase 4 Site expansion Each phase adds capability without touching OT operations until the baseline is stable. Priya Nair, OT security architect at PowerGrid India Pvt. Ltd. in Nagpur, faces this After Phase 1 Guardian deployment at a substation, Vantage shows 40% of Level 2 assets as 'unknown' — vendor and firmware cannot be identified. Likely cause The SPAN port on the heavily loaded Level 2 switch is dropping mirrored frames during peak SCADA polling cycles; Guardian misses the initial broadcast packets that carry device identity. Diagnosis In Vantage, filter assets by site and sort by 'Classification confidence' — the unknown assets all appear in the same VLAN. Check Guardian packet-drop counters; they show significant loss during peak windows. SPAN oversubscription is the root cause. Vantage ▸ Assets ▸ Filter by site ▸ Classification + Guardian ▸ Diagnostics ▸ Packet counters Fix Replace the SPAN connection with a hardware TAP on the two most critical uplinks to Guardian. No switch config change needed after the TAP is installed — Guardian begins receiving every frame. Verify Within hours of the TAP install, Vantage asset inventory drops to under 5% unknown. The previously 'unknown' PLCs are now fully identified with vendor, model, and firmware version. High unknown-asset rate = SPAN packet loss, not a Guardian bug After Phase 1, open the Vantage or CMC asset inventory and check the 'Classification confidence' column. High unknown-asset rates (above 10–15%) are a strong signal of SPAN packet loss — not a Guardian limitation. Switch to a TAP on the affected link and re-run the discovery phase. Quick check · Q4 of 10 · Evaluate An OT team is nervous about enabling Nozomi alerts because past tool deployments triggered nuisance alerts during shift changes. What is the correct first phase? a) Enable all alert policies immediately to discover issues faster b) Skip baselining — tune thresholds manually from day one c) Block anomalous traffic at the firewall from day one d) Deploy Guardian in monitor-only mode for 2–4 weeks to build a stable behaviour baseline before enabling alerting Correct: d. Phase 1 is always passive discovery and baselining with no active alerts. This respects the OT team's concern — Guardian learns what normal looks like (shift changes, scheduled polling cycles, maintenance windows) before any alerting fires, dramatically reducing false positives. 👉 So far: A safe OT rollout is four phases: passive discovery → baseline and tune → operational alerting → expand to more sites. Never skip the baseline phase — it prevents the false-positive storms that erode OT team trust. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. Where should the first Guardian sensor be placed in a new OT deployment? When should you use a TAP instead of a SPAN port? What is CMC and when do you choose it over Vantage? What does Arc add that Guardian cannot provide? What happens during Guardian's learning (baseline) phase? How does a phased Nozomi rollout work? Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in. ## 📝 Wrap-up assessment — six more You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end. Q5 · Remember Which Purdue level is the primary Guardian placement zone in most OT deployments? a) Level 2 — the HMI, SCADA server, and historian aggregation switch b) Level 5 — the enterprise data centre c) Level 0 — directly on every PLC and RTU d) Outside the perimeter firewall Correct: a. Level 2 (supervisory) is where HMIs, SCADA servers, historians, and engineering workstations communicate. The aggregation switch here sees the richest OT traffic for asset discovery and anomaly detection from the fewest sensors. Levels 0–1 field devices are typically covered via the Level 2 SPAN. Q6 · Understand Why can a SPAN port fail to deliver all traffic to Guardian under heavy load? a) SPAN requires a special licence on the switch b) SPAN ports cannot mirror Modbus/TCP traffic c) The switch may drop mirrored frames when its internal fabric is congested, creating gaps in Guardian's view d) SPAN requires an inline deployment mode Correct: c. Under switch load, the internal fabric prioritises live traffic. Mirrored (SPAN) frames are lower priority and can be silently dropped — Guardian receives an incomplete stream and may miss device-identity packets, causing high unknown-asset rates. A hardware TAP avoids this because it physically copies the signal before the switch fabric. Q7 · Apply A water treatment plant must keep all OT monitoring data on-site due to regulatory requirements. Which management topology should be used? a) Vantage SaaS — it is simpler to deploy b) CMC on-prem aggregating the site Guardians, with no cloud connectivity required c) Arc replacing Guardian at all Level 2 switches d) Guardian Air only — it works without any management layer Correct: b. CMC is the on-prem/virtual aggregation layer built for regulated, air-gapped, and sovereign environments. It consolidates Guardian data entirely on-site with no cloud dependency. Vantage SaaS would require sending OT metadata to the cloud, violating the regulatory requirement. Q8 · Analyze An OT security team finds that 30% of Level 2 assets appear as 'unknown' in Vantage after two weeks of Guardian monitoring. The most likely root cause is… a) Guardian does not support the OT protocols in use b) Vantage IQ is not enabled c) Arc is not deployed on the HMI servers d) The Level 2 SPAN port is dropping packets — Guardian is not seeing full discovery traffic Correct: d. A high unknown-asset rate after initial discovery strongly indicates SPAN packet loss. Guardian misses the initial broadcast/announcement packets that carry device identity when the SPAN drops frames under load. The fix is to replace the SPAN with a TAP on the affected uplinks. Q9 · Evaluate A site already has CMC aggregating its three Guardians. The CISO wants global visibility across 12 sites worldwide, some air-gapped. What is the best architecture? a) Replace all CMCs with Vantage SaaS to simplify the topology b) Keep CMC at air-gapped sites; connect cloud-capable sites directly to Vantage; optionally forward CMC summary data to Vantage for a single global pane c) Deploy one global CMC and disable Vantage d) Use Arc instead of Guardian at all 12 sites to avoid management overhead Correct: b. The hybrid topology is the correct answer: CMC stays at air-gapped or sovereign sites (no cloud dependency), cloud-connected sites send directly to Vantage, and CMC can forward alert/summary data to Vantage so the CISO sees all 12 sites in one dashboard. This respects the air-gap constraint while giving global scale. Q10 · Evaluate An OT manager insists on skipping the baseline phase and enabling all Guardian alerts from day one. The strongest counter-argument is… a) Guardian cannot detect threats until month three b) Skipping the baseline generates false-positive storms — shift changes, scheduled polling, and maintenance windows all look anomalous before a baseline is built, eroding OT team trust c) Alerting requires a separate Guardian licence d) Day-one alerting permanently disables passive asset discovery Correct: b. Without a baseline, every normal OT behaviour — shift-change traffic spikes, scheduled SCADA polling, planned maintenance — appears anomalous and triggers alerts. The resulting false-positive storm overwhelms the OT team and destroys confidence in the tool. The baseline phase (Phase 1) exists specifically to learn normal before alerting on abnormal. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 In your own words Type one line: why does a Nozomi deployment place Guardian at Level 2 rather than on every switch in the plant? Then compare with the expert version. Compare with expert answer Expert version: Guardian is a passive sensor that needs to see traffic, not be everywhere traffic travels. Level 2 (supervisory) is the natural aggregation point where HMI-to-PLC, HMI-to-historian, and engineering-workstation traffic all converge on one switch — so a single Guardian on the Level 2 SPAN sees the entire control zone. Adding sensors on every switch would multiply hardware cost and management overhead without adding proportional visibility; the coverage principle is one Guardian per discrete network zone, not per device or per switch. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Nozomi Networks at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary Guardian Nozomi's core passive network sensor — passive DPI, asset discovery, anomaly and threat detection, vulnerability assessment. Deploys as appliance, VM, or container. CMC (Central Management Console) On-prem or virtual aggregator that consolidates multiple Guardian sensors across one or more sites without cloud dependency — the choice for air-gapped and sovereign environments. Vantage Nozomi's cloud-native SaaS management platform — aggregates Guardians and Arc, single pane of glass, scales across many sites, adds Vantage IQ (AI analytics). Arc Lightweight Nozomi host sensor adding user, process, USB, and session context — fills passive network monitoring blind spots in zones without a SPAN port. SPAN port Switch mirror port that copies selected port traffic to a monitoring port; free and easy but can drop mirrored frames under heavy switch load. Network TAP Dedicated hardware device that passively copies 100% of frames on a link to Guardian with zero packet loss — recommended for high-value chokepoints. Purdue Model Reference architecture for industrial control systems, Levels 0–5: field devices (0–1), supervisory (2), site operations (3), IT/OT DMZ (3.5), enterprise (4–5). Guardian Air Wireless Guardian variant for Wi-Fi, Bluetooth, cellular, and drone-spectrum OT visibility — complements wired Guardian in sites with wireless OT devices. #### 📚 Sources Nozomi Networks — Guardian sensor product page & data sheet . nozominetworks.com/products/guardian - Nozomi Networks — Vantage SaaS platform overview & Vantage IQ . nozominetworks.com/products/vantage - Nozomi Networks — Central Management Console (CMC) overview . nozominetworks.com/products/central-management-console - Nozomi Networks — Arc endpoint sensor . nozominetworks.com/products/arc - NIST SP 800-82 Rev 3 — Guide to Operational Technology (OT) Security: Purdue Reference Model for ICS . nist.gov - ISA/IEC 62443 — Industrial Automation & Control Systems (IACS) security standards: zone and conduit model . isa.org ### What's next? Got the deployment topology? Next, go deep on how Guardian's hybrid detection engine builds its behaviour baseline, fires anomaly alerts, and how Nozomi Labs Threat Intelligence feeds enrich detection in real time. Next · All interview lessons → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt