時間切れで書き切れなかった OCSF の⾏末とは Security-JAWS 第32回 2024年2⽉14⽇(⽔) ⽇⽐野 恒

⾃⼰紹介 ⽇⽐野 恒 - Hisashi Hibino Security Architect CISSP, CCSP, CISA, PMP, 情報処理安全確保⽀援⼠（000999） [執筆] Ø Elastic Stack 実践ガイド [Logstash/Beats 編]（インプレス刊） Ø AWS 継続的セキュリティ実践ガイド （翔泳社刊） Ø セキュリティログ分析基盤活⽤⼊⾨（@IT） [略歴] l 2018 年までの 10 年間、IT コンサルティング会社に在籍 l 2019 年より⼤⼿ Web 系ユーザー企業のセキュリティ組織に所属 l 多くのログ基盤やクラウドセキュリティに関するプロジェクトを推進 l 現在はフリーの IT コンサルタント兼アーキテクトとして活動中 2

本⽇のテーマ 3

本⽇のお品書き 1. Security Lake の話 2. OCSF の話 3. どのように向き合うと良いか︖

最適なログ基盤アーキテクチャとは • “このツールを使えば最強だよ” というものはない。 どんなスキルの⼈がログを使って何したいのかによる （リアルタイム監視がしたいのか、分析レポートが作り たいのか ...etc） • 各⾃のやりたいことや実現したいことに応じて、最適な ツールやアーキテクチャにたどり着けるようなものが必 要だと考え、本書を書くことにした • 逆引き本にはしていないが、1 つの課題に対して⾊々な 選択肢が⽤意されている中で、その選択肢から⾃分たち に合ったものを選ぶための考え⽅や基準は指し⽰したつ もり 5

9⽉ 執筆完了 5⽉ Security Lake GA 12⽉ 書籍発売 6⽉ OpenSearch Ingestion 連携 11⽉ Detective との統合 10⽉ OpenSearch OCSF 対応 2⽉ 執筆開始 執筆時からの時系列とアップデート 2023 年にあった出来事 あ、出ちゃった... いやぁ、もう⼿遅れぽ... 【アップデート情報】 • https://aws.amazon.com/jp/about-aws/whats-new/2023/05/amazon-security-lake-generally-available/ • https://aws.amazon.com/jp/about-aws/whats-new/2023/06/amazon-opensearch-ingestion-events-security-lake/ • https://aws.amazon.com/jp/about-aws/whats-new/2023/10/security-analytics-opensearch-service-ocsf-custom-logs/ • https://aws.amazon.com/jp/about-aws/whats-new/2023/11/amazon-detective-log-retrieval-security-lake/ 6

この順番で読み進めると理解が深まるはず 余談ですが、本書を読む前に「AWS ではじめるクラウドセキュリティ」を読むのをお勧めする （査読させていただいた） （畠中さんに査読してもらった） 7

1. Security Lake の話

Security Lake とは 1. セキュリティ業務に必要なさ まざまなログを S3 に集約で きる 2. ログのフォーマットを OCSF に統⼀できる（Apache Parquet 形式で保存） 3. セキュリティ業務で利⽤され る分析ツールとの連携がシー ムレスになっている 【主な特徴】 セキュリティで利⽤するログやイベントをあとで活⽤しやすい形式で S3 に集約するためのサービス 9 3rd Party と Security Lake との統合（約70製品）: https://docs.aws.amazon.com/ja_jp/security-lake/latest/userguide/integrations-third-party.html

思想というか制約というか... 10 Security Lake は AWS セキュリティリファレンスアーキテクチャ（AWS SRA）に準拠している ü AWS Organizations の管理下に⼊れないと CloudTrail 管理イベントを集約できない （組織のマルチリージョン証跡が最低1つは必要なため、スタンドアローンアカウントでは収集できない） ü AWS Organizations の管理アカウントでは Security Lake を有効化できない （管理下のメンバーアカウントに Security Lake の管理を委任する必要がある） ü AWS Organizations 管理下の同⼀アカウントでは Detective との統合が設定できない （管理下の Security Lake の委任アカウントとは別のアカウントで Detective を有効化する必要がある） 例えば ... 推奨ではなく強制なため、Security Lake の検証環境構築のハードルは意外と⾼い

