100分の1:セキュリティギャップを埋めるためのチームの設計方法

100分の1

大規模な組織で働いている場合でも、ITで働いているすべてのセキュリティ担当者の名前を記憶できる可能性があります。これは、最近の調査によると、開発者とセキュリティの比率が100:1であるためです(同じ調査では、devsとopsの比率は10:1であることが示されています)。以前の研究では、100:3から100:6の比率が報告されているため、ある程度の進歩はありますが、十分な速さではありません。

これは、EUのGDPRなどの今後のデータプライバシー保護規制に取り組み、過去数年にわたって定期的にニュースに載っていたデータ流出を阻止するこれらの組織の能力にとって前兆ではありません。今日、このギャップを埋めるだけの十分なスキルを持ったセキュリティ担当者はいません。安全な開発と運用の実践を成功させるには、技術的な深い理解だけでなく、重要なことに、開発チームや(多くの場合)上級管理職からの賛同を得るためのコミュニケーション、説得、バランスのスキルが必要です。

歴史的に見て、企業はセキュリティに十分な優先度を与えていないため、セキュリティの専門化が十分に魅力的ではない悪循環に陥っています。これらの企業は現在、セキュリティゲームを強化する必要性が高まっていますが、人材が不足しています。

それでは、このセキュリティギャップを埋めるためにどのようなオプションが必要ですか?

最初に、基本的なセキュリティチェック(サードパーティの脆弱性など)とコーディングのガイドラインを自動化し、配信パイプラインにセキュリティを統合することは、今日の製品開発チームにとって簡単であることを明確にしましょう。 DevSecOpsのツールセットは拡大し続けており、コミュニティとエンタープライズグレードの両方の要件が満たされています。

それで、ギャップはどこですか?これは、「ハッカーの考え方」であり、アプリケーションの新しい潜在的な攻撃ベクトル(「未知の未知数」)を絶えず検索しています。また、意味のあるリスク分析と脅威モデリング、およびアクションと優先度への変換という難しいタスクにもあります。これらには深いセキュリティの考え方と背景が必要です。既存の責任に加えて、認知的負荷を追加するように製品開発チームに依頼することはできません。

Matthew Skeltonと私が行った研究は、DevOpsの採用を進めたりブロックしたりする上で、異なるDevOpsトポロジーがどのように重要な役割を果たすかを調査、カタログ化、および説明しています。

2つの異なる(そしておそらく補完的な)チームトポロジが思い浮かびます:

A)完全に共有されたセキュリティ責任

B)実現チームとしてのセキュリティ

各アプローチの違い、長所と短所は何ですか?

完全に共有されたセキュリティ責任とは、各製品開発チームが少なくとも1人のセキュリティ重視のT字型チームメンバーを統合することを意味します。このアプローチは、組織が機能横断型の自律的な製品開発チームを目指している場合に適切です。セキュリティ担当者は、複雑なセキュリティ上の脅威を、チームが技術的な観点から理解して実装できる実用的なセキュリティストーリーと受け入れ基準に変換できる必要があります。

また、ビジネスオーナーが理解して優先順位を付けることができる方法で、組織のリスクと潜在的なコスト(コンプライアンス、収益、および評判)を伝えることができなければなりません。一方、必要に応じて、セキュリティ関連以外のタスクを実行する準備ができている必要があります。時間が経つにつれて、T字型のセキュリティ担当者がセキュリティのベストプラクティス、新しい方法、ツールを常に把握し、セキュリティ関連のワークショップを促進し、製品のセキュリティをリードするという点で専門知識を保持しながら、セキュリティ分析と実装の所有権をチームに広げる必要があります戦略。

目標は、セキュリティ担当者にすべてのセキュリティ作業を割り当てることではありません。そうでない場合は、マクロレベル(隔離されたセキュリティチーム)のサイロをミクロレベル(隔離されたチームメンバー)に移動するだけです。
各製品チーム(黄色の円で表示)-7〜9人のチームメンバー(少なくとも1人はT字型のセキュリティ担当者)-緑の円の中に表示されますが、他の人もセキュリティ作業に参加します

