Sky Breaker

Hacking Celestial Wisdom with Skill and Technique.

NIST SP 800-82を読んだメモ書き(1) 2. OT Overview

OT NIST

アメリカのNISTが公開しているOTセキュリティに関するガイドラインを読みながら考えたメモ。
csrc.nist.gov

このブログポストを見る前に、まずは実際にNIST SP 800-82を全文読んでいただきたい。

「2. OT Overview」より前のガイドラインの目的や全体の概要部分は飛ばしている。全て読んでいるが、基本的には「2. OT Overview」以降を読めば分かることだと思っているので。

2. OT Overview

Operational technology (OT) encompasses a broad range of programmable systems and devices that interact with the physical environment (or manage devices that interact with the physical environment).

NIST SP 800-82によると、「OTは、物理的環境とやり取りする（あるいは物理的環境とやり取りするデバイスを管理する）プログラム可能なシステムやデバイスを幅広く含む。」とある。OTはOperational Technologyの略であり、日本語では「運用技術」と呼ばれる。「運用技術」という名の通り、OTと言われるシステムやデバイスは何らかの工程の監視や制御によって物理的な変化を引き起こす。なので、運用に関わる技術と言える。

ここで一旦、ITについて考えてみる。誰もが知る通り、ITはInformation Technologyの略である。ITは情報技術と呼ばれ、その名の通り、情報処理、データ管理、通信ネットワークといった情報の扱いに焦点を当てた技術分野である。なので、「ITとは、情報やデータの収集、処理、保存、伝送、分析を行うデジタルシステムやテクノロジーを幅広く含む。」と言えるだろうか。OTとの大きな違いは、「物理的な世界との直接的な相互作用ではなく、サイバー空間での情報やデータの処理・伝達に特化していること」と考えられる。

NIST SP 800-82のOTの話に戻ると、ここでは例として以下の7つのシステムの名前が挙げられている。

  • 産業用制御システム -> Industrial Control System、ICSと略されることが多い。一般的には、OT環境が利用される環境がほぼICSなので、OT環境に関してはICSと調べた方が沢山情報が出てくる。
  • ビルオートメーションシステム -> NIST SP 800-82の記載はbuilding automation systemだが、ビル管理のシステムであればBuilding Management System (BMS)やBuilding Automation And Control Systems (BACS) と呼ばれる方が多いのではないだろうか。
  • 輸送システム -> transportation system
  • 物理アクセス制御システム -> Physical Access Control SystemはPACSと略される。
  • 物理環境監視システム -> physical environment monitoring system
  • 物理環境測定システム -> physical environment measurement system

そして、システムは3つの方法のいずれかのループ制御で構成されると記載されている。

  • オープンループ (Open Loop)
    オープンループは、出力(物理的なフィードバック)を使用せずに動作する制御方式。出力結果を測定せず、入力のみに基づいて動作する。システムの状態や結果に関わらず、あらかじめ設定された指示に従って動作するため、外部の変化や外乱に対する自動調整機能が無い。単純な構造で実装が容易である一方、精度や信頼性には制限がある。
    例：タイマー制御の照明システム、一定時間で動作する自動散水システム
  • クローズドループ (Closed Loop)
    クローズドループ制御は、出力(物理的なフィードバック)を使用する制御方式。出力結果を継続的に測定し、目標値と比較して調整を行う。センサーからの情報を基にシステムが自動的に調整を行うため、外部環境の変化や外乱に対して自己修正能力を持つ。オープンループよりも複雑だが、高い精度と信頼性を提供する。
    例：部屋の温度を一定に保つエアコン、設定した速度を維持する自動車の定速走行システム、工場の自動制御システム
  • マニュアルループ (Manual Loop)
    マニュアルループ制御は、人間のオペレーターが制御プロセスに介入する方式。システムの状態は測定されるが、調整は人間のオペレーターによって手動で行われる。自動化されたシステムと人間の判断を組み合わせたハイブリッド型の制御であり、複雑な状況や予期せぬ事態に対して人間の判断を活かせる。完全自動化システムよりも柔軟性があるが、人的要素に依存するため一貫性に欠ける場合がある。
    例：オペレーターが監視画面を見ながら手動で調整する工場設備、半自動運転モードの車両、監視制御システム

それぞれ極端な想定の制御であり、実際には各々が忠実に実現されているわけではないと考えているが、基本としては3種類なのだろうなぁとも思う。

2.1 Evolution of OT