Source Detective Integration Tokyo Region SIEM on Amazon OpenSearch Service Source 検証環境を作ろうとすると... AWS Cloud（Master Account） AWS Cloud（Member Account） Tokyo Region CloudTrail (証跡) Security Lake Detective CloudTrail Flow logs Security Hub Route53 Security Lake 委任 IAM AA Macie Inspector GuardDuty Organizations Athena OpenSearch Root SQS es-loader SecOpe SecOpe 【検証内容】 • 取得可能な AWS サービスのソースを全て取得する • Detective から VPC Flow Logs と CloudTrail 管理イベントをクエリする • SIEM on Amazon OpenSearch Service にソースのデータを収集する 11 取込み 取込み クエリ クエリ 取込み 検索/可視化 検索 調査 ※ Athena および SIEM on Amazon OpenSearch Service は同⼀アカウントから検索可能

現時点では未対応な AWS サービスのログたち # サービス名/機能名 ログの種類 説明 1 API Gateway アクセスログ API Gateway で受信した API リクエストのアクセスログ 2 Aurora SQL 監査ログ データベースに対する SQL 操作の監査ログ 3 AWS WAF トラフィックログ ウェブ ACL で分析されるトラフィックに関する詳細情報をキャプチャしたトラフィックログ 4 CloudFront 標準ログ CloudFront が受信するユーザーリクエストに関する情報を含めたアクセスログ（概ね 1 時間以内） 5 CloudFront リアルタイムログ CloudFront が受信するユーザーリクエストに関する情報を含めたアクセスログ（数秒以内） 6 DynamoDB オブジェクトレベルログ MongoDB に対するデータ定義⾔語 (DDL)、認証、認可、ユーザー管理のイベント監査ログ 7 EKS 監査ログ Kubernetes のコントロールプレーンに関する監査ログ 8 ELB（ALB/CLB/NLB） アクセスログ ELB で受信したリクエストの詳細情報をキャプチャしたアクセスログ 9 FSx for Windows File Server ファイルアクセス監査ログ Windows ファイルサーバに対するファイルアクセス監査のイベントログ 10 Neptune クエリ監査ログ Neptune データベースに対するクエリ操作の監査ログ 11 OpenSearch Service 監査ログ OpenSearch に対する接続とユーザー操作に関する監査ログ（認証、リクエスト、検索クエリなど） 12 Route 53 Hosted Zone DNS クエリログ Route 53 で作成したホストゾーンが受信するパブリック DNS クエリログ 13 RDS SQL 監査ログ データベースに対する SQL 操作の監査ログ 14 S3 サーバアクセスログ S3 バケットに対するリクエストの詳細が記録されるサーバアクセスログ 15 Session Manager セッションアクティビティログ Session Manager で EC2 接続して実⾏したシェル操作ログ（Windows PowerShell も含む） 16 Transfer Family SFTP イベントログ OpenSSH をベースとした SFTP サーバのイベントに関するログ（接続、ファイル転送などに関する操作） 17 Network Firewall ファイアウォールログ VPC 向けのステートフルなマネージドネットワークファイアウォールを通過したフローログとアラートログ 12

2. OCSF の話

OCSF（Open Cybersecurity Schema Framework） 14 サイバーセキュリティのログ運⽤に必要なオープンで標準化されたスキーマを提供するフレームワーク （セキュリティエンジニアによる ETL ジョブの開発負荷を減らすことが期待されている） OCSF Schema: https://schema.ocsf.io/ ü 6 つのカテゴリ、32 種類のクラ スに分類され、各クラスごとにス キーマ（フィールド名、データ型 など）が定義されている ü CloudTrail 監査ログは API Activity (3005) と Authentication (3002)、VPC Flow Logs は Network Activity (4001)、Route53 Resolver ク エリログは DNS Activity (4003)、 Security Hub は Security Finding (2001) のスキーマを利 ⽤している 【主なポイント】

