Industrial cybersecurity investigations require more than identifying suspicious network traffic. Analysts must understand industrial protocols, interpret control commands, correlate evidence, and assess potential operational consequences.

With the growing capabilities of AI agents, I wanted to explore a practical question:

Can we equip AI agents with reusable, specialized skills to support ICS/OT cybersecurity investigations?

This led me to develop OT Security Agent Skills, an open-source project combining Python forensic tools, industrial protocol knowledge, and structured instructions for AI agents.

What’s Included?

The initial release includes eight specialized AI Agent Skills:

1. Modbus Forensics — Analyze PLC register and coil operations.

2. BACnet Forensics — Investigate building automation communications.

3. Siemens S7 Forensics — Examine PLC communications and control operations.

4. IEC-104 Forensics — Analyze SCADA telemetry and control commands.

5. OT Application Forensics — Investigate Node-RED, Grafana, InfluxDB, and MariaDB artifacts.

6. OT Evidence Normalizer — Transform forensic findings into structured evidence.

7. OT Process Analysis — Assess potential operational consequences.

8. Attack Chain Reconstruction — Reconstruct chronological IT-to-OT incident timelines.

Each skill includes a SKILL.md file for AI-agent instructions, Python analysis tools, technical references, and automated tests.

Each skill contains a SKILL.md file that guides compatible AI agents, alongside Python scripts, technical references, and automated tests.

The tools are designed for passive, offline analysis without interacting with live industrial controllers.

From Individual Tools to Agentic Investigations

The broader vision is to create an investigation workflow where an AI agent can select appropriate capabilities based on the evidence.

For example, an analyst investigating suspicious PLC communications could use a protocol forensic skill to extract relevant operations, normalize those findings, and pass them to process-analysis and attack-chain reconstruction tools.

The goal is to move from isolated scripts toward reusable, evidence-driven investigation capabilities.

Currently, the skills provide standalone analysis and selected cross-skill integrations. Fully autonomous investigation and orchestration remain future development goals.

Why Open Source?

Industrial cybersecurity benefits from shared knowledge, reproducible research, and collaboration.

By publishing these skills, I hope to encourage researchers, incident responders, and OT engineers to experiment with AI-assisted investigation techniques, validate the tools, and contribute improvements.

This is an experimental v0.1 release, not a production-ready incident-response solution. The results require independent verification, particularly when assessing industrial process impacts.

Explore the Project

The complete collection is available on GitHub:

OT Security Agent Skills — GitHub

Feedback, technical testing, and contributions from the ICS/OT cybersecurity community are welcome.

The objective is straightforward: use AI to strengthen industrial cybersecurity investigations while keeping evidence, operational safety, and human expertise at the center.

Dr. Sulaiman Alhasawi
ICS/OT Cybersecurity Researcher

NIST recently released the Initial Public Draft of SP 800–82 Rev. 4, Guide to Operational Technology (OT) Security.

I went through the new revision mainly with one question in mind:

What has actually changed from Rev. 3, and what should OT practitioners pay attention to?

This is not a completely new OT security model.

It is more of an evolution.

Rev. 4 brings SP 800–82 closer to NIST Cybersecurity Framework 2.0, strengthens governance and enterprise risk management, expands practical guidance around asset visibility and monitoring, and gives more attention to modern OT architectures and Zero Trust principles.

NIST also continues to emphasize something very important for anyone working in OT:

security controls and security testing must respect operational requirements, reliability, and safety.

The biggest change: CSF 2.0 and GOVERN

One of the clearest changes is the alignment with NIST CSF 2.0.

The familiar functions are now:

Govern → Identify → Protect → Detect → Respond → Recover

For OT, I think the addition and stronger emphasis on Govern is important.

Cybersecurity in industrial environments cannot remain only a technical discussion between engineers and security teams.

It has to connect with:

• business objectives
• operational risk
• responsibilities and accountability
• supply chain
• investment decisions
• enterprise risk management

This is an important direction.

A firewall, IDS, EDR platform, or segmentation project is not the objective by itself.

The real question is:

What operational risk are we trying to reduce?

Rev. 4 makes this connection much clearer.

OT continues to expand beyond traditional ICS

Rev. 3 already made an important change by moving from an ICS-centered view toward the broader term Operational Technology.

Rev. 4 continues in that direction.

NIST now explicitly discusses environments including industrial control systems, building automation and control systems, water and wastewater, transportation, maritime systems, Industrial Internet of Things, and cloud-connected OT environments.

This matters because OT security is no longer only about PLCs inside a refinery or manufacturing plant.

Cyber-physical systems are everywhere.

And the boundary between traditional IT, OT, IIoT, and cloud services continues to become less clear.

More emphasis on knowing what you actually have

Another useful improvement is the expanded guidance around asset management, network monitoring, and detection.

This sounds basic, but it remains one of the biggest practical problems in OT security.

Before asking:

How do we protect the environment?

we still need to answer:

What exactly is in the environment?

Rev. 4 provides more guidance around asset visibility and monitoring and recognizes the different approaches that may be required in operational environments.

It also expands guidance around network monitoring and detection.

For defenders, this reinforces the importance of understanding normal communications, asset relationships, network architecture, and what is happening between different parts of the OT environment.

Zero Trust comes further into OT

Rev. 4 also provides more guidance on applying Zero Trust principles to OT.

This should not be interpreted as taking an enterprise Zero Trust architecture and simply dropping it into a plant.

Many OT devices cannot support the same identity, authentication, endpoint, or policy technologies we expect in modern IT environments.

Instead, the principles become more interesting:

limit access, reduce unnecessary trust, control privileged access, segment systems, authenticate where possible, and continuously monitor communications.

The technology used to achieve this may be different in OT.

The principle is still useful.

NIST specifically identifies security architecture guidance around protecting management functions and applying Zero Trust principles as one of the important additions to Rev. 4.

What does Rev. 4 say about penetration testing?

This part caught my attention because I have been spending more time recently on OT penetration testing.

Rev. 4 does not introduce a new OT penetration testing methodology.

But it reinforces an important distinction between traditional IT penetration testing and testing industrial environments.

NIST says penetration testing can be used as part of vulnerability assessment, provided that the testing does not adversely impact the production environment.

That qualification is critical.

OT systems can have timing constraints, limited resources, legacy equipment, and direct interaction with physical processes.

A technique that is routine in IT may have very different consequences inside OT.

NIST therefore recommends caution when performing penetration testing on operational systems.

Where possible, testing may be performed using:

replicated, virtualized, or simulated systems.

Testing of production systems may sometimes need to be coordinated with planned outages or other operational windows.

NIST also highlights another important point:

effective OT penetration testing requires OT-specific knowledge and skills.