もちろん、組織内の複数の製品およびビジネス領域にわたるセキュリティを一元的に表示する重要な場所はまだあります。経験、アプローチ、結果を共有することが重要です。しかし、これは専用のチームではなく、練習コミュニティまたはギルド(Spotifyの用語では)意欲的な個人が定期的に集まるという形をとることができます(ただし、手段があればうまくいきます)。

長所

  • チームのセキュリティの所有権が上昇し、セキュリティインシデントの迅速な(重要な)解決につながり、おそらくより重要なこととして、将来の苦痛を繰り返さないように彼らから学ぶことができます。
  • チームには自然なサイズ制限(8〜9人)があるため、このチームトポロジでは、ITスタッフとセキュリティ(T字型)スタッフの比率を10:1に近づける必要があります。技術的背景のみの多様性は、問題と優先事項へのアプローチの点で利益をもたらします。
  • このトポロジへの移行は、セキュリティが当社製品の第一級市民になったという否定できないシグナルを組織内の全員に送信します。

短所

  • (寛大なパッケージが必要な場合があります)を見つけて採用し、9人のセキュリティ担当者(100人の開発者がいる組織)を増やすコストは、深刻な問題になります(この投稿の紹介に従って)。この移行にはかなりの時間がかかると予想されますが、その間にモデルを混在させる必要があります(一部の自律型製品チームと一部は依然として集中型チームに依存しています)。最初に行くチームを選択するための戦略を考えます。たとえば、組織内でよりリスクの高い製品に取り組んでいるチームに、経験豊富なセキュリティ担当者を割り当てることから始めます。
  • 優れた自律チームは、安定性に基づいており、お互いの長所と短所を知っています。チームの構成を変更すると、たとえ1人であっても、必然的に混乱が生じます。チームは、新しいセキュリティアングルを取り入れながら、成果が低下し生産性が低下していると感じるかもしれません。これが正常で受け入れられていることを全員が理解することが重要です。
  • セキュリティ上の懸念のための一元化された連絡先の欠如。特に、上級管理者は、分散型の構造には「セキュリティのホイールに誰もいない」と感じるかもしれません。コミュニケーションチャネルがあり、セキュリティ情報の要求を適切なチーム(または実践コミュニティ)に送信できる人がいることを確認してください。

ヒューリスティック

  • あなたの組織には、事業主を統合し、QAの責任を持ち、開発したアプリケーションの監視と実行を行う、機能横断型のチームが既にありますか?
  • 製品(またはサービス)は非常に異なるリスクプロファイルを表示しますか?
  • 製品(またはサービス)は異種の技術スタックとインフラストラクチャで実行されますか?

上記の質問の1つ以上に対する答えが肯定的である場合、このトポロジはセキュリティギャップに対処するのに適していることが判明する可能性があります。

実現チームとしてのセキュリティとは、専任のセキュリティチームが製品開発チームにサポートとガイダンス(安全な開発ガイドラインの作成など)を提供することを意味します。

重要なのは、中央集中型セキュリティチームが実際のセキュリティ分析と実装作業を実行せず、代わりに必要に応じてそれを促進およびガイドすることです。

製品チームがライフサイクルの各段階でセキュリティへの影響、アプローチ、およびプラクティスを検討できるように、プロジェクトまたはリリースの最初からこのチームが関与することも同様に重要です。

横方向のセキュリティチーム-縦に灰色で描かれています-3つの製品チームをサポートしています-オレンジで横に描かれています-セキュリティに対する責任を共有しています-明るい緑の円で描かれています

SpotifyやSportradarなど、多くの組織がこのアプローチを採用しています。基本的にこのチームの責任(実装ではなくガイダンスとサポート)を変更しているため、従来の「セキュリティチームサイロ」から大幅に少ない構造変更が必要です。しかし、それは、製品チームがシステムのセキュリティのより大きな所有権をとることが期待されていることを組織の残りが完全に理解することを難しくするかもしれません。