# フィールド名 データ型 サンプル値 1 metadata struct {product={version=1.09, name=CloudTrail, vendor_name=AWS, feature={name=Management}}, uid=8ab827c8-cd3f-4f13-a4a4-93a3a0438c3f, profiles=[cloud], version=1.0.0-rc.2} 2 time bigint 1707178499000 3 cloud struct {region=ap-northeast-1, provider=AWS} 4 api struct {response=null, operation=GetBucketAcl, version=null, service={name=s3.amazonaws.com}, request={uid=K0638DFVHV99MTPW}} 5 dst_endpoint struct - 6 actor struct {user={type=AWSService, name=null, uid=null, uuid=null, account_uid=null, credential_uid=null}, session=null, invoked_by=cloudtrail.amazonaws.com, idp=null} 7 https_request struct {user_agent=cloudtrail.amazonaws.com} 8 src_endpoint struct {uid=null, ip=null, domain=cloudtrail.amazonaws.com} 9 resources array [{uid=arn:aws:s3:::logs-123456789012, account_uid=123456789012, type=AWS::S3::Bucket}] 10 class_name string API Activity 11 class_uid int 3005 12 category_name string Audit Activity 13 category_uid int 3 14 severity_id int 1 15 severity string Informational 16 user struct - 17 activity_name string Read 18 activity_id int 2 CloudTrail 管理イベントログのスキーマ構造 ※ CloudTrail S3 データイベントおよび CloudTrail Lambda データイベントも同じスキーマ構造になっている 【ポイント1】 使いたいフィールドが STRUCT 型と なっている。意外と使いにくそう。 15 【ポイント2】 時刻がUNIXTIMEで且つ13桁でミリ 秒形式となっている。

# フィールド名 データ型 サンプル値 19 type_uid int 300502 20 type_name string API Activity: Read 21 status string Success 22 status_id int 1 23 mfa boolean - 24 unmapped map {additionalEventData.SignatureVersion=SigV4, additionalEventData.CipherSuite=ECDHE-RSA-AES128-GCM- SHA256, additionalEventData.bytesTransferredOut=548, requestParameters.acl=, additionalEventData.x-amz-id- 2=rCGmasisq1dUz/TJNQB76iKKNAd+vpTDpQYVEqckeAstaPnglwKfJ+j6xSbbtlWVXqT3f1Lju9s=, readOnly=true, eventType=AwsApiCall, requestParameters.Host=logs-123456789012.s3.ap-northeast-1.amazonaws.com, additionalEventData.AuthenticationMethod=AuthHeader, sharedEventID=a7338e6f-506c-4645-ae66- 0f684b903399, requestParameters.bucketName=logs-123456789012, recipientAccountId=123456789012, managementEvent=true, additionalEventData.bytesTransferredIn=0} 25 region string (Partitioned) ap-northeast-1 26 accountid string (Partitioned) 1234567890112 27 eventday string (Partitioned) 20240206 CloudTrail 管理イベントログのスキーマ構造（続き） 16 【ポイント3】 使いたいフィールドが MAP 型となってい る。これも使いにくそう。 （マッピングできなかったフィールドが 放り込まれるフィールド） ソースの柔軟性・可変性を許容するためにはこうなることは必然...

Athena でのクエリについて ü STRUCT 型のフィールド抽出⽅法 ü MAP 型のフィールド抽出⽅法 ü UNIXTIME の⽇付（⽇本時間）変換⽅法 17 Security Lake に集約したテーブルに対して、Athena でクエリする上でこの辺りは知っておきたい Security Lake クエリ: https://docs.aws.amazon.com/ja_jp/security-lake/latest/userguide/subscriber-query-examples.html

