コンテナ脆弱性対応
ServiceNow® コンテナ脆弱性対応 アプリケーションはコンテナ脆弱性一致アイテム (CVIT) をインポートし、ルールに従ってコンテナ脆弱性を修復できるようにします。脆弱性データは、脆弱性情報データベース (NVD) 統合やサードパーティの統合などの内部および外部のソースから取得されます。
ストアでアプリを要求する
ServiceNow Storeにアクセスして、利用可能なすべてのアプリを表示し、ストアに要求を送信する方法を確認してください。リリースされたすべてのアプリのリリースメモ情報については、「ServiceNow Store バージョンの履歴リリースノート」を参照してください。
メリット
- サードパーティのコンテナセキュリティ製品 (Palo Alto Networks の Prisma Cloud Compute など) と統合します。
- ランタイムに展開されているイメージの脆弱性データをインポートし、ランタイムコンテキスト情報 (ホスト、Kubernetes クラスター、サービス、名前空間など) によって脆弱性データを拡張します。
- ServiceNow Kubernetes 検出を使用して、脆弱性から関連する Kubernetes エンティティに対して作成された参照のリストを 構成管理データベース (CMDB) に表示します。
- 脆弱性と修復の傾向に関するインサイトを示す包括的なレポートダッシュボードを提供します。
主な機能
- 実行中のコンテナではなく、CVIT のソース Docker イメージをポイントします。
- イメージ、Kubernetes クラスター、名前空間、またはサービスレベルで追跡する CVIT の粒度を設定します。
- 新しいイメージバージョンを追跡して、修正された脆弱性を特定します。古いバージョンで報告された脆弱性は、新しいイメージバージョンが実行時に展開されると ServiceNow で自動的に解決されます。
- アプリケーションイメージとは別にベースイメージ内の CVIT を追跡して、独立した修復を有効にします。
- 例外要求または誤検出要求を作成します。これらは、複数レベルの承認者プロセスで確認できます。
- CVIT を自動的に保留するための例外ルールを定義します。
ユースケース
- ランタイムコンテキスト
- コンテナイメージの脆弱性は、アプリケーションライフサイクルの次のステージでイメージをスキャンすることで検出できます。
- ステージ 1：CI/CD パイプラインでイメージがビルドされるステージ。
- ステージ 2：イメージがレジストリに公開されるステージ。
- ステージ 3：イメージがランタイムに展開されるステージ。
ステージ 1 とステージ 2 のできるだけ早期の段階で脆弱性を特定することが重要ですが、ランタイム環境に展開されているイメージに対してスキャンを実行することも同様に重要です。これには次のメリットがあります。- 公開された新しい共通脆弱性識別子 (CVE) を特定します。
- 展開されているアプリケーションのリスク体制を正確に可視化します。
- 解決する必要がある脆弱性に優先順位を付けます。脆弱性が原因で影響を受けるアプリケーションサービスまたはビジネスサービスに関するランタイムコンテキストは、優先順位付けの際に役立つ可能性があります。
コンテナ脆弱性対応 は、Palo Alto Networks の Prisma Cloud Compute などのコンテナセキュリティ製品と統合して、ランタイムに展開されているイメージの脆弱性データをプルし、ランタイムコンテキスト情報 (ホスト、Kubernetes クラスター、サービス、名前空間など) で脆弱性データを拡張します。ServiceNow Kubernetes 検出を使用しているお客様に対し、脆弱性から関連する Kubernetes エンティティに対して作成された参照のリストが 構成管理データベース (CMDB) に表示されます。ServiceNow は、メタデータの拡張の他に、脆弱性と修復の傾向に関するインサイトを示す包括的なレポートダッシュボードも提供します。
- 所有責任の特定
- 前提条件
-
Kubernetes メタデータと参照：コンテナ脆弱性対応 が Kubernetes メタデータ (名前空間、クラスターなど) と 構成管理データベース (CMDB) エントリへの参照を入力できるようにするには、Information Technology Operations Management (ITOM) から Kubernetes 検出を実装する必要があります。Kubernetes 検出により、Docker イメージ、実行中の Docker コンテナ、ポッド、Kubernetes クラスターなどが CMDB に入力されます。コンテナ脆弱性対応 は、イメージ ID に基づいて CMDB 内の Docker イメージを識別してから、関連する Kubernetes エンティティを識別して、脆弱性一致アイテムからそれらのエンティティへの参照を入力します。
- クラウドメタデータと Docker イメージラベル：コンテナ脆弱性対応 は、Docker イメージラベル、クラウドアカウント ID、およびイメージが展開されているリージョンも入力します。このデータは、脆弱性一致アイテムに関連付けられている「検出されたコンテナイメージ」レコードに保持されます。このデータを入力するための前提条件はありません。コンテナ脆弱性対応 は、コンテナセキュリティ製品 (Palo Alto Prisma Cloud Compute など) から返されたデータを使用して、これらのエントリを入力します。
-
-
コンテナイメージの脆弱性にパッチを適用する所有責任は、組織によって異なります。この情報は、さまざまな場所で取得できます。特定のコンテナイメージを所有するアプリケーションチームを確認する方法として Docker イメージラベルを使用する組織がありますが、他の組織では、正しい所有者を特定する方法として、コンテナイメージが展開されている Kubernetes 名前空間またはクラウドアカウントが使用されます。
コンテナ脆弱性対応 は、「アサインルール」モジュールで Docker イメージラベル、Kubernetes クラスター/サービス/名前空間メタデータ、またはクラウドアカウントメタデータ (クラウドアカウント ID、リージョン、プロバイダーなど) をキャプチャして使用できるようにするために必要なデータモデル要素を提供します。また、イメージのメタデータまたはランタイム環境に基づいて、脆弱性を適切なアプリケーションチームに自動的にアサインします。
- ベースイメージの脆弱性の追跡
- 前提条件
コンテナ脆弱性対応 で [基準イメージ] プロパティが入力されるようにするには、Palo Alto Networks Prisma Cloud Compute の脆弱性対応統合 コンソールでベースイメージを明示的に設定する必要があります。Prisma Cloud でベースイメージを構成する方法の詳細については、https://docs.paloaltonetworks.com/prisma/prisma-cloud/prisma-cloud-admin- compute/vulnerability_management/base_images を参照してください。
コンテナ脆弱性対応 を使用すると、ベースレイヤーの個別の脆弱性レコードを作成でき、このレコードを別のチームにアサインできます。
コンテナイメージの他のレイヤーで検出された脆弱性から、Alpine などのベース OS イメージで特定された脆弱性を追跡します。多くの組織では、ベース OS イメージにパッチを適用し、すべてのアプリケーションチームがベース OS イメージを利用できるようにする作業を担当する専任チームを設けています。
- 脆弱性一致アイテムの粒度の定義
- 前提条件
次に移動して CVIT の粒度を構成する .
-
デフォルトでは、CVE と Docker イメージバージョン (参照 + タグ) の一意の組み合わせごとに脆弱性一致アイテムが作成されます。ただし、いくつかの Docker イメージが複数の Kubernetes 名前空間に展開されており、各名前空間が異なる事業部門またはチームによって所有されていることがあります。各チームが、脆弱性を修正するための新しいバージョンのコンテナイメージのロールアウトを、それぞれ独自の頻度で行う可能性があります。このような状況に対応するために、コンテナ脆弱性対応 では脆弱性一致アイテムの粒度を定義できます。つまり、Docker イメージバージョンと脆弱性の一意の組み合わせの Kubernetes 名前空間/クラスター/サービスごとに、1 つの脆弱性一致アイテムを作成するかどうかを定義できます。
この例では、同じ Docker イメージと CVE の組み合わせに対して 2 つの脆弱性一致アイテムが作成されていることがわかります。1 つは Kubernetes 名前空間「k8s-finservco-loans」の脆弱性一致アイテム、もう 1 つは「k8s-finservco-wealthandinsurance」の脆弱性一致アイテムです。
- タグベースのサービス識別を使用して影響を受けるサービスを識別する
- 前提条件
- アプリケーション内のさまざまなサービスを識別し、それらのサービスを表すタグ/キーと値のペアを定義します。
- これらのタグまたはラベルを使用して、Docker イメージと Kubernetes ポッドを展開します。
- 適切なタグまたはラベルを使用して「タグベースのサービス」を定義します。
- ITOM Kubernetes ディスカバリーを展開します。
- 適切なタグまたはキーと値のペアを使用して「タグベースのサービス」を定義します。
- コンテナ脆弱性対応 を使用して脆弱性データを ServiceNow にインポートする
-
脆弱性一致アイテムのリスク計算は、CMDB で CI (Docker イメージ) と関連サービスの重要度を確認することで実行できます。ただし、影響を受けるサービスを簡単に特定できるように、コンテナ脆弱性対応 にはタグベースのサービス識別機能があります。
Kubernetes ポッドまたはエンティティが、ServiceNow で任意の「タグベースのサービス」で定義されているキー値に一致するキー値またはラベルを使用して公開されると、コンテナ脆弱性対応 は、Docker イメージと影響を受けるアプリケーションサービスの間の関係を自動的に確立し、リスク計算でそのアプリケーションサービスの重要度を使用します。
フローは次のようになります。- コンテナ脆弱性対応 がコンテナセキュリティ製品から脆弱性データをインポートします。
- コンテナ脆弱性対応 はコンテナ脆弱性一致アイテムごとに、脆弱性がある Docker イメージを CMDB から取り込みます。
- 次に コンテナ脆弱性対応 は Docker イメージラベル、またはこのイメージが展開されている Kubernetes ポッドで公開されているラベル/キー値を調べます。Kubernetes 検出を実行している場合、このイメージは CMDB で利用可能です。
- コンテナ脆弱性対応 は、一致する同じ定義済みのキー値のペアを使用して、CMDB で「タグベースのサービス」を検索します。
- コンテナ脆弱性対応 は、一致する「タグベースのサービス」(検出された場合) の「事業上の重要度」を使用して、コンテナ脆弱性一致アイテムのリスクを計算します。
- 脆弱性の追跡
- 修復ターゲットの設定
ServiceNow では、脆弱性マネージャーが「修復ターゲットルール」を定義できます。これにより、コンテナイメージで見つかった脆弱性の修復に関する Service Level Agreement (SLA) を定義できます。修復ターゲット日は、イメージメタデータまたは脆弱性情報の条件/基準に基づいて定義できます。修復オーナーは、期日が近づいている脆弱性に関するメールを受信します。
- 例外の管理
-
次の理由から、脆弱性のアプリケーションチームまたは修復オーナーが例外を要求する必要があることがあります。
- 緩和コントロールが既に導入されている。
- リスクの受容
- 修正をプッシュするためメンテナンス期間待ちである。
ServiceNow ではセキュリティアドミニストレーターが例外要求に対して複数レベルで承認者を定義できます。特定の条件に一致する脆弱性を自動的に保留する目的で使用できる自動例外ルールを定義することもできます。
最新情報
オーストラリア の新機能と変更点の詳細については、オーストラリア のリリースノートを参照してください。
開始するには
- ServiceNow AI Platform インスタンスの セキュリティオペレーション の概要については、「Understanding Security Operations (Security Operations の理解)」を参照してください。
- ServiceNow Store からダウンロードできる セキュリティオペレーション アプリケーションの詳細については、「Security Operations and the ServiceNow Store (Security Operations と ServiceNow Store)」を参照してください。