Download as PDF, PPTX
More Related Content
Similar to 「なにをどこまでやれば？」OWASP SAMMが導く開発セキュリティ強化戦略
「なにをどこまでやれば？」OWASP SAMMが導く開発セキュリティ強化戦略
- 1.
- 2. 出荷直前のテストに重点を置く時代の終焉 フェーズ Percent 企画・要件定義フェーズ 53.4% 設計フェーズ16.5% 開発中 14.6% コードのチェックイン 4.9% リリース前 8.7% Other 1.9% 出典：SANS Institute (2015)
- 3. SHIFT LEFT! 0 20 40 60 80 100 設計 構築 検証運用 1 6.5 15 対応コスト 100 SHIFT LEFT 原因85
- 4.
- 5.
- 6. NISTIR-8151: A = f（p, s, e） • ソフトウェア保証は、ソフトウェアが必要に応じて動作することを保証するもので、3つの広範なソースから 提供されます。 • 1つは開発プロセスです。ソフトウェアが明確な要件を備えたチームによって開発され、十分に訓練され、 低い脆弱性率で優れたソフトウェアを構築する能力を実証している場合、そのソフトウェアが生産するソフ トウェアには脆弱性がほとんどないという確信があります。 •第2の保証の根源は、ソフトウェアの分析です。例えば、コードのレビュー、受入れテスト、静的分析は、脆 弱性がソフトウェアではまれである可能性が高いことを保証します。これら2つの保証のソースをトレードオ フすることができます。開発プロセスに関する情報がほとんどない場合、または開発プロセスで過去に優 れたソフトウェアが得られていない場合は、ソフトウェアの品質に対する信頼を得るために、さらに多くの 分析とテストを行う必要があります。対照的に、我々が開発チームと開発プロセスに自信を持っていれば、 ソフトウェアが過去の経験に確実に従うように最小限の分析を行うだけです。 • ソフトウェア保証の3番目のソースは、復元力のある実行環境です。ソフトウェアの品質に自信がなければ、 コンテナで実行し、システム権限をほとんど与えずに、他のプログラムで実行を監視させることができます。 その後、脆弱性が発生した場合、システムの損傷が制御されます。 • ここで、Aは保証の額、pはプロセスの知識から得られる保証、sは静的および動的分析からの保証であり、 eは厳密な実行環境から得られる保証です。
- 7. NISTIR 8151 said Aはソフトウェアセキュリティ保証の価値： • p = 開発プロセス •s = セキュリティテスト • e = 実行環境 •A = f（p, s, e）
- 8.
- 9. OWASP SAMM ソフトウェアセキュリティ保証成熟度モデル グローバルのOWASP コミュニティが策定 ・ 日本語訳は経済産業省のプロジェクトで翻訳 レベル1アドホック レベル2 方針化 レベル3 組織的取り組み X 「ガバナンス」 「実装」 「検証」 「デプロイ」
- 10. まさに A = f（p, s, e） ソフトウェア開発 ガバナンス 構築検証 デプロイ 戦略＆指標 ポリシー＆コンプライアンス 教育＆指導 脅威の査定 セキュリティー要件 セキュアなアーキテクチャ 設計レビュー コードレビュー セキュリティテスト 脆弱性管理 環境の堅牢化 運用体制の セキュリティ対応 ep s
- 11.
- 12.
- 13.
- 14. 開発セキュリティ・ガバナンス強化導入の目的 GOAL 1. 現状の把握・数値化、リスクの可視化を実現する – 規模や業務が様々なプロジェクト活動におけるセキュリティ関連の活動 – 及びリスクコントロール対策の現状を把握・数値化し、スコアリング GOAL 2. 開発・運用組織の活動計画が可能になる –データによる証拠に基づいた改善サイクルを実現するための基礎資料 – 組織全体における実現可能なリスクコントロールの明確化 GOAL 3. 開発・運用組織の方向性を決めることができる – 全体のリスクコントロールと個別のリスクを統合する – 開発プロジェクトにおける業務効率、リスク管理、開発品質の両立
- 15.
- 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.
- 18. ４ カテゴリ、12 アクティビティ、77チェック項目 明らかになること 戦略に不可欠な策定根拠 ü 合計77チェック項目で開発体制の成熟度を評価し、開発の組織の全体像及び特徴を把握 ü 開発アクティビティのガバナンスに関するコアな知識の深化 ü チームビルディング / 教育 / システムなどの補完が必要な部分の抽出 ソフトウェア開発 ガバナンス 構築 検証 デプロイ 戦略＆指標 ポリシー＆コンプライアンス 教育＆指導 脅威の査定 セキュリティー要件 セキュアなアーキテクチャ 設計レビュー コードレビュー セキュリティテスト 脆弱性管理 環境の堅牢化 運用体制の セキュリティ対応
- 19.
- 20.
- 21.
- 22.
- 23.
- 24. Education and Guidance Practice 「教育と指導」プラクティスの例 | Enabling Security ©2015 Asterisk Research, 24 教育&指導レベル1 •開発者が概略的なセキュリ ティ意識向上トレーニングを 受講済みである •セキュアな開発に関するベス トプラクティスや手引書が、す べてのプロジェクトチームで 利用できるようになっている 教育&指導 レベル2 •開発プロセスにかかわる職務 に対し、職務に特化したト レーニングや指導が実施され る •利害関係者が、プロジェクト のためにセキュリティコーチを 招くことができる 教育&指導 レベル3 •セキュリティ関連の手引書が 一元管理され、組織全体に一 貫した方法で配布される •人員について、セキュアな開 発の実践に関する基本水準 の技能を持つことがテストに より確認される
- 25.
- 26. 強化のサイクル 1.準備 2.調査 3.目標 を設定 4.計画 を定義 5.実施 6.発表 • 1->3. スコアリングにより目標を定めると、 現実の計画とバジェットを客観視します。 • 3->5. 四半期から半期ごとにスコア目標 にしたがって活動し、KPIやROIに反映し ます。 •5->1. 成果の共有とイネーブラーの理解、 また目標の調整によりチーム全体の士 気と能力を現実に沿って高めていくこと ができます。
- 27.