That is something I think deserves much more attention as interest in OT penetration testing grows.

Knowing Kali Linux, Metasploit, Nmap, or industrial protocol tools is not enough.

The tester needs to understand the environment being tested and the possible operational consequences of the test.

This reminded me of Duggan’s 2005 paper

This section of Rev. 4 immediately reminded me of an article I recently wrote about the 2005 Sandia report “Penetration Testing of Industrial Control Systems” by David Duggan and his colleagues.

The paper was published more than 20 years ago.

Interestingly, much of the terminology we use today was not yet established in the same way.

The industry was not having today’s discussions around “OT security,” “Zero Trust for OT,” or modern cyber-physical security programs.

But the core testing problem was already very clear.

Duggan and his colleagues were already discussing the fact that penetration testing industrial control systems is different because the tester must consider the consequences to the process itself.

That makes Rev. 4 an interesting follow-up.

The technology has changed.

The architectures have changed.

The frameworks have matured.

The terminology has changed.

But the basic principle remains:

You cannot test an industrial environment exactly like a normal IT network.

Twenty years later, NIST is still emphasizing the same operational reality, but now within a much broader OT cybersecurity framework.

For me, there is an important lesson here for penetration testers entering OT.

The goal is not to prove how aggressive your tools can be.

The goal is to understand security weaknesses without allowing the security test itself to become an operational incident.

My main takeaway

If I had to summarize the evolution:

Rev. 2: Secure ICS.

Rev. 3: Think broader — secure OT.

Rev. 4: Connect OT cybersecurity more closely with governance, enterprise risk, visibility, modern architecture, monitoring, and CSF 2.0.

And for penetration testers, the message remains consistent with what researchers were already saying two decades ago:

understand the process before you test the technology.

That may sound obvious.

In OT, it is fundamental.

One final point: Rev. 4 is currently an Initial Public Draft, published on September 21, 2026. NIST is accepting public comments until November 30, 2026, so the final version may still change.

Want to go deeper into OT security and penetration testing?

If you are new to OT security and want a practical introduction, you can start with my OT security fundamentals and penetration testing course, where I introduce the OT environment and basic hands-on testing using LabShock:

https://alhasawi.gumroad.com/l/OT-P2P

I am also developing a more detailed Practical OT/ICS Penetration Testing course covering OT architecture, scoping and rules of engagement, industrial protocols, enumeration, vulnerability assessment, and safe penetration testing techniques.

If you are interested in joining the next cohort, you can register here:

https://forms.gle/EyjHPzMwaKLqxBok8

References

NIST, SP 800–82 Rev. 4 — Guide to Operational Technology (OT) Security, Initial Public Draft, September 2026.

David P. Duggan, Michael Berg, John Dillinger, and Jason Stamp, Penetration Testing of Industrial Control Systems, Sandia National Laboratories, 2005.

Penetration Testing Industrial Control Systems: A 2005 Paper That Still Reads Like Modern OT Security Guidance

In cybersecurity, a paper written more than twenty years ago can easily feel obsolete. Tools change, architectures evolve, terminology changes, and threats become more sophisticated.

But Sandia National Laboratories’ 2005 paper, “Penetration Testing of Industrial Control Systems,” by David P. Duggan, Michael Berg, John Dillinger, and Jason Stamp, is surprisingly different.

The report was published in March 2005. Duggan-07 Yet much of its advice could appear in an OT penetration-testing methodology written today.

What makes it particularly interesting is not the tools it mentions. It is the mindset behind the testing.

Before “OT Security” Became the Language We Use Today

There is an interesting historical detail here.

The report uses Industrial Control Systems (ICS) in its title, but inside the paper the authors largely speak in terms of SCADA, EMS, DCS, PCS, and industrial control systems. Duggan-07

What we now commonly discuss as the broader discipline of OT cybersecurity was not yet expressed using today’s mature OT-security vocabulary.

There was no modern ecosystem of “OT security platforms,” “OT SOCs,” “OT EDR,” “attack-path management,” or the extensive commercial OT-security market we know today.

Yet the fundamental problem was already clearly understood:

Industrial systems are not simply another type of IT system.

That principle runs through the entire paper.

And twenty-one years later, it remains one of the most important lessons for anyone performing security assessments or penetration testing in industrial environments.

The Physical Process Changes Everything

The paper begins with a warning: penetration testing an industrial control system should not be taken lightly.

Why?

Because these systems control real-world equipment and processes.

Incorrect instructions can result in waste, damaged equipment, injuries, or even death. Duggan-07

The authors provide three striking examples.

During a ping sweep of a SCADA network controlling nine-foot robotic arms, one of the arms unexpectedly activated and rotated 180 degrees. Fortunately, the person in the room was outside its reach.

In another case, a ping sweep on a process-control network caused a semiconductor manufacturing system to hang, destroying approximately $50,000 worth of wafers.

And in a third case, an IT security consulting company performing a corporate penetration test crossed into a network directly connected to SCADA. The testing locked up the SCADA system and prevented a gas utility from sending gas through its pipelines for four hours. Duggan-07

These stories are over twenty years old.

But the lesson could be printed on the first slide of an OT penetration-testing course today:

The security test itself can become a process hazard.

IT Pentesting Logic Cannot Simply Be Copied into OT

Traditional penetration testing tends to encourage interaction.

Discover the hosts.

Scan the ports.

Enumerate the services.

Identify vulnerabilities.

Exploit where permitted.

In a conventional IT environment, an unstable server might be restarted or restored. Industrial systems are different because their actions interact directly with physical processes, some of which are time-critical. Duggan-07

The Sandia paper therefore asks an excellent question before discussing tools:

Why is penetration testing necessary for this system?

The authors suggest first understanding the threats being investigated. Are we concerned about malicious people, rogue hosts, accidental actions, or something else? More importantly, will penetration testing actually identify vulnerabilities relevant to those threats? Duggan-07

I think this remains extremely relevant.

Sometimes security teams begin with:

“What can we scan?”

The better question is:

“What are we trying to learn, and what is the safest way to learn it?”

That is a very different mentality.

Passive Before Active

One of the strongest parts of the paper is the table comparing normal IT penetration-testing techniques with preferred approaches for SCADA environments.

Instead of immediately using a ping sweep to discover systems, the authors recommend alternatives such as examining switch CAM tables, router configurations and routing tables, physically tracing connections, and passively listening to network traffic.

Instead of port scanning operational devices, they suggest local port verification or scanning duplicate, development, or test systems.

Instead of running vulnerability scanners directly against production systems, they suggest obtaining version information locally, comparing it against known vulnerabilities, or scanning representative test equipment. Duggan-07

