Slide 1

Slide 1 text

開発者が自律的に AWS Security Hub findings に 対応する仕組みと AWS re:Invent 2024 登壇体験談 Meguro SEC 2025/02/07

Slide 2

Slide 2 text

自己紹介  株式会社カミナシ  西川 彰(Security Engineering) ● 一般社団法人鹿児島県サイバーセキュリティ協議会 代表理事 ● 大和セキュリティ Hayabusa, Takajo 開発者 ○ HITCON 2024(台湾)、SecTor 2024(カナダ)登壇 ● CISSP

Slide 3

Slide 3 text

カミナシにおける AWS 環境 ● カミナシは複数のプロダクトを提供している ● それぞれのプロダクト毎に dev/stg/prod のアカウントが存在する ● それらのアカウントでは AWS Security Hub を有効化している サービスA サービスB Prod Stg Dev Prod Stg Dev Audit

Slide 4

Slide 4 text

カミナシにおけるセキュリティエンジニアの役割 ● それぞれのサービスのセキュリティへの対応の責任は開発者にある ● セキュリティエンジニアは開発チームのイネーブルメントを行う ● 開発チームが自分たちのサービスの堅牢化をサポートしたり、教育を行う

Slide 5

Slide 5 text

カミナシにおけるセキュリティエンジニアのミッション セキュリティ文化を構築するのが私たちのミッション! 具体的には、、、 ● 開発者が呼吸するようにセキュリティを意識するようになること ● セキュアな環境を構築しながらも敏捷性を保ち続けること ● 自浄作用があるということ(問題を放置し続けないということ)

Slide 6

Slide 6 text

Security Hub findings に開発者が自律的に対応できる仕組み(Liver) アカウント A アカウント B アカウント C Audit Security tooling On-call 担当者 AWS Security Hub Amazon EventBridge Amazon EventBridge AWS Lambda

Slide 7

Slide 7 text

Liver のコンセプト 1. アクショナブルであること   通知を受け取った人が何をすれば良いかを明確にする 2. 対応責任者を明確にする   その通知を”誰が”対応するかを明確にする 3. リスク管理 サービスによってセキュアにしなければいけない度合いは異なるのでカス タマイズできるようにしておく

Slide 8

Slide 8 text

アクショナブルであること 何をしたら良いかがわからない 通知に価値はない アクションを必要としない通知は可能な限り 送らない 対応が必要ない場合でも、何らかのアクション や確認は必要

Slide 9

Slide 9 text

対応責任者を明確化する カミナシではチームではなく ”個人”に対応責任を持たせる 開発チームは、AWS 環境で発 生したあらゆる問題に対処する 責任を負う 重要な問題やリスクが漏れない ようにする

Slide 10

Slide 10 text

リスクアセスメントマトリクス

Slide 11

Slide 11 text

リスクマネジメント サービスの重要性に基づいて 通知する最低重要度を設定 不要な通知を無くす Security Hub Automations ResourceId に下記が含まれて いれば対象外にしている ● ControlTower ● aws-controltower 環境によってコントロールを変える Security Hub configuration

Slide 12

Slide 12 text

運用設計 対応すると判断 対応 自動解決 対応しないと判断 理由をチケットに記 載 CTO が許容するか 否認するか判断 対応する/しない

Slide 13

Slide 13 text

運用を開始したところ... ちょっとしたインシデントが発生 Security Hub findings は、サービスやシステムのコンテキストを理解していない。サービスやシステム のコンテキストをよく理解しないまま対応すると、インシデントにつながる可能性がある Liver のようなシステムをできるだけ早く導入する Shift Left はやっぱり重要で、本番リリース前に可能な限り問題に対処したい

Slide 14

Slide 14 text

Ramp-up 期間を設けることに Ramp-up 期間の開始 Security Hub findings を確認する 無視したい検知項目が あればリソースに対し てタグをつける 運用開始

Slide 15

Slide 15 text

成果

Slide 16

Slide 16 text

ここまでが AWS re:Invent 2024 での登壇内容 登壇内容終わり

Slide 17

Slide 17 text

AWS Community Builder で募集されている CFP に応募したら通った ● Subject / Abstract の文字数制限が厳しいので弊社 CTO と洗練させた ● 最終的なタイトルは CFP のレビュワーの方から提案がきたので変更した ● CFP の構成が重要 ○ Issue → Solution → Result が重要(と思っている) ○ Issue は少なくともレビュワーが Issue として認識している必要がある なぜ登壇できたのか?

Slide 18

Slide 18 text

AWS re:Invent 前 ● 6月初旬 CFP 申し込み開始 ● 7月初旬 CFP 締切 ● 8月下旬 CFP 結果 & 専用の Slack チャ ンネルに Join ● 9月下旬 登壇日時決定 ● 10月中旬 登壇資料提出締切 ● 11月中旬 登壇内容をチェック(任意) 登壇までの流れ AWS re:Invent 期間中 ● 開催初日に到着は登壇の MUST 要件 ● 初日の朝 SWAG をもらいに行く(MUST) ● 初日の夕方登壇者顔合わせ会(任意) ● SRR(Speaker Ready Room)で最終登壇内容 修正(任意) ● 12月4日登壇

Slide 19

Slide 19 text

● いろんな人から声をかけてもらえる(英語) ● Customer Group Discussion に招待してもらえる(可能性がある) ● スピーカー SWAG がもらえる! 登壇者の特典

Slide 20

Slide 20 text

● とてもとても酷かった ○ それを踏まえて今後海外で登壇する方々に色々お伝えしたい!(切実) ● 何がいけなかった ○ 暗記で乗り越えようと思ったのがいけなかった ○ HITCON、SecTor ではスピーカーノートをほぼ頼った ● 初めての環境だった ○ バックステージから出るタイプは人生で初めてだった ○ 色々なものが目に飛び込んできて脳のリソースを全部持って行かれた ● ジョークは通じないと思った方が良い 登壇どうだったの?

Slide 21

Slide 21 text

大事なことは伝える・伝わること 格好よく登壇とかあまり意味は無い(個人の感想) ● AWS re:Invent は登壇者として求められるレベルが非常に高い ○ でも本質は伝えるということに変わりはない ● 日本人のアウトプットが海外に劣っているかというとそんなことはない ● 「どう伝えるか」よりも「何を伝えるか」で勝負する みなさんにお伝えしたいこと

Slide 22

Slide 22 text

ご清聴ありがとうございました