Zenn
😸

OWASP SAMMによるアプリケーションセキュリティ戦略

に公開
Security
アプリケーションセキュリティ
idea

はじめに

現代のソフトウェア開発において、アプリケーションセキュリティはますます重要な要素となっています。しかし、多くの組織ではいまだに明確なアプリケーションセキュリティ戦略やフレームワークを持たずに対策が進められているのが実情です。

特に見られるのは、次のような状態です

  • DevSecOpsの名のもとに、話題になっているツールをとりあえず導入している
  • 「セキュリティ強化」という曖昧な目的のもと、担当者任せで施策が断片的
  • 何が十分で何が不足しているのか分からないまま、とにかく何かやっている
  • 成果や成熟度が測れず、経営層への説明も困難
  • 開発チームとインフラチームとセキュリティチームの方向性があっておらず、バラバラに動いている

こうした状況では、コストや労力に見合った効果を得ることができず、かえってリスクが放置されることになりかねません。このような状況の時、汎用的で、効果が高く、説明可能なセキュリティフレームワークを使うことが望ましいと考えています。

今回はアプリケーションセキュリティの成熟度モデルであるOWASP SAMMの概要について翻訳・説明していきます。その後に私が考えるOWASP SAMMを使うメリットや注意点を説明しいきます。

OWASP SAMMの概要

OWASP SAMM (Software Assurance Maturity Model) とは、組織がソフトウェアセキュリティ体制を効果的かつ測定可能な方法で分析・改善するためのモデルです。これは、すべての組織に対して、安全なソフトウェアを設計、開発、展開する方法について認識を高め、教育することを目的とした自己評価モデルです。

SAMM モデルは以下のような特徴を持っています

  • MEASURABLE (測定可能): セキュリティプラクティス全体で定義された成熟度レベルがあります。
  • ACTIONABLE (実行可能): 成熟度レベルを向上させるための明確な道筋が示されています。
  • VERSATILE (汎用的): 技術、プロセス、組織に依存しないモデルです。
  • prescriptive model (規範的なモデル): 使い方がシンプルで、完全に定義されており、測定可能なオープンフレームワークです。

SAMM は、非セキュリティ担当者でも容易に理解できるように具体を提供します。組織が現在のソフトウェアセキュリティプラクティスを分析し、段階的な改善を示し、セキュリティ関連活動を定義・測定するのに役立ちます。このモデルは、小規模、中規模、大規模組織が、あらゆる開発スタイルに合わせてカスタマイズおよび採用できるよう、柔軟性を考慮して定義されました。SAMM は、組織がソフトウェア保証の道のりにおいてどこに位置しているかを知り、次の成熟度レベルに進むために推奨されることを理解するための手段を提供します。

SAMM は、5つのビジネス機能にグループ化された15のセキュリティプラクティスを中心に構成されています。各セキュリティプラクティスには、3つの成熟度レベルに構造化された一連のアクティビティが含まれています。低い成熟度レベルのアクティビティは、通常、高い成熟度レベルのアクティビティよりも実行が容易で、形式化の必要性が低くなっています。各セキュリティには、論理的な流れにグループ化され、2つのストリームに分割されたアクティビティがあります。ストリームはプラクティスの異なる側面をカバーし、独自の目的を持ち、異なる成熟度レベル全体でプラクティス内のアクティビティを連携させています。

SAMM モデルの構造は、以下のことをサポートします

  • 組織の現在のソフトウェアセキュリティ体制の評価。
  • 組織の目標の定義。
  • 目標達成のための実装ロードマップの定義。
  • 特定のアクティビティを実装する方法に関する規範的なアドバイス。

SAMMモデルの全体像

以下がSAMMモデルの全体像です。

この図だと少し分かりづらいため、わかりやすく書き直した図がこちらです。

OWASP SAMMのメリット

アプリケーションセキュリティにおいて、OWASP SAMMのようなセキュリティフレームワークを使うメリットはなんでしょうか？私が考えるメリットはこの4つです。

  1. 方針と優先順位が明確になる
    • 何を・なぜ・どの順でやるべきかが明確になり、リソースを効果的に配分できる
  2. 開発、インフラ、セキュリティで共通言語を持てる
    • 開発・インフラ・セキュリティの間で目標や対策レベルを共有しやすくなる
  3. 成熟度や成果を可視化できる
    • セキュリティ対策の進捗やギャップを定量的に把握し、経営層への説明にも使える
  4. 継続的な改善ができる
    • PDCAを回せる構造になっており、運用しながら改善サイクルを確立できる

OWASP SAMMを現場で活用する際の注意点

しかし、フレームワークを使うには気をつけないといけないことがあります。
私が考える注意点は次の5つです。

  1. 最初から完璧を目指さない
    • SAMMは全体を一気に適用するものではなく、段階的に成熟させるモデルです。最初は1〜2領域から始めて、少しずつ拡張するほうがスムーズに運用していけると思います。
  2. ビジネスとつなげて語る
    • セキュリティ活動の目的や価値を、経営や事業部門の言葉に翻訳しないと、支援や予算を得られません。ビジネス目標との関連づけが重要です。
  3. 自社の文化・リソースに合う形で運用する
    • SAMMの活動内容はフレキシブルに解釈可能ですが、形式にこだわりすぎると形骸化します。現場のスキル・文化・ツールに合ったやり方で落とし込むことが大切です。
  4. 現状評価を“正直に”行う
    • 自己評価において「できているつもり」にならないよう、客観的な視点で弱点を把握する必要があります。必要に応じて第三者レビューを活用するのも有効です。
  5. 継続的な改善の仕組みを作る
    • 評価・計画・実行・再評価を定期的に回す体制がないと、改善が止まってしまいます。定期的な見直しなど、サイクルを仕組み化することが必要です。

まとめ

開発チームとのセキュリティチームの連携で悩んでいる、アプリケーションセキュリティをどのように進めていけばよいかわからない、という悩みはよく聞きます。

そういうときにとりあえずSAST、とりあえずDASTではなく、戦略的に進めたいときOWASP SAMMを活用してみてはいかがでしょうか。

Discussion