OTは元々、ITとは異なる独自の技術でインターネットとは全く繋がらない内部ネットワークの話であったが、現在では大きく変化している。

今日のOTの多くは、既存の物理システムにIT機能を組み込むことで進化を遂げてきた。この過程で、物理的な制御機構が置き換えられたり、補完されたりしてきた。このような進化はコストと性能の向上によって促進され、スマート電力網、スマート交通、スマートビルディング、スマート製造、モノのインターネット（IoT）といった現代の「スマート」技術の誕生につながった。これらの技術の発展により、システムの接続性と重要性が高まる一方で、安全性、セキュリティに対するニーズも増大している。

かつては完全に隔離されていたOTシステムが、今ではITと融合し、インターネットに接続されることで新たな可能性と課題を同時に生み出している。

2.2 OT-Based Systems and Their Interdependencies

CISAが重要インフラセクター(Critical Infrastructure Sectors)として挙げている分野、さらにその中の太字の分野でOTが多く利用されているらしい。

  • 化学 (Chemical Sector)
  • 商業施設(Commercial Facilities Sector)
  • 通信(Communications Sector)
  • 重要な製造業(Critical Manufacturing Sector)
  • ダム部門(Dams Sector)
  • 防衛産業基盤(Defense Industrial Base Sector)
  • 緊急サービス(Emergency Services Sector)
  • エネルギー(Energy Sector)
  • 金融サービス部門(Financial Services Sector)
  • 食品,農業セクター(Food and Agriculture Sector)
  • 政府施設(Government Facilities Sector)
  • ヘルスケアおよび公衆衛生(Healthcare and Public Health Sector)
  • 情報技術分野(Information Technology Sector)
  • 原子炉、材料、廃棄物(Nuclear Reactors, Materials, and Waste Sector)
  • 輸送システム(Transportation Systems Sector)
  • 上下水道システム部門(Water and Wastewater Systems Sector)

さて、CISAの重要インフラセクター(Critical Infrastructure Sectors)はアメリカの話なので、日本ではどうなっているのか。

日本では、「経済安全保障推進法」基づき以下の15の事業分野を選定し、それらを「特定社会基盤事業者(重要インフラ)」としている。
1.電気
2.ガス
3.石油
4.水道
5.鉄道
6.貨物自動車運送
7.外航貨物
8.港湾運送(令和７年４月1日より施行)
9.航空
10.空港
11.電気通信
12.放送
13.郵便
14.金融
15.クレジットカード

ところで、特定重要設備を扱う事業者はリスク管理措置として脆弱性診断やセキュリティ管理・監視を行い、届け出をしないといけないような仕組みのように見える。 が、そのようなことを本当にやっているのだろうか???

これらの重要インフラは物理的、情報通信的に相互接続・相互依存的なシステムとなっている。例えば、電力送電システムの障害は電力網全体に連鎖的な障害を引き起こして広範囲の停電を発生させる可能性がある。その結果、電力に依存している石油・天然ガス生産、製油所、水処理システム、廃水収集システム、パイプライン輸送システムなど、多くの重要インフラにも影響が波及していくかもしれない。このような一つのインフラでのインシデントが連鎖的に拡大し、他のインフラにも直接的・間接的な影響を及ぼす可能性がある。こういった関係性を「システム・オブ・システムズ(system of systems)」と呼ばれることがあるらしい。確かに「システムのシステム」と呼ばれるのも分かる。面白い。

2.3 OT System Operation, Architectures, and Components

このセクションでは、監視制御•データ収集システム（SCADA）、分散制御システム（DCS）、プログラマブルロジックコントローラベースのトポロジ（PLC）、ビルオートメーションシステム（BAS）、物理アク セス制御システム（PACS）、産業用IoT（IIoT）など、一般的なOTシステムの種類の概要を説明している。

基本的な制御ループ(control loop)は、センサ、アクチュエータ、コントローラを利用してプロセスを制御する。センサが環境や機器の状態を測定し、その情報をコントローラーに送る。コントローラはこれらの情報を分析し、目標値と比較して必要な指示を作り出し、アクチュエータに送ります。アクチュエータは、制御弁、ブレーカ、スイッチ、モータなどの実際に動く部品で、コントローラからの指示に従ってプロセスを操作する。

これらは、ネストやカスケードされることであるループの設定値は別のループによって決定されたプ ロセス変数に基づいて決定されるような仕組みになっている場合もある。

オペレーターとエンジニアは、ヒューマンマシンインターフェース（HMI）を使用して監視や設定を行う。

