Introduction

There are many ways to think about Operational Technology (OT) aside from the official definition. With a quick search engine hunt of “what is operational technology,” you’ll find plenty of resources to choose from. And for more of a trusted point of reference and technical depth, we can look to NIST Special Publication (SP) 800-82 rev3.

I challenge you to define what “OT” is to your organization, and its alignment to your business. Do you have a list of assets that your organization considers “OT” by role, class, placement, or other decided criteria?

At a recent ISAC conference, I posed this question to attendees interested in lessons learned from a global OT Security Monitoring deployment: “Who has a curated list of device types that you consider to be your OT?” How many hands went up? Zero.

Why it Matters

Many organizations we’re working with know they need a strategy and a tactical plan for reducing security risk in their OT systems and environments. But before we can do that, what are we securing? It seems like a basic question, but is it?

First and foremost, is an asset even OT? Or should it be classified as Internet of Things (IoT), Industrial Internet of Things (IIoT), Internet of Medical Things (IoMT) or something else entirely like the traditional Information Technology (IT)?

It matters beyond the point of terms or classifications. It’s the device, the environment, and the different teams who manage it all:

  • What function or process does it perform?
  • What connectivity does it require?
  • What performance needs does the system have?
  • Does it make something or just do something?
  • Is it an autonomous, manual, or hybrid system?
  • What kind of systems and people need to support it?
  • What type of data inputs and outputs are required and what dependencies are required?
  • Does it support a critical process or serve a regulatory function?
  • What would happen if it wasn’t available or malfunctioned? Can it jeopardize personal safety? Financial or reputational damage?
  • Who knows it’s here? Can it be located, seen, touched, communicated with, or maintained?

The Complete Picture

OT security monitoring and detection vendors will tell you that visibility is what you need – and they’re right. Security visibility into OT environments has been a blind spot forever, but it’s also now one of the most mature sectors of OT security products to date. Dale Peterson has been bringing a lot of perspective on this product landscape emergence – take a look at this blog post, OT Security Product Market Winners = No Changes.

But ultimately, visibility isn’t the complete picture, and the question organizations also need to be asking is what do we do with that visibility once it’s in place?

  • Does your Security Operations Center (SOC) or Managed Security Service Provider (MSSP) know OT and how to respond differently (from IT)?
  • Are your defenders able to respond in a safe and reliable manner that does not impact critical operations?
  • Are there playbooks and processes for security teams to action if a priority alert triggers?
  • Do you have an OT Incident Response Plan (IRP)? Has it been communicated and adopted throughout your business?
  • Do you know enough about your environment and security risks to be able to say yes, this is an incident of high or low priority?
  • Do you have relationships with the sites to be able to track an asset and action on response procedures?
  • Do you have a training/sandbox environment to tune and hone OT security tooling?
  • Is security a part of your OT system lifecycle?

Every single question points back to a single need: defining the assets in your environment that you consider to be OT.

How to Start

Solving OT security is a more collaborative effort than any IT security effort your team has undertaken. Security, IT, business, site/plant leads, Engineering and Automation must collaborate.

To define the types of assets to consider as OT, you first need to know what systems you have and if you don’t have a vendor asset management solution already in place, you may end up needing to pull from an Excel file managed locally by your Site Lead. You must start somewhere though.

Once you finally have an asset list in hand, Venn diagram the assets with your teams and make it your own:

For additional information on the Purdue Enterprise Reference Architecture: https://en.wikipedia.org/wiki/Purdue_Enterprise_Reference_Architecture

To get this done, here are a few broad stroke things to consider :

  • Framing “OT”
    • Back to earlier points, yes, you can say that any device directly involved in the physical production of product is OT. That’s the point; this is an organizational decision.
    • What about corporate workstations used for engineering? Not OT. But as you evolve this understanding or introduce more systems indirectly involved in production, you may want to include them because of their role in influencing operations.
  • Simplicity First
    • Since Rockwell, Siemens, Honeywell, and Advantech are all Manufacturing companies (compared to Lenovo, for example) and you’re not trying to solve a philosophical problem, you can simply start with agreeing that their devices in your environment are OT. The IT and Security teams will appreciate this simplicity as a starting point.
    • Then, once you’ve gained some maturity, you can filter out certain types of their systems, not just considering all OT the same.
  • Captain Obvious here, checking in for duty
    • Most organizations have device/system naming syntaxes and maybe even include nomenclatures like “-mfg” in the hostname. So yes, include those too.

I recommend this simplified approach after having quite a few discussions about what kind of systems we would call “OT.” And after all those discussions, where I landed is… it depends. It depends more about how you’re using the assets in your business and how you govern OT and IT responsibilities.

A word of caution though – avoid analysis paralysis. It is much better to crawl, walk and then run than to be caught off guard or hindered in the unfortunate event of an OT security incident. Start simple with what you know is OT. Then work your way further down into the unknown.

Final Thoughts

Firstly, you don’t need to go at this alone. The ISA/IEC 62443 standards are the most comprehensive out there and are worth some time getting familiar with, if you’re not already: https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards.

If they’re too much to take on all at once though, Felipe Sabino Costa has a great blog post of practical thinking on 62443 in the ISA Global Cybersecurity Alliance (which SRA is part of): https://gca.isa.org/blog/a-practical-approach-to-adopting-the-iec-62443-standards.

And lastly, as “Industry 4.0” continues full steam ahead, separating “OT and IT” will become more and more ambiguous and challenging. It was easier to say that an asset is not OT because of x, y, or z. Or vice versa. But will you be able to draw those same conclusions when your OT is in your cloud instead of the plant floor? What if it’s now a shared-resource asset?

Feel free to reach out if you’d like to know more.

Jason Rivera
Director, PCNSA, CCNA | Archive

Jason specializes in Cyber Physical Systems (CPS) security strategy program development and controls. He has spoken at H-ISAC, ISACA and let multiple CPS security trainings while also serving in OT/IoT security leadership roles since 2018.

He has prior experience with Cybersecurity Operations, Incident Response (IR), Network Security and Risk Management.

In addition to helping clients, Jason been a go to for SRA in new and emerging services. He has also been a Palo Alto Networks Certified Network Security Administrator (PCNSA) and Cisco Certified Network Associate (CCNA) certified.