Local monitoring: what stays inside your site?

Local monitoring: what stays inside your site?

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

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

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

Start with four separate paths.

Draw the observation path, the management path, the storage locations and the update route. Include any connections leaving the site.

Use different labels for copied production traffic, administrator requests, exported reports and incoming update packages.

Keep the current installation separate from the proposed design. A diagram should describe what is actually connected and configured.

Observe a copy of selected communications.

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

The mirror configuration determines which ports, virtual networks and traffic directions are visible. Record that scope with the switch owner.

The monitor sees the copy delivered to it. It does not automatically see every device, every network segment or every production event.

Choose collection with the network owner.

A switch mirror, often called a SPAN port, needs a reviewed configuration and enough capacity for the traffic being copied.

A network TAP is hardware associated with the production link. Review its media, speed, power behaviour and installation requirements.

Choose the method with the network owner. Passive analysis does not remove the need to plan installation, change control and recovery.

Verify the intended receive-only behaviour.

Identify the capture interface by its physical port and hardware address. Keep its role visible in the installation record.

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

A label saying passive is not verification. Check the configured operating system, capture equipment and physical arrangement against the approved design.

Management is a separate connection.

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

Draw that route separately from the traffic-copy path. Identify the administrator device, management network and permitted destination service.

Review authentication, permissions and session records. A passive capture function does not make the management interface passive or risk free.

Check what else can communicate.

A system can analyse traffic locally while still using remote support, email, online services or an external management connection.

Check configured integrations, network routes, name services, time sources and identity dependencies. Include optional services that someone has enabled.

If you claim there is no external communication, verify that claim across the actual interfaces, services and operating conditions.

Separate packet data from derived records.

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

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

Record the physical storage location, responsible owner and access permissions for each category. Include temporary working files and imported captures.

Treat captures and exports with care.

A packet capture can contain device addresses, operational detail and, depending on the protocols, confidential payloads or credentials.

Reports and screenshots can also reveal equipment identities, vulnerabilities and plant relationships. Local storage still needs appropriate access protection.

Agree who may inspect, copy or export the material, where approved copies may be kept, and how the organisation handles it.

Agree how long evidence is kept.

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

Check available capacity and the behaviour when storage fills. Identify which records rotate, which processing may stop and who receives the warning.

Review deletion and backup behaviour together. Removing a capture from the dashboard may not remove a copy held in a backup or export.

A local report can still leave the site.

Trace downloads, printed reports, screenshots, support bundles and removable media. Each can move locally collected information beyond the monitoring system.

Before sharing, review the content, destination and authorised recipient. Keep the approved scope and handling arrangements with the export record.

Describe the difference between data remaining on the appliance and data remaining inside the site. Those are different boundaries.

Include recovery in the local design.

Identify what must be backed up to recover the installation, including configuration, required evidence and any keys needed to read protected data.

Record where the backup goes and who can restore it. An off-site backup changes the answer to what stays inside the site.

Test recovery through an approved procedure. Keep the restored data’s original observation dates distinct from the time it was imported or restored.

Check the functions without an internet route.

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

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

Document the result and the limitations. A local dashboard alone does not prove that all required functions operate without an external connection.

Updates are another boundary crossing.

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

Record the package source, intended installation, version and responsible person. Review the removable-media or transfer procedure with the site team.

The acquisition system and the monitoring appliance have different roles. Avoid creating an unreviewed internet route into production to make updates easier.

Check authenticity and applicability.

Where signed update packages are supported, verify the signature against the approved trusted key before import. Follow the documented verification process.

A hash can check consistency against a trusted reference, but a hash delivered with an untrusted file does not establish its publisher.

A valid signature does not prove compatibility or suitability. Review the package version, change notes, prerequisites and approval before applying it.

Plan the update and the way back.

Before updating, agree a backup, maintenance arrangements, validation criteria and a documented recovery or rollback option suitable for that package.

After import, confirm the installed version and check collection, job processing, storage health, access and reporting as appropriate to the change.

Keep the package identifier, verification result, operator, date and outcome. Record any interruption or limitation that affects the evidence collected.

Offline evidence still needs dates.

Separate software updates from intelligence or detection-content updates. Their release dates, import dates and operational effects may differ.

An offline installation continues using the content available to it. New external intelligence is absent until the approved update process supplies it.

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

Understand what passive observation misses.

Quiet equipment and unobserved network segments may be absent from the evidence. Encryption can hide payload detail, and unsupported protocols can limit interpretation.

Mirror overload, capture loss or a stopped processing service can also create gaps. Check collection and processing health before interpreting a quiet result.

Keep uncertain device identities and firmware versions uncertain unless the available evidence supports them. Observed communication does not prove that access was authorised.

An observation is a prompt for review.

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

The monitoring function itself does not block a command. Any separate enforcement integration needs its own explicit design, authorisation and validation.

Use alerts as evidence for investigation. Confirm the context with the plant team and follow the approved response process before changing production equipment.

Trace the paths. Check the claims.

Leave with a reviewed record of the traffic-copy path, management access, storage locations, exports, recovery arrangements and the update route.

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.

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