The principle behind the table is more important than the individual techniques:

Avoid generating unnecessary traffic against an operational industrial system.

The authors explicitly argue that traditional penetration-testing activities are only one way of obtaining the required information. Less intrusive approaches can often provide much of the same knowledge without introducing unnecessary operational risk. Duggan-07

Today we might describe this using terms such as passive asset discovery, safe assessment, representative testing, offline analysis, digital twins, testbeds, or controlled validation.

The technology has evolved.

The principle has not.

Operations Must Be Part of the Security Test

Another sentence deserves attention.

The paper says operations personnel must know when testing is occurring and must be prepared to respond immediately if something goes wrong. If manual control is possible, personnel capable of taking manual control should be present during security testing. Duggan-07

This is remarkably close to what we now consider good OT penetration-testing governance.

An OT pentest is therefore not merely:

Pentester → Network → Target

It is closer to:

Security + Operations + Engineering + Process Knowledge + Safety + Testing

The tester needs to understand not only whether an action is technically possible, but also what that action might mean to the process.

Legacy Systems Were a Problem Then — and They Still Are

The report also discusses another familiar OT problem: longevity.

Industrial systems can remain operational far longer than normal IT systems. Consequently, processors may be generations behind contemporary hardware, networks may operate at relatively low speeds, and active testing can overwhelm devices or network stacks. Duggan-07

Again, this sounds remarkably contemporary.

Twenty-one years later, security professionals still encounter legacy controllers, old operating systems, fragile protocol implementations, long equipment lifecycles, unsupported components, and devices that cannot safely tolerate aggressive scanning.

Modern tools may be better at recognizing industrial equipment and controlling scan intensity.

But “safer scanner” does not mean “safe under every process condition.”

Understanding the system still comes before touching it.

The IT/OT Connectivity Problem Was Already Visible

The paper also recognized the architectural tension that continues today.

Complete separation between SCADA and IT systems offers strong protection from external influences, the authors argue, but complete separation is often impractical because industrial information is required for business decisions.

Their answer was therefore to develop secure mechanisms for exchanging information while avoiding unnecessary direct connectivity between IT and SCADA components. Duggan-07

Today the architecture is much more complicated.

We have cloud connectivity, historians, remote vendors, IIoT, edge computing, remote operations, analytics platforms, AI systems, and increasingly interconnected supply chains.

But the architectural question remains almost identical:

How do we obtain the business value of connectivity without allowing that connectivity to create uncontrolled paths into the industrial process?

The technology surrounding the problem has changed dramatically.

The fundamental problem has not.

What I Think This 2005 Paper Gets Right

For me, the most valuable lesson in this short report is that OT penetration testing is not primarily about pentesting tools.

It is about consequence-aware testing.

The paper essentially tells the tester:

Understand what you are testing.

Understand why you are testing it.

Understand the process behind it.

Understand what your traffic could do.

Prefer passive information gathering when possible.

Use test or duplicate systems where practical.

Coordinate with operations.

And never allow the security assessment itself to become the incident.

The report closes with a memorable warning: no security tester wants to become known as the person who turned off the lights in a city, flooded a valley, or released toxic chemicals. Duggan-07

That may have been written in 2005.

It could just as easily have been written in 2026.

Twenty-One Years Later

Reading old cybersecurity research is useful because it helps distinguish between problems created by today’s technology and fundamental engineering problems that technology has never solved.

This paper belongs to the second category.

We now have better OT visibility tools, better asset identification, specialized industrial IDS platforms, improved vulnerability intelligence, sophisticated testbeds, threat intelligence, IEC 62443 practices, MITRE ATT&CK for ICS, and much greater awareness of industrial cybersecurity.

But a modern OT penetration tester still needs to answer essentially the same question Sandia was asking in 2005:

Can I obtain the security information I need without creating unacceptable risk to the physical process?

Perhaps that is the most important takeaway.

In IT penetration testing, we often think first about what a system will allow us to do.

In OT penetration testing, we should first think about what the process can safely allow us to do.

That distinction was understood more than two decades ago.

It is still worth teaching today.

Want to Get Started with OT Penetration Testing?

If you’re new to OT/ICS security and want to understand the basics before going deeper, I have a practical introductory course covering the fundamentals of OT cybersecurity and OT penetration testing, including hands-on exposure using LabShock.

It’s a good starting point for understanding how OT pentesting differs from traditional IT pentesting and how to approach industrial environments safely.

Start with the basic course:
OT/ICS Penetration Testing Basics

If you’re interested in joining my upcoming OT/ICS Penetration Testing course, register your interest below. I’ll notify you when the next course details, dates, and registration information are available.

Register your interest:
OT/ICS Penetration Testing Course Registration

Reference

Duggan, D. P., Berg, M., Dillinger, J., & Stamp, J. (2005). Penetration Testing of Industrial Control Systems. Sandia National Laboratories, SAND2005–2846P, March 2005. Duggan-07

Operational Technology penetration testing is difficult to teach realistically.

A real industrial environment may contain programmable logic controllers, human-machine interfaces, engineering workstations, SCADA servers, industrial protocols and physical processes. Testing these systems is fundamentally different from testing a conventional IT network.

In IT penetration testing, an aggressive scan or failed exploit might crash a server. In OT, a poorly chosen command could interrupt production, stop equipment, affect product quality or create a safety risk.

Students therefore need practical experience, but we cannot give beginners unrestricted access to a live factory. The solution is not to replace practical training with presentation slides. It is to create a safe and controlled environment in which students can use the tools, inspect the traffic, execute selected techniques and observe their effects.

This is the objective of my planned hands-on OT/ICS penetration testing course.

Two separate groups are planned: one delivered in Arabic and another delivered in English.

A Course Focused on Penetration Testing

This is not intended to be a general OT cybersecurity course covering every defensive technology, governance framework and compliance requirement.

Its focus is the practical OT penetration testing workflow:

Scoping → reconnaissance → enumeration → vulnerability identification → controlled exploitation → evidence collection → reporting

Students will work with a simulated OT environment through LabShock, supported by packet captures, Wireshark exercises and selected penetration testing tools.

A simulated environment cannot reproduce every condition found inside a factory. However, it can provide meaningful experience with the technologies, decisions and risks encountered during an OT security assessment.

The objective is not to teach students how to press buttons in an automated tool. They should understand what they are testing, why they are testing it and what effect their actions could have.

Understanding the OT Target

Before testing an industrial system, students must understand what they are looking at.

They will learn the roles of common OT components, including:

• Programmable Logic Controllers
• Human-Machine Interfaces
• Engineering workstations
• SCADA and supervisory systems
• Industrial communication protocols
• The physical or simulated process being controlled

