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