セキュリティエンジニアリングチームの管理と組織的リスク

# セキュリティエンジニアリングチームの管理と組織的リスク ## 定義セキュアで信頼できるコードを書くには、適切な文化・適切なスキルの組み合わせ・適切なインセンティブを持つチームを構築する必要がある。『Security Engineering』第3版第27章は、この課題を組織的なリスク管理の失敗(§27.5.8)とチーム構築そのもの(§27.6)の2側面から論じる。組織的なリスク管理の失敗については、**Bezos' law**(2枚のピザで賄えない人数のチームは動かせない、目安8人)が前提として置かれる。プロジェクトが大規模化するとチーム間の調整が必要になり、コミュニケーションの複雑性は、指揮系統が明確な場合はlog N、全員が全員と相談する場合はN²、任意の部分集合が委員会を作れる場合は2ᴺに向かって増大する。Bill Curtis・Herb Krasner・Neil Iscoeの大規模ソフトウェアプロジェクト disaster 研究は、要件理解の失敗——アプリケーションドメイン知識の希薄な分布が変動・矛盾する要件を招き、それがコミュニケーションの崩壊につながる——を最大の原因と結論づけており、ロンドン救急指令システムの崩壊がその典型例として挙げられる。対照的にY2K問題では要件が完全に判明していた(「今のまま2000年以降も動き続けてほしい」)ため、多くの大規模プロジェクトが期限通り・予算内に収まらないという通念にもかかわらず大規模障害は起きなかった。組織はまた、不確実性への対処が苦手で、チェックリスト的な発想(認証取得済みプロセスが批判的思考を駆逐する)に流れがちであり、良いCISOの平均在任期間は約2年と短い。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 27 Secure Systems Development]] ch.27 §27.5.8) チーム構築については、Fred Brooksが『人月の神話』で描いた「主任プログラマチーム(chief programmer team)」——生産性の高いプログラマを管理職に「昇進」させて失うのではなく、ツールスミス・テスタ・言語弁護士に支えられた開発リードのポストを作る発想——から、Microsoft・Google・Facebook・Netflixのような「最初から超生産的なエンジニアだけを採用する」現代的アプローチまでの系譜が示される。多様性(diversity)については、1960年代末まで女性がコンピューティングの多数派だった歴史(Grace Hopper、Katharine Johnsonら)を踏まえ、真の変化は最初の1人の女性エンジニアの採用ではなくチーム文化を変えるのに十分な人数(目安3人以上)を採用したときに生じるとされる。スキルの育成(§27.6.3)・創発特性としてのセキュリティ(全員が自分のコードに責任を持つか、専任のセキュリティ専門家に頼るか、答えは「両方」)・ワークフローの進化(静的解析ツール導入のタイミング、API進化の管理)が続く各節のテーマである。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 27 Secure Systems Development]] ch.27 §27.6.1-§27.6.5) ## 横断的知見 - 現時点では本章(Security Engineering 3e 第27章)が唯一のソースであり、横断的な突き合わせはまだ行えていない。ただし[[Fred Brooks]] entity(既存)は『人月の神話』の「主任外科医モデル」「ブルックスの法則」「偶有的複雑性/本質的複雑性」をAIエージェント時代の議論・SRE文献・ネットワークシステム論の3ソースで既に扱っており、本章が挙げる「主任プログラマチーム」は既存entityが記録する「主任外科医モデル」とほぼ同一の発想(著者名だけがHarlan Millsに帰属される点が異なる)である。既存entityにこの用語の異同を追記する必要がある。 - **『Building Secure and Reliable Systems』第19章のChromeセキュリティチームは、本章が抽象論として提示する「適切な文化・スキル・インセンティブを持つチーム」を具体的な組織進化の記録として裏づける**: 本章(Security Engineering 3e 第27章)はBezos' lawやCurtis・Krasner・Iscoeの研究を通じて「大規模化に伴う調整の失敗」を一般論として述べるが、Chrome第19章はv0.1(専任チームなし)→v1.0(専任チーム発足)→v2.0(VRP発足とハイブリッドエンジニアリングチーム化)→v3.0(コア原則・ミッション・5つの重点領域の確立)という単一組織の10年規模の進化を時系列で記録する一次資料である。とくに第19章が示す「セキュリティチームは孤立したコンサルタントではなく自らコードを書くエンジニアリングチームであるべき」という立場は、本章§27.6.4の「創発特性としてのセキュリティ(全員が自分のコードに責任を持つか専任専門家に頼るか、答えは両方)」という問いに対する、Google社内での実践的な解答例と読める。また第19章の「重点領域ごとに責任者を置きつつ領域横断のswarmingでサイロ化を防ぐ」という組織設計は、本章のBezos' law(調整コストの増大)への対処の具体例だが、本章自身はこの種の対処法まで踏み込んでいない。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 27 Secure Systems Development]] ch.27 §27.5.8, §27.6.4; [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 19 Case Study - Chrome Security Team]] ch.19 §Background and Team Evolution, §Security Is a Team Responsibility) - **Chrome第19章は「良い人材の獲得」を採用チャネルの多様化として具体化し、本章の多様性の議論を補う**: 本章は多様性の効果を1960年代の女性コンピュータ技術者の歴史から論じるにとどまるが、第19章はChromeチームが個人的ネットワークの育成、インターン採用、カンファレンス登壇者への直接アプローチ、さらには「セキュリティ専門家ではないがセキュリティに関心を持つ人材」(SRE出身のエンジニアの例)の意図的な採用という、より具体的で今日的な採用戦術を示す。両者は「多様な背景の人材が成功の鍵である」という結論では一致するが、根拠として持ち出す時代と手段が異なり、本章の主張がChromeの実践によって別の角度から補強される。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 27 Secure Systems Development]] ch.27 §27.6.2; [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 19 Case Study - Chrome Security Team]] ch.19 §Background and Team Evolution) - **BSRS第20章は、本章が問い残した「Chrome第19章のような重点領域責任者+領域横断swarmingという組織設計は一般化できるか」に対する一般原則を提供する**: 第19章はChromeという単一製品専属チームの内部設計を記録するにとどまるが、第20章は本書全体の立場として、専門家チームの配置は「完全な組み込み」から「完全な中央集権」までの連続体上にあり唯一の正解はないとしたうえで、Google全体では独立した報告系統を持つ中央セキュリティ組織と、各プロダクトチームに配置する「セキュリティチャンピオン」(中央チームの推進役だが実装権限は持たない)のハイブリッドを採用していると述べる。AndroidやChromeのような大規模製品専属チームは、このハイブリッドの中でさらに製品固有の分散型チームとして扱われる例外だと位置づけられており、Chrome第19章の組織設計は「一般則」ではなく「大規模化した製品に許される追加の選択肢」として本章の枠組みに位置づけ直せる。これにより、本章末尾の未解決の問い(Bezos' lawへの対処法の一般化)の一部に回答が与えられる。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 20 Understanding Roles and Responsibilities]] ch.20 §Integrating Security into the Organization, §Example - Embedding Security at Google; [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 19 Case Study - Chrome Security Team]] ch.19 §Background and Team Evolution) - **第20章の「専門家の4つの固有機能」は、本章がSecurity Engineering 3e第27章から集約した「創発特性としてのセキュリティ(答えは両方)」という結論を、より具体的な役割の切り分けへ分解する**: 本章はこの問い(全員が自分のコードに責任を持つか専任専門家に頼るか)への答えを「両方」とする以上には踏み込まなかったが、第20章はセキュリティ専門家に固有の役割を、(1) 設計レビュー・監査・テストによるコンサルテーション、(2) 暗号など専門知識を要する技術の直接実装、(3) 集中インフラ・組織横断の自動化の構築、(4) ベストプラクティス・ポリシー・教育の整備、の4つに限定し、それ以外を全員の責任とする明確な線引きを示す。これは「両方」という答えの中身を、専門家がどこまで踏み込みどこから開発チームに委ねるべきかという実務的な境界線として具体化するものであり、詳細は [[セキュリティの責任分担]] を参照。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 20 Understanding Roles and Responsibilities]] ch.20 §The Roles of Specialists; [[@2020__Wiley__Security Engineering 3e - Chapter 27 Secure Systems Development]] ch.27 §27.6.4) - **『Building Secure and Reliable Systems』第21章は、本章の定義文が挙げる「適切なインセンティブを持つチーム」という要件に、キャリア評価制度という具体的な機構を与える**: 本章冒頭の定義は「適切な文化・適切なスキルの組み合わせ・適切なインセンティブを持つチームを構築する必要がある」と述べるが、第27章自身はスキル(§27.6.3)とチーム構築(§27.6.1-§27.6.5)を詳述する一方、インセンティブの内実には深入りしない。第21章「Align Project Goals and Participant Incentives」は、SLOや脅威モデリングという観測可能な指標と、キャリア評価基準への明示的な組み込みの両輪を揃えるべきだと述べ、Googleのエントリーレベルのソフトウェアエンジニア職位定義が監視の追加やセキュリティテストの記述といったコア以外のスキル習熟を明記する例を挙げる。これは、セキュリティ・信頼性への貢献が実際の昇進・報酬に反映されなければ「不健全な文化」が生まれるという、本章が明示的に論じていなかったインセンティブ設計の具体像を補う。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 27 Secure Systems Development]] ch.27 冒頭, [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 21 Building a Culture of Security and Reliability]] ch.21 §Align Project Goals and Participant Incentives) ## 未解決の問い - Bezos' law(2枚のピザ)とCurtis・Krasner・Iscoeの「要件理解の失敗」説は、[[組織設計のスターモデル]]や[[組織の信頼性マインドセット]]といった既存conceptの枠組みとどう接続するか。突き合わせは未着手。 - 「多様なチームほど効果的」という主張の根拠(本章は定性的な観察にとどまる)を、他ソース(DORA調査等、[[DevOps]]concept参照)の定量データと突き合わせられるか。 - 良いCISOの平均在任期間が2年という統計は、[[セキュリティ経済学]]conceptが扱うセキュリティ人材市場の議論と、第20章が示すCISOの報告先の多様性(CEO/CFO/CIO/COO/法務/VP Engineering/CSO)はどう関係するか。報告先の不安定さが在任期間の短さの一因ではないかは未検証。 - チェックリスト的発想が批判的思考を駆逐するという指摘(本章は次章のISO 27001批判を予告する)は、次章(第28章 Assurance and Sustainability)ingest後にどう展開されるか要確認。 - ~~Chrome第19章が示す「重点領域責任者+領域横断swarming」という組織設計は、本章のBezos' law(調整コストの増大)への対処法として一般化できるか~~ → 第20章が示す「中央セキュリティ組織+セキュリティチャンピオン」のハイブリッドという一般原則と、大規模製品専属チーム(Android/Chrome)という例外的な選択肢の関係として、一部回答が得られた(既出の横断的知見)。ただし、この一般原則がセキュリティ以外の領域(たとえば信頼性・SRE組織)にも同様に適用できるかは、[[SREエンゲージメントモデル]]conceptとの突き合わせが必要で未着手。 ## 関連 - 概念: [[組織設計のスターモデル]] / [[組織の信頼性マインドセット]] / [[技術的負債]](§27.5.2で「DevOpsの哲学の一つは負債フリーで運用すること」と言及) / [[セキュリティの責任分担]](専門家の4機能への分解) / [[セキュリティと信頼性の文化]](インセンティブ整合を含む文化的枠組みの上位概念) / [[セキュリティの持続可能性]](チェックリスト的発想への逃避と持続可能性の欠如の関係) - source: [[@2020__Wiley__Security Engineering 3e - Chapter 27 Secure Systems Development]] — 組織的リスク管理の失敗とチーム構築の両面を扱う一次資料 / [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 19 Case Study - Chrome Security Team]] — Chromeセキュリティチームの10年規模の組織進化を記録する事例 / [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 20 Understanding Roles and Responsibilities]] — 専門家配置の一般原則(中央集権・組み込み・ハイブリッド)と専門家の4機能 / [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 21 Building a Culture of Security and Reliability]] — 「適切なインセンティブ」の具体的な機構(キャリア評価基準への組み込み) - 実体: [[Fred Brooks]](主任プログラマチーム、「銀の弾丸はない」) / [[Parisa Tabriz]](Chromeセキュリティチームを率いた著者) ## 出典 - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 27, §27.5.8, §27.6. - Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 19 (Written by Parisa Tabriz). - Heather Adkins, Cyrus Vesuna, Hunter King, Felix Gröbert, and David Challoner, in Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 20. - Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 21, §Align Project Goals and Participant Incentives.