ルールとルールセット

ポスチャマネジメント、インテリジェンス、Image Assuranceを含むすべてのCloudGuardコンポーネントは、ルールセットを組み合わせて使用して環境をテストします。ルールセットにはルールが含まれています。ルールは、環境内の個々の機能テストです。たとえば、ルールは、環境に「root」ユーザがあるかどうか、またはパスワードポリシーが適用されているかどうかをテストできます。

ルールセットの管理

ルールセット管理には2 つのタイプがあります。

  • CloudGuard-Managed Rulesets - CloudGuardには、リサーチチームが開発したルールセットが組み込まれています。これらのルールは、PCI-DSS、HIPAA、CIS Foundations for AWS、Azure、GCP、Kubernetes などのベストプラクティスおよび一般的なクラウドセキュリティ標準に準拠するために、環境をテストします。これらには、環境に適用できる修復手順が含まれています。

    注 - 環境に修復手順が適用され、CloudGuardが更新された場合(時刻は、内部同期間隔によって異なる場合があります)、評価を再実行して修復を確認します。

  • Customer-Managed Rulesets - CloudGuard管理ルールセットは変更できませんが、コピーを作成してコピーを変更するためにクローンを作成できます。カスタマー管理タイプでフィルタリングすると、変更したルールセットを見つけることができます。

重大度レベル

CloudGuardでは、それぞれの所見に独自のトリガーと状況がありますが、以下では、所見のリスクを反映するための一般的な基準と意味合いについて説明します。

CloudGuard は、5 つの重大度のいずれかを割り当てます。

  • Informational: セキュリティやインフラストラクチャのリスクはありません。管理者の認識が勧められます。

  • Low: セキュリティやインフラストラクチャのリスクはありません。ベストプラクティスに従ってアクションを実行することをお勧めします。

  • Medium: 潜在的なセキュリティリスクが存在する。合理的な期間内に、措置が要求される。

  • High: 潜在的なリスクにつながる可能性があります。ただちに処置が必要です。

  • Critical: アセットが侵害される。ただちに処置が必要です。

重大度の基準と意味

以下の3つの基準は、これらの重大度レベルを定義し、影響を与えます。

  1. Infrastructure exposure: 結果により、攻撃者に不正な行為の機会を与える危険性のある、不必要なインフラストラクチャエクスポージャがあるかどうか。

    1. None: インフラストラクチャのエクスポージャーのリスクはありません。

    2. May lead: 特定の条件下では、インフラストラクチャの露出につながる可能性があります。

    3. Exists: インフラストラクチャエクスポージャーが存在する

  2. Information disclosure: 知見には、機密データの漏洩につながり、悪意を持って使用される可能性のある情報開示が記載されているか。

    1. None: 情報開示のリスクはない

    2. May lead: 特定の条件下では、情報開示につながる可能性がある

    3. Exists:情報開示がある

  3. Potential impairment: 結果が、セキュリティ、設定ミス、またはメンテナンスの観点から、インフラストラクチャまたは情報の障害につながるかどうかを記述します。

    1. None: 減損のおそれがない

    2. May lead: 特定の条件下では、インフラストラクチャまたは情報の障害につながる可能性があります。

    3. Exists: インフラストラクチャまたは情報障害のリードがある

さらに、各重大度レベルは2つの含意レベルと相関します。

  1. 必要なアクションのレベル:

    1. None: アクションは必要ありません。

    2. Advised: ベストプラクティスに従ってアクションを実行することをお勧めします。

    3. Not immediate: 合理的な期間内に、措置が要求される。

    4. Immediate: ただちに対処する必要があります。

  2. 侵害アセット:

    1. None: アセットは侵害されない。

    2. Compromised: アセットは脆弱である。

重大度マトリックス

以下の表は、各重大度レベルと、記載されている基準および影響との関係を示しています。各所見について、その重大度は、少なくとも1つの基準を満たす最も高い重大度によって定義されます。

深刻度 判定基準意味

インフラエクスポージャー

情報開示

減損の可能性

侵害アセット

アクションレベル

情報

なし

なし

なし

なし

なし

低

なし

なし

なし

なし

アドバイス

中

メイリード

なし

なし

なし

即時ではない

高

既存

メイリード

メイリード

なし

即時

クリティカル

-

既存

既存

侵害

即時

悪質なIP分類

悪意のあるIP を識別する規則では、CloudGuard はCheck PointのThreatCloud テクノロジを使用します。各IP カテゴリの意味を次の表に示します。

分類

説明

非分類

サービスがIP を分類できませんでした。このリソースに関する十分なデータはありません。

アドウェア

IPドメインは、法律の灰色の領域で動作し、ユーザ上のプライベートデータを収集し、ダウンロードするサブアプリケーションを含む不要なコンテンツまたはWebサイトを表示する

Volatile

IPドメインには、悪意のあるソフトウェア(ハッキングWebサイトなど)が含まれています。

良性

悪意のある目的を果たさない合法的なIP

CnC サーバ

マルウェアのコマンドと制御

侵害サーバ

