Why Tero Separates Environments, Sensors and Decoys

Why Tero Separates Environments, Sensors and Decoys

Security infrastructure can become complicated quickly.

A company may have corporate offices, cloud networks, data centres, development environments, branch locations, and public-facing infrastructure.

Each contains different systems.

Each has different risks.

And each needs different kinds of detection.

Tero keeps that complexity manageable by separating three simple ideas:

Environment. Sensor. Decoy.

Each answers a different question.

Environment → Where is this?
Sensor      → Where does Tero run?
Decoy       → What should an attacker find?

That separation makes Tero easier to operate without forcing every part of an organization into the same model.

Environment: where are we protecting?

An Environment represents a part of your organization.

For example:

• Corporate Office
• Cloud / VPC
• Data Centre
• Branch Office
• DMZ / Edge
• Development / Test

The Environment gives Tero context.

A cloud network does not look like a corporate office.

A development environment does not look like a DMZ.

The systems an attacker expects to discover are different in each one.

By keeping environments separate, security teams can organize Tero around the way their infrastructure already exists.

You can see that broader model in One Platform, Many Environments.

Sensor: where Tero is deployed

The Sensor is the deployment point inside that environment.

It connects the environment to the Tero platform and manages the decoys deployed around it.

A customer might have:

Corporate Office
    ↓
Barcelona Office Sensor

Cloud / VPC
    ↓
Production Cloud Sensor

Development / Test
    ↓
Engineering Sensor

The Sensor gives Tero a presence inside that part of the network.

From the customer's point of view, its job is straightforward:

deploy it, keep it online, and use it to manage detection infrastructure in that location.

The customer does not need to manage every decoy as a completely independent installation.

For more on that role, read Introducing the Tero Sensor.

Decoy: what should someone discover?

The Decoy is the service presented inside the environment.

It is what an unexpected visitor can actually find and interact with.

That could be:

MongoDB
VPN Portal
SMB File Server
Kubernetes API
Redis
Internal Web
RDP
Staging Application

Different environments may need different decoys.

And one Sensor can support multiple decoys.

For example:

Cloud / VPC
    ↓
Sensor
    ├── MongoDB
    ├── Redis
    ├── Kubernetes API
    ├── Object Storage
    └── Internal API

The customer controls what appears there without having to rethink where Tero itself is deployed.

Why not combine everything?

It might seem simpler to treat an Environment, Sensor, and Decoy as one object.

In practice, that would make the product less flexible.

Imagine a company with one Cloud/VPC environment.

Today they may want:

MongoDB
Redis
Internal API

Later they may add:

Kubernetes API
Object Storage
Container Registry

The environment has not changed.

The Sensor may not need to change.

Only the detection coverage has changed.

Separating the three means Tero can grow with the customer without requiring them to rebuild the deployment every time they add another decoy.

It also makes the product easier to understand

The hierarchy gives every part of Tero a clear purpose.

Environment
Where does this belong?

Sensor
Where is Tero running?

Decoy
What is being presented for detection?

When an interaction occurs, that same structure gives the alert useful context.

Instead of seeing:

“

MongoDB activity detected.

the security team can understand:

Environment
Cloud / VPC

Sensor
Barcelona-01

Decoy
MongoDB

Activity
Database enumeration

That immediately answers more useful questions.

What was touched?

Where was it?

Which deployment observed it?

That context follows naturally into investigation.

One Sensor can support many detection opportunities

The Sensor is intentionally not tied to a single decoy.

Once deployed, it can support several services appropriate to that part of the organization.

That means the customer does not need to deploy a new agent every time they want another detection opportunity.

The model becomes:

Deploy Sensor once
        ↓
Add decoys as needed
        ↓
Expand coverage over time

That is particularly useful as Tero's decoy catalogue grows.

A company can start with a small deployment and expand the environment as its needs change.

Environments provide context without limiting choice

An Environment can help Tero understand where a Sensor belongs.

But it should not make the customer's decisions for them.

A Data Centre might commonly use database or monitoring decoys.

A Cloud/VPC might commonly use Kubernetes, Redis, or MongoDB.

A Corporate Office might commonly use VPN, SMB, or Windows services.

Those patterns can eventually help Tero recommend useful coverage.

But the security team remains in control of what it deploys.

That balance is important:

context from Tero, control for the customer.

The hierarchy follows the way security teams think

Most teams already think about infrastructure in roughly these layers.

Where does this system live?

What infrastructure operates there?

What services exist inside it?

Tero mirrors that mental model.

That means the platform can support very different organizations without forcing them into one rigid deployment structure.

A small company might have:

1 Environment
1 Sensor
4 Decoys

A larger organization could eventually have:

Multiple environments
Multiple sensors
Dozens of decoys

The operating model remains the same.

Simple structure. Broader coverage.

The separation between Environments, Sensors, and Decoys is ultimately about keeping Tero simple as coverage grows.

Environments give context.

Sensors provide the deployment point.

Decoys create the detection opportunities.

Together they let security teams expand visibility across different parts of the organization without turning every new service into another independent security deployment.

And when someone finally interacts with one of those decoys, that same structure gives the security team the context needed to understand what happened.

See what happens when someone touches a Tero decoy →

Or see the full model working together:

See Tero in action →