ユニット 11 / 11

エンドツーエンドの SOC ワークフロー、自動化 (SOAR)、品質管理、自己監査

利益:

  • 人工知能と人間のゲートの位置を指定して、収集、検出、トリアージ、調査、介入、改善、報告、フィードバックから構成されるエンドツーエンドの SOC ワークフローを設計する能力
  • リスク レベルに応じて自動化を分離し (低リスク/可逆的なステップは自動、高リスク/不可逆的なステップは人間によって制御されます)、各自動アクションのロールバック パスを設計する機能。
  • 偽陽性/偽陰性率、MTTD/MTTR、出力精度、モデルドリフトを定期的に測定する自己モニタリングおよびフィードバックループを確立する機能

この最後の単元では、モジュール全体で個別に学習した要素 (ログ分析、脅威ハンティング、脆弱性管理、インシデント対応、フィッシング、コード レビュー、インテリジェンス、レポート作成) を単一のエンドツーエンドのワークフローに結合します。真のセキュリティ オペレーション センター (SOC) では、これらのステップは切り離されていません。アラームによって調査がトリガーされ、調査によって対応がトリガーされ、レポートがトリガーされて、修復がトリガーされます。人工知能はこのチェーンのすべてのリンクに関与していますが、チェーンを保持し、すべての重要なドアで意思決定を行うのは人間です。

さらに、この単元では 2 つの重要なトピックについて説明します。 1 つ目は自動化です。SOAR (セキュリティ オーケストレーション、オートメーション、レスポンス - セキュリティ プロセスを自動化および組織化するプラットフォーム) と AI を組み合わせると、能力とリスクの両方が増加します。自動化できるものと人間の承認を絶対に削除できないものを区別する必要があります。第 2 に、品質管理と自主規制です。AI を活用したセキュリティ運用は、一度設定したらすぐに放棄されるわけではありません。それは常に監視され、測定され、フィードバックされ、修正されます。自動化により速度は向上しますが、責任がなくなるわけではありません。セキュリティ プログラムは、定期的な自己監視を通じてのみ安全を維持します。

エンドツーエンドの SOC ワークフロー

典型的なインシデントのライフサイクルにおいて AI がどこで登場し、誰がそれを承認するかを見てみましょう。

  1. 収集と監視: ログは SIEM に流れます。 AIがノイズを軽減、まとめます。 (自動、低リスク)
  2. 検知と警報:ルール+異常+AIパターン検知。 (自動生産、トリアージは人間が行う)
  3. トリアージ: アラームは本物ですか、それとも誤検知ですか? AI は理論的根拠と優先順位を提案します。アナリストが確認した。 (人間のドア)
  4. 調査: AI が証拠を収集し、タイムラインを確立し、根本原因をリストします。アナリストは生の証​​拠でそれを確認します。 (人間のドア)
  5. 介入: 隔離、ロック、クリーニング。 AI は選択肢と影響力を提供します。決定は認定アナリストの手に委ねられます。 (クリティカルヒューマンゲート)
  6. 修復: 脆弱性の解消、根本原因の除去。 AI計画草案。変更管理での承認。 (人間 + プロセス)
  7. レポーティング: AI が草稿を作成し、聴衆に適応します。専門家が証拠を検証し、署名します。 (人間のドア)
  8. 教訓の学習とフィードバック: AI がパターンを抽出します。チーム検出ルールとプレイブックを更新します。 (人間 + プロセス)

この連鎖のルール: リスクが低く、反復的で、元に戻せるステップは自動化できます。リスクが高く、取り返しのつかない、判断を必要とするステップは人間の扉を通過します。

自動化デシジョンテーブル

ステップ

自動化できるのか

状態

人間の承認

ログ収集、正規化

はい、まさに

必要ありません

アラーム強化(IOC検索)

はい

ソースは信頼できる

レビューされています

誤検知の除去 (既知の正常な状態)

部分的に

厳格な規則