Fig. 1. Basic operation of a typical OT system(NIST SP 800-82r3 11ページより)

2.3.1. OT System Design Considerations

OTシステムの設計時に考慮される7つの項目が挙げられている。

  • 安全性(Safety)
    どれほどシステムを安全に保てるか。危険な状態の検知や危険な状態になってしまった場合に安全な状態へ移行できるような仕組みが必要。
  • タイミング要件の制御(Control timing requirements)
    システムには、 速度、一貫性、規則性、同期性などの時間に関する要件がある。
  • 地理的分布(Geographic distribution)
    同じ部屋や同じ建物であれば良いが、異なる建物や都市を跨いで繋ぐような必要のある大規模な分散システムならどうするか。場合によっては、モバイル通信の利用があるかもしれない。
  • 階層(Hierarchy)
    散らかっているよりは、役割ごとにまとまって管理されていた方が監視しやすい。
  • 制御の複雑さ(Control complexity)
    単純な制御であればプリセットのもので制御できるが、複雑になるのであれば人間のオペレータが常に監視するような仕組みが必要な可能性がある。
  • 可用性(Availability)
    これが本当に大事。場合によっては、厳しい可用性と稼働時間の要件があり、全ての通信や制御の仕組みの冗長性が重要になるかもしれない。
  • 障害の影響(Impact of failures)
    障害が起こると、どのような影響が出る可能性があるか起こる前から想定しておく。もしかすると、制御ループごと、建物ごとに大きく異なる影響を引き起こすかもしれない。冗長制御によって運用を継続するか、それとも最低限でも動きつづける仕組みが必要になるか。

2.3.2 SCADA Systems

SCADAはSupervisory Control And Data Acquisitionの略。SCADAシステムでは、名前の通り監視制御とデータ収集を行うためにデータ収集、データ伝送、HMIが統合されている。単体のというよりは、複数の現場の集中的な監視制御に利用される。

主に、地理的に別の場所にあるような現場の制御サーバ(SCADAサーバ)、ネットワーク機器、フィールドデバイスの監視制御のためのRTU(Remote Terminal Units)やPLCで構成される。現場ではRTUやPLCが制御を行い、ネットワーク機器を通じて複数の現場の情報が制御サーバで保存・処理される。

これらに加えて、IED(Intelligent Electronic Device)などが制御サーバと直接通信する箇所やRTUとPLCのデータを収集して制御サーバにデータを渡す役割として配置される。IEDなどは異常値を検知した際に運用を止めるような保護リレーなどの役目を持つ。「異常な状態を放置せずに機器を止めることが可用性に繋がる」という考え方の保護リレーは、とても意味深い。

Fig 2が一般的なSCADA構成。図の上部が管理センターで制御サーバの他、HMIやエンジニアリングワークステーション、ヒストリアンが配置されている。現場から収集された情報をHMIに表示する他、検出されたイベントに基づいてアクションを実行する。

図の下の現場では、センサの監視、アクチュエータの制御が行われる。多くの場合現場では、オペレータが遠隔で作業可能なようにリモートアクセス機能が備えられている。

Fig. 2. A general SCADA system layout that shows control center devices, communications equipment, and field sites(NIST SP 800-82r3 ページ13より)

SCADAの通信とトポロジは実装によって様々あるらしい。seriesやmulti-dropって凄い。(Fig. 3)

Fig. 3. Examples of point-to-point, series, series-star, and multi-drop SCADA communications topologies(NIST SP 800-82r3 14ページ)

大規模であればサブの制御サーバが利用されることもある。(Fig. 4)

Fig. 4. An example SCADA topology that supports a large number of remote stations(NIST SP 800-82r3 15ページより)

SCADAシステムのより具体的な例として、鉄道監視・制御の例が示されている。この例では、SCADAサーバが各線区の列車、信号、電気設備、券売機の情報をポーリングし、管理センターのHMIに表示、オペレータによるコマンドを各線区に送信する。もしくは、状況監視、それらの状況に基づいて自動でコマンドが発行される。
例：浸水したエリアや他 の列車が走行しているエリアへの進入を防ぐために列車を停止させるなど

Fig. 6. An example rail monitoring and control SCADA system implementation(NIST SP 800-82r3 18ページ)

2.3.3 Distributed Control Systems ~ 2.3.6 Physical Access Control Systems

それぞれ考え方は異なるが、システム構成としては大体同じなので省略。
後の説明のために必要そうであれば追加。

2.3.7 Safety Systems

