Monitor a legacy system from the outside. Watch its network traffic, the devices it talks to, forwarded syslog or application logs, and basic availability checks. You are looking for new connections, new logins, new processes seen by neighbours, and changes in volume. No agent is needed to catch those.
Why this matters more for legacy systems
A compensating control that cannot be seen failing is not much of a control. NIST's system monitoring control asks you to monitor for attacks and indicators of potential attacks, and for unauthorized local, network and remote connections, using monitoring placed strategically within the system and at ad hoc locations to track specific transactions of interest. It describes both external monitoring at interfaces and internal monitoring of events inside the system.
For a system that cannot host software, the external side carries most of the weight.
Five places to watch
- The network boundary. Firewall logs for allowed and denied traffic to and from the host. A deny from an unexpected source is a signal. So is a sudden allow that was never there before.
- Flow data. Who talks to the system, how much, how often. Establish a baseline for a few weeks, then alert on departures.
- The access path. If you use a jump host, its logs show every administrative session.
- Whatever the system can emit. Many old systems support syslog or write local logs. OWASP recommends sending events to a centralized collection system or remote service over a secure transport, with syslog over TLS as one suggested option. If the system cannot do TLS, forward over a private hop to a collector that can.
- Neighbouring systems. Servers and devices that connect to the legacy host can log those connections from their side.
What to alert on
| Signal | Why it matters |
|---|---|
| New source address connecting | The allow list changed or a host was compromised |
| Outbound connection from the legacy host | These hosts rarely need to call out |
| Login outside the maintenance window | Possible misuse of the access path |
| Service stops or restarts unexpectedly | Possible exploit attempt or fault |
| Big change in traffic volume | Data movement or scanning |
OWASP also warns against logging everything on a checklist, since it creates alarm fog that hides real problems. Start with the five signals above and add more when an incident shows a gap.
Keep time and log integrity in order
Synchronize clocks on collectors and neighbours. OWASP says to synchronize time across servers and devices, and where that is not possible to record a confidence level for timestamps. Protect logs from tampering and restrict who can read or alter them.
Decide who reads the alerts
An alert nobody owns is noise. Name an on-call owner for the legacy system and write the first three response steps: confirm, isolate by firewall rule, call the application owner.
Try it yourself
Click through it at your own pace, or open it full screen. Step through it to see how ongoing scanning reports what changed over time.
Quick check
Is monitoring a substitute for patching?
No. Monitoring detects problems, it does not remove the flaw. Pair it with isolation and record it as one of several compensating controls.
How long should I keep the logs?
Follow your own retention policy and any obligations you have. Choose a period that lets you investigate an incident found weeks later.
Sources
- NIST SP 800-53 Rev 5 control catalog (OSCAL JSON, NIST oscal-content repository) (SI-4 System Monitoring)
- OWASP Logging Cheat Sheet
Last reviewed: 19 October 2026.