# フィールド名 データ型 フィールド値 1 api struct {response=null, operation=GetBucketAcl, version=null, service={name=s3.amazonaws.com}, request={uid=K0638DFVHV99MTPW}} api の値からサービス名をフィールドとして抽出するには階層構造をドットで指定する SELECT api.service.name AS service FROM "amazon_security_lake_glue_db_ap_northeast_1"."amazon_security_lake_table_ap_northeast_1_cloud_trail_mgmt_1_0” LIMIT 1; # service 1 s3.amazonaws.com 【実⾏結果】 【SQL⽂】 18 【参考】STRUCT 型のフィールド抽出⽅法

# フィールド名 データ型 フィールド値 1 unmapped map {additionalEventData.SignatureVersion=SigV4, additionalEventData.CipherSuite=ECDHE-RSA-AES128-GCM- SHA256, additionalEventData.bytesTransferredOut=548, requestParameters.acl=, additionalEventData.x-amz-id- 2=rCGmasisq1dUz/TJNQB76iKKNAd+vpTDpQYVEqckeAstaPnglwKfJ+j6xSbbtlWVXqT3f1Lju9s=, readOnly=true, eventType=AwsApiCall, requestParameters.Host=logs-123456789012.s3.ap-northeast-1.amazonaws.com, additionalEventData.AuthenticationMethod=AuthHeader, sharedEventID=a7338e6f-506c-4645-ae66- 0f684b903399, requestParameters.bucketName=logs-123456789012, recipientAccountId=123456789012, managementEvent=true, additionalEventData.bytesTransferredIn=0} unmapped の値から特定のキーをフィールドとして抽出するには MAP_FILTER 関数で条件指定する SELECT MAP_FILTER(unmapped,(k, v)->k = 'requestParameters.Host') AS request_parameters_host FROM "amazon_security_lake_glue_db_ap_northeast_1"."amazon_security_lake_table_ap_northeast_1_cloud_trail_mgmt_1_0” LIMIT 1; # request_parameters_host 1 logs-123456789012.s3.ap-northeast-1.amazonaws.com 19 【参考】MAP 型のフィールド抽出⽅法 【実⾏結果】 【SQL⽂】

# フィールド名 データ型 フィールド値 1 time bigint 1707155077000 time の値（UNIX時間のミリ秒表記）の秒以下を切り落とした上で表記とタイムゾーンを変換する SELECT CAST(from_unixtime(time / 1000) AS timestamp) AT TIME ZONE 'Asia/Tokyo' AS date_time_jst FROM "amazon_security_lake_glue_db_ap_northeast_1"."amazon_security_lake_table_ap_northeast_1_cloud_trail_mgmt_1_0” LIMIT 1; # date_time_jst 1 2024-02-06 02:44:37.000 Asia/Tokyo 【SQL⽂】 20 【参考】UNIXTIME の⽇付（⽇本時間）変換⽅法 【実⾏結果】

21 OpenSearch Service の unmapped フィールド STRUCT 型は⾃動的にフィールド抽出されるが MAP 型はフィールド抽出されず構造体のまま （ダッシュボードでの可視化やアラート条件に活⽤しにくい） ちなみに SIEM on Amazon OpenSearch Service に取り込むとこんな感じになっていた （これなら CloudTrail 証跡はそのままログとして取り込んだほうが扱いやすい）

3. どのように向き合うと良いか︖

クエリアクセス データアクセス Security Lake Security Lake を利⽤する上での考え⽅ 23 CloudTrail VPC Flow Logs ・ ・ ・ ログの収集 各種ログ (データソース) データレイク ログの保存 データ ウェアハウス ログの正規化 データ マート ※1 ログの活⽤ 探索的分析 監視 可視化 ス テ # プ 「監視によるアラート通知」を実施するには、データアクセスによるログ・イベント収集が必要になる （「探索的分析」や性能を求めない「可視化」であれば、クエリアクセスによる検索で⼗分事⾜りる） (サブスクライバー) ※1 監視クエリの定期実⾏はストレージのIO性能が求められるため、マートのためのストレージコストがかかるケースが多い。