OTシステムは、適切に制御できなければ人の命や自然環境に対して大きな影響を及ぼすような環境でも利用される場合がある。そのような場合には、制御のためのシステムとは別に危険な状況の発生確率や影響を低減するような安全システム(Safety Systems)も同時に利用される。OT環境に関連する安全システムには、緊急停止装置（ Emergency Shut Down=ESD）、 プロセス安全停止装置（Process Safety Shutdown=PSS）、防火•ガス検知システム（Fire and Gas Systems=FGS）などがある。

これらの安全システムに加えて、産業プロセスの安全性確保において特に重要な役割を果たすのが安全計装システム（Safety Instrumented System=SIS）。SISは、1つ以上の安全計装機能（Safety Instrumented Functions=SIF）から構成される。SIFは、センサ、ロジックソルバ、および最終制御要素（アクチュエータなど）から構成されるシステムであり、事前に設定されたしきい値に違反した場合にシステムを安全な状態にする。安全計装システムのための国際規格IEC61511に従って運用される。

多くの場合他のすべての制御システムから独立しており、SISではない基本プロセス制御システム（Basic Process Control System=BPCS）に障害が発生しても、SISの機能に悪影響は及ぼさない。(Fig. 11)

Fig. 11. An SIS implementation example(NIST SP 800-82r3 26ページ)

最近のSISの中には、制御システムとの通信を可能にするように設計されているものもあり、そのようなSISは統合制御安全システム（Integrated Control and Safety Systems=ICSS）と呼ばれる。

2.3.8 Industrial Internet of Things

OT環境には、IoTのOT環境版と言えるようなIIoTと呼ばれるIoTの応用が存在する。Industry IoT Consortiumは、エッジ層、プラットフォーム層、エンタープライズ層の3層システムアーキテクチャモデルを提案している。 (Fig. 12)

Fig. 12. A three-tiered IIoT system architecture(NIST SP 800-82r3 27ページ)

2.4 Comparing OT and IT System Security

ここでは、OTとITを比較しつつ、それぞれのOTのセキュリティで考慮すべきことが挙げられている。

始めは、インターネットに接続されない環境でITとは異なるOT独自のハードウェアやソフトウェア、独自の制御プロトコルが利用されていた。しかしながら、今では利便性や効率を求めてIT技術を組み込んでいくことで、部分的にITシステムに近づきつつある。これによって、従来は外の世界と分離されていたOTシステムが変化しつつあり、OTシステムを守る必要性が高まっている。一般的なITシステムでは、同様の問題に対して様々なセキュリティソリューションが存在するが、それらをそのままOTシステムに適用することはできない。ITシステムと異なる多くの特性、リスクや優先度を考慮したOTシステムのためのセキュリティソリューションが必要になる。

OTシステムを保護する際の特別な考慮事項は次のとおり。

適時性とパフォーマンス要件(Timeliness and performance requirements)

ITシステムは通常高いスループットを求められ、ある程度の遅延やジッターは許容できる。対照的に、OTシステムは一般的に時間に厳しい要件があり、許容される遅延やジッターの基準は個々の環境によって異なる。OTにおいては高いスループットが必ずしも重要ではなく、むしろ信頼性が高く決定論的な応答を必要とするシステムが多くある。

OTの中に自動応答時間や人間の操作に対するシステムの応答が極めて重要なものがある。このような時間的制約に対応するため、多くのOTシステムはリアルタイムOS（RTOS）を利用している。ここでのリアルタイムとは時間的な厳守要件を指す。ただし、リアルタイムの単位は用途によって大きく異なり、各システムにおいて明確に示される必要がある。

可用性の要件(Availability requirements)

産業プロセスを制御するシステムの予期せぬ停止は許容できない。例えば、生産に影響を与えずに停止・再起動することが難しいために高い可用性（すなわち信頼性）が求められる。このような特性から、停止は数日から数週間前に計画・スケジュールされる必要がある。

また、主要なコンポーネントが利用できない場合に継続性を確保するため、並列で動作する冗長コンポーネントを採用しているOTシステムも存在する。場合によっては、製造される製品や使用される設備の方が伝達される情報よりも重要視される。そのため、ITシステムでは一般的な機器の再起動といった典型的な解決法は、OTの高い可用性・信頼性・保守性の要件に悪影響を及ぼすために通常は適用できない。

リスク管理要件(Risk management requirements)

