One Platform, Many Environments

Modern organizations do not operate in a single environment. Employees work from corporate networks. Applications run in the cloud. Databases live in data centres. Remote offices connect back to central systems. Public-facing services sit at the edge. Engineering teams build and test inside development environments.

Each of those areas looks different. Each presents different opportunities for attackers. And each benefits from detection infrastructure that actually belongs there. That is why Tero is built around one platform supporting many environments. Not one generic decoy deployed everywhere. A consistent platform that can place the right believable systems in the right parts of your infrastructure.

Corporate Office

Corporate networks still contain some of the most attractive targets for attackers. Identity systems. File shares. Remote administration services. Internal applications. VPN access. A Tero Corporate Office environment can represent systems such as:

• Windows Domain Controller
• SMB File Server
• RDP
• WinRM
• VPN Portal
• Internal Web

These are services an attacker may expect to encounter after gaining access to an employee network. The goal is simple: make reconnaissance inside the office environment visible before the attacker reaches something real. A scan that finds what appears to be a file server or remote-access service can become a detection opportunity instead of just another line in a network log.

Cloud / VPC

Cloud environments create a completely different attack surface. Instead of file shares and domain controllers, an attacker may look for:

• Kubernetes APIs
• Redis
• MongoDB
• object storage
• container registries
• internal APIs

Tero's Cloud/VPC environment is designed around those expectations. The services can appear connected to the same synthetic cloud estate, giving the environment coherence rather than presenting isolated traps. An attacker discovering a database may find clues pointing toward an API. A Kubernetes workload may reference an internal registry. An application may appear to depend on Redis. That creates more opportunities to observe what the attacker chooses to investigate.

Read more in Protecting the Cloud With Decoys That Actually Belong There.

Data Centre

Data centres often contain infrastructure that is both valuable and highly trusted. Databases. Virtualization platforms. Backup systems. Storage. Monitoring. A Tero Data Centre environment can include systems such as:

• PostgreSQL
• Microsoft SQL Server
• Grafana
• vCenter
• NFS
• Backup Server

These services sit close to the kinds of assets attackers often pursue during internal reconnaissance and lateral movement. The value of a decoy here is not simply that it exists. It is that interaction with it has very little legitimate explanation. If someone begins enumerating a database or exploring a monitoring service that no production system depends on, the signal becomes immediately useful.

Branch Office

Branch offices create another challenge. They often have smaller local networks, fewer IT resources, and infrastructure that still needs to connect back to the rest of the organization. A believable Branch Office environment may include:

• File Server
• Printer / MFP
• Router / Firewall Admin
• RDP
• Internal Web
• VPN Portal

These are ordinary systems in many remote locations. That makes them useful places for detection. An attacker who begins probing local administration interfaces or remote-access services can reveal activity that may otherwise blend into normal branch traffic. Tero gives organizations a consistent way to extend detection coverage into those smaller environments without treating every site as a separate product deployment.

DMZ / Edge

The edge is where internal infrastructure meets the outside world. Web applications. Gateways. Reverse proxies. Mail services. VPN access. File transfer. A Tero DMZ/Edge environment can represent:

• HTTPS Web App
• VPN Portal
• SMTP
• SFTP
• API Gateway
• Reverse Proxy

The purpose here is different from an internal office network. The edge is expected to receive traffic. The challenge is identifying interaction that goes beyond normal public use and begins looking like exploration, enumeration, authentication testing, or attempts to move further inward. Decoys create systems where those actions can stand out more clearly.

Development / Test

Engineering environments are often rich with information. Source code. Build systems. Artifacts. Development databases. Staging applications. Internal APIs. Infrastructure configuration. For an attacker, that can be extremely valuable. A Tero Development/Test environment can include:

• Git Server
• CI/CD
• Dev Database
• Artifact Repository
• Kubernetes API
• Staging Application

These services can form a believable engineering workflow rather than existing as disconnected endpoints. A Git service can reference CI pipelines. CI can produce artifacts. Those artifacts can appear in a repository. Kubernetes can reference the same application versions. A staging application can look like the result of that deployment process. The more coherent the environment becomes, the more meaningful attacker exploration becomes.

Different environments. One operating model.

The environments change. The customer experience does not have to. Tero keeps the same core model across all of them:

Environment
    ↓
Sensor
    ↓
Decoy
    ↓
Interaction
    ↓
Evidence
    ↓
Alert
    ↓
Investigation

That consistency matters. Security teams should not need six different products to create detection opportunities across six different parts of their infrastructure. They should be able to manage them from one place.

Broad coverage without generic infrastructure

There is an important difference between supporting many environments and deploying the same thing everywhere. Tero is not broad because every Sensor exposes the same handful of services. It is broad because the platform can support infrastructure that makes sense in different contexts.

A VPN Portal makes sense in a Corporate Office. MongoDB may make sense in a Cloud/VPC. Grafana may belong in a Data Centre. A Git Server belongs naturally in Development/Test. The platform stays consistent. The decoys change with the environment. That is what makes the coverage useful.

One platform, more opportunities to detect

Attackers do not follow organizational diagrams. They move through whatever systems they can reach. Corporate networks. Cloud services. Remote offices. Development infrastructure. Public-facing systems. The more environments they explore, the more chances defenders need to recognize that activity.

Tero is designed to create those opportunities across the organization while keeping deployment and investigation centralized. One platform. Multiple environments. More places for unexpected activity to become visible.

To understand what happens once someone interacts with one of those systems, continue with:

What Happens When an Attacker Touches a Tero Decoy? →

Or see how the different environments work together:

See Tero in action →