サンプリングによる検査

フィッシングメールを隔離する

部分的に

高精度

レビュー + ロールバック パス

アカウントを自動的にロックする

注意深い

明確な基準のみ

人間による迅速な検証

サーバーを隔離する

一般的にはありません

重要インフラを除く

人間の強制的な決断

パッチ適用 (本番)

いいえ

テスト + 変更管理

公式報告・通知

いいえ

専門家 + 法律

品質管理と自己監査

AI を活用したセキュリティ運用は生きたシステムです。そのパフォーマンスは時間の経過とともに変化します (新しい攻撃、環境の変化、モデルの更新)。安全に保つために定期的な測定が必要です。

  • 偽陽性率と偽陰性率: AI はどれくらいの頻度で警告を発しても無駄で、実際の脅威を見逃してしまうことがどれくらいあるでしょうか?偽陰性は、静かに危害を引き起こすため、特に注目されています。
  • MTTD/MTTR:​​ 平均検出時間と応答時間は改善されていますか?
  • AI 出力の精度: サンプリングにより、AI の要約/調査結果/引用のうちどれだけが検証に合格しますか?
  • 自動化セキュリティ: 自動アクションは期待どおりに機能しますか、誤ったトリガーはありますか、ロールバックは機能していますか?
  • フィードバック ループ: 見つかった実際のイベントは新しい検出ルールになり、発生したアラームは例外リストになりますか?

用語: MTTD (平均検出時間)。フィードバック ループは、オペレーションが自身の結果から学習し、ルールを更新するときに発生します。モデルドリフトとは、環境の変化に伴ってAIが陳腐化し、パフォーマンスが低下することです。自己監査は、チーム自身のプロセスを定期的に批判的にレビューすることです。

ミニケース3個

ケース 1 — 正しい自動化。 SOC は、「既知の悪意のある IOC に一致し、低リスクのカテゴリにあるアラートを自動的に強化し、優先順位を付ける」ステップを自動化します。ただし、人間の承認を必要とする「サーバーの分離」ステップは常に残されます。その結果、アナリストは 1 日あたり 400 件の日常的なアラームから解放され、実際の調査に時間が確保され、重要な決定は人間に委ねられます。チェーンの右側の部分は自動であり、右側の部分は人間です。

ケース 2 — 自動化が裏目に出る。別の SOC では、「不審なログイン時にアカウントを自動ロックする」ルールを非常に広範囲に定義しています。ある日、構成エラーにより、ルールにより 1,200 人の正規ユーザーが一度にロックアウトされ、作業が停止します。また、リカバリパスは定義されていません。教訓: 影響の大きい自動化には、厳格な基準、段階的な導入、ロールバック パスが必要です。自動化は可逆的であり、自主規制を通じて監視される必要があります。

ケース 3 — 自制心によって滑りを捉えた。 3 か月の自己監査で、チームは AI のフィッシング検出精度が低下していることに気づきました。新しいフィッシングの波は、古いパターンに適合しないため (パターン ドリフト)、見逃されます。チームはサンプルを収集し、検出ルールを更新し、AI に与えられたコンテキストを更新します。定期的な自制がなければ、この沈黙の回避が何か月間も続いた可能性があります。教訓: パフォーマンスが一度良くなったからといって、常に良い状態が続くとは限りません。測定とフィードバックが不可欠です。

弱いプロンプト / 強いプロンプト

弱いプロンプト:

SOC を完全に自動化し、AI にすべてを処理させます。

この要求は、リスクを区別せずに自動化を要求し、人間のドアを無視し、ロールバックや制御を考慮していません。もし導入されれば、リスクの高い意思決定が監視なしで自動化され、最初のミスで大惨事に発展するでしょう。

強力なプロンプト:

あなたの役割: SOC プロセス設計のコンサルタント。 [リスト] これらのイベントのライフサイクルは、リスク レベルに基づいて 3 つのステップに分けられます: (A) 完全に自動化 (低リスク、可逆的、反復的)、(B) AI による推奨 + 人間の承認、(C) 常に人間の判断 (高リスク、不可逆的)。 (A) と (B) のそれぞれについて、必須のロールバック パスと追跡メトリックを提案します。また、四半期ごとの自己監査チェックリストの草案を作成します。偽陽性/陰性率、MTTD/MTTR、AI 出力精度サンプリング、パターン ドリフトの兆候。

強い需要があるため、リスクレベルごとに自動化が分離され、ロールバックと監視が必要となり、自主規制フレームワークが確立されます。

コピー可能なプロンプトテンプレート

自動化リスク分離テンプレート これらのセキュリティ ワークフロー ステップを 3 つに分離します: (A) 完全に自動化された適切な、(B) 人間の承認を推奨する、(C) 常に人間の決定。各ステップの正当性、可逆性、ビジネスへの影響を記述します。影響の大きいステップには必須のロールバック パスを推奨します。手順: [リスト]

自動アクション用のロールバック設計テンプレート [例:アカウント ロックアウト] 安全な設計を提案します: トリガー基準 (狭い)、段階的な展開、誤ったトリガーのロールバック ステップ、警告、人間による検証ポイント。やみくもな自動化を避けるように設計する。アクション: [書き込み]

自己監査チェックリストのテンプレート AI を活用した SOC の四半期ごとの自己監査チェックリストの草案を作成します: 偽陽性/陰性率、MTTD/MTTR バイアス、AI 出力精度サンプリング、自動誤トリガー、パターン ドリフトの兆候、フィードバック ループ操作、プライバシー/匿名化コンプライアンス。項目ごとに、どのように測定するかを書きます。

フィードバック ループ テンプレート失敗した実際のイベント/アラームから何が学習されるかを描画します: (1) 新しい検出ルールとなるパターン、(2) 例外リストに追加される誤検知、(3) 更新されるプレイブック ステップ、(4) AI に与えられる新しいコンテキスト。イベント/アラームの概要: [貼り付け]

よくある間違い

  • リスクの高いステップを自動化します。サーバーの分離、本番環境へのパッチ適用、公式通知などの元に戻せない手順は、人間の扉からは削除されません。
  • 回収までの道筋を立てていない。自動アクションが誤ってトリガーされる可能性があります。元に戻すポイントと確認ポイントのない自動化は危険です。
  • 設定すればあとは忘れます。 AI のパフォーマンスは環境の変化に応じて変化します。定期的な自己監視と測定がなければ、沈黙の回避が蓄積されてしまいます。
  • 誤検知を追跡するだけです。偽陰性 (本当の脅威が見逃されること) はより危険ですが、発見するのが困難です。プライベートで見てください。
  • フィードバックを無視する。検出されたイベントが新しいルールにならず、失敗したアラームが例外にならない場合、操作は学習せず、同じ間違いを繰り返します。
ヒント: 自動化を決定する際の重要な質問: 「このアクションが誤ってトリガーされた場合に元に戻すことができますか? ビジネスへの影響は何ですか?」答えが「簡単に元に戻せる、影響が少ない」のであれば、自動化しましょう。 「不可逆的または大きな影響」の場合は、人の家の玄関に保管してください。
注意: 自動化は責任を排除するものではなく、責任をスピードアップするだけです。不適切な自動アクションは、人間が行うよりもはるかに速く、広範囲に損害を与えます。すべての自動化は、狭い基準、ロールバック パス、定期的な検査に囲まれています。最終的な責任は常に人間にあります。

要約すると

