Choose Your Weapon: How to Select Open Source Tools in OT

As many operators already know, open source software is becoming more common in Operational Technology (OT) and Industrial Control Systems (ICS) environments. Especially for smaller campuses and teams, open source tooling can be a more affordable or customizable solution for everything from asset discovery and network monitoring to log management and security visibility.

Which is exactly why we published our OT Toolbox article, containing a comprehensive list of EmberOT-approved open source tools that can be used in OT.

But that’s not where your open source quest ends. In fact, it’s only the beginning.

Open source tools are rarely set-it-and-forget-it. Especially if a tool needs to be adapted to a specific environment’s needs.

Whether you’re an operator or a defender, adopting open source tools in OT requires a deliberate, risk-informed approach that respects the realities of industrial systems and your environment.

Below are some guidelines and best practices to help you not only choose the right tools for the job, but also ensure they’re useful and impactful. 

Start with Operational Risk, Not Features

In OT, the primary question is not what the tool can do, but how it may impact the process or environment. It’s easy to get awestruck by an open source tool’s (purported) features. Finding an open source solution that checks all your organization’s needs can feel like winning the lottery or finding buried treasure. Especially for us geeks and techies. 

It’s also worth noting that this is where the difference between IT and OT becomes particularly apparent. Feature-rich platforms that are acceptable in IT may be unsuitable for production networks running PLCs, DCSs, and safety systems.

Before implementing any open source tool, ask:

• Is this tool passive (listens but does not interact), or active (interacts with the network and/or systems)?
• Could this tool, or even its setup, impact system availability or deterministic behavior?
• Does it introduce latency, jitter, or unexpected traffic?
• What happens if it fails or behaves unpredictably?

Open source tools should be selected based on their ability to support operations without interfering with control processes. 

Know Your Skill Stats & Obstacles

Open source tools are products of community collaboration, usually an informal or ad-hoc team of developers or programmers.

Many OT environments, however, do not have developers or programmers on staff. So if you are the operator or team member deploying this tool, consider whether your team has the skills and/or knowledge required to keep it up-to-date. If they do not, can those skills be learned? Is there training available? And last but not least, does the team have the time (cycles) to gain these skills?

Often, “one-click” or “easy install” open source solutions are great when they work… until they don’t. An “easy, one-click” download can quickly become a multi-hour rabbit hole, especially if a tool is being customized. 

So be sure to thoroughly explore documentation, repos, and other materials about the tools you’re choosing before deploying them. 

Respect Legacy Systems and Vendor Constraints

It’s a well-worn jab that OT environments are among the few places still running legacy systems like Windows NT, XP, ME, etc. But that jab, and others like it, contain an important kernel of truth.

For a multitude of reasons, many OT environments use:

• Devices that cannot be patched or do not have patches available
• End-of-life and end-of-support operating systems & software
• Vendor-certified architectures with strict change controls

Any open source tools in OT must coexist with these realities.

For that reason, as a general rule (there will be differences depending on the specific environment), avoid open source solutions that:

❌ Require frequent updates in production environments

❌ Depend on agents installed directly on devices

❌ Assume modern operating systems and/or unlimited compute resources are in use

Whenever possible, favor passive monitoring, network-based visibility, and read-only integrations that minimize the risk of disrupting fragile systems.

Treat Open Source Tools in OT as Industrial-Grade Software

One of the biggest risks in OT is informal deployment, also known as “Shadow IT” (or maybe we should call it “Shadow OT” in these cases).

Open source tools in OT should be subject to the same rigor as any industrial system:

• Formal testing in an OT lab or staging environment
• Change management aligned with maintenance windows
• Configuration baselines and rollback procedures
• Clear documentation for operators and engineers
  • Defined playbooks for operators, such as support procedures and/or procedures for bypassing the tool in an emergency
• ❗ Cybersecurity is still important! All the usual guardrails in terms of Identity Access Management (IAM), vulnerability assessments, and more still apply 

Even minor configuration changes can have outsized impacts in ICS environments. “Quick fixes” and ad hoc updates have no place on production control networks.

Prioritize Safety and Availability Over Immediate Patching

In IT, rapid patching is often the default response to vulnerabilities. In OT, the calculus is different.

For open source tools:

• Evaluate whether a vulnerability is exploitable in your environment
• Consider compensating controls (segmentation, monitoring, access restrictions)
• Coordinate updates with operations and engineering teams, and document EVERYTHING along the way

CISOs and executive leaders should ensure OT vulnerability management is risk-based, not driven solely by CVSS scores or IT-centric timelines.

Understand Supply Chain and Dependency Risk

Open source tools often rely on complex dependency chains. This can cause complications even in typical use cases (cough – Log4j– cough). In OT, this creates unique challenges:

• Limited visibility into what components are running in production
• Difficulty updating dependencies once deployed
• Long system lifecycles that outlast many software projects

Maintaining an inventory, or SBOM, of open source components used in OT tooling helps organizations respond more effectively to emerging threats and supply chain incidents.

Define Clear Ownership Across IT, OT, and Engineering

Open source tools often fall into organizational gray areas.

Key questions to answer:

• Who owns the tool operationally?
• Who approves changes?
• Who responds when it fails at 2 a.m.?

In OT, ownership should be shared but clearly defined, with engineering and operations involved, not just IT or security.

Support models must reflect the reality that downtime has physical and financial consequences.

Document the answers to these questions and update that documentation with any changes. Not only does that ensure smooth operations, but it also makes preparing for a NERC CIP audit a bit easier, too.

Because even open source tooling “counts” when it comes to compliance. 

Evaluate Licensing and Compliance in an Industrial Context

Speaking of compliance, licensing issues are often overlooked until they become operational blockers. Just because a tool is open source and free doesn’t exempt it from the rules governing OT/ICS environments. 

For OT environments, consider:

• Whether license terms affect system distribution or vendor relationships
• Audit and documentation requirements
• Regulatory or safety certification implications

Legal and compliance teams, if available, should be involved early to avoid surprises, especially in regulated sectors such as energy, water, manufacturing, and transportation.

Integrate Open Source into Your OT Security Architecture

These tools should always complement, not complicate, your OT security strategy. Used correctly, open source should enhance situational awareness without increasing operational complexity for control room staff. 

But what does effective integration look like?

A general checklist of overarching principles might include: 

• Alignment with network segmentation and Purdue Model layers (as applicable) 
• Compatibility with incident response and recovery plans
• Visibility into both cyber and operational impacts

Balancing the Right Open Source Tools in OT

Open source tools can deliver real value in OT and ICS environments, but only when implemented with discipline, patience, and respect for operational realities.

For operators, the priority is safety, reliability, and efficiency. For defenders, the challenge is enabling visibility and security without introducing new risk.
When open source adoption is driven by operational risk management rather than convenience or cost, it can become a powerful and sustainable part of an OT security and operations strategy.

~Jori 🤘🔥