内部統制推進室の小倉です。
ただいま AWS re:Inforce 2025 に参加のため、アメリカのフィラデルフィアに来ています！
昨日の深夜に無事到着し、長いフライトの疲れを若干残しつつ、頭も気持ちも切り替えて早速本日からイベントに参加しております！

AWS re:Inforceとは

AWS が主催する、セキュリティに特化した世界最大級のカンファレンスです。
昨年と同じ Pennsylvania Convention Center を会場で、今年は6月16日〜18日の3日間の開催です。
会場内の場所を何となく覚えていたので迷ったりすることなく助かります。

まずはバッジを受け取り

朝準備をしていたところ、バッジの受け取りに長蛇の列がなっていると聞いたので、急いで会場へ。
無事にバッジを受け取ってから一度ホテルへ朝食を食べに戻り、いざセッション会場に向かいます！

1日目に参加したセッションの中から一つ紹介します。
私自身はエンジニアではないため、技術者の視点とは異なりますが、組織全体のセキュリティを考えるきっかけとして、セッションの内容をお届けできればと思います。

SEC204: Build and scale a security-first engineering culture

このセッションでは、エンジニアリングチームがセキュリティを自然に優先する文化を構築し、拡大するための実用的なアプローチが紹介されました。
組織内でセキュリティファーストなエンジニアリング文化を構築し、拡大することが主要なトピックでした。

AWSが実践する「Security-first engineering culture flywheel（以下フライウィール）」

セッションの中心的な考え方として、自律的に回転し続ける弾み車に例えた「フライウィール」というモデルが紹介されました。
これは、一度始めた取り組みが次第に勢いを増し、セキュリティ文化が組織に定着していく様子を表現しています。

フライウィールは4つのステップで構成されています。

①特定する (Identify)：リスクを見つける
②称賛する (Celebrate)：リスクを見つけた行動を褒める
③対処する (Address)：リスクを評価し、対応する
④システム的な変更 (Systemic Change)：再発を防止する仕組みを作る

このサイクルを回し続けることで、文化が形成され、組織全体のセキュリティレベルが向上していくということです。

この4つのステップを少し説明すると、

①特定する (Identify) – 発見のハードルを下げる
強い文化の第一歩は、リスクを自己発見（self-identify）すること。
そのために最も重要なのは、「セキュリティリスクの報告を、簡単で、予測可能で、少し退屈な（＝何の変哲もない）作業にすること」です。
何か「おかしいな」「不安だな」と感じたら、たとえそれがリスクではなかったとしても、躊躇なく報告できる仕組みが不可欠です。
AWSでは、ほぼ全ての社内Wikiページの上部に「インシデントを報告」というリンクがあり、誰でも簡単に報告できる仕組みが整っているそうです。

②称賛する (Celebrate) – 良い行動を定着させる
リスクが自己発見された際に、絶対に欠かせないのが「称賛」です。
AWSでは、週次のセキュリティ会議で自己発見された問題が報告されると、VP（ヴァイスプレジデント）自らが問題を発見した担当者に対して「素晴らしい！」「よくやった！」と称賛のメールを送る文化があります。

③対処する (Address) – 冷静かつ客観的に対応する
問題が見つかったら、次に対処のフェーズに入ります。ここで強調されていたのは、「医者（doctor）のように、極めて臨床的（clinical）であれ」 という心構えです。
つまり、発見された事象を大げさに表現せず、事実に基づいて客観的にリスクを記述するということです。

・リスクの明確化：前提条件と脅威、具体的なアクションを明確に記述します。
・影響の評価：顧客への影響、ビジネス上の評判リスクなどを評価します。
・優先順位付け：短期的な対策と長期的な対策を分け、何よりもまずリスクの軽減（Mitigation）を最優先します。

この標準化されたアプローチが、混乱を防ぎ迅速な対応を可能にします。

④システム的な変更 (Systemic Change) – 再発を防止する
特定の問題を修正して終わり、ではまた同じ問題が別の場所で再発する可能性があります。
フライウィールを完成させる最後のステップは、その問題から学び、「二度と同じ過ちを繰り返さないための仕組み」を構築することです。
AWS では、週次のセキュリティ会議が行われ、「このリスクは他のサービスにも影響するのではないか？」という問いが頻繁に投げかけられます。

文化を加速させる「経験」と「説明責任」

このフライウィールの回転をさらに加速させる要素として「経験(Experience)」と「説明責任(Accountability)」が挙げられました。

セッションでは「経験に勝る圧縮アルゴリズムはない（There is truly no compression algorithm for experience）」 という言葉がありました。
座学のトレーニングを何時間受けるよりも、一度でも実際のインシデント対応に関わった経験の方が、エンジニアを何倍も成長させるという意味です。

・経験を積む仕組み：「経験に勝る圧縮アルゴリズムはない」という言葉通り、座学より実際のインシデント対応に関わる方がエンジニアを成長させます。
AWSでは、各チームにセキュリティ推進役を置く「Guardians program」などで実践経験を積む機会を提供しています。
・説明責任の仕組み： 全てのセキュリティ課題には、アクションアイテム、担当者、完了予定日が設定され、リーダーがその完了までをしっかりと追跡します。

そしてセッションの最後には、この文化を築くための４つのメッセージで締めくくられました。


⒈セキュリティは全員の仕事である
⒉セキュリティを第一に考えた行動を称賛せよ
⒊セキュリティ問題の報告を当たり前の（簡単で退屈な）ものにせよ
⒋発見した問題を、仕組みを変えるきっかけとして活用せよ

まとめ

セキュリティをエンジニアや一部の専門家のものとせず、組織全体で「自分ごと」として捉えるこの視点は、すべてのビジネスパーソンにとって非常に重要だと改めて認識しました。

失敗を責めるのではなく称賛し、報告しやすい環境を作ること。
インシデントを、より良い仕組みに変えるための「財産」と捉えること。
そして、セキュリティ文化は一部の専門家ではなく、全員で築き上げるものだということ。
これらの学びは、セキュリティ意識の高い組織を築く上で、特定の誰かのものではなく、私たち一人ひとりが意識すべきことなのだと感じました。

今日はこの他に、AWSサービスを使ってセキュリティルールを作成し、問題を自動で検出・修正するハンズオンにも参加しました。
残念ながら、参加したかったAIコンプライアンスに関するセッションは満席で入れず…。AI関連は特に人気が高いようです。

明日はイベントのメインでもある Keynote も控えているので、しっかり休んで明日に備えます！