Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

「なにをどこまでやれば?」OWASP SAMMが導く開発セキュリティ強化戦略

1,588 views

Published on

OWASP SAMM v1.5

Published in: Engineering
  • Be the first to comment

「なにをどこまでやれば?」OWASP SAMMが導く開発セキュリティ強化戦略

  1. 1. 「なにをどこまでやれば?」 OWASP SAMMが導く、 開発セキュリティ強化戦略 OWASP Japan 岡田良太郎 riotaro@owasp.org
  2. 2. 出荷直前のテストに重点を置く時代の終焉 フェーズ Percent 企画・要件定義フェーズ 53.4% 設計フェーズ 16.5% 開発中 14.6% コードのチェックイン 4.9% リリース前 8.7% Other 1.9% 出典:SANS Institute (2015)
  3. 3. SHIFT LEFT! 0 20 40 60 80 100 設計 構築 検証 運用 1 6.5 15 対応コスト 100 SHIFT LEFT 原因85
  4. 4. 2016/11 リリース NISTIR-8151 Dramatically Reducing Software Vulnerabilities 業界平均 1-25 errors per 1000 lines of code. これを 2.5 errors per 10000 lines of code にできるプロセスとメソドロジをリサーチ
  5. 5. 3. Measures and Metrics 指標の使用を奨励します。 プロセスを継続的に改善するこのアプ ローチは、最高水準の成熟度モデルに あります。指標を使用すると脆弱性は大 幅に軽減します。
  6. 6. NISTIR-8151: A = f(p, s, e) • ソフトウェア保証は、ソフトウェアが必要に応じて動作することを保証するもので、3つの広範なソースから 提供されます。 • 1つは開発プロセスです。ソフトウェアが明確な要件を備えたチームによって開発され、十分に訓練され、 低い脆弱性率で優れたソフトウェアを構築する能力を実証している場合、そのソフトウェアが生産するソフ トウェアには脆弱性がほとんどないという確信があります。 • 第2の保証の根源は、ソフトウェアの分析です。例えば、コードのレビュー、受入れテスト、静的分析は、脆 弱性がソフトウェアではまれである可能性が高いことを保証します。これら2つの保証のソースをトレードオ フすることができます。開発プロセスに関する情報がほとんどない場合、または開発プロセスで過去に優 れたソフトウェアが得られていない場合は、ソフトウェアの品質に対する信頼を得るために、さらに多くの 分析とテストを行う必要があります。対照的に、我々が開発チームと開発プロセスに自信を持っていれば、 ソフトウェアが過去の経験に確実に従うように最小限の分析を行うだけです。 • ソフトウェア保証の3番目のソースは、復元力のある実行環境です。ソフトウェアの品質に自信がなければ、 コンテナで実行し、システム権限をほとんど与えずに、他のプログラムで実行を監視させることができます。 その後、脆弱性が発生した場合、システムの損傷が制御されます。 • ここで、Aは保証の額、pはプロセスの知識から得られる保証、sは静的および動的分析からの保証であり、 eは厳密な実行環境から得られる保証です。
  7. 7. NISTIR 8151 said Aはソフトウェアセキュリティ保証の価値: • p = 開発プロセス • s = セキュリティテスト • e = 実行環境 •A = f(p, s, e)
  8. 8. https://www.owasp.org/index.php/OWASP_SAMM_Project
  9. 9. OWASP SAMM ソフトウェアセキュリティ保証成熟度モデル グローバルのOWASP コミュニティが策定 ・ 日本語訳は経済産業省のプロジェクトで翻訳 レベル1 アドホック レベル2 方針化 レベル3 組織的取り組み X 「ガバナンス」 「実装」 「検証」 「デプロイ」
  10. 10. まさに A = f(p, s, e) ソフトウェア開発 ガバナンス 構築 検証 デプロイ 戦略&指標 ポリシー&コンプライアンス 教育&指導 脅威の査定 セキュリティー要件 セキュアなアーキテクチャ 設計レビュー コードレビュー セキュリティテスト 脆弱性管理 環境の堅牢化 運用体制の セキュリティ対応 ep s
  11. 11. Example:
  12. 12. Case
  13. 13. セキュア開発関連活動の 「可視化」を解消する方法 オープンなソフトウェアガバナンス・フレームワークを活用することにより、ソフトウェア 開発ライフサイクル戦略の策定に不可欠な、現状の把握のための可視化を実現 今後の四半期の注力分野に関する提案を策定し、今後の貴社の開発ガバナンスの スピードと質の助けになる
  14. 14. 開発セキュリティ・ガバナンス強化導入の目的 GOAL 1. 現状の把握・数値化、リスクの可視化を実現する – 規模や業務が様々なプロジェクト活動におけるセキュリティ関連の活動 – 及びリスクコントロール対策の現状を把握・数値化し、スコアリング GOAL 2. 開発・運用組織の活動計画が可能になる – データによる証拠に基づいた改善サイクルを実現するための基礎資料 – 組織全体における実現可能なリスクコントロールの明確化 GOAL 3. 開発・運用組織の方向性を決めることができる – 全体のリスクコントロールと個別のリスクを統合する – 開発プロジェクトにおける業務効率、リスク管理、開発品質の両立
  15. 15. OWASP SAMM (OPENSAMM)
  16. 16. OWASP OpenSAMM オープンなセキュリティ保証成熟度モデル https://www.owasp.org/index.php/OWASP_SAMM_Project 効果的なオープンなフレームワーク / ベンチマーク • ソフトウェア開発における活動の成熟度を可視化 • セキュリティ活動の妥当性や効果の評価 • セキュリティ姿勢強化ロードマップ • 採用企業: Dell uses OWASP’s Software Assurance Maturity Model (Owasp SAMM) to help focus our resources and determine which components of our secure application development program to prioritize., (Michael J. Craigue, Information Security & Compliance, Dell, Inc.) 日本語訳は経済産業省のプロジェクトで翻訳
  17. 17. ガバナンス・構築・検証・デプロイの4分野
  18. 18. 4 カテゴリ、12 アクティビティ、77 チェック項目 明らかになること 戦略に不可欠な策定根拠 ü 合計77チェック項目で開発体制の成熟度を評価し、開発の組織の全体像及び特徴を把握 ü 開発アクティビティのガバナンスに関するコアな知識の深化 ü チームビルディング / 教育 / システムなどの補完が必要な部分の抽出 ソフトウェア開発 ガバナンス 構築 検証 デプロイ 戦略&指標 ポリシー&コンプライアンス 教育&指導 脅威の査定 セキュリティー要件 セキュアなアーキテクチャ 設計レビュー コードレビュー セキュリティテスト 脆弱性管理 環境の堅牢化 運用体制の セキュリティ対応
  19. 19. ベンチマーク-> スコアリング -> 強化 強化計画ベンチマークを参照 チームをスコアリング
  20. 20. 各活動は、相互の作用がある 戦略&指標 ポリシー&コンプライアンス 教育&指導 脅威の査定 セキュリティー要件 セキュアなアーキテクチャ 設計レビュー コードレビュー セキュリティテスト 脆弱性管理 環境の堅牢化 運用体制の セキュリティ対応
  21. 21. 最新:SAMM v1.5
  22. 22. 22
  23. 23. 属人的な状況から組織の取り組みへ成熟度を高め、 開発によるリスクを下げかつ確実性を高めます 事後対応的でアドホック •「開発チームはセキュアプログラ ミングに関するリソースにアクセ スできる」 •この状態においては、素材の提 供、限定的な効果にとどまる。 構造的に進める •「全員がソフトウェアライフサイク ルについて教育されている」 •この状態においては、リーダーの 役割とチームとの連携が取れて いる。 •個々の必要に対応し、定型・非定 型のフィードバックを集めはじめ ることになる 網羅的で、再現性があり、 効果も確認できる •網羅的なトレーニングと認定の仕 組み •セキュリティの全体像と自分の役 割を関連づける •継続的に推進することができ、即 的可能な効果が出せる 23 リスク HIGH リスク MID リスク LOW
  24. 24. Education and Guidance Practice 「教育と指導」プラクティスの例 | Enabling Security ©2015 Asterisk Research, 24 教育&指導 レベル1 •開発者が概略的なセキュリ ティ意識向上トレーニングを 受講済みである •セキュアな開発に関するベス トプラクティスや手引書が、す べてのプロジェクトチームで 利用できるようになっている 教育&指導 レベル2 •開発プロセスにかかわる職務 に対し、職務に特化したト レーニングや指導が実施され る •利害関係者が、プロジェクト のためにセキュリティコーチを 招くことができる 教育&指導 レベル3 •セキュリティ関連の手引書が 一元管理され、組織全体に一 貫した方法で配布される •人員について、セキュアな開 発の実践に関する基本水準 の技能を持つことがテストに より確認される
  25. 25. Lightweight or Detailed 25
  26. 26. 強化のサイクル 1.準備 2.調査 3.目標 を設定 4.計画 を定義 5.実施 6.発表 • 1->3. スコアリングにより目標を定めると、 現実の計画とバジェットを客観視します。 • 3->5. 四半期から半期ごとにスコア目標 にしたがって活動し、KPIやROIに反映し ます。 • 5->1. 成果の共有とイネーブラーの理解、 また目標の調整によりチーム全体の士 気と能力を現実に沿って高めていくこと ができます。
  27. 27. リソース OWASP SAMM wiki: • https://www.owasp.org/index.php/OWASP_SAMM_Project

×