D02 - パッチ管理戦略

インフラストラクチャにタイムリーにパッチを適用しないことは IT 業界で依然として最も頻繁に発生するセキュリティ問題であり、WannaCry や NotPetya などのウィルスが立証しています。 "既製のソフトウェア" によるほとんどのソフトウェア欠陥はエクスプロイトが作成され使用されるよりずいぶん前からよく知られています。時には精巧なエクスプロイトでさえ必要としないこともあります。必要なのはそれらの既知の脆弱性にすぐにパッチを当てることです。

これは OWASP Top 10 の "既知の脆弱性" [1] と同様のものです。

特定のパッチが いつ 適用されるかについて、ポリシーに同意し、少なくとも共通の理解を得ることが必要です。多くの場合、この戦略は情報セキュリティ責任者 (Information Security Officer) ISO または CISO のタスクになります。 (C)ISO がないことはパッチ管理戦略がないことの言い訳にはなりません。この段落でのパッチ管理戦略という用語は意図する範囲が主に技術的なものではないことに注意してください。パッチ管理戦略の同義語にはパッチ管理ポリシー、パッチ管理計画、セキュリティ SLA があります。

脅威シナリオ

コンテナ環境で発生する可能性がある最悪の事態はホストまたはオーケストレーションツールのいずれかが危殆化することです。前者は攻撃者がホスト上で動作しているすべてのコンテナを制御できるようになり、後者はソフトウェアが管理している すべて のホスト上のすべてのコンテナを攻撃者が制御できるようになります。

ホストに対する最も深刻な脅威は root アクセスにつながる Linux sys(tem) コールの悪用によるコンテナ内からのカーネルエクスプロイトです [2] 。また、オーケストレーションツールにはデフォルトが脆弱であり、過去に多くの問題が発生したインタフェースがあります [3],[4] 。

Linux カーネルからの脅威は syscall のさらなる制限 (D4 参照) およびネットワークアクセス制限 (D3) を適用してオーケストレーションのネットワークベクトルを減らすことで部分的に軽減できますが、パッチを適用する以外に syscall の残りなどの将来のセキュリティ問題を軽減できないことを念頭に置いておくことが重要です。このようなインシデントが発生する可能性は低いかもしれませんが、その影響は大きく、結果としてリスクが高くなります。

タイムリーにパッチを適用することでインフラストラクチャに使用しているソフトウェアが常にセキュアであり既知の脆弱性を回避することを確保します。

別の脅威はホスト上の Linux サービスから発生します。ホスト構成が適切に保護されている場合 (D3 および D4 参照) たとえば脆弱な sshd があなたのホストにも脅威をもたらします。サービスがネットワークや構成を介して保護されていない場合、リスクは高くなります。

使用される "ops" コンポーネントのサポートライフタイムにも注意を払う必要があります。たとえばホスト OS またはオーケストレーションソフトウェアのサポートが切れてしまった場合、セキュリティの問題に対処できない可能性があります。

どうすれば防ぐことができるのか？

異なるパッチドメイン

四つの異なる "パッチドメイン" があるため、インフラストラクチャソフトウェアの保守はそれほど簡単ではありません。

  • イメージ: コンテナディストリビューション

  • コンテナソフトウェア: Docker

  • オーケストレーションソフトウェア (Kubernetes, Mesos, OpenShift, ...)

  • ホスト: オペレーティングシステム

パッチ適用の最初のドメインは一見簡単に見えますが、コンテナソフトウェアの更新が延期されることはめったにありません。オーケストレーションツールとホストはコアコンポーネントであるため、同じことが当てはまります。

上記の各ドメインについて EOL サポートに対する移行計画を立てます。

いつ何をパッチ適用するのか？

要約: パッチを頻繁に適用し、可能であれば自動化します。

上記のパッチドメインに応じて、適切なパッチ適用をどのように実現するか、さまざまなアプローチがあります。重要なのはコンポーネントごとにパッチ戦略を立てることです。パッチ戦略では 通常 パッチと 緊急 パッチを扱う必要があります。またパッチテストとロールバック手順も準備しておく必要があります。

