re:Invent 2025: MerckのOCSF活用によるインシデント対応時間の短縮とAI自動化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Build a Future-Ready SOC:Transform security logging with OCSF and generative AI
この動画では、MerckがOpen Cybersecurity Schema Framework（OCSF）を活用してセキュリティログを標準化し、インシデント対応時間を丸一日から30分以下に短縮した事例が紹介されています。異なるログソースと形式による可視性のギャップやデータパイプラインの複雑さといった課題に対し、OCSFがユニバーサルデータフォーマットを提供することで解決します。MerckはAmazon Security Lakeを導入し、運用効率を48%向上、インフラコストを47%削減しました。さらにagentic AIとOCSFを組み合わせることで、WAFログの分析やセキュリティインシデントの調査を自動化し、5分以内に包括的なレポートを生成できるようになりました。Parquet形式での保存による圧縮効果とクエリ最適化、AI/MLワークロードへの対応可能性など、OCSFの具体的な技術的メリットが実証されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
インシデント対応時間を30分に短縮：OCSFとAIによるセキュリティ革新の全貌
皆さん、こんにちは。本日はこうしてお集まりいただき、ありがとうございます。今日は、セキュリティログを OCSF フォーマットに変換することで、AI を活用した将来対応型のセキュリティオペレーションセンターを構築する方法についてお話しします。始める前に、私の共同プレゼンターの皆さんをご紹介させてください。Merck の Public Cloud ディレクターの Allan Umandap、AWS の Financial Services and Insurance シニアソリューションズアーキテクトの Pratima Singh、そして私、AWS Healthcare and Life Sciences シニアテクニカルアカウントマネージャーの Sushovan Basak です。Allan と Pratima は後ほどステージに登壇して、Merck のストーリーと素晴らしい agentic AI のデモをお見せします。では、アジェンダに入る前に、皆さんに興味深い質問をさせてください。
インシデント対応を丸一日の分析からわずか 30 分以下に短縮できるとしたら、どう思いますか？そう聞いて「本当かな」と思う方は手を挙げてください。何人か手を挙げていますね。実は Merck がまさにそれを実現したんです。そして今日は、OCSF を使ってあなたの組織でも同じ成果を達成する方法をお見せします。まず、異なるログソースと異なるログフォーマットから生じる一般的なデータの課題についてお話しします。その後、Open Cybersecurity Schema Framework、つまり OCSF をソリューションとしてご紹介します。
次に、Merck の実例をお聞きします。彼らがどのように OCSF を使って中央ログを変換し、OCSF と AI を組み合わせてインシデント対応を丸一日の分析からわずか 30 分に短縮したかについてです。最後に、素晴らしい agentic AI のデモで OCSF の力を実際に目にしていただきます。OCSF と AI でセキュリティオペレーションセンターをどのように革新できるかを、実際に見ていただけます。では、 始める前に、一つの基本的な真実を確認しておきましょう。セキュリティは根本的にはデータの問題なんです。課題はデータが不足していることではなく、持っているデータを理解することなんです。
現代のセキュリティチームが直面するデータの混乱：異なるログフォーマットがもたらす課題
現代のエンタープライズセキュリティの状況を見てみましょう。もはや一つの環境だけを管理しているわけではありません。オンプレミスのデータセンター、複数のクラウドプロバイダーに分散したワークロード、そして急速に成長している SaaS 環境のエコシステムがあります。ここで、セキュリティチームが潜在的なブリーチを調査しようとしていると想像してください。ファイアウォールログはオンプレミスにあり、エンドポイントデータは別のアプリケーションにあり、クラウドデータは複数のクラウドプロバイダーに散在しています。調査するには、3 つか 4 つの異なるシステムにアクセスする必要があり、それぞれが 3 つか 4 つの異なるログフォーマットを使用しています。これはたった一つの調査のためだけです。
アナリストたちはデジタル考古学者のようになり、何が起きたのかを把握するためだけに何時間も費やしています。その間に、全体像が見えないために、実際のインシデントが見落とされてしまいます。 しかし、ここが現実です。高度な脅威検出アルゴリズムを構築すべき最高のセキュリティエンジニアたちが、代わりに果てしないデータパーサーを書いているんです。なぜなら、すべてのシステムが異なる言語を話しており、フィールド名も異なれば、構造も異なり、タイムスタンプも異なるからです。彼らは System X のフィールド A を System Y のフィールド B にマッピングすることを何度も繰り返しています。新しいセキュリティツールを導入するたびに、別の複雑なデータパイプラインを管理する必要が生じ、別のカスタムパーサーを構築しなければなりません。これはまるで、Formula One のピットクルーが一日中タイヤを交換する代わりにツールを整理しているようなものです。
もし私たちがこれを変えることができたら？すべてのこの差別化されていない重い作業を行うシステムがあったら、データ変換を実行して1つのユニバーサルデータフォーマットを作成し、セキュリティエンジニアが最も重要なことに集中できるようにするシステムがあったら？脅威検出と対応です。 次の課題はデータの津波で、これは本当です。すべてのアプリケーション、すべてのネットワークデバイス、そしてすべてのエンドポイントが、これまで以上に多くのログを生成しています。聞き覚えがありますよね？でもここが重要なポイントです。単に多くのデータというだけではなく、異なるデータがより多くあるということです。情報の洪水に溺れているのに、インサイトには飢えている状態です。検出システムは対応するのに苦労していますし、このような膨大なログボリュームを処理するためのストレージとコンピュートパワーの予算も同様です。
Open Cybersecurity Schema Framework（OCSF）：ユニバーサルデータフォーマットによる解決策
では、私たちが話してきたこのデータの混乱に対する解決策は何でしょうか？OCSF、Open Cybersecurity Schema Framework をご紹介します。これはオープンソースで、プロプライエタリスキーマのすべての複雑さを取り除きます。これは単純なスキーマではなく、スキーマをレンダリングするためのフレームワークです。これは汎用的ではなく、セキュリティチーム向けに特別に設計されています。
ソースイベントに関係なく、OCSF は常に同じデータ構造を維持します。 コアフレームワークを保持しながら、自分のニーズに基づいてカスタマイズして拡張することができます。そしてこれが私のお気に入りです。 OCSF はソースに依存しません。ログがサードパーティベンダーから来ているか、AWS プラットフォームレベルのログであるかに関わらず、OCSF は常に1つのユニバーサルデータフォーマットを作成します。そしてそれがユニバーサルデータフォーマットであるため、OCSF は常に同じ構造、同じフィールド名、 同じクエリパスをセキュリティツールが使用するために提供します。
では OCSF が実際に動作しているところを見てみましょう。ここが魔法が起こるところです。 左側には、イベントプロデューサーがあります。セキュリティツール、アプリケーション、ネットワークデバイスです。従来、それぞれが独自の言語を話し、私たちが話してきたデータの混乱を作り出しています。OCSF は真ん中に位置し、ユニバーサルデータトランスレーターとして機能します。でも、右側のイベントプロデューサーからイベントコンシューマーへのマッピングをまだ行う必要があるのかと疑問に思っているなら、答えはノーです。AWS プラットフォームレベルのログについてはそうではありません。Amazon Security Lake がそれをあなたのために行います。
前に私たちが望んでいたシステムを覚えていますか？データ変換の差別化されていない重い作業をすべて行い、1つのユニバーサルデータフォーマットを作成するべきシステムです？ここにあります。Amazon Security Lake があなたのためにあります。では、右側のイベントコンシューマー、SIEM、データレイク、分析アプリケーション、AI/ML ワークロード、これらすべてが同じ一貫したフォーマットでデータを受け取ります。それだけではなく、ストレージの費用も少なくなります。Amazon Security Lake はデータを Parquet フォーマットで保存するため、OCSF フォーマットされたログデータをさらに圧縮します。
コンピュートのコストも安くなります。なぜだと思いますか？Parquet はカラムナー形式なので、本質的にクエリのパフォーマンスが向上するからです。つまり、Athena のクエリは以前よりもはるかに高速に実行されます。クエリの実行時間が短くなれば、使用するコンピュート能力が減り、それがコンピュートコストの削減につながるわけです。では、主な利点を説明する前に、これまで話してきたデータの課題をもう一度確認して、これらの主な利点がそれらの課題にどう対応できるか見てみましょう。
まず、私が言ったように、OCSF は 1 つの統一されたデータ形式を作成し、ハイブリッドクラウドとマルチベンダー環境で 運用できるようにします。つまり、異なるログソースと異なるログ形式による可視性のギャップはもうありません。 これはプロデューサーレベルで 1 回だけマッピングを設定するということです。それを消費するすべてのセキュリティツールごとに設定するのではなく、プロデューサーレベルで 1 回設定するだけです。コンシューマーレベルでカスタムパースが必要なくなります。なぜなら、すでにプロデューサーレベルで実施しているからです。これにより、私たちが話していた複雑なデータパイプラインの必要性がなくなります。これで、セキュリティ人材をデータ変換作業ではなく、より戦略的な仕事に最適化できるようになります。
そして最後に、最も重要なことですが、AI/ML に対応しています。 つまり、AI モデルはクリーンで一貫性のあるデータで動作し、増加し続けるログボリュームを貴重なインサイトに変えることができます。これが、データサイロを破壊し、セキュリティオペレーションを飛躍的に向上させる方法です。では、Merck が OCSF と AI を使用して中央ログをどのように変革したかについて、Allan から聞いてみましょう。Allan、よろしくお願いします。
Merckの中央ログ環境：AWS Security Lake導入前の状況と改善の余地
Sushovan、背景を提供し、OCSF で解決できる課題を紹介していただき、ありがとうございます。皆さん、こんにちは。Allan Umandap です。Merck のパブリッククラウドプラットフォームチームをリードしています。このチームには 10 年以上在籍しています。私たちのミッションは常に、ビジネスニーズをサポートするための重要なテクノロジーを提供・実現することで、お客様に環境を提供することでした。このプロセスを通じて、私たちはテクノロジーのライフサイクル全体をサポートできるセキュアなクラウド環境をユーザーに提供することができました。私たちのチームは、本番環境へのパスは幸せなパスであるべきだと考えています。最も簡単であることを確保することが、私たちの目標であり、ミッションです。
もしかして、私たちがどのようにこれを実現しているのか疑問に思っているかもしれません。それは、セルフサービスオファリングを通じて、中央ログ環境のデータへのアクセスを提供し、また、お客様に明確なガイダンスを提供することです。では、私たちの会社について説明させてください。Merck & Co., Inc.、米国とカナダ以外では MSD として知られています。 私たちは、処方医薬品、ワクチン、生物学的治療法、動物用医薬品、およびテクノロジーソリューションを通じて、革新的なヘルスソリューションを提供するグローバルなヘルスケア企業です。
私たちの歴史は、私たちのコミットメントを物語っています。130年以上にわたって、私たちは重要な医薬品とワクチンの開発を通じて、人類に希望をもたらすことができてきました。これは単なる私たちの歴史ではなく、現在も続く私たちのミッションなのです。
Sushovan Basak が OCSF について非常に良い背景説明をしてくれました。このプレゼンテーションから、皆さんが OCSF を評価し、自分たちの目的に合わせて活用するのに十分な情報を得られることを期待しています。このダイアグラムを使って、私たちがどのようにして OCSF への変革の旅を進めることができたのかを説明したいと思います。このダイアグラムは皆さんにとって非常に馴染み深いものですか？このお部屋にいるアーキテクトとエンジニアの皆さんであれば、AWS のマルチアカウント戦略をデプロイし、設計した経験があれば、このダイアグラムは非常に馴染み深いものであるはずです。
成功裏にデプロイされたすべてのランディングゾーンは、私の経験上、中央ロギング環境を持つことから恩恵を受けるでしょう。中央ロギング環境とは、複数のアカウントと複数のリージョンからのログを中央アカウントに収集するセットアップであり、これはモニタリング、分析、監査の目的に役立ちます。私たちの AWS マネージドアカウントから、CloudTrail がセットアップされており、ログを中央ロギングアカウントの S3 バケットに送信しています。私たちのアプリケーションアカウントから、AWS WAF ログとフロー ログも設定されており、これらも中央ロギングアカウントに送信されています。その後、お客様はこのデータにアクセスして、独自の分析とインサイトを生成することができます。
このセットアップは実際に非常に良いパフォーマンスを発揮しており、私たちの主要なコンプライアンス要件を満たしています。しかし同時に、このプロセスを簡素化する余地があることも認識しています。このようなプロセスを簡素化する機会は、基本的にはコストの削減、運用オーバーヘッドに費やす時間の削減を含んでおり、これにより私たちはより戦略的なプラットフォームイニシアティブに焦点を移すことができます。
OCSFへの変革の旅：運用効率48%向上とインフラコスト47%削減の実現
では、どのようにしてこれを実現できるのでしょうか？ビジネスの観点から見ると、4つの重要な要因があります。まず、迅速なインシデント検出を加速させる機会を探ります。迅速なインシデント検出とセキュリティおよび運用に関連するアクティビティへの対応を改善することで、私たちはより迅速に対応し、重要なインフラストラクチャを素早く保護することができます。また、AI と ML の機能を有効にすることで、お客様体験を改善したいと考えています。インフラストラクチャを最新化し、AI と ML の統合に対応できるように構築することで、高度な分析を活用してビジネス価値を迅速に引き出すための立場を整えることができます。
IT の観点からは、中央ログ環境の運用コストを最適化したいと考えていたので、ストレージコストを削減しながらプロセスを合理化する機会を探していました。運用効率の観点からは、マネージドサービスの利用をより多く進めたいと考えていました。前のダイアグラムでご覧いただいたように、中央ログ環境を引き続き使用するには、多くの AWS サービスをセットアップして使用する必要があります。これは実際に私のチームに多くの運用上のオーバーヘッドを生み出しています。そのオーバーヘッドを AWS に戻したいと考えていました。
また、AWS の使用量が増えるにつれて、生成されるデータの量も増えます。データの増加により、データをクエリと処理に使用する際に多くの非効率が生じます。これに影響を与えるもう一つの要因は、すべてのデータが実は異なるログ形式であるということです。では、どのようにして変革を実現したのでしょうか。2024 年の Q3 に、中央ログ環境の機能と価値を見ている包括的な評価を実施しました。
AWS パートナーと密接に協力し、戦略的なインプットと主要なベストプラクティスを求めて受け取りました。2025 年の Q1 に、計画を開始し、私たちのチームが実際にデプロイメント計画をリードしました。一緒に、最適な中央ログ機能で実行できる計画を作成することができました。2025 年の Q1 に、実装が実際に開始されました。AWS Security Lake を選択して実装し、データを OCSF に自動的に変換するという利点をすぐに得ることができました。また、期待に対する実世界のパフォーマンスについていくつかの測定を行うことができました。
2024 年の Q4 に、OCSF 正規化データを使用して最新化された中央ログ環境をさらに活用する機会を見つけることに焦点を移したいと考えていました。AI 機能を解放できるユースケースを探していたので、チーム内の他の目的に使用できます。これが私たちが構築した最新化された中央ログ環境と OCSF です。ご覧のように、アプリケーションアカウントは依然として AWS CloudTrail、VPC フローログ、および WAF ログを生成していますが、重要な違いは、Security Lake を使用してデータを OCSF 形式に自動的に変換していることです。中央ログ環境から、ユーザーはデータにアクセスして、インサイトを生成し、分析を実行することができます。マネージドサービスアプローチへのシフトは、ログを OCSF に変換するだけでなく、インフラストラクチャコストの大幅な削減と運用効率も実現しました。さらに、AI 対応データを備えた最新化された中央ログアカウントが実現しました。
では、どのようにして運用効率の向上を実現したのでしょうか。これらすべての変更により、中央ログ環境の管理に費やす時間が 48% 削減されました。運用コストはほぼ半分削減されました。これがチームにとって何を意味するか想像してみてください。チームは今、戦略的なイニシアチブにより多く焦点を当てることができるようになりました。
では、どのようにして48%の効率化を達成したのかについてお話しします。実は、3つの主要な要因があります。まず1つ目は、迅速な導入です。マネージドサービスからの焦点転換により、組み込み機能の評価とテストに力を入れ、新機能の開発に費やす時間を削減し、中央ログソリューションの改善に注力することができました。その結果、新機能の導入に要する時間を数週間から数時間に短縮することができたのです。2つ目は、運用オーバーヘッドの削減です。Security Lakeがログ変換の重い処理を担当することで、ログ処理に使用されていたカスタムコードを排除することができました。主要なステークホルダーのデータアクセスは、今ではSecurity Lakeから直接利用可能になっています。そして3つ目は、すぐに使用可能なアクセスです。Security Lake内でデータが自動的にOCSFに変換されることで、データへのアクセスがセルフサービス化されました。ユーザーは即座にデータにアクセスして、分析を生成し、インサイトを作成することができるようになったのです。
Now、インフラストラクチャの利点は実際には運用効率を超えて、大幅なコスト削減にも及んでいます。 インフラストラクチャのコスト削減は約47%です。Security Lake内でのOCSFの標準化により、データストレージ、処理、分析の改善を通じてインフラストラクチャコストが削減されます。アプリケーションチームからのデータが自動的にOCSFに生成され、Parquet形式で保存されることで、実は複数のコスト削減効果がもたらされるのです。
AI駆動の脅威分析：5分以内のインシデント調査を可能にしたAgentic AIプロトタイプ
では、47%のコスト削減の要因は何でしょうか。まず1つ目は、マネージドサービスです。AWS Security Lakeへの移行により、スケールメリットの恩恵を受けることができました。これにより、カスタムインフラストラクチャを構築・維持する必要がなくなったのです。
中央ログ環境をデコミッションし、総所有コストを削減することができました。Open Cybersecurity Schema Frameworkの標準化は、ストレージ前に冗長フィールドを排除する標準スキーマを使用しています。Security Lake内では、異なるログ形式で複数回保存する必要がなくなり、ストレージフットプリントが削減されました。
私たちが運用する規模とデータ生成量を考えると、OCSFで標準化されParquet形式で保存されたデータは、実は大きなストレージコストが発生します。しかし、Parquetが提供する優れた圧縮機能がこれを相殺するのに役立っています。さらに、データが列形式でパーティション化されることで、Athenaクエリがより効率的に実行されます。これら4つの主要な要因、つまりマネージドサービス、OCSF標準化、圧縮ストレージ、クエリ最適化による計算量削減により、47%のコスト削減を実現することができ、これを他の革新的なソリューションへの投資に充てることができるようになったのです。
では、インフラストラクチャのコスト生成から、最近行った、より興味深いアクティビティを通じた運用インサイトの生成へと焦点をシフトさせましょう。Security Lake をデプロイしてデータにアクセスした後、私たちは AI エキスパートと協力して、ログをセキュリティオペレーションに活用する概念実証を探索することができました。私たちの目標は、AI がセキュリティインシデントの調査をより効率的に支援できるかどうかをテストすることでした。Agentic AI プロトタイプを使用すれば、WAF レコード ID を提供するだけで済みました。それが行ったことは、5 分以内に包括的なレポートまたはインサイトを生成することです。トラフィックとリクエストパターンを分析し、IP アドレスを含むソースを調べ、行動条件を検査し、実行可能な推奨事項を提供する詳細なレポートを作成しました。
生成された AI の知見は、OCSF の標準化されたスキーマがあったからこそ可能でした。AI はセキュリティコンテキスト、脅威インテリジェンス、インフラストラクチャコンテキストを相関させることができ、5 分以内にこのレポートを素早く生成しました。セキュリティとオペレーションの観点から、これは AI 駆動の脅威分析における根本的な強化を表しており、チームが手動のアプローチよりも迅速に、より効果的に調査できるようにエンパワーします。
このプロセスをもっと深く見てみましょう。過去の調査は非常に手動でした。私たちのチームは通常、履歴レコードからコンテキストを導き出していました。異なるログフォーマットを学習して翻訳し、複雑なクエリを開発し、パーティション分割された生データに対してそれらの複雑なクエリを実行する必要があり、通常は長い実行時間が発生していました。出力が得られたとき、それを意味のある情報に翻訳する必要がありました。Agentic AI プロトタイプでは、オーケストレーターは、私たちが行っていた同じ手動ステップを実行する子エージェントと調整することができました。今では、履歴レコードからコンテキストを自動的に取得できます。OCSF フォーマットであるため、ログを迅速に分析でき、最適化されたクエリを開発し、Parquet フォーマットでも保存されている OCSF 正規化データに対してそれらを実行でき、非常に優れた人間が読める形のインサイトが得られます。
AI を使用してセキュリティインサイトを生成する方法をお見せしましたが、今では運用インサイトでもそれを行うことができます。
本番環境の直後、私たちのお客様の 1 人がコスト使用量のスパイクを報告して連絡してきました。私たちのエンジニアは AWS MCP servers を使用してデータをクエリすることができました。ただし、OCSF が複数の AWS サービスに適用される標準化されたスキーマを持っているため、その情報を非常に迅速に生成することができます。OCSF ユニバーサルフォーマットがなければ、すべてのログを組み合わせて、その根本原因を特定するための特定の関係を見つけるのに数時間を費やしていたでしょう。
このケースの根本原因は5分以内に特定されました。私たちのチームは、EU のデータイベントが実際に有効になっていたため、KMS decrypt データイベントのスパイクが原因であることを特定することができました。これまで行ってきたすべての変更、つまり中央ログ環境の最新化と OCSF へのデータの正規化により、インフラストラクチャのコスト削減、運用効率の向上、そしてより多くの AI 機能を探索することが可能になりました。
これは私たちのチームに大きな関心を生み出しました。次のステップとして、効率をさらに高め、コストを削減し、より多くの AI 機能を探索する機会を見つけることに、より多くの時間を費やしていく予定です。OCSF が高度な AI と出会うときに何ができるかを学ぶために、Pratima にバトンを渡します。
OCSFとAgentic AIの融合：標準化されたスキーマが実現する効率的なログ分析
ありがとうございます、Alan。Alan からお聞きになったように、単一の標準化されたフレームワークがインシデント対応の加速、本質的には検出から対応までの時間短縮に極めて重要な役割を果たしています。 OCSF と agentic AI ソリューションを見るとき、最も重要なのはエージェントのコンテキストウィンドウです。異なるタイプのログイベントを扱うとき、異なるスキーマを扱うとき、相関させる必要がある異なる属性を扱うとき、AI エージェントのコンテキストは処理する必要のある情報に応じて拡大・縮小することができ、それはどれだけの情報を生成するかによって異なる応答をもたらす可能性があります。
OCSF のような明確で標準化されたフレームワークを見ると、そのオープンソースコードをエージェントのナレッジベースとして簡単にロードでき、エージェントがそこから学ぶことができるようにガイドすることができます。ですから OCSF は agentic AI の時代に明確な価値を提供しています。 では、このセッションに来る前に OCSF について聞いたことがある人は何人いますか？何人か手を挙げていますね。OCSF についてとても簡単な入門を提供しますので、もっと質問したければ、セッション後に詳しく話すことができます。
OCSF の中核は属性です。属性はキーと値のペアです。ログイベントが提示している情報を識別するキーと、ログイベントが送信している情報をキャプチャする値があります。 関連する属性の集合はオブジェクトを形成します。オブジェクトをプログラマーとして考えるなら、それはあるものを定義する属性の集合を定義する原子的な単位です。
では、オブジェクトの集合がクラスになります。クラスは単一のログイベントを表します。 さて、複数の異なるタイプのソースから異なるタイプのログイベントが発行される可能性があります。単一のソースが異なるクラスに対応する様々なタイプのログイベントを発行することもあります。例えば、AWS CloudTrail を見ると、認証アクティビティを発行し、API アクティビティを発行し、また監査アクティビティを異なるクラスとして発行しています。
しかし、例えば EC2 インスタンスを通じて SSH で接続する際の SSH アクティビティを見ると、それは単一の標準的なログです。ネットワークアクティビティと呼ばれるカテゴリに該当する SSH アクティビティです。では、複数のクラスの集合が私たちが呼ぶところのカテゴリであり、それらはすべて関連しているので、認証アクティビティがネットワークアクティビティカテゴリの下に分類されることはありません。 SSH、TCP アクティビティ、HTTP アクティビティ、FTP アクティビティなど、ネットワークリソースまたはネットワークソースが生成できるすべてのものが関連しています。
OCSF は、任意の環境、任意のソリューション、または任意のアプリケーションに適応可能なオープンスタンダードであることを目標に設計されており、同時に既存のセキュリティコントロールを補完するため、環境内で既に持っている価値を減らすことはありません。 では、ここに 2 つのログソースがあります。手を挙げて、それぞれがどこから来ているのか特定できるかどうか教えてください。さて、見てみると、これらは AWS WAF と VPC flow logs から来ているログソースです。
ここで、例えば侵害の指標を見つけなければならないシナリオに置かれていると想像してください。ネットワークスタックを通じて、レイヤー 7 からレイヤー 4 まで移動している IP アドレスなどです。最初にしなければならないことは、VPC flow log が発行している 1 つの標準的なアウトラインを理解することです。それを JSON パース可能にし、VPC flow log を通じて来ている値をキャプチャするための属性を追加し、その後それらを相関させる機能を持つことになります。 そして、何らかのビジネス価値を生成するか、あなたがしようとしていることを達成します。
これが、今日、生のログソースで行わなければならない種類のデータラングリングであり、これは、異なるデータタイプとデータボリュームに関して以前に議論されたことを思い出させます。しかし、今、これをすべて翻訳して OCSF クラスにマップすると、すぐに目に飛び込んでくるのは、ログスキーマがいかに一貫しているかです。WAF アクティビティログと VPC flow log で、ソース IP アドレスがまったく同じ場所に見つかります。 あなたが覚えておく必要があるのは、すべてのログソースが行くデータレイクを持っている場合、その情報がどのテーブルに収集されているかだけです。
ソースエンドポイントの IP がまさにその IP アドレスが存在する場所であることが分かります。さらに重要なのは、OCSF はデータ型に関して非常に厳密だということです。IP アドレスは IP アドレスというデータ型になります。AWS アカウント ID は文字列型になり、あるログソースでは大きな整数ではなく、別のログソースでは文字列ではなく、データ型の変換を行う必要があります。もう 1 つの付加価値は、OCSF がカスタマイズ可能だということです 。observables という構造を使って、相関させたり情報を取得したりするために、より頻繁に使用する特定の共通値をサーフェスすることができます。
つまり、背後にあるログソースやログを発行しているエンティティに対して完全に免疫を持つようになります。あなたが気にするのは、どのアクティビティを追跡しようとしているのか、またはどの値を相関させようとしているのかだけです。では、典型的なトリアージシナリオに移りましょう。ここにいるセキュリティオペレーターの中で、セキュリティイベントが発生したときにページを受け取る人は何人いますか？朝の 3 時に起こされることになりますよね？では、アラートを受け取った最初にあなたは何をしますか？ 最初にすることは、このアラートで何をすべきかを理解しようとすることです。ランブック、プレイブック、または何もない状態で、何とか対応しようとします。
次にすることは、そのアラートについてなぜ気にする必要があるのかを確認することです。朝の 3 時に起こされる価値があるのでしょうか？もしかしたら本番環境で、対応する必要があるかもしれませんが、サンドボックス環境で開発者が大きなゲームの夜の後にテストすることに決めた場合、隔離された環境であることを知っているので、横展開を許さないため、今すぐ対応する必要はないかもしれません。これがビジネスコンテキストであり、対応の速度や率を決定します。
ビジネスコンテキストを確立したら、誰が何をしたのか、どこで、いつ、なぜかを理解したいのです 。これがすべての中心です。この環境で何が起こっているのか、そして何が起こっているかを確立した後に何をすべきかのログ分析です。最後に、これは以前に起こったことがありますか？ 起こった可能性があります。チケッティングシステムとバックアップシステムを通じて保存する履歴証拠があり、もしこれが再び起こった場合、どのような手順を取る必要があるかを確立したいのです。
これらすべてを agentic AI シナリオに組み込むと、これらすべてを異なるエージェントに分割することができます。 これにより、これらのログに対して操作し、ログ分析ワークフローを強化するカスタマイズ可能で曖昧でなく、一貫した方法が得られます。デモが後に続くため、これを分割します。このデモが特定のフローを説明します。 orchestrator がセキュリティオペレーターだと言いましょう。orchestrator に最初に当たるのはアラートです。この場合、何をすべきかを理解する必要があります。ランブックはどこにありますか？プレイブックはどこにありますか？
実践デモと今後の展開：AWS WAFログ分析とエージェント活用の可能性
あるエージェントが、皆さんの環境内のさまざまなデータソースに広がっていって、ランブックがどこにあるのかを見つけ出す、あるいは画面に映っているアプリケーションに関連した何かを見つけ出す、もしくは画面に映っているリソースに関連した何かを見つけ出すというシナリオを想像してみてください。ランブックを手に入れたら、今度は この特定のアラートのビジネスコンテキストが何であるかを確立したいわけです。これらのアラート内のリソースは、なぜそれらが重要なのか、あるいはそれらの周辺で何が重要なのか。機密情報へのアクセス権限を持っているかもしれませんし、その場合はすぐに対応する必要があります。あるいはサンドボックス環境でダミーデータを含んでいるかもしれませんし、その場合は後で対応してもいいかもしれません。
そこでオーケストレーター がビジネスコンテキストを取得するためにエージェントをトリガーします。ビジネスコンテキストを手に入れたら、そのコンテキスト情報を見て、ログ分析をトリガーするわけです。 ログ分析というのは、インシデント対応シナリオにおいて最も人手がかかるタスクの一つです。
インシデント対応シナリオにおいて人手がかかるタスクを自動化することは、皆さんの対応時間に大きな影響を与えることができます。ログを分析するのに費やす時間は、全体的な対応時間を増やすか減らすかのどちらかです。これらの人手がかかる、非常に繰り返し可能な手作業は、エージェントに任せるのに最適な候補であり、セキュリティオペレーターを解放して、より良いエージェントを構築したり、オーケストレーターがより解釈しやすいより良いプレイブックを考えたりすることができます。ログ情報を手に入れたら、オーケストレーターはそれを解釈して、受け取ったビジネスコンテキストと相関させることができます。
ログの行を手動で見ていって、その後、どこかで見たコンテキストを把握しようとしたり、アカウントがどこから来たのか、あるいは IP アドレスがどこから発信されているのかを判断しようとしたりしながら、同時にどんどん速く対応するよう急かされているというシナリオを想像してみてください。 もちろん、調査履歴も保存する必要がありますし、次に同様のことが起こった時に、この情報をすぐに利用できるようにする方法を考える必要があります。これは十分にシンプルに思えますし、本質的にはセキュリティオペレーションシナリオで皆さんがやることです。
これを Merck との事例に当てはめると、AWS WAF ログをより深く掘り下げるために、彼らとの概念実証を構築しました。デモとして、デモアプリケーションをデプロイして、WAF によってブロックされた約 1000 万件のリクエストを含む分散負荷テストでそれをロードしました。1000 万件の WAF ログを見て、各リクエストがブロックされたのか許可されたのかを確認して、フィルターを設定して、Athena クエリを実行して、すべてを生ログで操作しながら行うというシナリオを想像してみてください。それにかかる時間は相当なものになります。
ここに1つの orchestrator があるんですが、今のところ investigation がまったくないので、investigation history もまだ何もない状態です。 この orchestrator には3つのエージェントが利用可能なツールとして用意されています。log analytics agent、business metadata agent、そして historical evidence agent です。 最初に私がやることは、AWS WAF が特定の AWS アカウントで疑わしいアクティビティを検出したということをそれに伝えることです。それ以上の情報は何も与えません。このアカウントが自分の AWS アカウント全体の中でどういう意味を持つのか分かりませんし、WAF が何のアクティビティを検出したのかも分かりません。ただ何かが起きているということだけ分かっているんです。
orchestrator が最初にやることは playbook agent をトリガーすることです。なぜなら、それが何をすべきなのかを理解する必要があるからです。 アカウント ID が関係していることが分かります。WAF を見ていて何かをしようとしているので、その後さらに2つのエージェントをトリガーします。 そして、このアカウント ID のビジネスコンテキストを見つける必要があると言うんです。なぜなら、このアラートから得られる唯一のリソースがそれだからです。それが重要なのかどうかも知る必要があります。また、何が起きたのか、どこで、いつ、なぜ起きたのかを知る必要があります。
ゆっくりと確実に、バックエンドを調べていきます。私の場合は DynamoDB テーブルに値を入れておきましたが、皆さんの場合は、エージェントに接続する CMDB の MCP である可能性もあります。そして分析を完了して、何が起きているのかを教えてくれます。これは皆さんが調べるよう求めたアカウントです。 AWS organization に関するすべての情報を提供してくれます。ビジネスの重要度、データ分類、そしてこのアカウントで何か起きた場合に誰と話すべきかという情報も含まれています。これらの情報はすべて皆さんが既に持っているデータから来ているんです。その後、WAF で起きたすべてのことを調べます。1000万行のログを停止させたと教えてくれて、それらはすべてブロックされていました。疑わしいアクティビティが起きています。これは DDoS のようなイベントで、レート制限されており、推奨アクションを提示してくれます。
ちなみに、私はエージェントにそのようなことをするための訓練をする必要はありませんでした。単に WAF ログアクティビティを調べて、ここで何ができるかを教えてくれというプロンプトを入れただけです。約3時間分のデータを見ています。コンテキストウィンドウに過負荷をかけたくないからです。 すべてを小さな investigation history に要約して、それがデータストアに investigation history として戻ります。 次にこのエージェントをトリガーして同じアカウント ID を与えるとき、playbook agent を見る必要さえありません。なぜなら historical evidence を通じて、このアカウント ID は最後のイベントで調べたのと同じメタデータを持つことになっているということを既に知っているからです。その特定の investigation のコストを捉えるために興味深いことをしました。何個のエージェントがトリガーされたか、そして何個のトークンが交換されたかです。
これらすべてが数分の間に起きました。コンピュータの反対側にいる自分自身を想像してみてください。これを行うのに、数分ではなくても、少なくとも数時間はかかるでしょう。何が起きているのかを理解して、その investigation history を作成するのに。今、これらすべては OCSF によって内部で動作しています。私のエージェントは OCSF をそのまま解釈することができました。異なるタイプのログスキーマが通ってくるときに幻覚を見ませんでした。なぜなら、彼らは正確にどのログスキーマ、またはむしろフレームワークで作業しているのかを正確に知っていたからです。そして、それが WAF ログから来ていることを理解していました。WAF ログアクティビティについて話すときそれが何を意味するのかを理解していました。
このプルーフオブコンセプトの構築は非常にシンプルでした。OCSF コミュニティは多様性と適応性の価値を認識しており、Black Hat 2022 で最初に紹介されて以来、成長を続けています。現在、1,100 以上のパートナーがこれをサポートしており、200 以上の組織が使用しています。上部の QR コードをスキャンすると、OCSF のオープンソース Slack チャネルにアクセスできます。OCSF について質問がある場合は、コントリビューターに直接質問することができます。彼らは参加できるコールを開催しています。2 番目の QR コードは、最近リリースした Amazon の OCSF Ready specialization パートナー向けのものです。これらは AWS サービスによって生成された OCSF ログを消費し、その上にソリューションを構築する技術的能力を確立したパートナーです。ビジネス内でこれを行える人数が限られている場合は、これらのパートナーを活用することができます。
テクノロジーのすべてのことと同様に、生成 AI ソリューションではさらに加速していますが、すべてが常に変わっています。このソリューションを構築したとき、Bedrock Agents がバックエンドでしたが、今はすべて Agent Core です。Agent Core を使用してイノベーションを起こす方法を考えてみてください。Agent Core は、生成 AI ソリューションを構築するための完全にセキュアな環境を提供します。これは完全にマネージドされており、エージェント間の分離を構築するために identity と gateway のようなコンストラクトを使用しています。追加のエージェントを追加する方法を考えてみてください。ビジネスにとって何が有益でしょうか。インシデント対応ライフサイクルの中で、エージェントが必要な独自のアイテムは何でしょうか。それらは私が示したものとは異なる可能性があります。これは一般化されたユースケースです。
MCP 統合について考えてみてください。すべてを AWS アカウント内に保存していない理由があるかもしれません。サードパーティのアカウントやサードパーティのサービスを使用している可能性があります。特定の identity サービスや特定の response サービスを使用している可能性があります。MCP を使用して、これらすべてのソリューションをこの環境に統合し、その情報から供給を受けることができます。Amazon の OCSF Ready パートナーを使用している場合、OCSF をそのまま消費することができます。これを構築したとき、Amazon Quick Suite は利用できませんでしたが、Amazon Quick Suite は生成 AI ソリューションと対話するための完全にマネージドされたインターフェースを提供するため、フロントエンドを構築する必要がなくなります。Amazon Quick Suite との MCP 統合を通じてフックするだけです。
このセッションの重要なポイントは、OCSF についてさらに学習を続け、OCSF がログ分析ユースケースとセキュリティオペレーションユースケースでどのような価値をもたらすことができるかを確認することです。エージェンティック AI ソリューションについてさらに学んでください。そこにリンクされているエージェンティック AI の学習リソースがあります。実は昨日、AWS MCP server をリリースしました。これは AWS API MCP と AWS knowledge bases への管理インターフェースです。これは、環境内のリソースを直接修復できるエージェントを構築するのに役立ちます。これを使用して、下位の環境を自動的に修復し、本番環境を修復するための人間の監督または承認ワークフローを配置することもできます。本日、何か新しいことを学んでいただけたことを願っています。セッションにご参加いただきありがとうございました。アプリのセッションサーベイでフィードバックをお願いします。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion