Professional Security Operations Engineer

Question 16

過剰なネットワーク接続を検出する Google Security Operations (SecOps) の検出ルールが、あまりにも頻繁にトリガーされ、多くの誤検知アラートを生成していることに気づきました。このルールの有効性を損なうことなくノイズを削減するために、ルールを改善したいと考えています。検出ルールにどのような変更を実装すべきですか？

YARA-L の `condition:` セクションにしきい値を追加し、特定の接続数を超えた場合にのみルールがアラートを出すようにする。

YARA-L の `outcome:` セクションでリスクスコアを割り当て、アラートキューでアラートをより効果的に優先順位付けする。

YARA-L の `match:` セクションに、同じ送信元と宛先のネットワーク接続に対して10分間の時間枠を含め、アラートを集約する。

YARA-L の `events:` セクションを更新し、ネットワーク接続アラートに関与する最も一般的なIPアドレスを除外して、アラートの数を減らす。

Question 17

あなたは、グローバル企業のインシデント対応チームのメンバーです。Google Security Operations (SecOps) を使用して、組織のデータ内に存在する、Google Threat Intelligence が検知した潜在的なすべての IOC (侵害の痕跡) を特定する必要があります。どうすればよいですか？

Google SecOps の [Cases] ページを使用する。

Google Threat Intelligence が潜在的な脅威を特定したときに検知してアラートを出す YARA-L ルールを作成する。

Gemini を使用して、組織のデータに対する潜在的なサイバーセキュリティの脅威を検索する。

Google SecOps の [Alerts & IOCs] ページを使用する。

Question 18

あなたのGoogle Security Operations (SecOps) SOARとSecurity Command Center (SCC) の統合では、組織レベルで検出結果への読み取りアクセス権を持つサービスアカウントを使用しています。Google SecOps SOARはSCCの検出結果データを正常に読み取れますが、検出結果の状態を更新しようとすると、一貫して権限拒否エラーが発生します。最小権限の原則に従ってこのエラーを解決するには、どうすればよいですか？

サービスアカウントに、組織レベルで `roles/securitycenter.findingsBulkMuteEditor` IAMロールを付与する。

サービスアカウントに、組織レベルで `roles/securitycenter.findingsEditor` IAMロールを付与する。

サービスアカウント自身に `roles/iam.serviceAccountUser` IAMロールを付与する。

サービスアカウントキーを再生成し、Google SecOps SOARの認証情報を更新する。

Question 19

あなたは、クラウドを多用するエンタープライズ環境で、Google Security Operations (SecOps) SIEM の導入に向けたログのオンボーディングを計画しています。検出エンジニアリングチームは、以下の項目に対する可視性を確保できるログソースを求めています。 - ユーザーIDの振る舞い - ラテラルムーブメント - 権限昇格の試みどのテレメトリソースを最初に取り込むべきかを判断する必要があります。どのログソースを優先すべきでしょうか？

Cloud Access Security Broker (CASB) のログ

EDR (Endpoint Detection and Response) のログ

IAM (Identity and Access Management) のログ

ネットワークファイアウォールのログ

Question 20

あなたのチームは、サードパーティ製のDNSフィルタリングソリューションから新しいログソースを取り込みました。取り込み後、Google Security Operations (SecOps) でパースされたイベントにおいて、`network.dns.questions.name` や `metadata.product_event_type` といった主要なUDMフィールドが欠落していることが判明しました。デフォルトのパーサーがソースのフォーマットと完全には一致していないと推測されます。DNSクエリのテレメトリとイベントの分類に依存する後続の検出ルールでこれらのフィールドを利用できるようにする必要があります。どうすべきですか？

取り込みソースの定義を変更し、UDMサンプル出力を使用して生のフィールドを直接UDMに再マッピングする。

ログソースのアセットエンリッチメントを有効にして、相関するホストのアクティビティに基づいて欠落しているフィールドを推測する。

検出のためにすべてのフィールドを生のJSONとして出力するカスタムパーサーを使用する。

欠落しているソースフィールドを正しいUDMフィールドにマッピングするパーサー拡張機能を作成し、既存のパーサーにアタッチする。