このユニットは、モジュールのすべての部分をエンドツーエンドの SOC ワークフロー (収集、検出、トリアージ、調査、対応、修復、レポート、フィードバック) に結合しました。 AI はすべてのリンクに関与していますが、チェーンを保持し、すべての重要なドアで意思決定を行うのは人間です。自動化 (SOAR + AI) により能力が向上します。ルールは明確です。低リスクで元に戻せる反復的なステップは自動化され、高リスクで元に戻せないステップは人間の扉を通過し、すべての自動化には元に戻す方法があります。最後に、AI を活用したセキュリティ プログラムが稼働します。誤検知/誤検知、MTTD/MTTR、出力精度、パターン ドリフトが定期的に測定されます。見つかったものは、フィードバック ループ内のルールとプレイブックに変わります。自動化は責任を取り除くのではなく、責任を加速させます。自制心によってセキュリティが維持されます。

アプリケーションタスク

自分の組織 (またはサンプル SOC) のインシデント ライフサイクルを書き出します。 「自動化リスク分離」テンプレートを使用して各ステップを A/B/C に分類し、少なくとも 1 つの「影響の大きい」ステップについては「ロールバック設計」テンプレートを使用して安全な自動化設計を導き出します。次に、「自己監査チェックリスト」テンプレートを使用して四半期ごとのチェックリストを作成し、環境内の各メトリックを測定する方法を決定します。

チェックリスト

  • [ ] インシデントのライフサイクルの各ステップを A/B/C リスク クラスに分割しました。
  • [ ] 私は人間の扉の前で、危険性が高く、取り返しのつかないステップを踏み続けました。
  • [ ] 各自動アクションの狭い基準と元に戻すパスを設計しました。
  • [ ] 偽陽性、特に偽陰性の割合を監視する計画を立てました。
  • [ ] MTTD/MTTRとAIの出力精度を定期的に測定するつもりでした。
  • [ ] 私はパターンドリフトに関する四半期ごとの自己監視チェックリストを確立しました。
  • [ ] 見つかったイベントとスローされたアラームをフィードバック ループに接続しました。

モジュール試験

1. SIEM トリアージ AI がアラームに「優先度が低く、誤検知の可能性がある」というフラグを付け、リストの一番下に押し込みました。アナリストはこのアラームに対して何をすべきでしょうか?

  • A) 依然として独立してアラームをチェックし、生の証拠でそれを検証します。アナリストは閉鎖の決定を下し、それを記録します ✔
  • B) 人工知能は優先度が低いため、検査せずに自動的にアラームをオフにします。
  • C) アラームをそのまま次のシフトに転送します。
  • D) 人工知能によって与えられた概要を見て、レポートを渡すだけです

説明: AI の優先順位付けは推奨事項であり、診断ではありません。 「低優先度」フラグは、実際の攻撃 (偽陰性) をカバーする可能性があります。アナリストは依然として独自にアラートをチェックし、生の証拠で検証し、アラートを閉じる決定を自分で下す必要があります。 AI の出力がマイナスであっても、「脅威がない」という保証はありません。

2. AI が実際の攻撃を「通常」とラベル付けし、アナリストがこれを信頼して自身の分析を緩めるリスクの組み合わせは何ですか?

  • A) 誤検知およびアラーム疲労のみ
  • B) 偽陰性と自動化バイアス (AI への過度の依存) ✔
  • C) ログソースのみが不足している
  • D) SIEM ルールエラーのみ

説明: モデルが本当の脅威を見逃した場合、それは偽陰性です。自動化バイアスとは、アナリストが人工知能を過剰に信頼し、独立したレビューを放棄することです。この 2 つが組み合わされると、人間による制御の存在意義がなくなり、攻撃が完全に回避されるようになります。そのため、人工知能が「クリーン」と呼ぶ領域も検査されます。

3. AI はトリアージ中に「CVE-2024-88888、CVSS 9.8、すぐにパッチを適用してください」と言いました。アナリストは最初に何をすべきでしょうか?

  • A) CVE が信頼できると判断し、パッチ適用計画を直ちに開始します。
  • B) CVSS が 9.8 であるという理由だけで、他の脆弱性を検討せずにそれを最優先します。
  • C) NVD/ベンダーレコード内の CVE 番号とスコアを検証します。 ✔記録がない場合は偽物の可能性を承知で出品しておりません。
  • D) 管理者は CVE を検証せずに、それをレポートに「重大な脅威」として書き込みます。

