Start with the questions your network should be able to answer.

Keep segmentation observable

A firewall rule or architecture diagram describes intended connectivity. It does not prove that the network is still behaving that way. Temporary access can become permanent, a workstation can reach a server through an unexpected path, or a new service can bypass the boundary where controls were originally designed.

obserae’s Flow Matrix records the communications the organisation expects between named networks, groups, hosts and services. Observed sessions can then be classified as covered or unmatched.

This helps answer:

• did a user network communicate directly with a protected server zone;
• is an administration protocol appearing from an unexpected source;
• are two environments communicating even though no relationship was declared;
• did a new service or port appear on a previously understood path?

The result is evidence for a review, not automatic enforcement. obserae remains out of band and does not block traffic; firewall, NAC or response tooling keeps that responsibility.

Discover assets and relationships missing from the inventory

An inventory is only useful when it follows the infrastructure. DHCP, temporary systems, lab equipment, virtual machines and forgotten subnets make that difficult, particularly when a small team maintains both production and security.

Flow telemetry reveals active addresses and the relationships between them. obserae proposes observed networks and hosts that are absent from the cartography, so an operator can decide whether to name, classify or ignore them.

Discovery can expose:

• a device active on a subnet but absent from documentation;
• an address communicating through a network that was never modelled;
• a server exposing or consuming an unexpected service;
• a relationship that makes the role of an unknown asset easier to infer.

This is network discovery from observed communications, not an intrusive vulnerability scan. It only sees what is visible in the NetFlow or IPFIX records received from configured exporters.

Identify suspicious destinations and unexpected exposure

An encrypted connection still leaves network facts: endpoints, time, protocol, port, direction, packets and volume. obserae can enrich public destinations with cloud-provider, geography, ASN, Tor and threat-intelligence context, then make that information available to investigations and rules.

A team can review questions such as:

• which internal asset contacted an address present in an enabled threat feed;
• did a server reach a country, ASN or cloud region it does not normally use;
• is a clear-text or remote-administration service exposed on an inappropriate path;
• did an internal host begin communicating with a new public peer?

Threat intelligence is context, not a verdict. Lists can contain stale or shared infrastructure, and an unfamiliar destination is not automatically malicious. obserae retains the underlying session so the analyst can review the signal rather than act on a label alone.

Detect behavioural change without hiding the method

Some useful detections are not signatures. They are changes relative to the behaviour of a host, network or service: a new peer, an unusual number of connections, a volume that does not fit the period, or a recurring pattern that suddenly moves outside its baseline.

obserae supports explicit threshold rules and statistical baselines over saved NFQL queries. The methods are documented: moving averages, medians, deviations and dispersion measures are visible to the operator rather than presented as an unexplained score.

Typical signals include:

• a host communicating with far more peers than usual;
• a transfer volume outside its recent range;
• repeated attempts that resemble scanning or brute force;
• a service appearing at an unusual time or frequency;
• a relationship never previously observed for that entity.

Baselines still need context and time to learn. A deployment should begin with reviewable signals, observe false positives and only automate downstream response where the organisation has defined a safe procedure.

Investigate incidents with network context

During an incident, the first question is often an address. The useful questions come next: what is that asset, which systems did it contact, when did the behaviour begin, was the relationship expected, and what else happened around the same time?

obserae reconstructs bidirectional sessions and associates them with cartography names, services, rules and available enrichment. NFQL can search flows, sessions, detections and context by names rather than requiring an analyst to remember every address.

An investigation can therefore move from a single indicator to:

• the asset and network to which it belongs;
• its peers before and after the event;
• services, ports, volumes and direction;
• the intended-connectivity rule that covered the session — or the absence of one;
• other sessions matching the same question.

A useful investigation query can be saved and scheduled as an alert. Structured outputs can send the result to an existing ticketing, SIEM, SOAR or on-call workflow while the detailed flow evidence remains on the obserae instance.

Retain evidence for control reviews

Security and compliance reviews need more than a current dashboard. They need evidence that can be connected to a control, an owner and a decision.

obserae can retain configuration, cartography, intended connectivity, alert history, reports and a tamper-evident audit trail. This can support reviews of segmentation, access, change and incident handling without claiming that the product delivers compliance by itself.

The dedicated NIS2 network monitoring page maps those contributions to common programme concerns and states the boundaries explicitly. The same principle applies to other frameworks: start from the control objective, identify the evidence required, then verify whether the product produces evidence the organisation can actually use.