ICS環境とパッチ管理:パッチ適用ができないときの対策

avatar

 2020.04.14  Japanブログ編集部

サイバー脅威の環境の変化により、サイバーリスクがセキュリティインシデントに発展する前に、それを特定、分析、評価する能力を強化したいという新たな企業のニーズが浮上しています。パッチ管理脆弱性管理という用語は同じような意味合いで使用されていますが、実はそうではありません。パッチの適用は、サイバーリスクを低減するために私たちができる多くの方策の1つであるため、多くの人は混乱しています。

パッチ適用(およびパッチ管理の)利点とリスク

パッチのインストールを行うかどうか決断する前に、それにともなう利点とリスクについて理解しておくことが重要です。パッチを適用する価値はあるのでしょうか。

パッチ適用の最も明白な理由について、一般的に組織は、「OSやアプリケーションのセキュリティ上の欠陥を修正する必要があるためである」と考えるでしょう。しかし、パッチを適時かつ正確に適用することの利点はそれだけではありません。多くのベンダーは、アプリケーションの安定性改善を目的にパッチをリリースしています。このような改善は、ICS環境においてパッチを展開することの強力な理由となります。なぜならば、重要なデバイスの安定性とアップタイムは最も重要な要素であるからです。さらに、パッチは特定のアプリケーションのバグや欠陥の解決にも役立ちます。これはもう1つの利点であり、組織がパッチを適用すべきである理由を強く後押しするものです。

このような利点だけでなく、パッチを適用しないために生じる悪影響やリスクもあります。それは、企業のOT側と比較して、IT側がどのようにリスクを捉えるかということと密接に関係しています。IT側では、データの損失がネットワークのダウンタイムよりも大きな問題と見なされるため、リスクを上回るメリットが得られます。一方で、OT側では、システムのアップタイムが非常に重要です。IT側とOT側がリスクとメリットをどのように捉えるかは大きく異なります。それについては、次の項で説明することにします。

信頼性が重要な要素であるICS環境においては、誤りのあるパッチや破損したパッチによって重要なネットワークやコンポーネントが停止することが多大なリスクとなり得ます。さらに、15を超える新しい脆弱性が毎日発見されていることを考えると、パッチ適用は、場合によってはフルタイムの仕事となるような、時間のかかる作業です。

リリースされたパッチのテストにかかるコストもまた、考慮すべき問題です。考慮すべきコスト要因についても、企業のIT側とOT側では異なります。どちらの側においても、本番システムに展開する前のパッチをテストするための開発用ラボを構築する必要があります。仮想環境を利用して本番システムをシミュレートできるITの世界とは異なり、OTの世界では、本番システムをシミュレートするためにハードウェアを購入しなければなりません。OTの本番システムの複製に伴うロジスティクスや関連コストは、ITシステムのそれをはるかに上回ります。

さらに、ITでは、自動化されたパッチ管理ソリューションを利用して、すべてのパッチをテストするために必要なスタッフの数と工数を大幅に削減することもできます。残念ながら、OTの場合、そうはいきません。OTチームは、パッチを個々のデバイスでテストする必要があります。またおそらく、ベンダースペシャリストにアップデートの配布を任せなければならないでしょう。これにより、IT側よりもはるかに高い費用が生じます。

最後に検討する必要があるのは、ベンダーの製品ライフサイクルにおける生産終了(EOL)です。IT側にとって、これはそれほど大きいリスクではありません。たとえば、仮想環境などのソリューションを使用すれば、OSのテストとアップグレードをかなり簡単に行えます。アップタイムに対する懸念が軽減されることも考慮すると、OT側とは異なり、IT側では、EOLの問題に対処するのはずっと簡単です。OT環境では、生産システムの一部には、20年以上も使用されているものがあります。そしておそらく、そのほとんどには、アップグレードやパッチの適用が行われていません。何十年もの間完璧に機能していたシステムに対し、ハッキングされにくくするために、リスクを冒してまでパッチを適用するようにOT部門に依頼することは難しいことです。

「問題はハッキングされたかどうかではなく、いつハッキングされるかである」という言葉は、何の対処もしないことのリスクを端的に表しています。残念ながら、多くのOT部門は、ハッキングなど起こるはずがないと思っています。しかし、「いつハッキングされるか」というリスクを詳細に検討すべきであるとともに、「想定外の制御不能なシステムシャットダウンが起きること」と「制御された方法で、セグメント化を行い、手動でパッチ適用すること」のどちらを取るかを比較評価しておくべきでしょう。

