Universal security and network monitoring rules for everyday use

What rules should be followed to keep your network monitoring setup up-to-date

Direction arrows

Information threats continue to evolve, so it is worth revisiting a few practical rules that help keep a monitoring setup current and reliable.

None of these rules are cast in iron; they are all flexible enough to adapt to any given environment. What matters is underlying idea; the implementation is what makes them suitable for custom needs.

1. Assume nothing

Although any monitoring is based on comparison of two or more states (previous one and current one), performance value shouldn’t be judged based upon previous experience only.

For example, if a file presence is monitored, file absence doesn’t necessarily mean something is broken; file (re)appearance doesn’t, similarly, means the problem is gone.

The simplest example: assume a maintenance is run for a Web site, with most of its files being updated. While file is being updated, it can be inaccessible by File monitor (in ideal situation, dependency may be used to avoid polling for file presence while another process is being run).

However, when the file becomes available again, it still should not be assumed to be in a known-good state until it is examined. A custom script-based monitor can be used for stronger validation, such as checking file contents, checksum, or another integrity marker instead of relying on presence alone.

2. No redundancy can be in excess

This is simple one. Nothing really important may exist in single copy.

Make at least two monitoring paths: the simplest pattern is still to have a second monitoring installation watch the primary one, so you do not lose visibility when the main setup fails.

Make at least two notification paths as well. Current IPNetwork Monitor versions support both a Primary mail server (SMTP) and an Alternate mail server (SMTP), and the alternate server is used automatically if the primary one fails to send a message. SMS via GSM modem or e-mail can serve as an additional backup path when ordinary mail delivery is not enough.

For critical resources, make at least two meaningful checks. If a file must not change under normal circumstances, checking only its presence, size, or timestamp is weaker than checking its actual contents or integrity too. Likewise, for web resources, reachability alone is often not enough: current HTTP(S) monitors can also validate response content.

3. Everything changes

There’s nothing really static; everything is changed, updated, replaced. That concerns monitoring, as well.

Apart from applying updates to everything, from your system to monitoring piece of software, there might be new monitors, new external services or software pieces better matching your needs.

When one performs monitoring, it is essential to keep updated on every significant topic related to your network assets. That means you should check for new IPNetwork versions, as well. Using out-of-date software and/or reference manuals may suddenly render your monitoring setup incapable of monitoring resources.

4. Remain vigilant

Even a small changes in overall monitoring patterns may work as a side channel: it can indicate a possible threat that’s not, in fact, identified.

For example, if an HTTP(S) monitor starts showing unusual behavior, it is worth investigating promptly. In current IPNetwork Monitor versions, that can mean not only response time changes, but also unexpected response codes or failed response-text validation. That is often a stronger signal than simple reachability alone.

If those changes correspond to legitimate traffic growth, it may be time to review capacity. If they correspond to unexpected pages, redirects, or missing expected content, the cause may be a broken deployment, a routing issue, or suspicious probing activity.

Where short-lived anomalies are common, spike filters are also worth using so that one brief glitch does not create noise while repeated failures still stand out clearly.
When anything happens out of pattern, it should always be treated as suspicious.

Conclusion

What rules of thumb do you use, differing from the one above? We are eager to know – contact us.