ITは主にデータと情報の保護に焦点が当たるが、OTは物理的な設備や制御システムの保護に焦点が当たる。この違いにより、セキュリティアプローチも大きく異なる。OTシステムへの攻撃は、データ漏洩だけでなく、設備の停止、機器の誤動作、さらには人命に関わる重大な事故につながる可能性がある。

OTの運用、セキュリティ確保、保守を担当する人員は、安全性とセキュリティの重要な関係を理解する必要がある。OT環境では安全性が最優先事項であり、安全性を損なうあらゆるセキュリティ対策は許容されない。

物理的影響(Physical effects)

OTシステムによる制御は、物理的な事象として影響するものである。そのため、OTシステムのセキュリティや運用を考える際には、技術的な側面だけでなく、それが制御する物理的プロセスへの影響も含めた総合的な視点が必要となる。OTシステムの特性を理解し、異なる専門分野の知識を統合することで、安全かつ効率的な運用を目指す。

システム運用(System operation)

OTシステムの運用には、ITとは異なるスキルセット、経験、専門知識が求められる。OT環境では、産業制御システムや特殊なプロトコルに関する深い理解が必要。これらのシステムは一般的なITインフラとは異なる動作をし、異なる目的を持っている。

そのため、OTとITの違いを軽視するとシステム運用に重大な影響を及ぼす可能性がある。例えば、ITの標準的なセキュリティ対策をそのままOT環境に適用すると、制御システムの可用性や安全性を損なう恐れがある。また、OT特有の要件を理解せずに変更を行うと、生産ラインの停止や安全上の問題を引き起こす可能性もある。

リソース制約(Resource constraints)

OTシステムには、ITシステムと比較して多くのリソース制約がある。OTおよびその環境で利用されるRTOSは、リソースが限られている。これらのシステムには、一般的なITセキュリティ機能を実装するための十分な計算リソースが備わっていない。

こういった状況から、近年のセキュリティに不可欠な機能を持たない場合があり、例えば暗号化機能、エラーロギング、パスワード保護などの望ましいセキュリティ機能が欠如していることがある。これらの基本的なセキュリティ機能が無く、システムの保護が困難になっている。

かといって、OTにおいてITセキュリティの手法を無差別に適用するとシステムの可用性やタイミングに支障をきたすことがある。OTシステムはリアルタイム性や連続稼働が重要であるため、セキュリティ対策がこれらの要件を妨げることは許容されない。

先の通り、OTのコンポーネントに最新のセキュリティ機能を後付けにも計算リソースがない場合もある。物理的な制約や設計上の制限により、リソースや機能を追加することが不可能な場合もある。これにより、セキュリティの近代化が非常に困難になっている。

OTシステムのセキュリティ確保には、これらの制約を理解し、それに適したアプローチを取る必要がある。既存のシステムの制約内で最大限のセキュリティを確保しながら、システムの本来の機能や可用性を維持することが重要となる。場合によっては、物理的な分離やネットワークセグメンテーションなど、システム自体の変更を最小限に抑えるセキュリティ対策が必要になる。

通信(Communications)

OT環境で使用される通信プロトコルやメディアは、通常のIT環境とは異なる。フィールドデバイスの制御やプロセッサ間通信において独自のプロトコルやメディアが使われることがある。

ここまで何度も出てきた通り、OT環境ではリアルタイム性、信頼性、耐久性などの要件が厳しく、一般的なIT環境で使用される標準プロトコルでは対応できない場合がある。そのため、特定の産業や用途に特化した独自の通信方式が発展してきた。IT環境でよく聞くものはTCP/IP、HTTP、FTPなどの標準的なインターネットプロトコルだが、OT環境ではModbus、Profibus、HART、DNP3、BACnetなどの産業用プロトコルが使用される。これらのプロトコルは、特定の産業プロセスや制御要件に合わせて最適化されている。ただし、少しづつITシステムとの統合が図られている部分があり、TCP/IPが利用されるOT環境もある。

IT環境とOT環境の統合が進む中で、これらの独自プロトコルとIT標準プロトコルの橋渡しが課題となっている。セキュリティの観点では、OT独自のプロトコルの多くが当初セキュリティを考慮せずに設計されたため、現代のサイバー脅威に対して脆弱性を持つものもある。

変更管理(Change management)

セキュリティアップデートを行わなければ重大な脆弱性が放置されたままになるため、ITシステムとOTシステムの両方で完全性を維持するために変更管理が重要となる。ただし、OTシステムではITシステム同様に迅速に実施できるとは限らない。

ITシステムのソフトウェア更新、特にセキュリティパッチは、適切なセキュリティポリシーと手順に基づき、通常は迅速に適用される。さらに、これらの手順はサーバーベースのツールを使って自動化されることが多い。

