何百もの修正に対処するには？正しい脆弱性管理ソリューションの選択

By 清水 孝郎 - JULY 17, 2023
Topics: コンテナ、Kubernetes、ホストのセキュリティ

SHARE:

本文の内容は、2023年7月12日にJOSEPH YOSTOS が投稿したブログ（https://sysdig.com/blog/how-to-deal-with-hundreds-of-fixes/）を元に日本語に翻訳・再構成した内容となっております。

共通脆弱性スコアリングシステム（CVSS）のみに頼ることは、効果的な脆弱性管理に関しては不十分です。CVSSスコアは、脆弱性の深刻度を定量的に示すものではありますが、組織にとっての実際のリスクに大きな影響を与えうる文脈的なニュアンスを捉えることはできません。この記事では、脆弱性管理ソリューションの最適な選択方法について説明します。

ネットワークアーキテクチャー、資産価値、エクスプロイトの有無、組織固有の環境などの要因は、現在のCVSSスコアの計算では十分に考慮されていません。

最近、CVSS v4.0のプレビュー版が発表されました。この新バージョンでは、脆弱性管理の文脈的側面をとらえる追加メトリクスを組み込む意向があります。これらのメトリクスがCVSS 4.0でどのように実装されるかについての具体的な詳細は、現時点ではまだ不明ですが、より包括的なアプローチの必要性が認識されたことは有望です。

脆弱性の評価とリスクの優先順位付け

包括的な脆弱性管理を確実にするためには、悪用される可能性があるかの分析、資産の重要性、ビジネスへの影響、Runtime Insights、修正プログラムの有無、回避策の有無など、CVSSスコア以外の追加メトリクスを組み込んだワークフローを確立することが極めて重要です。

次の例でさらに掘り下げてみましょう：

この例では、security_playground という HTTP ウェブサーバのイメージを使用します。常に自分自身の例を使用することをお勧めします。

深刻度の評価

脆弱性の深刻度は、CVSS スコアを計算することによって決定されます。結果として得られる CVSS スコアは、0 から 10 までの範囲で、10 が最も深刻です。深刻度評価は、一般的に以下のように分類されます：

CVSSスコア0.0～3.9：深刻度は低い

CVSSスコア4.0～6.9：中程度の深刻度

CVSSスコア7.0～8.9：深刻度が高い

CVSSスコア9.0から10.0: クリティカルな深刻度

イメージをスキャンしてみましょう。この例では、Sysdig CLI スキャナーを使用しました。Sysdig CLI スキャナについては、こちらを参照してください。

~ % ./sysdig-cli-scanner docker.io/sysdiglabs/security-playground:latest --apiurl https://eu1.app.sysdig.com/Code language: JavaScript (javascript)


その結果、このイメージには3969件の脆弱性があり、そのうち191件がクリティカルであることがわかりました。

実際、1 つのイメージの中で 3969 個の脆弱性に直面することは、圧倒され、対処が困難になる可能性があります。結果にコンテキストを追加するために追加のメトリクスを組み込むことは、これらの脆弱性の優先順位付けと効果的な管理に大いに役立ちます。

エクスプロイタビリティ分析

エクスプロイタビリティ分析では、各脆弱性が悪用される可能性を評価します。多くの脆弱性は理論的なものであり、現実には容易に悪用できません。悪用可能性情報は、セキュリティアナリストによって報告されています。脆弱性の悪用可能性は、以下の場合に確認されます：

  • この脆弱性を狙った攻撃が報告されている。
  • 概念実証（POC）コードが公開されている。

悪用された脆弱性に関する情報を提供するフィードやデータベースには、National Vulnerability Database（NVD）、Cybersecurity and Infrastructure Security Agency（CISA）、Exploit Database（Exploit-DB）など、評判の良い情報源がいくつかあります。

脆弱性スキャナーの中には、スキャンプロセスの一部としてこの情報を提供できるものもあります。前述の例からスキャン結果をフィルタリングしたところ、最初の3,969件の脆弱性のうち、悪用可能な脆弱性が203件、クリティカルな脆弱性がわずか6件であることが判明しました。

Runtime insights 分析

コンテナ環境で報告された脆弱性のほとんどは、実際にはノイズである場合があります。ランタイムに使用されるパッケージに関連する脆弱性だけが、悪用される可能性があります。Runtime insights は、システムコールを深く可視化し、実行時にロードされるパッケージを特定します。

強力な Runtime insights メカニズムは、実行時に使用されるすべてのバイナリを追跡し、それをパッケージとリンクさせ、悪用可能なメモリ内のロードされたパッケージに基づいて脆弱性をフィルタリングすることができなければなりません。

ランタイムにおいてFalcoを用いたパッケージの検出

この例では、クリティカルな CVE の一つは、openssl パッケージで報告されている CVE-2021-3711 です。ご覧のように、影響を受けるパッケージは “libssl-dev, libssl1.1, openssl” です。