説明: 言語モデルは、存在しない CVE 番号とスコアをスムーズに適合させることができます (幻覚)。アナリストは、パッチ適用スケジュールを実行する前に、NVD/ベンダー ログ内の CVE を検証し、その信頼性とスコアを確認する必要があります。未検証の CVE は最初にリソースに接続します。そうしないと、チームは存在しないパッチを追いかけて時間を無駄にすることになります。

4. インシデント調査を迅速化するために、専門家は生のファイアウォール ログを実際の内部 IP、ユーザー名、VPN サーバー名とともに一般公開されている AI ツールに貼り付けます。ここでの主な問題は何ですか?

  • A) AIはログ形式を読み取ることができないため、分析は役に立ちません
  • B) ログが長すぎると、モデルの速度が低下します。
  • C) いずれにしてもファイアウォールのログは分析には適していません
  • D) 実際の IP、ユーザー、サーバー名は匿名化されずに共有されます。これは、KVKK の違反であると同時に、組織のネットワーク マップの漏洩です ✔

説明: セキュリティ データは、個人データ (ユーザー、IP) と、組織の攻撃対象領域 (ネットワーク トポロジ、サーバー名) を明らかにする企業インテリジェンスの両方です。これを匿名化せずに外部ツールに渡すと、KVKK に違反するだけでなく、攻撃者にとって有益なネットワーク マップが明らかになります。まず、実際の値は一貫したプレースホルダーでマスクされます。

5. 脅威ハンティングが適切に設計されているとみなされる理由は何ですか?

  • A) 具体的で検証可能な仮説から始まり、見つかった痕跡は生の証拠によって確認されます ✔
  • B) 人工知能に「ネットワーク内に攻撃者がいるかどうか調べてください」と指示することから始まります。
  • C) 検出されたすべての異常/稀なイベントを自動的に攻撃として宣言します
  • D) アラームが到着した場合にのみ機能し、事前対応的ではありません

説明: 優れた脅威探索は、アラームではなく、真実であるかどうかわからない、具体的で検証可能な仮説から始まります (例: 「アカウント X は営業時間外に 50 を超える内部 IP に接続したか」)。 「ネットワークに何か問題があるのではないか」といった漠然とした質問はテストできず、AI が推測することになります。見つかった痕跡は、生の証拠で検証されるまで脅威とみなされません。

6. 内部ネットワーク上の隔離されたテスト サーバーでは、脆弱性の CVSS スコアは 9.1 です。同じリストでは、サーバー上の CVSS 7.5 はインターネットに公開されていますが、KEV リストには別の脆弱性があります (実際に悪用されています)。正しい優先順位付けとは何でしょうか?

  • A) CVSS (9.1) が最も高いものに常に最初にパッチが適用されます。
  • B) インターネットおよび KEV リスト上の 7.5 の脆弱性が取り上げられます。 CVSS が唯一の基準ではなく、暴露と実際の虐待が決定的です ✔
  • C) 両方に同じ優先度で同時にパッチが適用されるため、区別する必要はありません
  • D) テストサーバーに脆弱性があるため、いずれにもパッチが適用されていません

説明: CVSS は単独で優先順位を設定しません。実際のリスクは、EPSS (悪用の確率)、KEV (実際の悪用)、および組織の状況 (危険性、重大性、代償的管理) によって決定されます。インターネットに公開され実際に悪用される (KEV) 脆弱性により、孤立した可能性の低い高 CVSS 脆弱性が防止されます。

