Local monitoring: what stays inside your site?
Episode 04 — Practical architecture

[00:00:00.000] Welcome back. I am Sam Armstrong. This episode asks a practical question: what stays inside your site when you monitor locally?

[00:00:09.189] We will follow an illustrative traffic copy through a local monitoring system, then examine management access, stored evidence and updates.

[00:00:18.328] The aim is a clear data-flow record, with named owners and checks that support the claims made about your deployment.

[00:00:27.680] Draw the observation path, the management path, the storage locations and the update route. Include any connections leaving the site.

[00:00:36.822] Use different labels for copied production traffic, administrator requests, exported reports and incoming update packages.

[00:00:45.612] Keep the current installation separate from the proposed design. A diagram should describe what is actually connected and configured.

[00:00:56.011] In our example, a switch mirror sends a copy of selected traffic to a monitoring interface while production communications continue between their endpoints.

[00:01:06.693] The mirror configuration determines which ports, virtual networks and traffic directions are visible. Record that scope with the switch owner.

[00:01:15.858] The monitor sees the copy delivered to it. It does not automatically see every device, every network segment or every production event.

[00:01:26.459] A switch mirror, often called a SPAN port, needs a reviewed configuration and enough capacity for the traffic being copied.

[00:01:35.196] A network TAP is hardware associated with the production link. Review its media, speed, power behaviour and installation requirements.

[00:01:44.690] Choose the method with the network owner. Passive analysis does not remove the need to plan installation, change control and recovery.

[00:01:55.134] Identify the capture interface by its physical port and hardware address. Keep its role visible in the installation record.

[00:02:03.971] For a receive-only design, review interface addresses, routes, bridging and services. Ask the engineer how transmission into production is prevented.

[00:02:14.288] A label saying passive is not verification. Check the configured operating system, capture equipment and physical arrangement against the approved design.

[00:02:26.120] The management connection lets authorised people open the dashboard, administer the system and retrieve approved evidence. It carries normal two-way communication.

[00:02:37.211] Draw that route separately from the traffic-copy path. Identify the administrator device, management network and permitted destination service.

[00:02:47.026] Review authentication, permissions and session records. A passive capture function does not make the management interface passive or risk free.

[00:02:58.137] A system can analyse traffic locally while still using remote support, email, online services or an external management connection.

[00:03:07.724] Check configured integrations, network routes, name services, time sources and identity dependencies. Include optional services that someone has enabled.

[00:03:18.634] If you claim there is no external communication, verify that claim across the actual interfaces, services and operating conditions.

[00:03:29.478] List the categories your deployment actually stores: retained packet captures, asset records, communication summaries, alerts, audit logs and generated reports.

[00:03:40.775] A product may retain only some of these categories or use different retention settings. Confirm the configuration rather than assuming full packet storage.

[00:03:51.187] Record the physical storage location, responsible owner and access permissions for each category. Include temporary working files and imported captures.

[00:04:02.980] A packet capture can contain device addresses, operational detail and, depending on the protocols, confidential payloads or credentials.

[00:04:12.781] Reports and screenshots can also reveal equipment identities, vulnerabilities and plant relationships. Local storage still needs appropriate access protection.

[00:04:23.635] Agree who may inspect, copy or export the material, where approved copies may be kept, and how the organisation handles it.

[00:04:33.545] Agree retention for each data category, based on the operational purpose and the organisation’s requirements. Avoid an unexplained keep-everything setting.

[00:04:44.165] Check available capacity and the behaviour when storage fills. Identify which records rotate, which processing may stop and who receives the warning.

[00:04:54.703] Review deletion and backup behaviour together. Removing a capture from the dashboard may not remove a copy held in a backup or export.

[00:05:05.397] Trace downloads, printed reports, screenshots, support bundles and removable media. Each can move locally collected information beyond the monitoring system.

[00:05:16.455] Before sharing, review the content, destination and authorised recipient. Keep the approved scope and handling arrangements with the export record.

[00:05:26.300] Describe the difference between data remaining on the appliance and data remaining inside the site. Those are different boundaries.

[00:05:36.073] Identify what must be backed up to recover the installation, including configuration, required evidence and any keys needed to read protected data.

[00:05:46.764] Record where the backup goes and who can restore it. An off-site backup changes the answer to what stays inside the site.

[00:05:55.181] Test recovery through an approved procedure. Keep the restored data’s original observation dates distinct from the time it was imported or restored.

[00:06:06.576] For a deployment intended to operate offline, list the functions expected to work without internet access: collection, analysis, administration and reporting.

[00:06:17.776] Have the responsible engineer verify them in an approved test arrangement. Check dependencies such as licensing, time, identity and external data services.

[00:06:29.153] Document the result and the limitations. A local dashboard alone does not prove that all required functions operate without an external connection.

[00:06:40.771] An offline update process may obtain packages on an approved connected system, then transfer them through the site’s controlled import process.

[00:06:50.752] Record the package source, intended installation, version and responsible person. Review the removable-media or transfer procedure with the site team.

[00:07:01.232] The acquisition system and the monitoring appliance have different roles. Avoid creating an unreviewed internet route into production to make updates easier.

[00:07:12.980] Where signed update packages are supported, verify the signature against the approved trusted key before import. Follow the documented verification process.

[00:07:23.955] A hash can check consistency against a trusted reference, but a hash delivered with an untrusted file does not establish its publisher.

[00:07:33.461] A valid signature does not prove compatibility or suitability. Review the package version, change notes, prerequisites and approval before applying it.

[00:07:45.008] Before updating, agree a backup, maintenance arrangements, validation criteria and a documented recovery or rollback option suitable for that package.

[00:07:55.823] After import, confirm the installed version and check collection, job processing, storage health, access and reporting as appropriate to the change.

[00:08:05.910] Keep the package identifier, verification result, operator, date and outcome. Record any interruption or limitation that affects the evidence collected.

[00:08:17.903] Separate software updates from intelligence or detection-content updates. Their release dates, import dates and operational effects may differ.

[00:08:27.944] An offline installation continues using the content available to it. New external intelligence is absent until the approved update process supplies it.

[00:08:38.747] Show the relevant versions and dates during review. Do not describe an old imported feed as current simply because the appliance is running today.

[00:08:49.787] Quiet equipment and unobserved network segments may be absent from the evidence. Encryption can hide payload detail, and unsupported protocols can limit interpretation.

[00:09:01.555] Mirror overload, capture loss or a stopped processing service can also create gaps. Check collection and processing health before interpreting a quiet result.

[00:09:12.245] Keep uncertain device identities and firmware versions uncertain unless the available evidence supports them. Observed communication does not prove that access was authorised.

[00:09:25.487] A passive monitor may highlight observed behaviour using its supported detections, but cannot guarantee that every attack or unsafe condition will be recognised.

[00:09:36.449] The monitoring function itself does not block a command. Any separate enforcement integration needs its own explicit design, authorisation and validation.

[00:09:47.470] Use alerts as evidence for investigation. Confirm the context with the plant team and follow the approved response process before changing production equipment.

[00:09:59.414] Leave with a reviewed record of the traffic-copy path, management access, storage locations, exports, recovery arrangements and the update route.

[00:10:09.594] Name the owners and retain the checks supporting local-operation claims. Include observation coverage, feed dates and the limits the team still needs to address.

[00:10:20.303] That gives your team a clearer answer to what stays inside the site, what can cross its boundary, and who controls it. Thank you.


[00:10:30.000] End card: Thank you.
