[レポート] Scaling security with Sportsbet's Security Guardians program #APS204 #AWSreInforce

こんにちは、コカコーラ大好きカジです。
今回は「APS204: Scaling security with Sportsbet's Security Guardians program」のレポートをお送りします。

これから、Security Guardians プログラムみたいな取り組みをしたい方には非常に参考になるセッションでした。
実際に遭遇した困難などについても語られており、非常に良かったので紹介します。

セッション概要

AWS re:Invent 2024のこのセッションでは、オーストラリア最大のベッティングプラットフォームSportsbetが実装したセキュリティチャンピオンプログラムについて解説されました。AWSとSportsbetの担当者が、組織規模に関わらず適用できるセキュリティスケーリング手法を紹介していました。

セッションの冒頭では、多くの組織で共通する課題が提示されました。開発チームが本番リリース直前になってセキュリティレビューを依頼し、脅威モデリングもセキュリティ標準の遵守もない状態で承認を求めるという状況です。この問題を解決するため、AWSとSportsbetはそれぞれ独自のSecurity Guardians プログラムを開発しました。

セッション内容

AWSのSecurity Guardians プログラム

AWSでは、ソフトウェアエンジニアにセキュリティの知識と経験を身につけさせるGuardiansプログラムを立ち上げており、数年前のreinforceから紹介されています。各Two-pizza team（8名程度のチーム）に少なくとも1名のセキュリティに精通したエンジニアを配置し、開発ライフサイクル全体をサポートする体制を整えています。

現在、AWSには約6,000名のGuardiansがおり、セキュリティレビューにかかる時間が約20日短縮され、セキュリティ上の問題の数も減少しているそうです。

Sportsbetの課題と背景

Sportsbetは市場シェア42%を持つオーストラリア最大のベッティングプラットフォームです。年間約40億の価格更新、2,400万のアクティブマーケット、250万人のアクティブ顧客をサポート

特に「Melbourne Cup Day」と呼ばれる最大の競馬イベント日には、通常の約4,000ベット/分から65,000ベット/分へと取引量が急増し、1日で1,200万件のベット、160万件の入金、1億ドル以上の支払いを処理します。
これはAmazonのBlack Friday級のトランザクションボリュームのようです。

このような環境では、セキュリティの問題が発生すると、単に新機能のリリースが遅れるだけでなく、リアルタイム金融システムに影響を与える可能性がありそうです。

セキュリティチャンピオンプログラムの構築

Sportsbetは、AWSのプログラムを参考に独自のSecurity Champions Programを構築し、目標は開発ライフサイクルの早い段階で「何を構築しているのか？」「何が問題になる可能性があるのか？」「それに対して何をしているのか？」という3つの質問を、より多くのチームが自問するようにすること

組織内に既に存在していた「セキュリティの友人（friends of security）」と呼ばれる人々に注目しました。これらは、セキュリティの問題を早期に提起し、チームの他のメンバーに適切なアプローチを指導する人々でした。

Sportsbetは、日本のデザイン哲学「侘び寂び（Wabi Sabi）」の原則を採用し、完全に洗練されたプログラムを目指すのではなく、まずは動き出し、聞き、改善していくアプローチを取りました。

個人的な感じたこと

「Wabi Sabi」の採用は、MVPの概念に近く、継続的改善を前提とした実装アプローチとして効果的と思いました。完璧主義に陥りがちですが、重要な考え方と思いました。

パイロットプログラムの実施

Sportsbetは、パイロットを成功させるために6つのステップを紹介していました。

1. 計画の策定: Sportsbetに適したものを正式化
2. 採用: 非公式の協力者を信頼できるパートナーに変換
3. リーダーとの調整: リーダーの支援を確保
4. 立ち上げ: チャンピオンを集めて開始
5. 教育キャンペーン: 基礎知識の確立
6. 振り返り、学習、改善: 継続的改善

個人的な感じたこと

