共通のリスク言語を構築する: OT（オペレーショナルテクノロジー）を巡る変化する視点
本サイト上のコンテンツは、参照目的だけのために、英語の原本から翻訳されたものです。また、本サイト上のコンテンツの一部は機械翻訳されたものです。日本語版と英語版の間に何らかの齟齬がある場合には、英語版が優先されます。当社は改善のためのあらゆる努力を行いますが、翻訳の正確性及び信頼性は保証せず、当社に故意または重大な過失がある場合を除き、不正確性又は遺漏により生じる損失又は損害に責任を負わないものとします。
世界中で 重要インフラへの攻撃 が増加しているという話は皆読んだことがあると思います。アメリカでは 水道システム や 医療機器 への成功した攻撃から、 日本では冷凍食品サプライチェーンの凍結が被害に遭うなど、OT（オペレーショナルテクノロジー）を取り巻くリスクは現実のものとなっています。運用技術(OT)デバイスのプロファイリングや攻撃技術は10年以上にわたり広まっています。 AIベースのツールキット は攻撃を容易にしました。恐怖、不確実性、疑念(FUD)はこれでブログ記事を一つ分くらいにまとめておきますね!代わりに、ITやOT業界がどのように考え方を変え、それによって物語を変えているのかについて話したいと思います。
激しい議論と解決策
そうした変化は、決して簡単に進むものではありません。実際、つい先週、OTサイバーセキュリティ業界で15年の経験を持つベテランから、IT担当者とOT担当者のグループによる議論が、最終的に怒鳴り合いへと発展する場面を目撃したという話を聞きました。議論のテーマは、PLC（Programmable Logic Controller：プログラマブルロジックコントローラ）に二要素認証（2FA）を適用するべきかどうかでした。PLCは、パイプラインやHVAC（空調設備）、風力発電設備、コンベヤーベルト、遠心分離機などの物理システムを制御する装置です。IT担当者にとって、2FAの実装は当然の対策です。しかし、OT担当者にとっては、それは考えられないことかもしれません。
なぜこんなことが起こるのでしょうか?
従来、ITとOTの従業員は、下の表に示すように、根本的に異なる考え方や動機を持ってきました。
考え方の違い
| 原理 | ITの考え方 | 作業療法の考え方 | OTの担当者が言うかもしれないこと |
| 稼働時間 |
場合によっては「ファイブナイン（99.999%の可用性）」の実現も不可能ではありません。しかし、機器の特性やプロトコル、運用手順、そしてコストの観点から、実際には現実的でないこともあります。再起動が発生することも珍しくありません。
|
稼働率（アップタイム）に影響を与えることは許されません。100％の稼働率は当然の前提です。システムはシンプルさを重視して設計されています。冗長化も当然の前提です。再起動が行われることはめったにありません。
|
「単純な再起動？それは壊滅的な損失か、生産性の低下を意味する。」 |
| レイテンシ許容範囲 |
さまざまな遅延やジッター（通信のばらつき）、さらには時間に起因する問題も許容できます。何よりもパケット化が優先されます。
|
厳しいタイミング要件が求められるため、遅延やタイミングのずれに対する許容範囲は極めて小さい。
|
「わずかな遅延であっても、人命に関わる事故につながったり、工場の操業が混乱したりする可能性がある。」
|
| システム制御/アクセス制御 |
システムを制御する前に、2FA（多要素認証）からアクセス制御機能まで、さまざまな要件を満たさなければなりません。相互依存性とシステム間の接続性は当然の前提となっています。
|
システムは制御信号に対して即座に応答しなければなりません。そうでなければ、人の安全が脅かされ、機器の故障につながる可能性があります。暗号化や認証が、かえってリスク要因となる場合もあります。システムの分離（アイソレーション）は一般的であり、むしろ望ましいとされることも少なくありません。
|
「非常停止ボタンを押したときは、何ものもその動作を妨げてはならない。2FAであっても例外ではない。」
|
|
長寿命性
|
古いシステムは、しばしば負債や技術的負債（テクニカルデット）と見なされます。コンポーネントの寿命は3～5年程度であることが一般的です。
|
システムは長期間の運用を前提に設計されています。15年程度の寿命は珍しくありません。成功とは、安定性を維持しながらライフサイクルを長く延ばすことによって評価されます。
|
「ちょっと待ってくれ。期待された寿命の間、きちんと役割を果たしているシステムを、『古い』という理由だけで問題視しているのか？」
|
| パッチ適用とメンテナンス |
当たり前のこととして受け入れられています。定期的に実施されます。ダウンタイムは許容されることが少なくありません。システムコストが比較的低いため、本番環境に適用する前にパッチを検証するためのステージングサーバーやネットワーク、テスト環境を用意することができます。
|
パッチは十分な検証と確認を経た上で適用しなければなりません。ダウンタイムはほとんど、あるいはまったく許容されません。OTシステムは高価で独自性が高いため、一般的なパッチ適用サイクルが中断されたり、そもそも実施できなかったりすることもあります。パッチ適用はOTチームやITチームではなく、機器メーカーや専門の請負業者によって実施されることが一般的です。通常、「Patch Tuesday」のような定期的な更新サイクルは存在しません。レガシーシステムでは、十分に検討され、文書化され、正式な承認を得たアプローチが求められます。
|
「動いてるよ。直さないで。」 |
| プロトコル | TCP/IPベースのシステムはHTTP、HTTPS、DNSなどを使用します。 | Modbus、ICCP、CIP、DNP3、PROFINET;TCP/IPは比較的新しい技術です。 |
どちらも正しい...そして間違っている。
こうした異なる考え方が存在するのには、それぞれ正当な理由があります。そのため、単純に「OTシステムは古い」と言ったり、OT担当者の考え方を変えるべきだと結論づけたりするのは、正確でもなければ有益でもありません。これは単にシステムを最新化すれば解決するという問題ではないのです。どちらか一方が完全に正しく、もう一方が完全に間違っているわけではありません。考え方やプロセスは変化しつつありますが、こうした従来からの違いは依然として存在し続けており、現在も重要な要素となっています。
何が変わったのでしょうか?
IT担当者とOT担当者の双方が考え方を変える必要がある最大の理由は、攻撃者が従来から存在するITとOTの分断を悪用しているからです。もう一つ重要なのは、IT担当者とOT担当者の双方が、これまで以上に厳しい基準を求められているという事実です。欧州のNIS2やDORAをはじめとする世界各国の法規制や指令により、多くの組織がOTデバイスについても独立した監督体制やガバナンスが必要であると認識するようになっています。
また、技術的な理由もあります。まず、現在のOTデバイスはTCP/IPを利用しています。さらに、リモートデバイスへのアクセス手段も大幅に増えています。かつてのOT機器ではリモートアクセスの選択肢は限られていましたが、現在のデバイスはITシステムと同じような接続方法を備えています。例えば、Secure Shell（SSH）、Webインターフェース、VPN（仮想プライベートネットワーク）などが利用されています。中には、Remote Desktop Protocol（RDP）やVirtual Network Computing（VNC）を使用するものもあります。
私たちは今、同じ船に乗っている: 共通のリスク言語を構築する
では、こうした状況は何を意味するのでしょうか。第一に、IT部門とOT部門のリーダーは、もはやそれぞれが孤立して業務を進めることはできません。第二に、OTやICS（産業用制御システム）に関する知識は、もはや一部の専門家だけが持つニッチなスキルではなくなっています。コンプライアンス担当者、ペネトレーションテスター、セキュリティアナリストをはじめ、多くのIT・サイバーセキュリティ担当者がOTやICSについて理解する必要があります。
CompTIAの取り組み
組織文化を変えるうえで、教育ほど大きな変革をもたらすものはありません。
OTセキュリティを巡る議論を変え、共通のリスク言語を構築したいのであれば、まずはお互いの言葉を理解する必要があります。また、OTを取り巻く攻撃対象領域（アタックサーフェス）を新たな視点で捉えるためには、OTシステムがどのように動作するのかを誰もが理解できるようにしなければなりません。そのためにCompTIAは、CompTIA SecOT+ を開発しました。IT担当者が実際にOTシステムを操作している場面を最後に見たのはいつでしょうか。CompTIA SecOT+では、実践ラボを通じてその体験を可能にしています。
これにより、IT担当者とOT担当者は、監視と可観測性を向上させることが何を意味するのかを共に理解できるようになります。また、稼働率に影響を与えることなく、どのように稼働率をモデル化し、システムのパッチ適用のための予算を確保するかについても共に理解できるようになります。
このためには、人々が両方の考え方を理解することが求められます。そうすることで、担当者はそこに存在するニュアンスや難しい課題を理解できるようになります。