Security Lake vs S3 24 S3（素の） Security Lake つよみ つらみ ü Security Lake のソースで対応していない AWS サービ スのログも扱えるため、ソースの柔軟性が⾼い ü Athena や OpenSearch などの分析環境を構築しなく てもファイルをダウンロードしてテキスト上で検索でき る（検索の柔軟性が⾼い） ü 半構造化データ（CSV/TSV、JSON、parquetなど）で あれば、Athena含め分析や可視化は⽐較的容易に実施 できる ü S3 に集約・蓄積するだけではすぐにビジネスに利活⽤ できない（Athenaでクエリするにもスキーマ定義など の分析環境の構築が必要となる） ü S3 に蓄積したデータがどんなフィールド構造になって いるか分からない場合は、アドホックな分析を⾏い、 データのカタログ化などの準備作業が必要になる ü Security Hub が出⼒する Findings を S3 にシームレ スに連携する⽅法はない（Lambda で処理を書くな ど） ü CloudTrail S3/Lambda データイベント、VPC Flow Logs、Route53 Resolver は Security Lake での有効 化で⾃動で集約が始まる（Security Hub はサービスを 有効化しないと Findings は集約されない） ü 3rd Party 統合対応している製品を使いたい場合、連携 が容易になる ü Detective との統合で CloudTrail 管理イベント、VPC Flow Logs の⽣ログのクエリが可能となる ü マルチアカウント・マルチリージョンの集約が容易にな る ü AWS Organizations 管理下のアカウントで有効化しな いとできないことがあるため、⼩規模環境では気軽るに 開始しづらい（CloudTrail 管理イベントの集約、 Detective との統合など） ü ⾔うほどスキーマ定義が共通化されていないため、クエ リでできることが限定的となる（別途マートを作ること になりそう） ü ソース対応していないログを活⽤したい場合、別途 S3 バケットに集約することになり、運⽤が複雑化する S3 バケットにログを集約している場合、Security Lake に移⾏すべきか検討する上で整理してみた

まとめ 25 ü AWS Organizations 管理下でのマルチアカウント運⽤が求められる ü ソースとして利⽤できる AWS サービスログがまだ限定的である ü OCSF の共通スキーマ定義の使い勝⼿が思ったほど良くなさそうな印象である マルチアカウント・マルチリージョンのログ・イベントを⾃動的に集約できたり Detective から CloudTrail 管理イベントや VPC Flow Logs を直クエリできるので便利である。 ⼀⽅で、以下のような課題も存在する。 3rd Party 統合で利⽤できる製品次第ではあるが SIEM/XDR は多くのソースを直接取り込めるようになっているはず （Security Lake を挟むメリットがあまりない気がする） と⾔うことで、今後のアップデート（Bedrock 連携など）に期待したい

Appendix

# フィールド名 データ型 サンプル値 1 medadata struct {product={version=5, name=Amazon VPC, feature={name=Flowlogs}, vendor_name=AWS}, profiles=[cloud, security_control], version=1.0.0-rc.2} 2 cloud struct {account_uid=123456789012, region=ap-northeast-1, zone=apne1-az4, provider=AWS} 3 src_endpoint struct {port=0, svc_name=-, ip=172.31.42.149, intermediate_ips=null, interface_uid=eni-09b791735bb3e9ae0, vpc_uid=vpc-0da4aa09028b541e1, instance_uid=i-04fc2c8d2cca8ce3e, subnet_uid=subnet-0bc6aad367a36f46d} 4 dst_endpoint struct {port=0, svc_name=-, ip=172.217.26.228, intermediate_ips=null, interface_uid=null, vpc_uid=null, instance_uid=null, subnet_uid=null} 5 connection_info struct {protocol_num=1, tcp_flags=0, protocol_ver=IPv4, boundary_id=5, boundary=Internet/VPC Gateway, direction_id=2, direction=Outbound} 6 traffic struct {packets=240, bytes=20160} 7 time bigint 1707056824000 8 start_time bigint 1707056824000 9 end_time bigint 1707057063000 10 status_code string OK 11 severity_id int 1 12 severity string Informational 13 class_name string Network Activity 14 class_uid int 4001 15 category_name string Network Activity 16 category_uid int 4 17 activity_name string Traffic VPC Flow Logs のスキーマ定義（1/2） 27