Falco では、各コンテナ内でオープンされたファイルを監視するルールを作成するだけでです。

 customRules:
  my_rules: |-
    - rule: Monitor Opened Files in Containers
      desc: Detect when files are opened inside containers
      condition: evt.type in (open,openat,openat2) and container and container.image != "host" and k8s.ns.name= "default"
      output: >
        Opened file: %fd.name
        Process: %proc.name
        Process ID: %proc.pid
        Container ID: %container.id
        Container Name: %container.name
      priority: NOTICE
      tags:
        - file_openCode language: JavaScript (javascript)


このルールでは：

  •  condition フィールドはルールをトリガーする条件を指定します：
    • evt.type in (open,openat,openat2) の場合、ファイルを開くイベントをキャプチャーします。
    • container and container.image != "host" and k8s.ns.name= "default" イメージで実行されておらず、Kubernetes のネームスペース “default “内にあるコンテナに限定。
  •  output フィールドは、ルールがトリガーされたときの出力メッセージを定義します。これには、オープンされたファイルの名前  (%fd.name)、プロセス名 (%proc.name)、プロセス ID(%proc.pid)、およびファイルにアクセスしているユーザ (%user.name)が含まれます。
  •  priority  フィールドは、アラートの優先レベルを設定します。
  •  tags  フィールドには、アラートを分類するための関連タグが含まれます。

デフォルトのネームスペース内のワークロードに対してこのルールを有効にすることで、Falco はファイルを開くためのすべての syscall をログに記録します。 Falco ログをチェックして libssl をフィルタリングすると、libssl が開かれてメモリにロードされていることがわかり、悪用される可能性があります。

これは、脆弱性に優先順位をつけるためにランタイムにおける洞察を活用する例でした。しかし、本番環境では、このプロセスを自動化することが不可欠です。バイナリを自動的に検出し、それぞれのパッケージにリンクし、脆弱性スキャンの結果と比較することで、特定された脆弱性に基づいて効率的にフィルタリングし、アラートを生成することができます。

修正または回避策の有無

脆弱性が発見された場合、セキュリティ上の問題を緩和したり解決したりするための既知の解決策や対処法があるかどうかを判断することは極めて重要です。修正プログラムの入手可能性は、脆弱性に対処するための改善策を適用することの実現可能性と緊急性を判断するのに役立ちます。

修正プログラムの入手可能性は、脆弱性の性質や影響を受けるソフトウエアやシステムによって異なります。修正プログラムは、ソフトウェアベンダによって、ソフトウェアアップデート、パッチ、または特定の設定変更として提供される場合があります。場合によっては、恒久的な修正プログラムが利用可能になるまで、暫定的な回避策や緩和策が提案されることもあります。

修正プログラム提供の例：

私たちの openssl 脆弱性に対する修正策として提案されるのは、openssl のバージョンを 1.1.1d-0+deb10u2 にアップグレードすることです。

回避可能な例：

log4j の悪用は、Log4j2 ライブラリが LDAP と JNDI ルックアップから変数データを受け取り、検証なしで実行できるときに起こります。このシナリオでは、開発チームがこれらのデプロイメントにパッチを当てるまで、log4j サーバへの不正な LDAP トラフィックをブロックするセキュリティルールを作成することが、良い回避策になります。

資産の重要性とビジネスへの影響

資産の重要性とビジネスへの影響は、脆弱性管理の評価において不可欠な要素です。資産の重要性と組織に対するビジネスインパクトに基づいて、最も価値のある重要な資産に焦点を当てることで、修復作業の優先順位を決めることができます。通常、これらの指標は機密性、整合性、可用性の観点から測定されます。

成果

このワークフローに従うことで、最初に発見された3,969件の脆弱性を、早急な対応が必要な2件だけに効果的に絞り込むことができました。

説明したステップは、脆弱性管理のアセスメントと優先順位付けが水面下でどのように機能しているかを示しています。しかし、本番環境では、これらのステップを自動化し促進する堅牢な脆弱性管理ソリューションを実装することが極めて重要です。

最後に、脆弱性管理システムを CNAPP ソリューションに統合し、エコシステムとソフトウェア開発ライフサイクル（SDLC） の中でシームレスな統合を確実にすることは、多くの利点をもたらします。脆弱性管理のようなセキュリティ機能を単一の CNAPP ソリューションに集中させることで、運用を合理化し、複雑さを軽減し、全体的な効率を向上させることができます。エコシステムと SDLC 内の統合により、開発、テスト、デプロイメントを含む様々な段階で、自動化された脆弱性スキャン、アセスメント、および修正プロセスが可能になります。

まとめ

  • 脆弱性管理ソリューションを選択するとき、それがこれらのステップをどのように扱うかを確認してください。
  • ランタイムインサイト（実行時の洞察）を活用して、修復作業の優先順位を決めることは、脆弱性管理ライフサイクルの中核をなす要素であり、堅牢なランタイムエンジン・セキュリティエンジンが必要です。
  • エコシステムに統合され、適合する包括的な CNAPP ソリューションを検討することによって、セキュリティツールを統合するようにしてください。