ハッキングされ、現在は悪意のある目的を果たしている合法的なIP

フィッシング

IPドメインは、しばしば悪意のある理由で、電子通信における信頼できるエンティティとしてマスカレーディングすることによって、ユーザ名、パスワード、およびクレジットカード詳細(および時には間接的に、お金)などの機密情報を取得しようと試みる

感染源

IPドメインは、訪問者にマルウェアを感染させる可能性があります。

Webホスティング

IPドメインを使用すると、Webサイトのビジネス領域をレンタルできるようになります。

ファイルホスティング

IP ドメインを使用すると、ストレージの領域をレンタルしてビジネスを行うことができます。

パーク

IP ドメインには永続的にコンテンツがありません。登録されているが、オリジナルコンテンツがまだないページに広告コンテンツが含まれている場合があります。

スキャナ

IPは公知のインターネットスキャナである

匿名化装置

IPは既知のトー(オニオンルータ)匿名性プロキシサーバである

クリプトマイナー

IPドメインは、暗号化のために使用される

スパム

IPドメインはスパムに使用されます。

被害ホスト

被害者の知的財産

CloudGuard Rules Repository

CloudGuard コンプライアンスエンジンは、評価、修復、および継続的なセキュリティコンプライアンスの実施のためのエンドツーエンドのセキュリティおよびコンプライアンスソリューションです。CloudGuard GSL (ガバナンス仕様言語) は、CloudGuard コンプライアンスエンジンを使用して、クラウドセキュリティおよびコンプライアンスルールを定義するための構文です。これは、お客様の環境の評価に適用することができます。

Cloud Security Posture Repository は、AWS、Azure、GCP、Kubernetes のセキュリティおよびコンプライアンスに関する共有ナレッジプラットフォームです。これは、CloudGuard によって収集、開発された、進化する一連のセキュリティとコンプライアンスのベストプラクティスを提供します。コントロールには、セキュリティガバナンスおよびパブリッククラウド環境のコンプライアンスに必要なリスクおよび修復の詳細が含まれます。

アクション

新しいルールセットを追加します。ルールセットがある場合は、ルールを追加できます。その後、ルールは、いずれかの環境の VPC または CloudFormation テンプレートに適用できます。

  1. Posture Management メニューのRulesets メインページに移動します。

  2. Add Ruleset をクリックして新しいルールセットを作成します。ルールセットの名前と、必要に応じて説明を入力し、適用するクラウドプロバイダを選択します。

既存のルールセットをコピーできます。コピーには同じルールが含まれます。これは、編集できないCloudGuard管理ルールセットのルールを変更または拡張する場合に便利です。

  1. Rulesets タブに移動します。

  2. コピーするルールセットをクリックし、詳細を開きます。

  3. Cloneをクリックします。

  4. Clone <name>ruleset ウィンドウで、新しいルールセットの名前とその説明を入力します。

ルールセットにルールを追加します。カスタムルールセット(追加する新しいポリシー)にルールを追加できますが、事前定義ルールセットには追加できません。

  1. Rulesets タブに移動し、ルールセットを選択します。

  2. New Rule をクリックして、ポリシーにルールを追加します。これにより、オンラインGSLルールビルダが開きます(ガバナンス仕様言語(GSL)を参照)。

  3. ルールの名前と、必要に応じて、説明、修正(修正ステップ)、ルールが対象とするコンプライアンスセクション、および重大度レベル(つまり、このルールの違反の重大度または影響)を入力します。

  4. GSL 構文を使用してGSL Editor ボックスにルールを入力し、Test を押してルールをチェックします。終了したら、Done ボタンをクリックします。ルールは、ポリシーのルールのリストに表示されます。Free text モードではテキストとして、Builder モードではグラフィカルにルールを入力できます。

  5. 必要に応じて、ルールのCompliance Section にクラウドボットによる自動修復 タグを追加します。これらのタグは、ルールが 連続ポスチャー ポリシーで使用されている場合にのみ使用されます。ルールが評価に失敗した場合に実行される修復CloudGuardクラウドボットを示します。タグの形式は次のとおりです。

    AUTO: ec2_stop_instance

    プレフィックス'AUTO' は、これが自動修正タグであることを示します。タグの後に続く式は、修復ボットの名前('ec2_stop_instance' など) の後にパラメータ(オプション) が続きます。ルールに複数のタグを追加できます。ルールが失敗すると、すべての修復アクションが実行されます。

  6. 必要に応じてルールを追加します。

カスタムルールセット内の既存のルールを変更できます。新しいルールを作成するのと同じ方法で、グラフィカルルールビルダを使用して変更できます。CloudGuard はルールをJSON 形式で保存するため、JSON ブロックを編集してポリシーのルールを編集することもできます。

  1. Rulesets に移動し、ルールセットを選択します。

  2. 編集するルールをクリックします。ルールビルダーが開きます。そこからルールを変更できます。テキストを編集するか、グラフィカルビルダーを使用します。

  3. 必要に応じてルールのテキストを変更し、Done をクリックします。