あしざわです。
米国フィラデルフィアで開催されている AWS re:Inforce 2024 に参加していました。
本記事は AWS re:Inforce 2024 のLightning Talk 「How to fail at building a security champions program」のレポートです。
セッション動画
セッション概要
So, you’ve heard of the AWS Security Guardians program, you know the basics, and now you’re interested in building a security champions program of your own. Join this talk to dive deeper and learn how a champions program can be done wrong and how to approach it if you’re looking for long-term success. Go beyond the basics and discuss common pitfalls and practical applications. Walk away with insight into the common mistakes you should be sure to avoid and actionable steps you can take to get your program started.
用語の理解
セッションの前提として、私なりの理解でセッションで出てくるチーム・役割についてまとめました。
- セキュリティチーム、アプリケーションセキュリティチーム、AppSec
- セキュリティを専門でやっているチーム。開発プロセスの中で行うセキュリティレビューを担当。
- ビルダー、ビルダーチーム
- サービスの開発を行うチーム。
- セキュリティチャンピオン、ガーディアン
- ビルダーの中でも特にセキュリティに興味関心を持ち、主体的にセキュリティを実施するメンバーのこと。ビルダーチームのセキュリティリーダー。
内容
今回のAWS CISSOのChris BetzによるKeynoteでは、テーマの中心が『Culture of Security』でした。
これはAWSが長い時間をかけてセキュリティのカルチャーを構築して、セキュリティを最優先事項にしているということを表す言葉です。
AWSでは、サービスチームを支援するためのチームとして、「Security Guardian Program(セキュリティガーディアンプログラム)」を運用しています。
ガーディアンとは、開発チームの中にいるセキュリティリーダーのことを指します。深く広いセキュリティの知見を持つガーディアンは開発チームの中でセキュリティに関するオーナーシップを発揮し、問題解決の平均時間を削減しています。
まずは、Security Guardian Program(セキュリティガーディアンプログラム)にフォーカスした話から始まります。
セキュリティガーディアンプログラムは、セキュリティオーナーシップの分散メカニズムです。
- セキュリティ組織(AppSecなど)だけが製造される製品のセキュリティを決定させることを避けたい
- ビルダーチームが構築する製品のセキュリティリスクをセキュリティ組織に負わせたくない
つまり、セキュリティに関する意思決定・リスクの両方をビルダーチームに追わせ、セキュリティチームがビジネス的に正しい意思決定を行うためのサポートを行う仕組みです。
セキュリティガーディアンプログラムは「セキュリティチャンピオンプログラム」とも呼ばれていますが、これはAWS社内でセキュリティチャンピオンプログラムのことを「ガーディアン」と呼んでいることからだそうです（なぜかそう呼ばれているかは不明？）
分散型セキュリティ・オーナーシップで達成させたいのは、パイプラインに早期にセキュリティを組み込み、初日から製品にセキュリティを組み込むことです。
ビジネス、ビルダー、セキュリティ部門の間で円滑なコミュニケーションをとり、セキュリティ意思決定を迅速に行うことが理想。セキュリティについて早く着手し、もっと時間をかけて意思決定を行いたいのです。
ガーディアンは、他のビルダーとは違いセキュリティマインドがあります。自ら事前に脅威モデリングを担当、実施を主導し、セキュリティエンジニアがレビューする前に、適切なレベルにあることを確認しています。このような運用体制が達成できていると、ガーディアンがセキュリティ意思決定を行うためセキュリティエンジニアはほとんどサポート役になります。
そんなセキュリティガーディアンプログラムの失敗方法（アンチパターン）がLTの主題です。
こちらがアンチパターンの一覧です。
- ビルダーチームやセキュリティチームに「正しいことをするように」頼む (you ask your builders and your security teams to do the right thing.)
- セキュリティ問題から逆算する(you work backwards from the security problem)
- 「速く」進めすぎない(You go too fast)
- 従業員数を増やす (You Increase head count)
1. ビルダーチームやセキュリティチームに「正しいことをする」ようにいう (you ask your builders and your security teams to do the right thing.)
皆セキュリティに関心があり、正しいことがしたい。しかし、締め切りが間近だったりするとセキュリティのことを考えず、抵抗が少ない道を選んでしまっているかもしれないから。
2. セキュリティ問題から逆算する(you work backwards from the security problem)
セキュリティチャンピオンの育成を成功させるには、ビジネスリーダーによるトップダウンアプローチが重要で、ビジネスから逆算すべきだということ。
3. 「速く」進めすぎない(You go too fast)
ビジネスリーダーを納得させるためには、全社的に始めるとか全チームへの導入を考え始めてはいけない。まずは試験的に導入するところから、小さく始めるべき。
- 進め方の例
- ミニガーディアンプログラムをすでにやっているような、簡単なチームから始める。
- 次にプログラムの恩恵が最も受けられる、動きが遅くセキュリティ判断を迅速ではないリソースが少ないチームを選ぶ。
- 最後にハイリスクな、セキュリティリスクを多く抱えているチームを選ぶ。
4. 従業員数を増やす (You Increase head count)
既存のビルダーをガーディアンに変えるのではなく、外部から雇おうとすると失敗するという話。
既存のビルダーが適している理由はすでにシステムを熟知していて、どのようにシステムが構築されたかを知っているから。そういった背景から外部からセキュリティチームを雇っても効果が薄れてしまうのでは。ガーディアンの役割の1つにビルダーとセキュリティチームとの橋渡しもあるため。
おわりに
以上、「How to fail at building a security champions program」のレポートでした。
Keynoteでも触れられていたセキュリティガーディアンプログラムについて、アンチパターンという角度から理解を深められるセッションでした。
ただ、あくまでこのセッションの主題はプログラムのアンチパターンについての紹介です。セキュリティチャンピオン、セキュリティガーディアンプログラムそのものについてもっと知りたい方は
- ビルダーのビルダーによるビルダーのためのセキュリティ - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
- [re:Inforce] 組織によるセキュリティレベルの向上事例 | APS201 How AWS and MongoDB raise the security bar with distributed ownership セッションレポート #AWSreInforce | DevelopersIO
AWS EventsのYoutubeチャンネルでは、re:Inforceやre:Inventで行われた過去のセッションのアーカイブがたくさん見られます。気になる方はご活用ください。
あしざわでした。
0