7. インシデント対応で、人工知能は「IC_HOST_7 から発信されたトラフィックは疑わしいので、このサーバーを隔離してください」と言います。 IC_HOST_7 は、機関のメイン認証サーバーです。アナリストは何をすべきでしょうか?

  • A) 人工知能はそう言うのでサーバーを即座に隔離します
  • B) 隔離の決定を完全に人工知能に任せる
  • C) まず、ビジネスへの影響とトラフィックの原因を評価します。影響を測定せずに重要なインフラを隔離せず、アナリストとしての意思決定を行う ✔
  • D) サーバーを隔離し、すべてのログを削除します。

説明: 孤立は重要な決定であり、覆すのは難しく、ビジネスの中断につながる可能性があります。人工知能に転送することはできません。認証サーバーを分離すると、すべての従業員がログインできなくなる可能性があります。アナリストはまずビジネスへの影響とトラフィックの原因 (正当なトランザクションである可能性があります) を評価し、自分自身で決定を下す必要があります。人工知能の提案は命令として実行されるべきではありません。

8. ランサムウェア インシデントが発生した場合、チームは影響を受けたマシンを再構築して迅速に駆除したいと考えています。しかし、マシン上にはまだ収集されていないフォレンジック証拠 (メモリ ダンプ、攻撃者ツール) があります。正しいアプローチとは何でしょうか?

  • A) マシンはすぐに再インストールされます。証拠は関係ない
  • B) 人工知能に「最速の掃除」を要求し、その指示を盲目的に適用します。
  • C) 証拠がすでにログに記録されているため、マシンの電源がオフになり廃棄されます。
  • D) まず、フォレンジック画像とメモリダンプを取得して証拠を保存し、その後クリーニング/リカバリを実行します ✔

説明: 回復のスピードは証拠保全に勝るものではありません。証拠を収集せずに機械を再設置すると、拘留連鎖が破壊され、司法手続きが機能不全に陥ります。まず、フォレンジック イメージとメモリ ダンプが取得され、次にクリーニング/リカバリが実行されます。フォレンジックの手順は AI に委任されません。

9. フィッシングの疑いのある電子メールを分析する際に、技術的検証で最も信頼できる層の 1 つは何ですか?また、それをどのように確認する必要がありますか?

  • A) SPF/DKIM/DMARC により電子メール ヘッダーが生成されます。 AIの概要ではなく生のタイトルで確認✔
  • B) 電子メールの色とフォント。ビジュアルデザインで決める
  • C) ライブ システム上の疑わしいリンクをクリックし、開いたページを確認します。
  • D) 「フィッシング」だけで十分な証拠であると言う人工知能

説明: 電子メール ヘッダーの SPF/DKIM/DMARC の結果は、その電子メールが実際にそのドメインから送信されているかどうかを示す強力な指標です。 3 つすべてが失敗し、送信者がドメインを偽装した場合、疑いはさらに強くなります。ただし、これは AI の概要ではなく、生のタイトルから確認する必要があります。さらに、ライブ システムでは疑わしいリンクがクリックされることはありません。

10.コードレビューで、AIはXSS脆弱性の修正を提案し、「脆弱性を解決する」と述べた。アナリスト/開発者は何をすべきでしょうか?

  • A) 修正が信頼できると考えて、本番環境に直接導入します。
  • B) 修正をレビューし、実際に脆弱性が解消され、新たな脆弱性やバグが導入されていないことを確認し、テストを作成します。そうして初めて保管場所に入ります ✔
  • C) よくわからないので、ファイル全体を人工知能に書き換えて使用します。
  • D) 修正を適用したが、テストを書かずにパスした

説明: AI によって提案された修正は、自動的には安全ではありません。脆弱性が完全に解決されない場合や、間違ったレイヤーが削除される場合、または新しい脆弱性/機能エラーが発生する場合があります。各パッチはレビューされ、実際に脆弱性を解決するかどうか、新しい問題を引き起こすかどうかが評価され、肯定的なテスト ケースと否定的なテスト ケースが作成されます。そうして初めて倉庫に入ります。

