脆弱性ポリシー

By 清水 孝郎 - AUGUST 8, 2023
Topics: Sysdig機能

SHARE:

本文の内容は、2023年8月8日現在のVulnerability Policies(https://docs.sysdig.com/en/docs/sysdig-secure/policies/vulnerability-policies/)を元に日本語に翻訳・再構成した内容となっております。

このページでは、Sysdig Secureのパイプライン、ランタイム、ホストスキャン機能を管理するSysdig脆弱性ポリシーを紹介します。

このドキュメントは、脆弱性管理エンジンにのみ適用されます。Sysdig Secureが2022年4月20日以前にデプロイされた場合は、スキャン機能と脅威検出ポリシーのドキュメントを使用してください。こちらもご覧ください：どのスキャンエンジンを使用するか

概要

Sysdigには、アウトオブボックスで動作するパイプライン、ランタイム、ホストの脆弱性に対するスキャンポリシーが、関連するルールバンドルとともに含まれています。ポリシーとルールの編集や新規作成のプロセスは、どちらも同様です。

利用可能なルール

脆弱性ルール(Vulnerability Rule)

深刻度と脅威(Severities and Threats)

同時に、レポートされた脆弱性が分析対象の特定の本番環境に関連しない場合もあり、特定のソフトウェア・パッケージについて脆弱性がまったくない環境を実現することは、通常は非現実的です。各組織は、評価対象資産が許容範囲内であるか、または非準拠と見なされるべきかを判断するために、脆弱性の許容リスク閾値を設定します。

CVE拒否リスト(CVE DenyList)

このルールに記載されている脆弱性が検出された場合、深刻度やその他の脆弱性属性に関係なく、ルールはフェイルします。

ImageConfig ルール

OCI Image Configuration は、コンテナランタイムおよび実行ツールで使用するイメージと、ファイルシステムのチェンジセットとの関係を記述した JSON ドキュメントです。

つまり、イメージ構成とメタデータで構成されます。

例えば：

  • Entrypoint / CMD
  • Configured user
  • Environment variables
  • Labels
  • Author
  • Creation time
  • Build history
  • … (他にも多くの設定キーがあります。いくつかは必須で、いくつかはオプションです)

Dockerfiles VS ImageConfiguration： Dockerfilesは、イメージの生成に使用される言語を指定します。DockerfileとImageConfigurationファイルは密接に関連していますが、同じ概念ではありません。Docker/Dockerfiles以外の開発ツールを使用して、準拠したImageConfigurationファイルを生成することができます。

デフォルトユーザー(Default User)

エントリーポイントまたはCMDを実行するために設定されたデフォルトユーザー。

rootをデフォルトにすることは、不必要な特権を与え、攻撃者に特権昇格やラテラルムーブメントの動きを許す可能性があるため、推奨されません。

rootを避けるだけでなく、このルールでは、設定しなければフェイルする特定のユーザ（jenkinsなど）を指定することもできます。

推奨されるインストラクション(Recommended Instructions)

COPYの方がより予測しやすく、エラーが発生しにくいため、ADD命令の使用は推奨されません。

パッケージマネージャーインストラクション(Package Manager Instructions)

このルールでは、推奨されるセキュリティプラクティスに従って、パッケージマネージャーインストラクションの使用を禁止します。(イメージビルド中にパッケージマネージャーを使ってパッケージの最新バージョンを直接取得することは、再現性のないビルドにつながる可能性があるため、推奨されません)。

現在、以下のパッケージマネージャー / 更新サブコマンドがイメージのビルド履歴から検出されています：

apk
.*apk upgrade.*
apt
.*apt-get upgrade.*
.*apt upgrade.*
yum
.*yum upgrade.*
rpm
.*rpm (--upgrade|-U).*
pip
.*pip3* install (--upgrade|-U).*
pipenv
.*pipenv update.*
poetry
.*poetry update.*
npm
.*npm update.*
yarn
.*yarn update.*
composer
.*composer update.*
cargo
.*cargo update.*
bundle
.*bundle update.*
gem
.*gem update.*

Code language: JavaScript (javascript)

イメージの作成日(Image Creation Date)

イメージの作成日は、イメージが古くなったことを示すために使用できます。

ノート: イメージの作成日はオプションの属性なので、日付が宣言されていない場合、このルールはフェイルします。

機密情報とシークレット(Sensitive Information and Secrets)

機密情報の漏えいは、最も深刻なセキュリティ問題の一つであり、実際にセキュリティ侵害につながることも少なくありません。このルールを有効にすると、ImageConfig メタデータの機密文字列が解析されます。

イメージラベル AWS_TOKEN で見つかった AWS シークレットの違反例：

このルールで現在利用可能な検出は以下のとおりです：

  • Aws_secret
    • AKIA keys: AKIA[0-9A-Z]{16}
    • Any other key: aws.{0,20}?(?:key|pwd|pw|password|pass|token).{0,20}?
  • Azure storage account key
  • Basic Auth: detects [http,ssh]://user@pass:domain.com
  • JWT token
  • Private keys: 文字列が以下を含むかどうかをチェックします

“BEGIN DSA PRIVATE KEY”,
“BEGIN EC PRIVATE KEY”,
“BEGIN OPENSSH PRIVATE KEY”,
“BEGIN PGP PRIVATE KEY BLOCK”,
“BEGIN PRIVATE KEY”,
“BEGIN RSA PRIVATE KEY”,
“BEGIN SSH2 ENCRYPTED PRIVATE KEY”,
“PuTTY-User-Key-File-2”

ルールバンドル(Rule Bundle)の作成

ルールバンドルは、グループ化されたスキャニングルールのセットです。

ノート：

  • デフォルトのSysdigルールバンドル（Sysdigシャベルアイコンで識別）は削除できませんが、新しいルールバンドルのテンプレートとして使用する場合は複製できます。
  • 同じルールバンドルを複数の異なるポリシーに使用できます。
  • ルールの順序は評価の観点からは関係ありませんが、視覚化しやすいようにお好みで整理することができます。


作成手順

1. Policies > Rule Bundles に移動し、 +Add Bundle をクリックします。

2.パラメータを入力します：

  • Name: このルールバンドルのユーザー割り当て名
  • Description: ユーザーが割り当てたルールバンドルの説明
  • Rules: ルール バンドルは 1～N 個のスキャン ルールから構成されます。ビジュアル エディタを使用して、新しいルール (インターフェイスでは「カード」として表示されます) を作成および設定できます。


3. Saveをクリックします。これで、このルール バンドルをポリシーに添付できます。

例

以下の例では、次の場合に特定の脆弱性のチェックにフェイルします：

  • severityが [High] または [Critical] で、AND
  • 発見から60日以上経過している、AND
  • 修正プログラムが公開されている、AND
  • 公開されているエクスプロイトがある場合

ノート：

  • 同じポリシー バンドルに対して同じルール テンプレートの複数のバージョンを作成できます。つまり、上記のタイプの “Vulnerabilities: Severities and Threats”のカードのような 2 つ以上のカードを作成できます。
  • 同じルール間の条件は AND ロジックで評価されます。上の例のように、脆弱性が違反と見なされるには、すべての条件を満たす必要があります。
  • ルールバンドル内のすべてのルールは OR ロジックで評価されます。
  • いずれかのルールが違反の場合、ルールバンドルは違反です。
  • また、ルールバンドルが違反の場合、それを含むポリシーも違反となり、「フェイル」とみなされます。


スキャン ポリシーの作成

お客様の組織の脆弱性管理ガイドラインを満たすために、必要に応じてカスタムスキャンポリシーとルールバンドルを作成することができます。スキャンポリシーとルールの基本概念は次のとおりです：

  • イメージは、1～N個のポリシーで同時に評価できます。
  • 1つのポリシーには、評価対象となる1～N個のルールバンドルを含めることができます。
  • ルールバンドルは、評価される任意の数のルールで構成されます。

パイプライン(Pipeline)

1. Policies | Vulnerabilities > Pipeline の順に選択します。パイプライン スキャン ポリシー リストが表示されます。

2. +Add Policy|Pipelineをクリックします。

3.パラメータを入力します：

  • Name: このポリシーのユーザー割り当て名
  • Description: ユーザーが割り当てたポリシーの説明
  • Always apply toggle: 使用するマッピング戦略：
    •  Always Apply  が enabled な場合、スキャナーのすべての実行でこのポリシーが適用されます。これは CLI パラメータで上書きできません。
    •  Always Apply が disabledの場合、このポリシーを評価に適用するには、スキャナの実行時に明示的に要求する必要があります。
  • Rule Bundles: ポリシーには、評価対象のルール バンドルが含まれます。このウィジェットを使用して、このポリシーに使用するバンドルを追加、削除、または変更できます。
    •  Edit Assigned Rule Bundles  をクリックし、割り当てるバンドルを切り替えます。 Update をクリックします。
  • このポリシーでイメージをスキャンする方法: スキャナーの実行にポリシーを適用するために使用するコマンド ラインをプレビューするヘルパー ウィジェット。こちらも参照してください： “Sysdig Secure を使い始めるには”も参照してください。

4. Createをクリックします。

ランタイム(Runtime)

1. Policies | Vulnerabilities > Runtimeに移動します。ランタイムスキャンポリシーリストが表示されます。

2. +Add Policy|Runtimeをクリックします。

3.パラメータを入力します：

  • Name: このポリシーのユーザー割り当て名
  • Description: ユーザーが割り当てたポリシーの説明
  • Scope: アセット タイプ (コンテナ イメージのワークロードとホスト) とスコープ値のサブセットから構成されます。
    • Asset Type: デフォルトは  Any Asset です。 Host または Workloadを選択して絞り込みます。
    • Scope:  Entire Infrastructure を使用するか、希望のスコープをビルドアウトします。選択した資産タイプに適用されるスコープ値が表示されます。
      •  See Workloads in this Scope をクリックして、スコープが有効で期待どおりに動作していることを確認します。
      • ノート：アセットタイプ Any Asset を使用する場合、HostsとWorkloadsの両方に適用されるScopeは Entire Infrastructure または kubernetes.cluster.nameのみです。
  • Rule Bundles: ポリシーには、評価するルールバンドルが含まれます。このウィジェットを使用して、このポリシーに使用するバンドルを追加、削除、または変更できます。
    •  Edit Assigned Rule Bundles  をクリックし、割り当てるバンドルを切り替えます。 Update をクリックします。