変更またはパッチのポリシーやプロセスがある環境にいない場合、以下をお勧めします (簡潔にするためにテスト手順は省略しています) 。

  • 保留中のパッチが 定期的に 適用されるタイムスパンを定義します。このプロセスは自動化する必要があります。

  • これはパッチドメインごとに異なる可能性があります (リスクが異なる可能性があるため) が、そうである必要はありません。リスクが異なるために異なる可能性があるものとして次があります。公開されたコンテナ、オーケストレーションソフトウェアの API、または重大なカーネルバグはコンテナ、DB バックエンド、またはミドルウェアよりもリスクが高くなります。

  • パッチサイクルを実行し、成功と失敗を監視します。下記参照。

  • 通常パッチ間のタイムスパンが攻撃者にとって大きすぎる環境への重大なパッチに対して、そのような場合に従う必要がある緊急パッチについてのポリシーを定義する必要があります。また、たとえばベンダーの発表やセキュリティメーリングリストを通じて、重大な脆弱性とパッチを追跡するチームも必要です。緊急パッチは一般的に数日または一週間以内に適用されます。

パッチの中にはサービスの再起動、新しいデプロイメント (コンテナイメージ) 、またはリブート (ホスト) を必要とするものがあることに注意してください。これが行われない場合、パッチを適用しないのと同様となる可能性があります。サービス、ホストを再起動、または新しいデプロイメントを開始する際の技術的な詳細もパッチ計画で定義する必要があります。

冗長性を計画しておくと非常に役立ちます。たとえば、コンテナの新規デプロイメントやホストのリブートがサービスに影響を与えないようにします。

どうすれば見つけ出せるのか？

あなたの役割に応じてさまざまなアプローチがあります。外部にいる場合や関与していない場合には、さまざまなパッチドメインに対する計画を尋ねて、その計画を説明してもらうことです。これはシステムを調べることで補足できます。また継続性管理にも注意します。

手動

深く調査をしなくても、ホスト上で以下のような優れた指標を収集できます。

  • uptime

  • 最後にパッチが適用されたのはいつか (rpm --qa --last, tail -f /var/log/dpkg.log) 。どのパッチが保留中か (RHEL/CentOS: echo n | yum check-update, Suse/SLES: zypper list-patches --severity important -g security, Debian/Ubuntu: echo n | apt-get upgrade) 。

  • ls -lrt /boot/vmlinu* と uname -a

  • プロセスの実行時間を見ます (top --> column TIME+) 。たとえば dockerd, docker-containerd* および kube* プロセスなど。

  • 削除されたファイル: lsof +L1

役割が組織の内部である場合、パッチ管理計画が存在して、適切に実行されていることを確認する必要があります。ポリシーをどこから始めるかによりますが [5] をお勧めします。

自動化

ホストの場合: 頻繁にパッチを適用します。現在のすべての Linux ベンダーは自動パッチ適用をサポートしています。パッチを監視するために OpenVAS [6] などの認証された脆弱性スキャンに対して利用できる外部ツールがあります。なお、すべての Linux オペレーティングシステムには未解決のセキュリティパッチを通知する手段をビルトインで提供してもいます。

コンテナイメージに対する一般的な考え方は頻繁に、そして新しくビルドされたコンテナのみをデプロイすることです。ここでもスキャンは対処手段として使用するのではなく、パッチが機能することを検証するために使用する必要があります。コンテナイメージにはさまざまなソリューションが利用可能です [7] 。どちらも利用可能な CVE のフィードデータを使用します。

いずれの場合も、保留中のパッチを通知する監視ソフトウェアに対するプラグインを使用することをお勧めします。

参考情報

コマーシャル

PreviousD01 - 安全なユーザーマッピングNextD03 - ネットワークセグメンテーションとファイアウォール

Last updated