IT vs. OT

リスクの認識と優先順位付けに関し、IT側とOT側の違いを理解するには、双方がCIAトライアド(情報セキュリティの原則とされる三大要素)をどのように考えているかを知ることが役に立ちます。

IT側が最も重要視するのは、機密性です。顧客データや従業員の個人データなどの流出は、どの組織にとっても破滅的であり、経済的損失、評判の失墜、ならびに規制上の罰則を伴う可能性があります。IT側にとって、2番目に重要なのは、完全性です。企業が侵害に遭い、データや知的財産が流出すると、企業ブランドや顧客維持率に甚大な影響が及ぶ可能性があります。完全性に影響を与えるインシデントもまた、経済的損失をもたらす可能性があります。また、罰金や不満を抱えた顧客によって通常の収益が失われる場合もあるでしょう。

そして、最後が可用性です。企業は常にシステムの可用性の維持に努めています。特に、顧客に対応するシステムの可用性には注意を払っています。しかしながら、システムがダウンした場合、平均復旧時間(MTTR)への影響は、OT環境よりも、IT環境のほうが期間が短く済みます。仮想バックアップからシステムを再構築することは、物理デバイスを本番環境から外して新しいデバイスと交換するよりもはるかに簡単です。これには通常、ベンダーのスペシャリストが必要となり、より多くのコストとダウンタイムがかかります。

PatchManagement1

一方で、OT側にとっては、可用性が最優先事項です。たとえ短期間であっても、システムのダウンタイムによって、数百ドルや数百ユーロのコストが発生する可能性があるため、このことは、もちろん理解できます。言うまでもなく、そのようなダウンタイムは、社会全体に甚大な影響を与えかねません。万一、電気グリッドにダウンタイムが生じれば、どれだけの家庭が影響を受けるか想像してみてください。さらに、OTシステムが生産停止に陥った場合には、他の企業や業界に影響が波及する可能性があります。なぜならば製品やサービスは、相互に関係し、強く依存し合っているからです。

優先順位の2番目は、ITと同様で完全性です。その理由も同じで、ブランディング、収益の喪失、罰金です。優先順位の最後は、機密性です。もちろんその問題を小さく捉えているわけではありません。実際、産業スパイによる機密データや秘密データの損失は、個人データの損失として、組織にさらに深刻な影響をもたらす可能性があります。

IT、OT間にはこのような違いがある一方で、「安全性」という共通点があります。また、双方の共通点はそれだけではありません。以下のイラストは、IT、OTに固有のシステムやソリューションを示しています。これを見ると、資産の検出、脆弱性評価、ポリシー管理、変更検知、構成評価、ログ管理といった多数の領域がオーバーラップしていることがわかります。

PatchManagement2

OTとITを融合させて1つの技術的なグループとしてまとめたうえでレポートを行う企業であれば、ITヒストリアンを介したすべてのOTデータを分析することの利点を簡単に理解できるでしょう。IT側では、一元化されたオペレーションチームを構成し、注目する脅威のパターンをすばやく識別してOTチームに警告するためのツールがすでに準備されています。その場合、OTチームは、不要な情報に対処するのではなく、単一のイベントを処理することになるため、人員とそれに関連するコストが削減されます。

パッチ適用できない場合は何をすべきか?

ここまでで、ITとOTの違い、およびICS環境におけるパッチ適用のリスクと利点について分析してきました。そのため、特定の状況下においては、パッチ適用を回避すべきである理由についても理解されたと思います。それでは、パッチの適用ができない場合には、他に何をすればよいのでしょうか。

まず、「パッチ管理は脆弱性管理のサブセットである」ことを認識することから始めましょう。脆弱性管理は、スキャンとパッチを行う独立した機能ではありません。脆弱性管理は、デプロイされたハードウェアやソフトウェア上で特定された脆弱性に対処するという難しいタスクを、プロアクティブなビューを活用して管理するという総合的な機能なのです。

脆弱性管理は、インフラストラクチャーにパッチの適用が必要となった際に、アラートを受信するためだけのものではありません。脆弱性管理とは、情報に基づいた意思決定を行って、緩和すべき脆弱性の適切な優先順位付けを行い、その方法を示すためのものです。これは、すべてのソースからの脅威インテリジェンスのための外部フックだけでなく、テレメトリー用の内部フックをすべての対象システムに埋め込むことによって実現されます。