SportradarのCTOであるPablo Jensenは、製品チームと緊密に連携してセキュリティガイドラインとポリシーを推進し、フィードバックに耳を傾け、時間をかけて反復する、情報セキュリティチームの役割について最近話しました。彼らのプロジェクトライフサイクルゲートの1つは、セキュリティの影響とそれに応じて計画された作業を十分に検討したセキュリティチームによる承認を必要とする「開発を開始するための適合性」です。このチームはCEOに直接報告し、必要に応じて製品の発売を停止する権限を持っています。

製品のセキュリティ作業を行うのではなく、ガイダンスを提供する集中型セキュリティチームの役割(クレジット:SportradarのCTOパブロジェンセン— QCon London 2018プレゼンテーションのスライド)

長所

  • セキュリティ作業の大部分を行う従来の隔離されたセキュリティチームから有効化モデルに移行するためのより短い時間枠。
  • 多数の新規雇用を必要としないため、関連するすべての労力と潜在的なチームの混乱を回避できます。ここでの焦点は、有効化チーム全体が、技術的なスキルに加えて、必要なすべてのソフトスキルを持っていることを確認することです。

短所

  • このチームは効果的なコミュニケーションを習得する必要があり、それ自体は良いことです。これは時間をかけて磨く必要があるスキルであるため、最初はコミュニケーション戦略とキュレートコンテンツを定義するために外部または内部のヘルプに投資する必要があります。
  • このモデルに移行すると、セキュリティフォーカスの変更に関する弱いシグナルが送信されます。信号は増幅する必要があり、組織文化の一部として沈み込むまで長時間繰り返す必要があります。
  • 新しい責任、慣行、およびツールを導入することは、すでに能力のピークにある製品開発チームにとって困難な場合があります。一元化されたイネーブルメントチームは、ヘルプのリクエストに圧倒され、製品のセキュリティ実装を支援するようプレッシャーにさらされる可能性があります。これは、モデルの全体の目的に反します。
  • 時間が経つにつれて、製品チーム内のセキュリティの焦点は、セキュリティ担当者がチームのリリース/スプリント計画や毎日のスタンドアップに参加しなくても消えていく可能性があります。この影響を回避するには、何らかのガバナンスを導入する必要があります。

ヒューリスティック

  • 少数の製品開発チームがいますか(セキュリティチームとの緊密なコラボレーションを可能にしますか)?
  • 製品チームのメンバーは、セキュリティトピックや学習意欲に関心を示していますか(たとえば、技術会議やミートアップに参加していますか)。
  • 本番環境でのセキュリティ関連のインシデントの解決には、当然、セキュリティと開発の両方の人が関与しますか(それぞれの側が責任から遠ざかる非難ゲームとは対照的に)?

上記の質問の1つ以上に対する答えが肯定的である場合、このトポロジはセキュリティギャップに対処するのに適していることが判明する可能性があります。

結論

DevSecOpsはITのセキュリティのプロファイルを上げており、深刻なデータ侵害の定期的な流れにより、ほとんどの組織のセキュリティギャップが明らかになりました。この投稿では、そのギャップを埋めるためのいくつかの可能なアプローチ(完全に共有されたセキュリティ責任対有効化チームとしてのセキュリティ)、その長所と短所、およびコンテキストに基づくヒューリスティックを紹介しました。

チームの設計は静的ではないことを忘れないでください。組織、人、プロセスは時間とともに自然に進化します。今日の最適なものは、より高速で安全なソフトウェアに対する明日の障害になる可能性があります。セキュリティの認識と専門知識が製品チーム全体に広がるにつれて、組織は最初に従来のセキュリティサイロアプローチから「セキュリティを実現するチーム」モデルに最初に移行し、「フルに共有されるセキュリティ責任」構造に徐々に移行するでしょう。

組織やクライアントで見た他のチームトポロジやセキュリティ戦略は何ですか?以下にコメントするか、私にメールしてください:

マヌエルパイスドットネットの私