セキュリティ監視ソリューションのベンダーによって書かれたこの記事では、otシステムのパ 著者は、それは難しいので、セキュリティを改善するために他の方法に目を向けるべきだと主張しています。 彼の理論は、彼のような警告技術をオンにし、保留中のアラームをセキュリティインシデント対応チームとペアにすることです。 言い換えれば、パッチ適用を受け入れるだけでは難しいです、あきらめて、以前の学習に多くのお金を注ぐ（多分？）と、より積極的に応答します。
しかし、この結論（パッチ適用は難しいので気にしないでください）は、いくつかの理由で欠陥があります。 言うまでもなく、彼はまた、考慮すべき対応や修復を大幅に複雑にする非常に大きな要因についても言及しています。
これが危険なアドバイスである最初の理由は、パッチ適用を無視することはできないということです。 できること、できるときに行う必要があり、パッチ適用がオプションでない場合は、プランB、C、およびDに移動します。 何もしないことは、あなたの環境に自分の道を作る任意およびすべてのサイバー関連の事件が最大の被害を生成することを意味します。 これは20年前のM&m防御によく似ています。 これはあなたの保証解決が外側で堅く、カリカリ、内部で柔らかく、歯ごたえがあるべきであるという考えである。
このアドバイスが間違っている第二の理由は、OTセキュリティスタッフ（インシデント対応やパッチ適用のため）が見つけて展開するのが簡単であ 実際、この記事で参照されているICSセキュリティインシデントの1つは、パッチが利用可能でインストールの準備ができている間に、パッチのインス プロアクティブなパッチ管理プログラムの一環として、既知のイベント前の保護を展開するためにセキュリティ専門家を解放できない場合、遅すぎる
最後に、この議論の欠けている部分は、OT/ICSパッチ管理に対する課題が、OTネットワーク内の資産とアーキテクチャの量と複雑さによってさらに悪化する 明確にするために、新しいパッチや脆弱性がリリースされたときに、スコープ内の資産の数とその場所を理解するほとんどの組織の能力は課題です。 しかし、インシデント対応チームが効果的であるためには、同じレベルの洞察と資産プロファイルが必要です。 パッチ適用の練習を無視する彼の助言は強い、文脈上の目録（パッチ適用のための基礎を造らなければならないことを避けることができない!）あなたのOTサイバーセキュリティプログラムの基盤として。
では、どうすればいいですか？ まず第一に、パッチを適用しようとする必要があります。 成熟したICSパッチ管理プログラムを成功させるためには、次の3つのことが含まれている必要があります。:
- リアルタイムのコンテキストインベントリ
- 修復の自動化(パッチファイルとアドホック保護の両方)
- 補償コントロールの識別と適用
パッチ管理のためのリアルタイムコンテキストインベントリ
ほとんどのOT環境はWSUS/SCCMのようなスキャンベースのパッチツールを使用している。私たちが持っている資産とそれらがどのように構成されているかを示すために、標準的ですが、過度に洞察力がありません。 本当に必要なのは、運用コンテキストが含まれた堅牢な資産プロファイルです。 私はこれによって何を意味するのですか？ 資産IP、モデル、OS、等。 最新のパッチの範囲内にあるかもしれないものの非常に大まかなリストです。 より価値のあるのは、安全な運用に対する資産の重要性、資産の場所、資産の所有者などの運用コンテキストです。 すべてのOT資産が平等に作成されているわけではないため、新興リスクを適切に文脈化するために。 では、まず重要なシステムを保護したり、適切なテストシステム（重要なフィールドシステムを反映している）を特定し、戦略的にリスクを削減し
そして、これらの資産プロファイルを構築している間、IP、Macアドレス、OSバージョン以外の資産についてできるだけ多くの情報を含める必要があります。 インストールされているソフトウェア、ユーザー/アカウント、ポート、サービス、レジストリ設定、最小特権制御、AV、ホワイトリスト、バックアップステータ これらの種類の情報源は、新たなリスクが発生したときに、行動の優先順位を正確に決定し、戦略を立てる能力を大幅に高めます。 証拠をしたいですか？ 以下に提供される通常の分析フローを見てみましょう。 さまざまな段階で質問に答えるためのデータはどこで入手できますか？ 部族の知識？ 本能？ なぜデータではないのですか？
ソフトウェアパッチ適用の修復の自動化
ソフトウェアパッチ適用のもう一つの課題は、パッチ(または補償コント OTパッチ管理で最も時間のかかるタスクの1つは、準備作業です。 通常、ターゲットシステムの識別、パッチの展開の構成、失敗したときのトラブルシューティング、または最初にスキャン、パッチのプッシュ、および成功を判断するための再スキャンが含まれます。
しかし、たとえば、次回BlueKeepのようなリスクが発生したときに、ターゲットシステムにファイルを事前にロードして、次の手順に備えることができたらどう あなたとあなたのより小さく、より機敏なOTセキュリティチームは、資産の場所や重要性などの堅牢な資産プロファイルの任意の数の要因に基づいて、
さらに一歩進んで、パッチ管理技術が最初にスキャンを必要とせず、すでにパッチをスコープ内のアセットにマップしていて、それらをインストールした
今すぐパッチを適用できない、またはパッチを適用したくないすべてのリスクの高い資産について、代わりにポート、サービス、またはユーザー/アカウントの変更をアドホック補正コントロールとして作成することができます。 そのため、BlueKeepなどの脆弱性のために、リモートデスクトップまたはゲストアカウントを無効にすることができます。 このアプローチはすぐにそしてかなり現在の危険を減らし、また終局のパッチのために準備するより多くの時間を可能にする。 これは、パッチ適用がオプション補償コントロールではないときに何をすべきかの”フォールバック”アクションに私をもたらします。
補償コントロールとは何ですか？
補償コントロールは、単にアクションとセキュリティ設定であり、パッチ適用の代わりに展開することができ、また展開する必要があります。 これらは通常、（可能であれば）積極的に展開されますが、イベントで展開したり、BlueKeepのパッチを適用している間にリモートデスクトップを無効にするなど、保
OTセキュリティでの補償コントロールの特定と適用
補償コントロールは、アプリケーションのホワイトリストやウイルス対策の最新情報の保持から、多 しかし、このケースでは、OTパッチ管理の重要なサポートコンポーネントとしてICS endpoint managementに焦点を当てたいと思います。
補償制御は、積極的にも状況的にも使用することができ、また使用する必要があります。 休眠している管理者アカウントや、エンドポイントにインストールされている不要または未使用のソフトウェアを発見することは、OT cyber securityの誰に また、ベストプラクティスのシステム強化の原則が、私たちが望むほど普遍的ではないことも秘密ではありません。
私たちのOTシステムを真に保護するためには、私たちも大切な財産を強化する必要があります。 リアルタイムで堅牢な資産プロファイルを使用することで、産業組織は、低いぶら下がっている果実（休止中のユーザー、不要なソフトウェア、およびシステ
不幸な出来事では、我々には新たな脅威（BlueKeepのような）があり、一時的な補償コントロールを追加することは可能です。 私のポイントを強調するための簡単なケーススタディ:
- BlueKeepの脆弱性がリリースされました。
- 中央チームは、リスク期間中にリモートデスクトップサービスを有効にするために、システムごとに特定の要求を必要とするすべてのフィールドアセット
- Central teamは、スコープ内のすべてのアセットにパッチファイルを事前にロードします。
- 中央チームは、資産の重要性、場所、補償コントロールの有無によって最も合理的な行動計画を決定するために招集する（すなわち、最後のバックアップに失敗した影響力の高い資産に対する重大なリスクは、リストの一番上に行く。 ホワイトリストが有効で、最近の良好な完全バックアップがある影響の低い資産は、おそらく待つことができます）。
- パッチ適用のロールアウトが開始され、進行状況はグローバルレポートでライブで更新されます。
- 必要に応じて、OT技術者はパッチの展開を監督するコンソールにいます。
- この必要性のスケジュールと通信は、中央チームが使用するデータによって完全に計画され、優先順位が付けられています。
これは、OTパッチ管理の処理方法です。 そして、より多くの組織が場所にこのタイプのプログラムを配置し始めています。
補償コントロールで積極的に
ICSパッチ管理は難しいですが、単に試してみることをあきらめることも良い反応ではありません。 先見の明のビットと、より容易で、より有効な修繕および/または償い制御に三つの最も強力な用具を提供することは容易である。 Insightは、あなたが持っているもの、それがどのように構成されているか、そしてそれがあなたにとってどのように重要であるかを示しています。 コンテキストを使用すると、優先順位を付けることができます（最初のパッチの試行–秒は、補償コントロールを適用する方法と場所を知ることがで このアクションにより、修正、保護、偏向などが可能になります。 監視にのみ依存するには、火災を期待し、より多くの煙探知機を購入すると、損傷を最小限に抑えることができます認めることです。 どのアプローチをあなたの構成が好むことを考えるか。