Upgrade to Pro — share decks privately, control downloads, hide ads and more …

AppSec Team Strategy using OWASP SAMM v1.5

AppSec Team Strategy using OWASP SAMM v1.5

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

Speaker: OWASP Japan 岡田良太郎

OWASP Japan

March 11, 2017
Tweet

More Decks by OWASP Japan

Other Decks in Programming

Transcript

  1. SHIFT LEFT! 0 20 40 60 80 100 設計 構築

    検証 運用 1 6.5 15 対応コスト 100 SHIFT LEFT 原因85
  2. 2016/11 リリース NISTIR-8151 Dramatically Reducing Software Vulnerabilities 業界平均 1-25 errors

    per 1000 lines of code. これを 2.5 errors per 10000 lines of code にできるプロセスとメソドロジをリサーチ
  3. NISTIR-8151: A = f(p, s, e) • ソフトウェア保証は、ソフトウェアが必要に応じて動作することを保証するもので、3つの広範なソースから 提供されます。 •

    1つは開発プロセスです。ソフトウェアが明確な要件を備えたチームによって開発され、十分に訓練され、 低い脆弱性率で優れたソフトウェアを構築する能力を実証している場合、そのソフトウェアが生産するソフ トウェアには脆弱性がほとんどないという確信があります。 • 第2の保証の根源は、ソフトウェアの分析です。例えば、コードのレビュー、受入れテスト、静的分析は、脆 弱性がソフトウェアではまれである可能性が高いことを保証します。これら2つの保証のソースをトレードオ フすることができます。開発プロセスに関する情報がほとんどない場合、または開発プロセスで過去に優 れたソフトウェアが得られていない場合は、ソフトウェアの品質に対する信頼を得るために、さらに多くの 分析とテストを行う必要があります。対照的に、我々が開発チームと開発プロセスに自信を持っていれば、 ソフトウェアが過去の経験に確実に従うように最小限の分析を行うだけです。 • ソフトウェア保証の3番目のソースは、復元力のある実行環境です。ソフトウェアの品質に自信がなければ、 コンテナで実行し、システム権限をほとんど与えずに、他のプログラムで実行を監視させることができます。 その後、脆弱性が発生した場合、システムの損傷が制御されます。 • ここで、Aは保証の額、pはプロセスの知識から得られる保証、sは静的および動的分析からの保証であり、 eは厳密な実行環境から得られる保証です。
  4. NISTIR 8151 said Aはソフトウェアセキュリティ保証の価値: • p = 開発プロセス • s

    = セキュリティテスト • e = 実行環境 •A = f(p, s, e)
  5. まさに A = f(p, s, e) ソフトウェア開発 ガバナンス 構築 検証

    デプロイ 戦略&指標 ポリシー&コンプライアンス 教育&指導 脅威の査定 セキュリティー要件 セキュアなアーキテクチャ 設計レビュー コードレビュー セキュリティテスト 脆弱性管理 環境の堅牢化 運用体制の セキュリティ対応 e p s
  6. 開発セキュリティ・ガバナンス強化導入の目的 GOAL 1. 現状の把握・数値化、リスクの可視化を実現する – 規模や業務が様々なプロジェクト活動におけるセキュリティ関連の活動 – 及びリスクコントロール対策の現状を把握・数値化し、スコアリング GOAL 2.

    開発・運用組織の活動計画が可能になる – データによる証拠に基づいた改善サイクルを実現するための基礎資料 – 組織全体における実現可能なリスクコントロールの明確化 GOAL 3. 開発・運用組織の方向性を決めることができる – 全体のリスクコントロールと個別のリスクを統合する – 開発プロジェクトにおける業務効率、リスク管理、開発品質の両立
  7. 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.) 日本語訳は経済産業省のプロジェクトで翻訳
  8. 4 カテゴリ、12 アクティビティ、77 チェック項目 明らかになること 戦略に不可欠な策定根拠 ü 合計77チェック項目で開発体制の成熟度を評価し、開発の組織の全体像及び特徴を把握 ü 開発アクティビティのガバナンスに関するコアな知識の深化

    ü チームビルディング / 教育 / システムなどの補完が必要な部分の抽出 ソフトウェア開発 ガバナンス 構築 検証 デプロイ 戦略&指標 ポリシー&コンプライアンス 教育&指導 脅威の査定 セキュリティー要件 セキュアなアーキテクチャ 設計レビュー コードレビュー セキュリティテスト 脆弱性管理 環境の堅牢化 運用体制の セキュリティ対応
  9. 22

  10. 属人的な状況から組織の取り組みへ成熟度を高め、 開発によるリスクを下げかつ確実性を高めます 事後対応的でアドホック •「開発チームはセキュアプログラ ミングに関するリソースにアクセ スできる」 •この状態においては、素材の提 供、限定的な効果にとどまる。 構造的に進める •「全員がソフトウェアライフサイク

    ルについて教育されている」 •この状態においては、リーダーの 役割とチームとの連携が取れて いる。 •個々の必要に対応し、定型・非定 型のフィードバックを集めはじめ ることになる 網羅的で、再現性があり、 効果も確認できる •網羅的なトレーニングと認定の仕 組み •セキュリティの全体像と自分の役 割を関連づける •継続的に推進することができ、即 的可能な効果が出せる 23 リスク HIGH リスク MID リスク LOW
  11. Education and Guidance Practice 「教育と指導」プラクティスの例 | Enabling Security ©2015 Asterisk

    Research, 24 教育&指導 レベル1 •開発者が概略的なセキュリ ティ意識向上トレーニングを 受講済みである •セキュアな開発に関するベス トプラクティスや手引書が、す べてのプロジェクトチームで 利用できるようになっている 教育&指導 レベル2 •開発プロセスにかかわる職務 に対し、職務に特化したト レーニングや指導が実施され る •利害関係者が、プロジェクト のためにセキュリティコーチを 招くことができる 教育&指導 レベル3 •セキュリティ関連の手引書が 一元管理され、組織全体に一 貫した方法で配布される •人員について、セキュアな開 発の実践に関する基本水準 の技能を持つことがテストに より確認される
  12. 強化のサイクル 1.準備 2.調査 3.目標 を設定 4.計画 を定義 5.実施 6.発表 •

    1->3. スコアリングにより目標を定めると、 現実の計画とバジェットを客観視します。 • 3->5. 四半期から半期ごとにスコア目標 にしたがって活動し、KPIやROIに反映し ます。 • 5->1. 成果の共有とイネーブラーの理解、 また目標の調整によりチーム全体の士 気と能力を現実に沿って高めていくこと ができます。