This understanding matters because an OT penetration tester is not simply attacking an IP address.

A command sent to a controller might start a motor, change a setpoint, open a valve or stop part of an industrial process. The tester must understand the relationship between the cyber asset and the physical process before performing any active test.

Scope, Authorization and Safety

A professional OT penetration test begins before the first packet is transmitted.

Students will learn how to define:

• The systems included in the assessment
• The systems that must not be tested
• Permitted and prohibited techniques
• Approved testing periods
• Scan-rate and intensity restrictions
• Operational stop conditions
• Evidence and reporting requirements
• Restoration and cleanup procedures

These decisions are not administrative details. They are part of the technical methodology.

A technique that is safe in a simulated lab is not automatically safe against a production PLC. Real-world testing requires written authorization, coordination with plant operations and an understanding of the potential operational consequences.

Passive Reconnaissance and Traffic Analysis

Packet captures and Wireshark will remain important parts of the course.

Students will inspect industrial network traffic to identify:

• Communicating devices
• Client-server and master-slave relationships
• Industrial protocols
• Frequently accessed functions or registers
• Read and write operations
• Potentially sensitive or dangerous commands
• Normal communication patterns

This develops the ability to learn about an OT environment without immediately transmitting packets to industrial devices.

In a real assessment, passive analysis can help the penetration tester build an initial asset and communication map before deciding whether active testing is appropriate.

Students will not merely open a PCAP and follow prepared instructions. They will be expected to explain what the packets reveal about the devices, communications and controlled process.

Controlled Active Discovery

Students will use tools such as Nmap inside the isolated lab to discover hosts, ports and exposed services.

The objective is not merely to memorize scanning commands. Students must understand:

• Why the scan is being performed
• Which targets are authorized
• Which ports and protocols should be examined
• How aggressive the scan should be
• What the returned information means
• How to validate the result
• Why the same scan may be inappropriate in production

Students will compare active discovery results with information obtained from passive traffic analysis.

This helps them understand both the value and limitations of active scanning in OT environments.

Industrial Protocol Testing

The primary practical industrial protocol will be Modbus/TCP.

Students will learn to:

• Identify Modbus devices
• Understand common function codes
• Discover Unit IDs
• Read coils and registers
• Interpret returned values
• Perform authorized write operations
• Observe changes in the simulated process
• Validate the operation through Wireshark

EtherNet/IP may also be included where supported by the available lab scenarios.

Other industrial protocols can be introduced through packet captures or demonstrations. However, I do not want to claim hands-on coverage of a protocol unless students can personally interact with a functioning target.

Developing practical depth in one or two protocols is more valuable than claiming superficial coverage of many.

Testing HMIs and Supporting Systems

OT penetration testing is not limited to communicating directly with PLCs.

Industrial environments also contain web interfaces, Windows systems and supporting network services. These systems can provide an attack path toward the control environment.

Depending on the available scenarios, students may practise:

• Enumerating industrial web interfaces
• Identifying exposed management services
• Testing weak or default credentials
• Performing banner and service fingerprinting
• Researching known vulnerabilities
• Validating suitable vulnerabilities inside the lab
• Following a controlled attack path toward an OT asset

This helps students understand that an attacker may reach a controller through weaknesses in supporting systems rather than attacking the PLC directly from the beginning.

Controlled Process Manipulation

One of the most important learning moments is seeing the relationship between a cyber command and its physical consequence.

Inside the controlled environment, students may perform an authorized action such as changing a register, modifying a setpoint or changing the state of a simulated actuator.

The objective is not simply to “turn something off.” Students must document:

• The target asset
• The command or function used
• The original process state
• The resulting process change
• The relevant network evidence
• The possible operational consequence
• The required restoration procedure

This transforms exploitation from a technical trick into a meaningful OT penetration testing finding.

It also teaches students that demonstrating control over an industrial process carries greater responsibility than obtaining a shell on a conventional computer.

Practical Tools

The course will use a focused set of tools and environments, potentially including:

• LabShock
• Kali Linux
• Wireshark
• Nmap
• Shodan
• SearchSploit and ExploitDB
• Selected Python scripts
• Metasploit where an appropriate lab target exists
• Selected OT assessment tools whose results can be manually validated

Every tool must serve a clear assessment objective.

The course will not measure success by the number of tools installed. The important skill is selecting an appropriate tool, understanding what it does, validating its results and recognizing the possible consequences of using it.

Evidence Collection

Finding a vulnerability is only one part of a professional penetration test.

Students will learn to collect reproducible evidence, including:

• Commands and tool output
• Screenshots
• Relevant packets
• Timestamps
• Affected assets
• Before-and-after process states
• Steps required to reproduce the result

Good evidence should allow another qualified assessor to understand what was tested, confirm the result and evaluate its importance.

Students must also distinguish between identifying a potential weakness and proving that it is exploitable. Automated tool output alone should not be treated as conclusive evidence.

Reporting the Findings

The final stage of the course will convert technical observations into a penetration test report.

A finding should explain:

• What weakness was identified
• Which asset or service was affected
• How the weakness was validated
• What evidence supports the conclusion
• How an attacker could use it
• What the possible operational or process consequence might be
• How the organization could remediate it

A limited MITRE ATT&CK for ICS mapping may be used to improve the report and describe the demonstrated attack path. However, framework mapping will support the penetration test rather than become the main subject of the course.

The final deliverable should communicate clearly with both technical and non-technical stakeholders.

What the Course Can — and Cannot — Provide

A simulated course can provide genuine hands-on experience with:

• OT reconnaissance
• Industrial traffic analysis
• Asset and service enumeration
• Industrial protocol testing
• HMI and supporting-system testing
• Controlled process manipulation
• Evidence collection
• Technical penetration test reporting

It can prepare students to participate in an authorized OT penetration test, particularly under the guidance of an experienced assessor.

It cannot reproduce every vendor, protocol, physical process or operational constraint present in a real factory. It also cannot qualify someone to independently test a live production plant immediately after completing the course.

Real-world OT penetration testing additionally requires site-specific preparation, engineering knowledge, written authorization, operational coordination, safety awareness and professional experience.

Being honest about this limitation does not reduce the course’s value. It clarifies its purpose: building a practical foundation that students can develop further through supervised experience.

The Intended Outcome

By the end of the course, students should be able to conduct an end-to-end penetration test against a simulated OT environment:

1. Understand the target architecture and controlled process.
2. Define the assessment scope and restrictions.
3. Analyze industrial network traffic.
4. Discover and enumerate exposed systems.
5. Test selected vulnerabilities safely.
6. Execute a controlled industrial protocol action.
7. Observe and document its process effect.
8. Collect defensible evidence.
9. Restore changes made during testing.
10. Produce a clear technical penetration test report.