# フィールド名 データ型 サンプル値 18 activity_id int 6 19 disposition string Allowed 20 disposition_id int 1 21 type_uid int 400106 22 type_name string Network Activity: Traffic 23 unmapped map {sublocation_id=-, sublocation_type=-} 24 region string (Partitioned) ap-northeast-1 25 accountid string (Partitioned) 123456789012 26 eventday string (Partitioned) 20240204 VPC Flow Logs のスキーマ定義（2/2） 28

# フィールド名 データ型 サンプル値 1 metadata struct {product={version=1.100000, name=Route 53, feature={name=Resolver Query Logs}, vendor_name=AWS}, profiles=[cloud, security_control], version=1.0.0-rc.2} 2 cloud struct {account_uid=123456789012, region=ap-northeast-1, provider=AWS} 3 src_endpoint struct {vpc_uid=vpc-0da4aa09028b541e1, ip=172.31.42.149, port=52467, instance_uid=i-04fc2c8d2cca8ce3e} 4 time bigint 1707056160000 5 query struct {hostname=time.aws.com., type=A, class=IN} 6 answers array [{type=A, rdata=15.152.63.145, class=IN}, {type=A, rdata=15.168.66.245, class=IN}, {type=A, rdata=13.208.78.139, class=IN}, {type=A, rdata=15.152.48.157, class=IN}, {type=A, rdata=15.152.214.99, class=IN}] 7 connection_info struct {protocol_name=UDP, direction=Unknown, direction_id=0} 8 dst_endpoint struct - 9 severity_id int 1 10 severity string Informational 11 class_name string DNS Activity 12 class_uid int 4003 13 category_name string Network Activity 14 category_uid int 4 15 disposition string Unknown 16 disposition_id int 0 17 rcode_id int 0 18 rcode string NoError Route53 Resolver ログのスキーマ定義（1/2） 29

# フィールド名 データ型 サンプル値 19 activity_id int 2 20 activity_name string Response 21 type_name string DNS Activity: Response 22 type_uid int 400302 23 unmapped map - 24 region string (Partitioned) ap-northeast-1 25 accountid string (Partitioned) 123456789012 26 eventday string (Partitioned) 20240204 Route53 Resolver ログのスキーマ定義（2/2） 30

# フィールド名 データ型 サンプル値 1 metadata struct {product={version=2018-10-08, feature={uid=security-control/Config.1, name=Security Hub}, uid=arn:aws:securityhub:ap-northeast-1::product/aws/securityhub, vendor_name=AWS, name=Security Hub}, profiles=[cloud], version=1.0.0-rc.2} 2 time bigint 1707066633390 3 confidence int - 4 cloud struct {account_uid=123456789012, region=ap-northeast-1, provider=AWS} 5 resources array [{type=AwsAccount, uid=AWS::::Account:123456789012, cloud_partition=aws, region=ap-northeast-1, labels=null, details=null, criticality=null}] 6 finding struct {created_time=1707066633390, uid=arn:aws:securityhub:ap-northeast-1:123456789012:security- control/Config.1/finding/0a33f265-e171-4523-91ea-111bd9c3f4a8, desc=This AWS control checks whether the Config service is enabled in the account for the local region and is recording all resources., title=AWS Config should be enabled, modified_time=1707066633390, first_seen_time=1707066633390, last_seen_time=1707066637257, related_events=null, types=[Software and Configuration Checks/Industry and Regulatory Standards], remediation={desc=For information on how to correct this issue, consult the AWS Security Hub controls documentation., kb_articles=[https://docs.aws.amazon.com/console/securityhub/Config.1/remediation]}, src_url=null} 7 compliance struct {status=FAILED, requirements=[CIS AWS Foundations Benchmark v1.2.0/2.5, CIS AWS Foundations Benchmark v1.4.0/3.5, NIST.800-53.r5 CM-3, NIST.800-53.r5 CM-6(1), NIST.800-53.r5 CM-8, NIST.800-53.r5 CM-8(2), PCI DSS v3.2.1/10.5.2, PCI DSS v3.2.1/11.5], status_detail=null} 8 malware array - 9 process struct {name=null, pid=null, file={path=null, type_id=0, name=''}, parent_process=null, created_time=null, terminated_time=null} 10 vulnerbilities array - 11 class_name string Security Finding 12 class_uid int 2001 Security Hub Findings のスキーマ定義（1/2） 31