一方で、OTのソフトウェア更新は必ずしも迅速に実施できるわけではない。これらの更新によって制御プロセスにどのような影響があるか、ベンダとエンドユーザの双方によって十分にテストされた上で実施される必要がある。加えて、OTシステムの管理者は数日から数週間前にOTシステムの停止計画とスケジュールを立てなければならない。更新プロセスの一環として、OTの再検証が必要になる場合もある。Windowsのように気づいたら青い画面になって「更新プログラムを構成しています。PCの電源を切らないでください。」なんてことになると、OTシステムでは大惨事が発生するということ。

さらに、多くのOTシステムではベンダからのパッチサポートが終了した古いOSのバージョンを使用しているという問題もある。OTシステムのコンポーネントはIT環境よりも長い寿命が想定されており、安定した稼働を継続するためにアップデートをしない、最新のアップデートに対応していないサポート切れ機器を使用している可能性もある。

サービスサポート体制(Managed support)

ITサービスとOTサービスのサポート体制には大きな違いがある。

一般的なITサービスでは、多様なサポート形態に対応することができる。異なるベンダの技術が相互に連携するアーキテクチャをサポートする、あるベンダの技術を関連の無い構築専門の企業やサポート専門の企業が提供することも一般的。これにより、ユーザは様々なベンダのソリューションを組み合わせて最適なシステムを構築することが可能。

一方、OTサービスではサービスサポートが単一のベンダからのみ提供される場合が多くある。OT環境では、システムの安定性や互換性を確保するために特定のベンダに依存したクローズドな環境が構築される。OT環境では、ベンダのライセンスやサービス契約により、サードパーティのセキュリティソリューションが許可されないことがある。これは、システムの安定性や安全性を確保するための措置だが同時に柔軟性を制限することにもなる。さらに、ベンダの承認や同意なしにサードパーティ製アプリケーションをインストールすると、サービスサポートが受けられなくなる可能性がある。これは、OT環境の運用において大きなリスクとなり得る。

このようなサポート体制の違いは、セキュリティ対策の実施方法にも大きな影響を与える。ITシステムでは比較的自由に最新のセキュリティソリューションを導入できるが、OT環境ではベンダの制約内で対策を講じる必要がある。

世の中には、既にOTのセキュリティ監視やセキュリティソリューションが存在するが、この問題とどのように向き合っているのか非常に気になる。セキュリティベンダがOTコンポーネントのベンダと手を組んでやっているのか、セキュリティベンダはバレないようにやっているのか、それともセキュリティベンダが責任を持って引き受けることがあるのか。

コンポーネントの寿命(Component lifetime)

IT環境とOT環境のコンポーネント(機器、ソフトウェア、仕組み)には寿命の面でも大きな違いがある。

ITコンポーネントの寿命は、おおよそ3年から5年程度と思われる。結局のところ、技術の急速な進化による新しいソフトウェア、ハードウェアの登場で比較的短いサイクルで更新が行われる。

OTコンポーネントは、多くの場合特定の用途や実装のために技術が開発されており、寿命は10年から15年、場合によってはそれ以上になる。それらの対象の機器や制御システムが専用の用途にしか使用されず、それらが長期間に渡って安定して稼働することを前提に設計されている。また、OTコンポーネントは長期間使用され、時間の経過とともに脆弱性が発見される可能性がある。しかし、稼働中のシステムを簡単に更新できない場合も多く、セキュリティと安定稼働のバランスが課題となる。

コンポーネントの設置場所(Component location)

ほとんどのITコンポーネントと一部のOTコンポーネントは、基本的な交通手段で物理的にアクセス可能な企業の建物や商業施設に設置されている。これらの場所は比較的アクセスが容易で、一般的な業務環境内に存在している。工場、発電所、パイプライン、送電網など、産業インフラの一部など、分散型のOTコンポーネントは広範囲に分散していることが多い。孤立している遠隔地などに存在し、頑張らないと辿り着けないような僻地な場合がある。

コンポーネントの設置場所は、必要な物理的および環境的なセキュリティ対策も考慮する必要がある。設置場所の特性に応じて、適切なセキュリティ対策が異なる。遠隔地や孤立した場所にあるOTコンポーネントは、物理的なアクセス制御が難しい一方で、自然災害や環境条件からの保護が必要となる。また、アクセスが困難であるため、メンテナンスや緊急対応の計画も特別な考慮が必要。