The goal is not to produce students who can run the largest number of tools.

The goal is to develop practitioners who understand what they are testing, why they are testing it, what their actions could affect and how to communicate the results professionally.

That is the practical bridge between an OT cybersecurity lab and participation in a real-world OT penetration testing engagement.

Interested in Joining?

Two separate course groups are planned:

• An Arabic-language group
• An English-language group

If you are interested in joining, please register your interest using the following form:

Register your interest in the OT/ICS Penetration Testing Course

After registering, you will receive a follow-up email when information about the course dates, price, delivery format and registration process becomes available.

Submitting the form expresses your interest and helps organize the appropriate language groups. It does not require an immediate commitment.

Remote access has become one of the biggest challenges in OT and ICS environments.

Industrial facilities often require vendors, engineers, system integrators, and support teams to remotely access:

• HMIs
• engineering workstations
• historians
• Windows servers
• Linux systems
• virtualization platforms

In many environments, this access was introduced years ago using:

• traditional VPNs
• exposed RDP services
• shared accounts
• unmanaged remote access tools
• direct vendor connectivity into OT networks

While these methods may solve operational problems, they can also introduce major cybersecurity risks inside industrial environments.

Apache Guacamole is an open-source browser-based remote access gateway that offers a different approach. Instead of exposing systems directly to external users, it centralizes remote access through a web interface while supporting authentication integration, auditing, access restrictions, and session management capabilities.

In this article, we will look at how Apache Guacamole can help address common OT remote access challenges through features such as:

• Browser-based remote access
• Multi-factor authentication (MFA)
• LDAP / Active Directory integration
• Single Sign-On (SSO)
• Connection-level access control
• Session recording and auditing
• Clipboard and file transfer restrictions
• Brute-force protection
• Secure DMZ and jump-host deployment architecture

It is important to understand that Apache Guacamole is not:

• a firewall
• a segmentation platform
• a PAM solution
• a replacement for OT security architecture

It should be treated as a controlled remote access broker inside a properly segmented environment.

Browser-Based Remote Access

One of the common operational issues in OT environments is dependency on unmanaged remote access software.

Many vendors still rely on:

• standalone RDP clients
• SSH clients
• VNC software
• TeamViewer
• AnyDesk
• third-party remote support tools

Apache Guacamole provides browser-based remote access through its HTML5 web interface and guacd service.

Supported protocols include:

• RDP
• SSH
• VNC
• Telnet (legacy environments)

Relevant components:

• guacd
• guacamole.war

Relevant configuration:

guacd-hostname: localhost
guacd-port: 4822

Instead of this:

Vendor Laptop
     ↓
VPN
     ↓
Direct RDP Access
     ↓
Engineering Workstation

Organizations can move toward:

Vendor
     ↓
Browser
     ↓
Guacamole
     ↓
Approved Internal System

This helps organizations centralize and control remote access sessions while reducing unmanaged software inside the environment.

Multi-Factor Authentication (MFA)

Weak authentication and shared accounts remain common issues in industrial environments.

Apache Guacamole supports MFA using authentication extensions.

Supported MFA extensions include:

• guacamole-auth-totp
• guacamole-auth-duo
• guacamole-auth-sso-saml
• guacamole-auth-sso-openid

Example TOTP configuration:

totp-issuer: OT-Remote-Access
totp-digits: 6
totp-period: 30

Example Duo configuration:

duo-api-hostname:
duo-integration-key:
duo-secret-key:
duo-application-key:

This allows organizations to strengthen authentication security for remote vendor and engineering access.

LDAP and Active Directory Integration

Managing remote access accounts independently across OT systems becomes difficult over time.

Apache Guacamole supports LDAP and Active Directory integration using:

guacamole-auth-ldap

Relevant configuration examples:

ldap-hostname:
ldap-port:
ldap-user-base-dn:
ldap-search-bind-dn:
ldap-search-bind-password:
ldap-username-attribute:

This allows organizations to:

• centralize identity management
• integrate with Active Directory
• apply role-based access
• remove access centrally
• reduce unmanaged local accounts

Single Sign-On (SSO)

Many organizations want remote access integrated into existing enterprise identity systems.

Apache Guacamole supports SSO extensions including:

• SAML
• OpenID Connect
• CAS

Relevant extensions:

• guacamole-auth-sso-saml
• guacamole-auth-sso-openid
• guacamole-auth-cas

Example SAML configuration:

saml-idp-url:
saml-entity-id:
saml-callback-url:
saml-strict: true

Example OpenID configuration:

openid-authorization-endpoint:
openid-jwks-endpoint:
openid-issuer:
openid-client-id:
openid-client-secret:
openid-redirect-uri:

This helps organizations integrate centralized authentication workflows into remote access infrastructure.

Connection-Level Access Control

A common OT security problem is excessive vendor access inside industrial networks.

Apache Guacamole supports:

• connection permissions
• user groups
• connection groups
• role-based access management

Database-backed access control is supported using:

• guacamole-auth-jdbc-mysql
• guacamole-auth-jdbc-postgresql

This allows organizations to restrict which systems each user may access instead of providing unrestricted network-level access.

Clipboard and File Transfer Restrictions

File transfer and clipboard access can introduce operational and security risks inside OT environments.

Apache Guacamole supports restricting:

• clipboard usage
• copy/paste operations
• drive redirection
• file transfers

Relevant configuration examples:

disable-copy=true
disable-paste=true
enable-drive=false

This can help reduce:

• malware introduction
• unauthorized tool uploads
• accidental file movement
• uncontrolled data transfers

Session Recording and Auditing

One of the major issues in OT remote access environments is the lack of visibility into vendor activity.

Apache Guacamole supports:

• session history
• audit logging
• session recording
• connection tracking

Recording configuration examples:

recording-path:
/var/lib/guacamole/recordings

create-recording-path=true

SSH recording support:

typescript-path:

Database audit history tables include:

• guacamole_connection_history
• guacamole_user_history

This helps organizations improve:

• accountability
• auditing
• compliance
• incident investigations
• operational visibility

Instead of relying entirely on trust, organizations gain the ability to review and investigate remote sessions when required.

Browser-Based Clientless Access

Apache Guacamole uses:

• an HTML5 frontend
• WebSocket tunneling

No additional client software is required on the endpoint.

Reverse proxies must support:

Upgrade: websocket

This helps reduce dependency on unmanaged remote access software installed on vendor systems.

SSL/TLS Enforcement

Remote OT access should always use encrypted communications.

Apache Guacamole deployments commonly use reverse proxies such as:

• Nginx
• Apache HTTP Server

Example TLS configuration:

server {
    listen 443 ssl;
    ssl_certificate ...
    ssl_certificate_key ...
}

Relevant Guacamole proxy settings:

proxy-hostname:
proxy-port:

This helps protect:

• remote sessions
• credentials
• authentication traffic

Brute-Force Protection

Internet-facing remote access systems are commonly targeted by password attacks.

Apache Guacamole supports brute-force protection using:

guacamole-auth-ban

Relevant configuration examples:

ban-address-duration: 300
ban-max-invalid-attempts: 5
ban-max-attempts-per-interval: 5
ban-login-failure-window: 60

This helps reduce automated login attack attempts against remote access portals.

Database-Backed Centralized Administration

Apache Guacamole supports centralized administration using:

• MySQL
• PostgreSQL

Supported extensions:

• guacamole-auth-jdbc-mysql
• guacamole-auth-jdbc-postgresql

Example MySQL configuration:

mysql-hostname:
mysql-port:
mysql-database:
mysql-username:
mysql-password:

Example PostgreSQL configuration:

postgresql-hostname:
postgresql-port:
postgresql-database:
postgresql-username:
postgresql-password:

This helps organizations centralize:

• users
• permissions
• audit data
• connection management

Secure DMZ and Jump-Host Architecture

One of the most dangerous mistakes in OT environments is exposing RDP or engineering systems directly to the internet.

Apache Guacamole should not provide unrestricted access directly into industrial networks.

A more controlled deployment model places Guacamole behind:

• reverse proxies
• firewalls
• DMZ environments
• jump hosts

This approach helps organizations:

• centralize remote access
• reduce direct exposure of OT assets
• apply segmentation boundaries
• monitor vendor sessions
• restrict reachable systems

instead of exposing engineering systems directly to external users.

Suggested deployment diagram:

Open Source and Operational Control

Many organizations are increasingly exploring open-source technologies to improve operational control and reduce dependency on proprietary ecosystems.

Open-source platforms provide:

• self-hosted deployment flexibility
• visibility into configurations
• integration freedom
• reduced vendor lock-in
• deployment customization

For OT environments, this becomes especially valuable when organizations require greater operational ownership over their remote access infrastructure.

Final Thoughts

Remote access is now a normal operational requirement in many industrial environments. The challenge is making it secure, controlled, and operationally manageable.

Apache Guacamole provides multiple features that can help organizations improve centralized remote access management in OT and ICS environments when deployed correctly.

These capabilities include:

• browser-based access
• MFA
• LDAP/AD integration
• SSO
• session recording
• access restrictions
• brute-force protection
• centralized administration
• segmented deployment architectures

Like any security technology, proper architecture and operational controls remain critical.

Guacamole should not be viewed as:

• a magic security product
• a replacement for segmentation
• a replacement for firewalls
• a replacement for OT security architecture

Instead, it should be treated as a controlled remote access broker operating inside a properly designed OT environment.

At ZeroNtek, we help organizations worldwide design and deploy secure open-source solutions for both OT and IT environments.

This includes:

• secure remote access architectures
• OT segmentation guidance
• logging and monitoring integration
• open-source OT security deployments
• hardening and operational support

We strongly believe open-source technologies can play an important role in building more transparent, flexible, and sovereign security environments for critical infrastructure and industrial operations.

References

• Apache Guacamole Official Website
• Apache Guacamole Configuration Guide

A person I know recently faced a serious issue at work: important documents became inaccessible because the Microsoft Office subscription had expired, while the files still contained critical operational data.

I advised him to try LibreOffice and explained the concept of open-source software — that there are powerful alternatives which give users more freedom, flexibility, and control over their own data without being fully dependent on licensing restrictions or a single vendor ecosystem.

After switching to LibreOffice, he was able to open his files and continue working without interruption.

This goes beyond office software. It reflects a much larger conversation around digital sovereignty, ownership, and operational resilience.

In OT/ICS environments, overdependence on closed ecosystems, proprietary platforms, or vendor lock-in can become a real operational risk. Whether it is engineering workstations, monitoring systems, remote access solutions, or industrial visibility platforms, organizations should think carefully about continuity, accessibility, and who truly controls the technology stack.

Open source is not only about reducing cost.
It is about transparency, flexibility, long-term sustainability, and maintaining control over your operational environment and data.

In critical infrastructure, sovereignty and resilience matter.

For organizations interested in OT/ICS security, visibility, monitoring, and secure infrastructure approaches, check out Zerontek services:

Zerontek Services

In the previous post — “Using modbus-cli to Read and Write Modbus Coils in LabShock” — I showed something simple:

We were able to read and write Modbus coils… with no authentication.

In this part, I continued the experiment inside LabShock (OilSpring Air lab), but instead of coils, I focused on actual process values — and also writing directly to registers.

The Setup (Operator View)

From the OpenPLC monitoring dashboard, everything looks clean:

• pump1_speed_in → %QW10 → 50
• pump1_speed_out → %IW10 → 50
• pump1_temp → %IW11 → 16
• pump1_pressure → %IW12 → 3158

You just see:

• Speed
• Temperature
• Pressure

That’s the operator view.

Reading via Modbus (What We Did)

After installing modbus-cli, I ran:

modbus read 192.168.2.10 %MW10 20

Quick breakdown:

• modbus read → read from device
• 192.168.2.10 → PLC IP
• %MW10 → start from memory word 10
• 20 → read 20 values

So we dump:

• %MW10 → %MW29

What We Got

From the output:

• %MW10 = 50
• %MW20 = 50
• others mostly 0

One command → raw memory view.

Making Sense of %QW, %IW, %MW

%QW10 → Output

What the PLC sends (e.g., pump speed)

%IW10 → Input

What the PLC reads (sensor values)

%MW10 → Memory

Internal storage used by the program

Why We Saw Those Values

Even though the dashboard shows %QW and %IW, we read %MW.

That’s because PLC logic often copies values internally:

%QW10 → %MW10
%IW10 → %MW20

So:

We didn’t read outputs or inputs directly — we read their copies.

Writing to a Register (New Part)

Now the important part.

We didn’t just read — we also wrote to memory.

modbus write 192.168.2.10 %MW10 60

Breaking It Down

• modbus write → send value to PLC
• 192.168.2.10 → PLC IP
• %MW10 → target register (memory word 10)
• 60 → value to write

So:

Write value 60 into memory address %MW10

What Happens After Writing

If you check:

• OpenPLC dashboard (or SCADA in LabShock)

You will see the value change.

To confirm from CLI:

modbus read 192.168.2.10 %MW10 1

This reads only one value.

You should now see:

• %MW10 = 60

Why This Is Important

This is not just reading anymore.

This is:

Direct modification of PLC data

Depending on the logic, this could:

• Change setpoints
• Affect process behavior
• Influence outputs indirectly

Operator vs What We Did

OperatorWhat We DidUses dashboardUsed Modbus CLISees valuesReads raw memoryNo direct memory accessFull accessControlled UINo restrictions

What This Proves

This reinforces the same point as Part 1:

Modbus is not secure by design.

We were able to:

• Read process values
• Dump memory
• Write to registers
• Write to coils (Part 1)

All of this:

• No authentication
• No encryption
• No validation

Why This Matters

1. Read = Recon

You can map the system just by reading.

2. Write = Impact

You can influence the system by writing.

3. No Barriers

If you can reach the PLC:

You can interact with it.

What Defenders Should Take From This

• Restrict Modbus access (segmentation is critical)
• Monitor read activity, not just writes
• Understand what each register exposes
• Treat internal memory as sensitive

Final Thought

Part 1 showed we can control coils.
Part 2 shows we can read and modify process values.

When a protocol lets you read and write critical data with no authentication,
that’s not a misconfiguration — that’s the design.

And once you see that layer,
you’re no longer looking at the system like an operator…
you’re seeing it like an attacker.

Operational Technology (OT) cybersecurity is different.

You can read about PLCs, SCADA, and industrial networks…
but without hands-on experience, it remains theory.

This is where platforms like LabShock come in.

What is LabShock?

LabShock is a virtual OT/ICS lab platform designed to simulate real industrial environments.

It allows you to interact with:

• PLCs and HMIs
• Industrial protocols
• Network traffic inside plant environments
• Attack and defense scenarios

In simple terms, it’s a safe environment where you can see how OT systems actually behave — and how they are secured.

🆓 The Free Version: A Starting Point

LabShock provides a free version for basic exploration.

You get:

• Core features
• Limited local labs
• Time-restricted access
• Only 2 zones
• Limited levels

It’s useful to understand the platform.

But it’s not enough if your goal is to build real OT skills.

My Offering: Enterprise-Level Access

Through my offering, you get access to LabShock under an Enterprise environment.

This means:

• Full lab capabilities
• No zone limitations
• Complete scenarios and components
• Real OT workflow practice
• A structured environment for training

More importantly, you get access to advanced industrial scenarios not included in the free version, such as:

• Siemens S7 environments
• Modbus-based systems
• PLC and SCADA interactions
• CNC systems
• Water treatment environments
• Oil & gas scenarios

These are closer to what you would encounter in real industrial operations.

Why This Option?

The official Pro version usually requires long-term commitment.

This option gives you flexibility:

• Try Enterprise-level access
• Use it for one full month
• Practice real OT scenarios
• Decide later if you want to continue

No yearly lock-in.
Lower commitment.
Practical experience.

🎯 Who Is This For?

• Engineers moving into OT cybersecurity
• ICS students who want hands-on learning
• Professionals preparing for real-world roles
• Anyone serious about industrial environments

If you only want to explore, the free version is enough.

If you want to actually build OT capability, this is where you start.

👉 Access the Lab

You can get access here:
https://zerontek.com/zt/ot-lab

If you have questions, feel free to reach out.

— Dr. Sulaiman Alhasawi
OT/ICS Cybersecurity | ICS Arabia Podcast | ZeroNteK

Six years ago, ICS Arabia was launched with a single goal: to provide high-quality, professional education for the Industrial Control Systems (ICS) and Operational Technology (OT) cybersecurity community. Today, we celebrate a major milestone in our journey from a specialized technical project to a global educational resource.

📈 The Journey in Numbers

Over the past 6 years, ICS Arabia has grown from a foundational library into an industry-leading technical resource. Our 2024–2025 growth trajectory has been nothing short of exponential.

• Total Episodes: 71
• Total Views: 45,944+
• Total Watch Time: 2,633+ Hours
• Total Global Impressions: 568,983+

🌍 Global Impact & Language Strategy

To ensure that our content reaches both the international expert community and our regional professionals, we maintain a strategic bilingual approach.

• English Episodes: 51 (72%) — Engaging the global OT security community.
• Arabic Episodes: 20 (28%) — Providing specialized access for the Middle Eastern workforce.

A Comprehensive Technical Curriculum

Our library of 71 episodes is organized into 10 key educational pillars, ensuring that OT professionals have a 360-degree learning path:

🏗️ Pillar 1: Foundations & Architecture

• My interview with SCADAhacker
• OT 101
• What Does OT Really Mean?
• IT/OT Convergence
• The Iceberg of OT Cybersecurity
• Conversations on OT Cybersecurity with Anton Shipullin
• My interview with Shodan’s founder
• My interview with ICS Village in Kuwait

🧪 Pillar 2: Lab & Testbed

• Hands-On ICS/OT Testbeds
• Labshock
• How to build a cybersecurity lab for ICS/OT

🔎 Pillar 3: Risk Assessment & Visibility

• Interview with Sinclair Koelemij
• OT Risk Management
• OT Security Posture & Attack Path Analysis
• OT Project Estimation Made Simple
• PLC Scanning: Safe Practice or Security Risk?
• Exploring ICSRank: Review and Demo with Mike Holcomb

🔓 Pillar 4: Open Source

• Engineering OT Security: ISA Standards & Open Source in Action
• Open Source Zero Trust

🛡️ Pillar 5: Offensive Security (Red Teaming)

• FAT/SAT for ICS/OT: Break Early, Build Secure
• OT Red Team
• OT Penetration Testing
• First-Time SCADA Penetration Testing
• Is PLC Remote Mode Secure? Mike Holcomb Breaks It Down
• SCADA Hacking & Defense deep dive

🚀 Pillar 6: Engineering & Emerging Tech

• TrueOT Team
• Secure Deployment in OT
• AI & IIoT in OT Environments: Real-World Challenges
• Digital Twins in ICS/OT
• AI & Cloud in OT Security: A Game-Changer or a Risk?

📜 Pillar 7: Standards & Compliance

• Demystifying ISA/IEC 62443 with Khalid Ansari
• Inside ISA/IEC 62443
• 5 ICS Critical Controls

🚨 Pillar 8: Defensive Ops & Incident Response

• OT Incident Response Explained
• OT/ICS Network Defense w/ Shaker Hashlan
• OT DFIR Uncovered: PLC Forensics, Tools, and Lessons from the Field
• Disaster Recovery in OT with Saltanat Mashirova
• My interview with Naser Aldossary (ICS Incident Responder)
• OT/ICS Ransomware
• EDR and ICS/OT Security: Best Practices and Real-World Applications

⚙️ Pillar 9: Industry Verticals (Sector-Specific)