# フィールド名 データ型 サンプル値 13 category_name string Findings 14 category_uid int 2 15 severity_id int 3 16 severity string Medium 17 activity_name string Generate 18 activity_id int 1 19 type_uid int 200101 20 type_name string Security Finding: Generate 21 state_id int 1 22 state string New 23 unmapped map {ProductFields.Resources:0/Id=arn:aws:iam::123456789012:root, ProcessedAt=2024-02-04T17:10:40.130Z, FindingProviderFields.Types[]=Software and Configuration Checks/Industry and Regulatory Standards, RecordState=ACTIVE, Severity.Normalized=40, Severity.Original=MEDIUM, ProductFields.aws/securityhub/ProductName=Security Hub, CompanyName=AWS, FindingProviderFields.Severity.Original=MEDIUM, FindingProviderFields.Severity.Normalized=40, WorkflowState=NEW, ProductFields.aws/securityhub/CompanyName=AWS, Compliance.AssociatedStandards[].StandardsId=ruleset/cis-aws-foundations-benchmark/v/1.2.0,standards/aws- foundational-security-best-practices/v/1.0.0,standards/cis-aws-foundations-benchmark/v/1.4.0,standards/nist- 800-53/v/5.0.0,standards/pci-dss/v/3.2.1, FindingProviderFields.Severity.Label=MEDIUM, Compliance.SecurityControlId=Config.1, ProductFields.aws/securityhub/FindingId=arn:aws:securityhub:ap- northeast-1::product/aws/securityhub/arn:aws:securityhub:ap-northeast-1:590184108226:security- control/Config.1/finding/0a33f265-e171-4523-91ea-111bd9c3f4a8} 24 region string (Partitioned) ap-northeast-1 25 accountid string (Partitioned) 123456789012 26 eventday string (Partitioned) 20240204 Security Hub Findings のスキーマ定義（2/2） 32

SIEM on Amaozn OpenSearch Service OCSF AuditActivity Summary Dashboard（1/2） 33

SIEM on Amaozn OpenSearch Service OCSF AuditActivity Summary Dashboard（2/2） 34

SIEM on Amaozn OpenSearch Service OCSF NetworkActivity Summary Dashboard 35

参考URL Amazon Security Lake ユーザーガイド https://docs.aws.amazon.com/ja_jp/security-lake/latest/userguide Amazon OpenSearch Ingestion 開発者ガイド https://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/ingestion.html Amazon Detecrtive ユーザーガイド（Amazon Security Lake との統合） https://docs.aws.amazon.com/ja_jp/detective/latest/userguide/securitylake-integration.html SIEM on Amazon OpenSearch Service（Amazon Security Lake との統合） https://github.com/aws-samples/siem-on-amazon-opensearch-service/blob/main/docs/securitylake_ja.md 組織内のセキュリティデータをAWS上で⼀元管理できる︕Amazon Security LakeがGA(⼀般利⽤開始)されました https://dev.classmethod.jp/articles/amazon-security-lake-ga/ Amazon Security Lake のサブスクライバー機能を使って他のアカウントから Athena で検索する https://dev.classmethod.jp/articles/amazon-security-lake-subscriber-query-access/ Amazon OpenSearch Service の取り込みパイプラインが Amazon Security Lake からのイベント取り込みをサポートしました https://dev.classmethod.jp/articles/opensearch-ingestion-security-lake/ Amazon DetectiveがSecurity Lakeとの統合をサポートしたので試してみた https://dev.classmethod.jp/articles/amazon-detective-supports-integration-with-security-lake-awsreinvent/ Open Cybersecurity Schema Framework https://github.com/ocsf/ocsf-schema 36