11. 攻撃を分析する際、人工知能は「これは間違いなくAPT-Dark Eagleグループの仕業である」と言いました。脅威インテリジェンスの観点から正しいアプローチは何ですか?

  • A) 言及をそのまま受け入れ、報告書に「明確な加害者」として記載します。
  • B) 彼はグループ名に疑問を抱くことなく、そのグループに基づいて防御全体を構築します。
  • C) 正確な帰属ではなく「技術と一致する」という表現を使用し、既知の情報源でグループを検証し、捏造の可能性を考慮に入れる ✔
  • D) 引用は常に不要であり、まったく考慮されません

説明: グループの帰属は、インテリジェンスの中で最も難しく、最も不正確な領域です。 AI は存在しないバンド名を作ることもできます。正確な参照の代わりに、「これらの技術と互換性のある」言語が使用され、グループ名は既知の情報源で確認されています。さらに、防御は短期間の IOC ではなく、永続的な TTP 検出に基づいています。

12. インシデント報告書草案の中で、AI は「攻撃者は 3 週間屋内にいた可能性が高く、顧客データを流出させた」という文章を書きました。一方、これらの主張を裏付ける決定的なログ証拠はありません。アナリストは何をすべきでしょうか?

  • A) ドラマティックで印象的な文章なのでそのままにします
  • B) 文は残しますが、最後に「人工知能が書いた」を追加します
  • C) レポート全体を人工知能に再印刷し、検証せずに署名します。
  • D) 証拠に基づいて主張を修正します。 「可能性がある/証明されている/調査中」を区別し、証拠なしで決定的な声明を抽出します ✔

コメント: 正式なセキュリティレポートでは、すべての主張が実証されるべきであり、「可能性がある」ことと「証明された」ことを混同してはなりません。証拠のない主張は、法的、経済的、評判に影響を及ぼします。アナリストは証拠に従って文章を修正する必要があります(たとえば、最初のアクセスが検出された日付を書き、データ漏洩については「決定的な証拠は見つからず、調査が進行中です」と記載します)。

13. マネージャーは、従業員が「忠実」であるかどうかを理解するために、人工知能を使用してセキュリティ ログから従業員のすべてのアクティビティをプロファイリングしたいと考えています。セキュリティ専門家は何をすべきでしょうか?

  • A) リクエストを拒否し、適切なチャネル (人事/法務/規定の調査) に転送します。セキュリティデータは個人監視の手段ではありません ✔
  • B) マネージャーの要求によりプロファイルを作成して配信する
  • C) 一部のログのみを抽出し、部分的なプロファイルを提供します
  • D) 責任は人工知能に移るので、人工知能にプロファイルを作成してもらう

説明: セキュリティ データはセキュリティ目的で収集されます。個人の追跡/プロファイリングは悪用であり、個人監視となり、KVKK に違反します。専門家はこの要求を拒否し、適切なチャネル (人事、法務、定義された正当な調査枠組み) に転送する必要があります。善意や経営者の願望によってこの制限が正当化されるわけではありません。

14. SOC は、セキュリティ ワークフローのどのステップを自動化するかを決定します。自動化に最適な原則はどれですか?

  • A) 人間の関与を排除するために、最もリスクの高い意思決定を最初に自動化する必要があります。
  • B) 低リスク/元に戻せるステップは自動化されています。高リスク/不可逆的な手順が人間の扉に残されており、すべての自動化には元に戻す方法があります ✔
  • C) すべての SOC は完全に自動化されるべきであり、自己監査は不要です
  • D) AI はミスをしないため、自動化されたアクションを元に戻す必要がありません

説明: 低リスクで反復的かつ元に戻せる手順 (ログ収集、アラーム強化) は自動化できます。リスクが高く、元に戻せない、判断が必要な手順 (サーバーの分離、運用環境へのパッチ適用、公式通知) は人間の扉を通過します。さらに、すべての自動アクションには、狭い基準と元に戻す方法が必要です。自動化は責任を取り除くものではなく、単にスピードを上げるだけです。