Control of your network starts with observability.

obserae gives small and mid-sized organisations a practical way to understand actual connections, detect change and investigate incidents — using the NetFlow and IPFIX records their infrastructure already exports.

Serious network visibility, sized for the team operating it

A security product creates value only when the organisation can afford to deploy it, understand it and keep it running.

Observability

Know the network you actually operate

Name assets, reconstruct conversations and compare observed traffic with the connectivity the organisation intended.

Operability

Run one coherent application

Collection, storage, cartography, detection, investigation and alerting live in one instance, without a cluster or external data platform.

Experience

Start from needs seen in the field

A small team of cybersecurity practitioners builds obserae from direct operational feedback and the questions they need answered themselves.

Trust

Make the product understandable

The documentation explains data paths, models, algorithms, sizing assumptions, limitations and operating procedures in reviewable terms.

Observability is the foundation of network control

Security policy describes the network an organisation intends to operate. The real network changes: devices appear, temporary services become permanent, direct access bypasses an expected path, cloud destinations multiply and old rules outlive the systems they were written for.

Without observability, that gap remains an assumption. With usable network evidence, a team can ask:

  • which systems are communicating now;
  • whether that relationship was expected;
  • what changed since the last review;
  • which asset reached a suspicious destination;
  • whether the segmentation seen in traffic matches the architecture on paper.

obserae turns NetFlow and IPFIX records into named, bidirectional sessions, then adds cartography, intended-connectivity rules, enrichment, detections and investigation. The purpose is not to produce another wall of flow logs. It is to give security and infrastructure teams a common description of what the network is doing.

An NDR that fits small and mid-sized organisations

Smaller organisations face the same need to understand unexpected network activity as a large enterprise, with fewer people, less specialist infrastructure and a budget that has to compete with every other operational priority. Many do not have a SOC, a dedicated network-security team or a data-engineering platform waiting to receive another stream.

obserae is designed for that reality. It brings the NDR workflow into one application: collect the telemetry, reconstruct conversations, describe assets, model expected communications, detect exceptions, investigate and alert. A small team can deploy the whole product without first building and learning a cluster around it.

This is not an enterprise suite reduced until it fits a smaller licence. The architecture and scope were chosen from the start for organisations that need meaningful network security without turning the tool itself into an infrastructure programme.

Focused telemetry is a deliberate engineering choice

obserae natively ingests NetFlow v5/v9 and IPFIX. That is a narrower input than platforms that retain packets or combine many proprietary sensors, and the trade-off is explicit. Flow metadata does not show the contents of a file or the exact request inside an encrypted session.

It does, however, contain the network facts teams need most often: who communicated with whom, when, over which protocol and port, in which direction, how frequently and in what volume. With asset names, expected-connectivity rules and history, those facts expose new peers, suspicious destinations, segmentation drift, unusual volumes and relationships nobody declared.

Not collecting full packet content also avoids much of the CPU, memory, storage and privacy burden that deeper inspection brings. obserae can retain useful history on a small server, a VM or — for a small deployment — a Raspberry Pi with suitable storage. The sizing guide publishes the measured storage coefficients, identifies which figures are only estimates and shows how to replace them with observations from the customer’s own instance.

Simplicity is an operating and security property

The collector, hot-path processing, Parquet storage, query engine, cartography, rules, alerts and web interface run as one coherent application. obserae requires no Kafka, Elasticsearch, Redis or external SaaS platform. There are fewer components to expose, patch, monitor, upgrade and recover.

The design makes a clear availability trade-off: one instance is a single point of failure. Because obserae is passive and out of band, an outage pauses visibility and alerting but never production connectivity. For the organisations it targets, a documented backup and restore process is often more useful than operating a distributed high-availability stack they do not have the team to maintain.

The objective is not technical minimalism for its own sake. It is to keep the total cost of ownership — hardware, dependencies, upgrades and human attention — proportionate to the security value.

Built by practitioners, from questions encountered in the field

obserae is developed by a small team of cybersecurity practitioners at Spartan Conseil. Its roadmap starts with direct operational feedback, architecture reviews, investigations and the team’s own need to understand real networks — not with a checklist designed to imitate every capability in the NDR category.

That origin shapes the product. A workstation reaching a server it should never contact, a new peer, an unexplained transfer, a known malicious destination or a communication absent from the intended architecture are simple signals, but they are the signals an operator must be able to see and explain.

A focused product will not cover every scenario a large, packet-inspecting platform can address. It aims instead to make high-value network evidence deployable by teams that would otherwise have little or no continuous network visibility. The best tool for that organisation is one it can run, understand and act on.

Predictable pricing should preserve coverage

For a small business or startup, a six-figure annual security platform is often not a realistic option. A price tied to addresses, assets, sensors or flow volume can also make a future invoice hard to predict — and can discourage a team from monitoring a new subnet or exporter.

obserae publishes its prices and bases commercial bands on organisation size. Within a listed commercial edition, adding an exporter, observing more addresses or retaining more history does not change the licence price. Business, Business+ and Enterprise receive the same product capabilities; the employee band is what changes.

That model is intentional. Better coverage should improve security, not create anxiety about the next renewal. The pricing page states the annual amount, eligibility band, included capabilities and technical limits before an organisation begins an evaluation.

Transparency is part of the product

obserae is proprietary software, but it should not behave like an unexplained black box. The public documentation describes the ingestion pipeline, session reconstruction, cartography model, query language, rule evaluation, anomaly-detection methods, storage arithmetic, security controls, APIs, alert contracts, backups and failure modes.

Where a figure is measured, the documentation says how. Where it is estimated, it says that too. Detection methods are described so an operator can understand what a baseline learns, why a rule fired and which limitations remain. Releases include signatures, checksums, an SBOM and build provenance; qualified security reviewers can request source access under NDA.

Transparency also means stating the boundaries plainly:

  • native telemetry is NetFlow v5/v9 and IPFIX;
  • there is no full-packet or Layer 7 content inspection;
  • obserae detects and supplies evidence but does not block traffic;
  • the compact single-instance architecture is not a distributed HA cluster;
  • self-hosting leaves capacity, updates, access and recovery under the customer’s responsibility.

Trust is not a promise that the product has no trade-offs. It is the ability to understand those trade-offs before buying, verify them during an evaluation and operate the software without depending on sales claims.

Start with a question your network cannot answer today.

Choose one segment, send its existing flow telemetry and assess whether obserae provides useful visibility at an operating cost your team can sustain.