OT / ICS SECURITY

DTLab Control Center.

From network signals to a documented investigation.

In an industrial lab, seeing an event is only the first step. DTLab Control Center connects inventory, telemetry and evidence to operators’ work: understanding what happened, assigning a review and preserving the record.

Cybersecurity & Networks Public repository

The project at a glance

Area
Cybersecurity & Networks
Technologies
Python · FastAPI · Next.js
Status
Public repository
Explore
Code and documentation
Context
Public repository · OT/ICS lab

My contribution

I developed DTLab Control Center to connect data collection, correlation, operational interfaces, tickets and evidence. The code and revision history are public. The work began in the context of the DTLab Networking Bootcamp 2026.

Where the project begins

Context before code.

An OT/ICS environment brings together industrial devices, virtual machines and communication protocols with different needs from a typical web application. Information useful to an investigation may live in separate systems: an inventory asset, an observed network communication or a change detected on a device.

Cisco Cyber Vision remains the source for network visibility. The project adds a correlation and operational management layer, connecting those observations to VMware and endpoint signals without presenting calculated or operator-confirmed information as Cisco data. The documented setting is a lab, rather than a promise of universal protection for industrial systems.

The workflow

Design choices, one step at a time.

The project’s journey, from the initial information to what people can do.

  1. 01 Read-only collection
  2. 02 Snapshots and correlation
  3. 03 Tickets and investigation
  4. 04 Dossiers and export
01

Collect without querying devices for every screen.

Collectors gather data and publish validated snapshots. Interfaces read those snapshots instead of connecting directly to devices during rendering. This separates dashboard response time from the availability of each source.

Current, previous and last_known_good references make available versions explicit. SHA-256 hashes connect evidence to preserved content and help verify integrity; they do not constitute a digital signature identifying the author.

02

Show where a conclusion comes from.

The model distinguishes direct observations, derived values, operator-confirmed associations and unavailable information. A correlation between a virtual machine and a network asset should remain distinguishable from the original data.

Asset 360 brings together inventory, protocols, vulnerabilities, signals, tickets and evidence for the same asset. Risk received from Cisco remains separate from the project’s calculations; a degraded source continues to be visible as degraded.

03

Complement what the network sensor cannot see.

A local Modbus write may not cross the traffic capture point. The endpoint audit module observes these operations and sends authenticated events to the receiver, complementing network visibility.

Episode aggregation, a bounded spool and deduplication prevent repetition of one event from becoming an uncontrolled stream of alerts. This module complements Cyber Vision; it does not replace network sensors or modify industrial traffic.

04

Bring evidence into the operator’s workflow.

Ticketing preserves the owner, priority, status, checklists, comments and audit trail. A signal becomes work to follow through, with recurrence and exports, rather than remaining only a dashboard indicator.

Dossiers collect snapshots and manifests for later verification. Technical and public exports are separate; public exports remove operational identifiers. Continuous SIEM integration requires a configured real receiver.

Inside the project

Technology has a job to do.

Tools and components, explained through their role in the system.

VMware ESXi Cisco Cyber Vision PLC endpoint audit
Collection and correlation Validated snapshots · provenance · SHA-256 integrity
Dashboard and API Tickets and audit trail Dossiers and exports
Simplified DTLab architecture: from sources to consultation and investigation. Diagram based on the project documentation.

Python and Streamlit

Collectors, correlation services and the operational dashboard. Collection is separate from snapshot consultation.

FastAPI and Next.js

An API with authentication and roles, alongside an alternative frontend. The repository also documents a sandbox dataset for demonstrations.

SQLite and JSON contracts

Ticket persistence, data schemas and evidence manifests. Documentation covers tests, deployment and rollback.

Current state and next steps

What exists today.

I developed a lab workflow connecting collection, dashboard, endpoint detection, ticketing, evidence management and recovery procedures. Its value lies in continuity between those steps, rather than the number of charts displayed.

Code, contracts, tests and architecture documentation are available for further exploration. The use context is an OT/ICS lab.

People and documentation

Contributions and sources.

Code and documentation: Antonio Ferone. Cisco and VMware integrations are described in the project’s technical references.

Beyond the case study

Based on the public project documentation consulted on 19 October 2026. Decorative illustrations are graphic representations; real screenshots are identified in their captions.