ここ数年、ゼロ・トラスト・セキュリティ・モデル(ゼロ・トラスト・アーキテクチャー)は、技術者にも非技術者にも人気を博している。
トラスト・バイ・デザインのアプローチは時代遅れであり、コンテクストを動的に考慮することなく、デバイスやアプリケーションを先験的に信頼すると、物事がいかに悪い方向に進むかを示している。簡単に言えば、同じネットワーク上にあるからといって、デバイスやアプリケーションを信頼できると考えるのは、古く、安全でなく、間違った仮定なのだ。
タダ飯はない
ゼロ・トラスト(ZT)を適切に適用するには、システムがどのように相互作用し、互いに何を必要とし、情報へのアクセスをどのように最小化するかを研究する必要がある。特に、相互作用するシステムがすでに存在し、ZTを実施するために進化させたり適応させたりする必要がある場合はなおさらだ。
サイバーセキュリティの専門家として、私たちは、上司を喜ばせるような新しいことのチェック・ザ・ボックスの仕事をしたいわけではない。理論に書かれていることを最も厳密な方法で実装したい。さもないと、時代遅れのtrust-by-design-アプローチと同じ問題に対処することになる(多少複雑さは増す)。自己署名されたローカルTLS証明書が何度受け入れられ、たとえ安全でなくても、CAが発行した証明書と正しくデプロイされることはない。例を挙げればきりがない。
よく言われる格言が示すように、この目標を本当に達成するためには、やるべきことがたくさんある。
原理的には、ZT実装の望ましい最終目標は、すべてのコンポーネント(一部でもなく、最も重要なものでもなく、既知のものだけでもなく、すべて)が、アクセスに関するすべての検証を行った上で相互作用することである。しかし、これを達成するためには、すべてのデバイス、アプリケーション、通信プロトコルがZTを念頭に置いて設計されている必要がある。これは今日、すべてのケースで可能なのだろうか？しかし、そこに到達するための計画を描くことはできる。
1つ目は、トラスト・バイ・デザインの古い習慣は取り除かれたものの、技術の限界のために問題が残っている状態、そして2つ目は、システムのあらゆる部分がZTアプローチをサポートする状態である。
最初のマイルストーンは十分な努力で達成可能なはずだが、2番目のマイルストーンには時間がかかり、段階的に達成される可能性が高い。さらに重要なのは、標準化のさまざまなコミュニティで協力する最高の技術的才能が必要だということだ。
バイアスを取り除く：信頼ゼロへの最初のマイルストーンOT とIoT
ゼロ・トラストの信条は、デザインによる信頼ではなく、アプリケーション／デバイス／システムで認証されたユーザーが、与えられたコンテキスト(このコンテキストの一部はデバイスの健康状態である)で、与えられたリソースにアクセスする権利を持っているかどうかを常に検証することである。
これは十分に汎用的であるが、悪魔は細部に宿る！リソースへのアクセスを要求するシステムは、どの程度の粒度なのか？デバイス全体なのか、アプリケーションなのか、それとも特定のセッションなのか？あるいはもっと細かいのか？また、アクセスを要求されているリソースの大きさは？システム全体なのか、ファイルなのか、レコードなのか、属性なのか？
忘れないで私たちはボックスにチェックを入れたくない
この最初のマイルストーンの目標は、ZT の骨格を構築することである。NIST.SP.800-207文書では、ZTを採用するための3つの主なアプローチとして、「強化されたIDガバナンスを使用するZTA」、「マイクロセグメンテーションを使用するZTA」、「ネットワークインフラおよびソフトウェア定義境界を使用するZTA」が説明されている。これらはいずれも実現が容易でなく、既存システムとの完全な互換性も保証されていない。
私たちは、エージェントや適切に機能し設定されたファイアウォールのような、何らかの形のポリシー決定・実施ポイントを導入することができる。これは間違いなく最初のマイルストーンの一部である。"同じLAN＝より安全 "という偏見を取り除き、異なる考え方を始めるのだ。しかし、もっと詳しく見てみると、ZTが解決したい問題を完全に解決することはできない。
その理由を見てみよう
Modbus、DNP3、またはIEC 104を使用してPLCと接続するHMIまたはSCADAが1つある最小のOT セットアップを考えてみましょう。そして、HMIにZT対応エージェントをデプロイし、2つのアクターが通信するための専用ネットワークを持つようにネットワークをマイクロセグメント化できたとします。悪意のあるアップデート(オートメーションベンダーが侵害されたサプライチェーンベースの攻撃とします)が、USBキー経由でメンテナンス中にHMIにインストールされる可能性があります。HMIがPLCにアクセスできるようにするかどうかは、「はい」か「いいえ」の2択になります。
そこではプロトコルの制限があるため、アプリレベルのセマンティクス、たとえば制御されるセンサ/アクチュエータなどのために、PLC へのきめ細かなアクセスを許可することは複雑(または実質的に不可能)になります。ZT 用語を念頭に置くと、リソースの概念を十分に小さな領域に制限することはそれほど簡単ではありません。それはおそらく PLC 全体でしょう。
上記の例では、オープンで標準的なプロトコルを使用した。しかし、OT 、IoT のネットワークは、多種多様なプロプライエタリ・プロトコルによって特徴づけられており、このような側面に取り組むことを困難にしている。そしてもちろん、不明瞭さによるセキュリティは解決策にはならない。
もう一つの課題は、アプリケーションを変更することなくセッション認証を行うことである。多くのOT 、IoT プロトコルには認証と認可が組み込まれていないか、そのための非常に基本的なモデルしかない。また、オペレータは共有アカウントでログインすることが多いが、それはまた別の話である。
資産の健全性については？
別のトピックに移ろう。資産は、その健全性も考慮してリソースへのアクセスを許可されるべきである。つまり、パッチが適用されていなかったり、アンチウイルスがエンドポイントにインストールされていなかったり、シグネチャが古かったりする場合、そのアセットは、更新と再試行が可能なサービスにのみアクセスできるべきである。例えば、OT 環境では、オートメーションベンダーは、HMI にインストールする前に Windows の更新を検証するのが一般的である。現実的なZTの展開では、これを考慮し、パッチに一定のギャップを持たせるべきである。繰り返しになるが、理論的なZTモデルは完全には適用されず、管理されないリスクの余地を残すことになり、最終的には完全で絶対的なセキュリティという誤った認識から生じることになる。
プロトコルに関連した課題によって、ZTは実装可能ではあるが、レガシーな仕様やコンテクストによって、最終的にいくつかの制限やトレードオフが与えられることは、もはや明らかだろう。
古い制限の修正：OT 、信頼ゼロへの第二のマイルストーン。IoT
最初のマイルストーンは、同じネットワーク上に住む2つの資産は他よりも信頼できるという古い態度を取り除くことだ。しかし、前のセクションで見たように、今すぐ完璧なデプロイメントを行うことは不可能だ。この2つ目のステップで、その欠点を修正したい。
そして、それは私たちだけの ものでは ありません。 これは顧客X、Y、Zのためのプロジェクト・マイルストーンではありえない。より多くの時間と協力が必要で、目指すべき漸近線のようなものになる。しかし、パズルの各ピースが適切な場所に収まるにつれて、完成度は高まるだろう。
プロトコルの制限については、2つのアプローチが考えられる。標準プロトコルがZTの原則を取り入れるように進化し、業界で採用されるか、あるいは、様々なベンダーがプロトコルを適応・進化させ、ZTを適切に実装するソリューション(エージェント？
標準プロトコルが認証と認可をフローに組み込み、リソースによりきめ細かくアクセスできるようにするため、いくつかの面で取り組みが行われている。例えば、電力システム分野では、 IEC 62351規格ファミリーが、ZT展開をより高度にするための有用なビルディング・ブロックを追加している。ODVA標準開発組織は、EtherNet/IPOT 通信プロトコルを改善し、CIPセキュリティ拡張機能による包括的なアップデートを追加しました。
プロトコルが進化し、あらゆる業種やコンテクストに対して適切なセキュリティ機能を提供できるようになるには時間がかかる。あなたにとって何が重要かを定義するワーキンググループに参加し、最新情報を入手し、必要な進化に貢献することをお勧めする。
例えば、パッチの適時性と適切な品質の保証について言及した。ソフトウェア・インフラを進化させ、より迅速で自動的な検証を可能にすると同時に、アセット・ヘルス・サービスとうまく統合させ、PDP/PEPが状況に応じて適切な判断を下せるようにするには時間がかかるだろう。
しかし、パデュー・モデルはどうだろうか？
テクノロジーの世界は進化し、収束している。そして今日、コンピューター・ネットワークを見て、何がITで、何がOT 、何がIoT (またはIoMT、IIoTなど)なのかを見分けるのは興味深いことだ。境界線は曖昧になっており、ラベルのことは忘れて、結局のところ、すべてはテクノロジーに過ぎないということを思い出した方がいい場合もある。可能な限り最善の方法で保護されるべき、ひとつのシステムなのだ。
とはいえ、OT の世界では、パデュー・モデル(あるいはパデュー・エンタープライズ・リファレンス・アーキテクチャ)は何十年も前から存在し、新しいシステムを設計したり、古いシステムを進化させたりするためのリファレンスとして使用されている。
パデュー・モデルの要点は、ネットワークをレベル分けし、各レベルが近接するレベルとのみ通信できるようにし、レベルが上がる(つまりオートメーション機器から遠くなる)ほど、基礎となるプロセスのセキュリティをより厳しくすることである。
ゼロ・トラストとパデュー・モデルの共通点は何か？どちらも資産を組織的に相互接続し、特定のリソースへの望ましくないネットワークアクセスを最小限に抑えようとするソリューションである。しかし、ZTには、パデュー・モデルを時代遅れにする可能性のある概念が追加されている。必ずしもここでその話を切り出したいわけではないが、Purdue Modelの観点からZTを見る1つの可能性として、レイヤーの分離だけでは不十分であるため、より多くのコントロールを導入する必要があるということがある。一方、ZTはより柔軟で、おそらく同じように安全なアーキテクチャをOT 。
まとめ
これまで見てきたように、OT とIoT のZTは、(信頼の欠如と)同じくらい検証に関するものである。
しかし、少なくとも考え方として、それを採用し始めるのは良いことだ。ゼロ・トラストは今後5～10年は進化していくだろう。同じ名前かもしれないし、別の名前かもしれないが、コンセプトは確実に残り、進化していく。
Nozomi Networks なぜなら、各資産の可視性、継続的なモニタリング、健全性に関する知識は、ZTの中核をなすものだからだ。そして、良いニュースは、このような移行は非常に非侵入的な方法で始めることができるということだ。
同時に、Nozomi Networks 、同様のソリューションを導入することはスタートに過ぎないことを理解することが重要である。ゼロ・トラストへの完全移行には、広範な計画、時間、努力が必要である。