以上のことを考慮すると、パッチの適用を行わないICS組織は、最低限、次のことを行うべきです。

  1. 資産の分析または資産の検出 環境内の保護すべき資産を知ることが目的です。このプロセスによって、「これらの資産は本当にすべて必要か。不要な資産の安全性を確保するために無駄な時間を費やしてはいないか?」という疑問が提起されることもあるでしょう。
  2. 境界の保護 物理的およびデジタル的な侵入に対して組織を強化します。ファイアウォールやアクセス制御などもそのための手段です。
  3. セグメンテーション 水平移動を防ぎ、セキュリティインシデントが組織全体に及ばないよう封じ込めを行ううえで非常に役立ちます。
  4. ログ管理 IDSツールとして、あるいは変更を検出する目的で使用するものではなく、組織内の動きを監視し、潜在的な攻撃を検出する目的で使用されるツールです。
  5. 脆弱性評価 潜在的な弱点を特定し、各資産の脆弱性リスクを特定します。脆弱性スキャンが完了すると、各脆弱性に対しスコアが付けられます。このスコアは、「脆弱性を悪用するために必要なスキル」と、「悪用によって攻撃者が得ることのできる権限」を元に算出されるものです。脆弱性が悪用されやすく、悪用によって得られる権限が高いほど、リスクスコアは高くなります。
  6. ファイル整合性監視 (FIM) ICS組織内で実際に発生している変更を監視します。前述のステップは主に外部の脅威とその監視を対象としていますが、FIMは組織の内部を対象とするものです。内部の動きを実際の変更と関連付けて、不要な情報をさらに減らしたうえで、アラームを発します。

Tripwireの対応

最高レベルのソリューションで構成されるTripwireのポートフォリオは、最大限の柔軟性を提供しており、それぞれを連携させたり、スタンドアロンのソリューションとして使用することが可能です。Tripwireのファイル整合性マネージャーは、組織内で発生したすべての変更を特定し、アラートを生成するファイル整合性および構成評価ソリューションです。誰が、いつ、どのような変更を行ったかといった変更の詳細を、サイドバイサイド形式の比較レポートとして提供します。

Tripwire IP360は、ネットワーク上の資産を検出するだけでなく、13万超の固有のテストから得られた既知の脆弱性データベースに照らして、それらの資産の脆弱性をスキャンする脆弱性ソリューションです。IP360もまた、独自のスコアリングアルゴリズムを使用して脆弱性の優先順位付けを行えるユニークなソリューションです。この優先順位付けのメソッドにより、組織が重点を置いて対処すべき脆弱性の数が減り、組織のパッチ管理戦略が容易になるため、非常に有効です。

Tripwire Log Centerは、完全かつ安全で信頼性の高いログ収集を提供し、大量のデータから関心のあるイベントに焦点を当てることができる「スマートなヒストリアン」であると考えることができます。

最後に、Tripwire Industrial Visibility(TIV)は、Tripwire EnterpriseやIP360と同様に、重要な構成要素の取得、処理、アラート生成を行うよう設計された、ICSに特化したソリューションです。ただし、TIVでは、データパケット分析の観点から(つまり、エージェントレス型の「ネットワーク上」のトラフィックモニタリング機能により)これらを実行します。

すべてのTripwireソリューションを統合すると、推奨されるセキュリティ対策が最低限(パッチ管理を含む)として提供されるだけでなく、潜在的な脅威の検出に必要なデータの量を低減するプロセスも同時に提供されます。エージェントベースとエージェントレスの両方のテクノロジーを使用できるため、組織は、エンドポイントの安定性、保証、多様性を心配することなく、インフラストラクチャー内のあらゆるデバイスを対象に含めることができます。どのようなデバイスであるかは関係なく、重要なデバイスであるとみなすのであれば、それは例外なく監視・レポートの対象とすべきです。それが、パッチ管理の背後にある哲学なのです。

トリップワイヤ・ジャパンでは脆弱性管理、法規制遵守、インシデント対応やサイバーセキュリティに関する有益な情報をお届けしております。すべてのカタログ、セキュリティに関する情報はこちらからダウンロードいただけます。Tripwireセキュリティ リソース

TRIPWIRE IP360 データシート

RECOMMEND関連記事


RECENT POST「ICS」の最新記事


この記事が気に入ったらいいねしよう!