特に重要と感じたのは「リーダーとの調整」です。トップダウンで戦略が決まっても、直属のマネージャーがサポートしなければ現場では機能せず、コミットメントを文書化することで、チャンピオンが安心してプログラムに参加できる環境と思いました。

チャンピオンの選定と教育

チャンピオン候補の条件は「セキュリティ知識があり、チーム内で影響力を持つシニアエンジニア」でした。コミュニケーション用に3つのSlackチャンネル（全体用、ファシリテーター用、チャンピオン専用）を設置し、8週間の基礎教育から始めて12ヶ月でメンターレベルへと成長させる計画を立てました。

教育の中心は以下の3つ

1. 脅威モデリング: STRIDEフレームワークを使用
2. セキュアなSDLC: アプリケーションセキュリティの脆弱性と対策
3. セキュアなパターン: 再利用可能なセキュリティパターンの作成

成果と課題

パイロットプログラムの初期の成果として、以下が挙げられました

• チャンピオンの高い関与
• チャンピオン間の文化的変化（アイデアやパターンの共有）
• 自発的な脅威モデルの作成
• イノベーションの創出（例：脅威モデリング用カスタムプラグインの開発）

一方で、以下のような課題も明らかに

1. 明確な期待の設定: チャンピオンの離脱防止
2. チャンピオンの保護: 誤った役割認識の防止
3. カリキュラムの簡素化: 重要事項への集中
4. 管理層の支持獲得: 価値の明確化
5. 適切なタイミング: ピーク時の立ち上げ回避
6. グローバル対応: タイムゾーン問題の解決

測定と評価

Sportsbetは、プログラムの成功を測定するために、定量的・定性的指標を設定しました：

定量的指標:

• セキュリティレビュー時間
• 脅威モデル数
• セキュアパターンの作成・更新
• 特定されたリスク数
• 教育セッション数
• 定着率

定性的指標:

• エンゲージメントの質
• セキュリティ質問の頻度
• コラボレーションの改善
• チーム間関係の改善

重要な成果として、チャンピオンが脅威モデリングを通じてサードパーティツールによるフロントエンドデータスクレイピングを発見し、本番環境への予期しないデータ漏洩を防いだ事例があり、すごいと感じました。
Sportsbetでは、定性的指標を50%の重要度と位置づけており、プログラムが単なる数値改善だけでなく、組織文化の変革を目指していることを示していました。

現在の状況と今後

現在、Sportsbetのプログラムは10名から約42名のチャンピオンに拡大し、以下に焦点を当てている

• 適切な人材の意図的な採用
• より多くのチームへの展開
• 専門性の深化
• セキュリティチームとの連携最適化
• 測定手法の改善

QAで、このプログラムが予算ゼロ（「ドーナツ予算」）で開始されたと話されていました。
価値を証明してから投資を求めるアプローチは、経営陣への説得力を高め、プログラムの継続性を確保する上で効果的のように感じました。

まとめ

Sportsbetの事例から学べる主要なポイントは以下の3つと思います。

1. 小さく始め、進化させる: 完璧を目指さず、少数のチャンピオンと限定的な範囲から始め、フィードバックを基に改善する

2. 明確な役割と責任: チャンピオンの役割を明確に定義し、組織全体に伝え、本来すべき点以外の依頼が行かないようにすること

3. コミュニティと文化の構築: チャンピオン同士が学び合い、協力できる環境を作り、セキュリティを「誰かの仕事」から「全員の責任」へと変える

このセッションの最も重要な教訓は、セキュリティの責任がどこにあるかを明確にすることで、各チームが自分たちのアプリケーションのセキュリティに責任を持つ文化があってこそ、セキュリティチャンピオンプログラムは真価を発揮すると感じました。

AWSとSportsbetという規模の異なる2社が同様のアプローチで成功しているので、このモデルが多くの組織で応用可能と感じました。
セキュリティを開発プロセスの最後に「追加する」ものではなく、最初から組み込むものとして考えることで、より効率的で安全なソフトウェア開発が可能になると感じました。