• Securing the Digital Power Grid
• Rail Cybersecurity & OT SOCs in the Middle East
• Railway Cyberattacks Are Rising
• Automotive, Mining, Pharma, and Food Industry Security
• Medical Systems & Wearable Medical Devices Security (Hacking Health)
• Substation IDS: Multi-Protocol Support

🎓 Pillar 10: Professional Development

• OT Cybersecurity Skills: Building Your Expertise
• From Academia to Cybersecurity Leadership
• From Physical Security to OT Cybersecurity
• Cybersecurity Journalism & OT Security

🤝 The Team Behind the Mission

The success of ICS Arabia is the result of dedicated production and strategic management.

Dr. Sulaiman Alhasawi — Founder & Host

Every episode is filmed and produced on-site at Sulaiman’s home office studio in Kuwait, ensuring a consistent and professional environment for high-level technical discourse.

Bassem Ben Amor — Strategy & Content Management

Bassem is a core pillar of the team. He manages guest recruitment and authors our bilingual articles. His dedication has been a major catalyst for our recent growth. Bassem also manages our presence on Spotify, ensuring our content is accessible to professionals everywhere.

🎙️ A Community of Industry Professionals

We are proud to have hosted an incredible directory of industry professionals:

Aaron C. Crow • Adnan Ahmed • Ahmed Al Saleh • Alessio Rosas • Ali Y Dashti • Ali Laribi, CISSP, CPP, CISM • Andre Froneman • Anton Shipulin • Ayed Al Qartah عايد القرطه • Bassem Ben Amor PMP® • Dieter Sarrazyn • Dr. Fouad Abou Chacra • Haitham Rashwan, PhD • Dr. Jesus Molina • Sridhar Adepu PhD • Eduard Kovacs • Faisal Albuloushi • Fawaz Adi • Fred Gordy • Hussain AlSayegh, CPAS, ITIL, CBET, CHTM • Jan Hoff • Joel Langill • John Matherly • Khalid Aljamed • Khalid Ansari • Leen AlHalabi • Marco (Marc) Ayala • Michael Hoffman • Mike Holcomb • Mohammed Al Dabbous • Naser Aldossary • Nebras ALQURASHI • Omar Sherin • Philip Griffiths • Rakesh Kumar • Raphael Arakelian • Saltanat Mashirova • Scott Reynolds • Shaker Hashlan • Sinclair Koelemij • Steve Mustard • SZ Lin (林上智) • Tobias Halmans • Vivek Ponnada • Zakhar Bernhardt • 🇸🇦 🇩🇰 Abdulrahman Al Safh • Nasser Al Alawi • Samir Mokthar

Looking Ahead

As we move into 2026, our mission remains unchanged: to provide the best OT/ICS security education in the world, straight from Kuwait.

Thank you to our 1,500+ subscribers and the global community for your trust. We are just getting started.

But OT environments were never meant to be managed by products alone.

They require engineering discipline, operational awareness, and long-term control over architecture and data. In an era of geopolitical tension, supply-chain fragility, and increasing cyber-physical risk, this leads to a more fundamental question:

Who actually owns and understands their OT environment?

This is where Open OT begins.

What Open OT Really Means

Open OT is not a product.
It is not a dashboard.
And it is not limited to visibility.

Open OT is a service delivery framework for designing, securing, operating, and governing OT environments using open, transparent, and vendor-neutral principles.

It is the framework we use at ZeronTek to ensure that industrial organizations:

• Understand their systems
• Control their architectures
• Own their data
• And are never held hostage by black-box dependencies

Open OT is about sovereignty in practice, not slogans.

Why Traditional OT Approaches Are Failing

Most OT environments today suffer from the same structural problems:

• Architectures that evolved without a long-term security model
• Tool sprawl with overlapping capabilities and unclear ownership
• Black-box platforms that provide alerts but no understanding
• Remote access solutions that prioritize convenience over control
• ESG and operational reporting built on estimates instead of real data

The result is an environment that appears monitored, but is not truly understood.

Open OT was created to address this gap.

Open OT as a Framework (Not a Toolset)

Open OT organizes OT services into five coherent domains, each addressing a real operational need.

1. Secure Foundations

OT security starts with architecture, not alerts.

This domain focuses on:

• OT security architecture and engineering
• Alignment with IEC 62443 and NIST principles
• Zone and Conduit design
• Industrial DMZs and segmentation
• Vendor-neutral decision-making

Without this foundation, every other control becomes fragile.

2. Secure Operations

Visibility alone is not security.

Secure Operations focuses on:

• OT monitoring and detection
• Protocol-level awareness
• SIEM / XDR integration
• Detection engineering for industrial environments
• Custom analysis for non-standard or legacy protocols

The goal is not noise — it is operationally relevant signal.

3. Secure Access

Remote access is one of the highest-risk areas in OT.

This domain addresses:

• Controlled access to HMIs and OT workstations
• Clientless, encrypted access models
• Reduced reliance on traditional VPNs
• Identity-aware access aligned with operations

Access should enable operations without expanding the attack surface.

4. Operational Intelligence

OT environments generate data, but rarely insight.

Operational Intelligence focuses on:

• Production and asset health views
• Management-level dashboards beyond the HMI
• Energy, ESG, and sustainability metrics
• Decision support without touching control logic

This is about understanding system behavior over time, not real-time control.

5. Capability Building

No OT system is sovereign if only external vendors can maintain it.

This domain includes:

• OT security masterclasses
• Operator and engineer awareness
• Knowledge transfer and documentation
• Research into industrial protocols and behaviors

True resilience exists only when local teams are empowered.

How Open OT Is Delivered

Open OT services are delivered using strict operational principles:

• Remote-first where appropriate
• Read-only by design whenever possible
• Non-intrusive to control systems
• OT-safe and operations-aware
• Vendor-neutral and auditable

The framework adapts to the environment — not the other way around.

Why This Matters Now

Industrial organizations are being asked to do more with less:

• Maintain uptime
• Improve safety
• Defend against cyber threats
• Report on sustainability
• And remain operational during global uncertainty

This cannot be achieved with tools alone.

It requires clarity of architecture, control of data, and ownership of decisions.

Open OT and ZeronTek

Open OT is the framework.
ZeronTek is the organization that delivers it.

Our role is not to sell licenses or push platforms.
Our role is to help organizations build OT environments they actually control.

Open source provides the freedom.
Open OT provides the structure.

Together, they enable Industrial Digital Sovereignty.

If your OT environment feels monitored but not understood, secure but not controlled, or compliant but fragile — it may be time to rethink the model.

That rethink starts with Open OT.

For collaboration, partnerships, or Open OT engagements, visit: https://zerontek.com