Yinkozi
Contact
services / SCADA / OT security

SCADA, ICS, and operational-technology security — for the networks commercial tools cannot reach.

Refinery, pipeline, generation, manufacturing, and utility control networks. Real-PLC testing in our hardware lab, custom protocol analysis, air-gapped engagement methodology. Most commercial OT-security tooling cannot run inside the customer's environment for regulatory reasons — that is precisely the work we are built for.

01 / why OT is different

You cannot test a refinery the way you test a webapp.

OT environments have rules that make IT-style penetration testing inappropriate. A scan that fingerprints a programmable logic controller can crash it. A scan that crashes a PLC can stop a turbine. A turbine that stops unscheduled is a safety incident, not a finding.

We test these systems by reading the customer's documentation, taking traffic captures from the customer's environment to our lab, replicating the relevant PLCs and field-equipment behaviour against real hardware we own, and running the offensive work against the lab — not against production. The findings come back to the customer with reproducible test conditions and remediation that respects production constraints.

Where the customer's threat model includes intentional sabotage by capable adversaries — energy, defence, water, sovereign infrastructure — the engagement extends into hardware-implant analysis and supply-chain integrity work.

Purdue Enterprise Reference Architecture — five-level model with IT/OT boundary — purdue enterprise reference architecture L 4–5 Enterprise IT ERP · email · corporate identity · cloud — traditional IT pentest scope — it / ot boundary · the line we test across L 3 Site & plant operations historian · MES · engineering workstations · jump servers L 2 Supervisory · HMI · SCADA servers control rooms · operator consoles · process visualization L 1 Control · PLCs · RTUs · SIS programmable logic · safety instrumented systems · field controllers — hardware-lab tested L 0 Process · Field equipment turbines · pumps · valves · sensors · actuators · physical reality attacker traversal · IT → OT → physical
02 / capabilities

What the work covers.

Hardware lab testing

Real PLCs, RTUs, and field equipment in our lab. Siemens, Schneider, Rockwell, ABB, Honeywell. Replication of customer environments under controlled conditions.

Industrial protocols

Modbus, DNP3, IEC 60870-5-104, IEC 61850, OPC UA, Profinet, S7. Manual protocol analysis and custom fuzzing harnesses for vendor-specific extensions.

Architecture review

Purdue-model adherence, IT/OT boundary review, jump-server design, data-diode placement, conduit and zone analysis to IEC 62443.

Engineering workstations

Engineering-station compromise paths, programming-software supply chain, project-file integrity, attack paths from corporate IT into the engineering boundary.

SIS & safety systems

Safety Instrumented System review, SIL-rated equipment exposure, Triconex / SIMATIC-S / vendor-equivalent platforms.

Remote access & vendor

Vendor-VPN review, third-party-engineer access analysis, cellular and satellite back-channels, supply-chain attack paths from vendor environments.

Wireless & field

WirelessHART, ISA100, LoRa-based field deployments, cellular field-equipment endpoints, RF-side analysis where the threat model includes it.

Detection & logging

OT-IDS evaluation (Claroty, Nozomi, Dragos), passive monitoring placement, log-pipeline integrity from field equipment, detection-rule design.

Hardware & supply chain

Firmware extraction, hardware-implant analysis, vendor-supply-chain review, air-gapped update mechanisms, signed-firmware attestation.

03 / what we don't do

The shape we don't ship.

  • No live-network scanning

    We do not run active scans against production OT environments. Active scanning crashes industrial equipment. The methodology is built around lab replication and passive observation.

  • No vendor-tool resale

    We are not a Claroty / Nozomi / Dragos reseller. We evaluate those tools in our customers' environments where appropriate; we do not have economic pressure to recommend any of them.

  • No SaaS in the data path

    Many OT environments have regulatory or sovereignty requirements that prohibit cloud-hosted analysis. Our tooling runs in the customer's environment or in our isolated lab.

  • Local LLMs do not drive control-system reasoning

    Industrial-protocol analysis depends on understanding deterministic, time-critical control behaviour — current models do not reason reliably about that, and the cost of being wrong is measured in physical damage, not findings. We do use local LLMs we run in-house to accelerate documentation review and tooling development around the engagement. Nothing about the customer's environment leaves the lab.

04 / engagement shape

Scoped to the footprint, not to a calendar.

Single-site assessment. One refinery, plant, or generation site. IT/OT boundary review, lab replication of relevant control equipment, architecture review.

Portfolio-wide review. National-scale operator, multi-site review, vendor-supply-chain analysis, custom assessment tooling for the customer's standard equipment.

Continuing OT-security engagement. Ongoing relationship as the operator's footprint evolves — new-site commissioning, new equipment integration, post-incident analysis.

Duration depends on the operator's footprint and the regulatory environment. We scope against the actual estate.

05 / start a conversation

Critical infrastructure deserves the deeper work.

email