[レポート][NEW LAUNCH!] Introducing Amazon Security Lake #SEC216 #reinvent

AWS re:Invent 2022で発表された新サービスAmazon Security Lakeのブレークアウトセッションのレポートブログ
2023.01.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

セッション

スピーカー:Rod Wallace, Jonathan Garzon
セッションレベル:200 - Intermediate
カテゴリ:Security

動画本編

はじめに

本投稿は、AWS re:Invent 2022で行われたセッション「[NEW LAUNCH!] Introducing Amazon Security Lake」のレポートブログになります。
本編ではAWS re:Invent 2022で新サービスとして発表されたAmazon Security Lakeのサービス概要やユースケース、料金について紹介されています。

内容

  • セキュリティデータの分析はますます困難になっている

  • セキュリティデータが増え続けていること
    • オンプレミスからクラウドへ移行することでデータ量がさらに多くなる傾向がある
    • クラウドへの移行によってシャドーITが突然完全に見ることができるようになった
    • それと引き換えにデータ分析の難しさが増している
    • 1日あたり1Tバイトや1Pバイトのログを減らしたいと要望する顧客も多い
    • ログをどのように処理するか

  • データの一貫性と完全性の欠如
    • ログ収集の失敗がおこると二度と可視性を取り戻すことができなくなる
    • クラウドにおけるアジリティは一種の諸刃の剣である
    • あるセキュリティ製品では、30日間のデータ保持期間がないため30日分の分析しかできないものもある

  • データの所有権を直接保有していないケース
    • アプリケーション上にデータを収集していてもセキュリティの専門的分野からは切り離されている
    • 例えば、MLで分析を開始したい場合でも、データの所有権を保有していないことが問題になる

  • 増えていくデータのクレンジグと分析力の欠如
    • データの正規化やデータ収集のパフォーマンスの向上を実現するため、独自の実装をしようとするが、多くの人的リソースを必要としてしまう

  • これらの課題に対して4つのサービスを必要としている
    • セキュリティレイクを自分のアカウントに自動的に構築してくれる
    • クラウド、オンプレミス、SaaSなどの組織全体で中央化され、標準化されたフォーマットでのログ収集
    • 十分に長いデータ保持期間と最適化されたストレージ
    • やりたい分析を自由に選択できる

  • ログ標準化の問題に関してはOCSF(Open Cybersecurity Schema Framework)を活用することができる
    • 同じデータフォーマットを持つことでデータの輻輳と分析に関する問題が改善される

  • re:Invent 2022でAmazon Security Lakeのサービスを公表した
  • クラウド、オンプレミス、SaaSどんな環境であれセキュリティデータをー元化する
  • データはクエリのために最適化され、データサイズも同様に最適化される
  • AWS環境の場合AWSソースはすべて自動的にOCSFに変換される
  • データはS3に保存されるので、データの所有権を保持したまま
  • データを実際に操作するためのソリューションを自由に選択することができる

  • OCSFのデータフォーマットになっているためDNSログの場合、Route 53とBindサーバーのように異なるソースであっても、同じクエリを利用することができる
  • データはApache Parquetによって90%圧縮できる
  • S3に保管されるので、データの保持期間を自由に操作しながら、他のデータストレージ層へライフサイクルマネジメントをすることができる
  • AWSソースについては数クリックで取り込むことができる
  • 様々なサードパーティーのセキュリティ分析ソリューションからセキュリティレイクのデータを利用できる

  • プレビュー段階で37社のセキュリティパートナーが統合を開始することになっている

  • Security Lakeのデータ収集設定
    • クロスアカウントで全てのAWSソースを取り入れることができる
    • 収集するソースの各種定義とデータの保持期間を設定する

  • Security Lakeに取り込んだデータはすぐにOCSFクエリを使うことができる

  • AWSだけではなく、オンプレミスのセキュリティデータを取り込むことができる
  • Create custom data sourceで作成をクリックすると、S3、OCSF、Apache Parquet形式で直接書き込むためのソースプロバイダーが引き受ける必要があるロールが作成される

  • 有効にする共有データモードを選択することができる
  • Data accessではデータの取り込みがあったことの通知を受けることができる
  • Query accessという統合パターンでは、データを移管することなく、SIEMや他のセキュリティソリューションからオンデマンドにデータを取り出し調査を実行できる

  • 特定のセキュリティソリューションとデータを共有するためのサブスクライバーを構成するための設定

  • Data accessの選択では、S3かLakeformationを選択できる
  • サブスクライバーが受け取る通知をSQSかSNSから構成することができる

  • 様々なサードパーティーをサブスクライバーとして構成することでセキュリティレイクのデータを利用することができる

  • プライシング
    • サードパーティーのデータをセキュリティレイクに持ち込む場合、セキュリティレイクでの料金はかからない
    • AWSサービスからセキュリティレイクに取り込み時と、正規化時にデータのGBあたりの料金がかかる
    • ※その他に連携するAWSサービスの料金は別途かかる

参考情報

まとめ

re:Invent 2022で新サービスとして発表されたAmazon Security Lakeのブレイクアウトセッションについてご紹介しました。

ログ管理がより統制され、OCSFという共通のログフォーマットに正規化されることで、用途に則した他の分析基盤との連携がやりやすくなりました。
その他にもデータの収容先としてS3に保管できるので、分析の際のコストパフォーマンスにおいても非常に期待ができそうです。
各種サードパーティーの分析基盤を利用した際の実際のコスト感についてはまだ調べきれていませんが、その辺りも注目していこうと思います。