PowerPoint プレゼンテーション

Size: px

Start display at page:

Download "PowerPoint プレゼンテーション"

たいちことじ
7 years ago
Views:

2 Copyright 2012NTT DATA Corporation 2 自己紹介金子朋子博士 ( 情報学 ) NTT データ品質保証部所属. 入社以来航空機データ通信システム遊技系システム等のシステム開発に従事. 情報セキュリティの社会問題化したプロジェクトも経験. 社内在宅勤務制度の設立時 WG メンバー年情報セキュリティ大学院大学博士後期課程修了. 同大学院客員研究員. 文部科学省認定プログラムサーティフィケート取得者 ( 情報セキュリティスペシャリスト, ソフトウェアスペシャリスト ) 2015 年日本ネットワークセキュリティ協会 (JNSA) 学術論文部門優秀賞受賞研究テーマ : セキュア開発方法論品質保証

3 Copyright 2012NTT DATA Corporation 3 Index 1. はじめに 2. 関連要素技術 ( コモンクライテリアアシュアランスケース ) 3.CC-Case の CC 認証を伴わないセキュリティ要求分析への適用方法 CC-Case インシデント対応版提案の背景 CC-Case_i の定義と目的構造適用対象モデルセキュリティインシデントとそのプロセスセキュリティインシデント解決方法の妥当性 4. CC-Case_i のメリット見える化の特長使い方の工夫

6 Copyright 2015 NTT DATA Corporation 6 CC とは何か? CC(Common Criteria:ISO/IEC15408)=IT セキュリティ評価基準 ( 国際規格 ) CC は開発者が主張するセキュリティ保証の信頼性に関する評価の枠組みを規定 * セキュリティ保証 = セキュリティ機能が間違いなく動作することの確からしさ * IT セキュリティ評価 = セキュリティ保証を確認すること国家レベルで, 第三者による確認の制度と確認結果を国際的に認め合う相互承認制度も確立されている.

7 CC の構造 CC パート 1 概説と一般モデルセキュリティ目標 (Security Target:ST) ST 概説適合性主張セキュリティ課題定義脅威組織のセキュリティ方針前提条件セキュリティ対策方針 TOE のセキュリティ対策方針運用環境のセキュリティ対策方針セキュリティ対策拡張コンポーネント定義セキュリティ要件セキュリティ機能要件セキュリティ保証要件セキュリティ要件根拠 TOE 要約仕様プロテクションプロフェイル (PP) CCパート2 機能コンポーネント CCパート3 保証コンポーネント CEM 情報セキュリティ評価方法 CC ハート 2 ( セキュリティ機能要件 ) CC ハート 3 (EAL 保証要件 ) 7

Copyright 2015 NTT DATA Corporation 8 ST のセキュリティ機能への論理展開 ST

9 Copyright 2015 NTT DATA Corporation 9 アシュアランスケース (ISO/IEC15026) とは? テスト結果や検証結果をエビデンスとしそれらを根拠にシステムの安全性信頼性を議論しシステム認証者や利用者などに保証するあるいは確信させるためのドキュメント *GSN は代表的なアシュアランスケース手法アシュアランスケースの構造と内容の要求事項 ( 最低限 ) システムや製品の性質に対する主張 (claim) 主張に対する系統的な議論 (argumentation) この議論を裏付ける証跡 (evidence) 明示的な前提 (explicit assumption) 議論の途中で補助的な主張を用いることにより最上位の主張に対して証跡や前提を階層的に結び付けることができる

11 CC-Case インシデント対応版提案の背景 CCの課題一般的なセキュリティ複雑要求分析にはあまり利用されていないデジタル複合機などの特定のセキュリティ機能のハードウェア製品や政府調達対象案件に利用が限られる CC-Case 認証を取るための開発を想定していたインシデントのニーズが高いことがわかった!! セキュリティインシデント後の本格対処で利用を検討 < 理由 > セキュリティは非機能要件であり, 当初のシステム設計時には機能要件として挙がらないがその後のインシデント発生によりシステム改修が必要となる事例が多いため Copyright 2015 NTT DATA Corporation 11

12 CC-Case と CC-Case_i の定義 CC-Case の定義セキュリティ要求分析と保証の統合開発方法論 CC-Case_i の定義 CC 認証を伴わないセキュリティインシデントの本格対処に適したセキュリティ要求分析と保証をサポートするプロセスと記法の統合手法 CC-Case の目的開発のセキュリティ上の課題を解決するためセキュアなシステム開発への対応を実施すること CC-Case_i の目的インシデントの本格対応も含め CC 認証を伴わない一般的な開発におけるセキュリティ上の課題解決に役立てること Copyright 2015 NTT DATA Corporation 12

Copyright 2015 NTT DATA Corporation 13 CC-Case_i の構造適用対象 CC-Case_i は CC-Case と論理構造は同じ!

16 Copyright 2015 NTT DATA Corporation 16 セキュリティインシデントとそのプロセスセキュリティインシデント : 事業運営に影響を与えたり情報セキュリティを脅かしたりする事件や事故のことセキュリティインシデント対応 1. 平時におけるインシデント対応の準備インシデントに対応する際の目的と目標事項, 通知体制の確立が必要セキュリティポリシーに記載すべき事項 2. 情報セキュリティ侵害を検出インシデントであることと, その重要性に対するインシデントの識別が必要 3. 情報セキュリティインシデント対応暫定的対応本格的対処システムの改修や運用方法の変更を伴うことも多い.

17 Copyright 2015 NTT DATA Corporation 17 段階 G-1 CC-Case_i のプロセスゴール目的入力手続き出力 XX システムのセキュリティインシデント解決方法は妥当である G-2 インシデント認識は妥当であるセキュリティインシデントの解決方法の妥当性を確認するインシデントを認識し, 一時対処が妥当であることを確認するインシデントの発生セキュリティ方針 G-2 から G-6 までのゴールがすべで満たされていることを確認する基準に基づき結果を評価するインシデント解決の評価一時対処の実施結果出力に対する確認妥当性確認妥当性確認 G-3 現状調査と原因分析は妥当である本格対処に必要な現状調査分析を行う設計書保護資産システム構成装置や機能等に分けて脅威分析するシステムとシステム間の脅威分析結果妥当性確認 G-4 対策立案と選択は妥当である最適な対策を選択する前提条件技術と運用の対策に分けて洗い出した脅威に対策をたてる基準に基づき対策を選択する対策選択根拠選択対策への承認結果残存リスク妥当性確認 G-5 対策実施は妥当である対策を着実に実行する選択した対策実施状況を管理し, 対策を実施する実施結果妥当性確認 G-6 結果の評価は妥当である実施結果を評価し, 次の改善につなげる実施結果基準に基づき結果を評価する実施状況の評価結果妥当性確認

19 セキュリティインシデント解決方法の妥当性セキュリティインシデントの本質的原因は? いろいろあり脅威分析システムリスク評価が不十分各フェーズ間のセキュリティに関する分析の一貫性欠如解決方法は? 様々なケースがあるセキュリティ対策の検証方法のあいまいさ設計実装時のレビューが不十分でシステムバグを見つけ切れていない運用でカバー同様なインシデントを防ぐ仕組みの確立が必要システム自体の大規模な技術的改修が必要インシデントが起きた装置システムだけでなく他装置への影響検討が必要単なる問題解決だけでなく今後のリスク対処が必要原因も解決方法も多様なためインシデントの解決は難しいでは解決方法が妥当であることを示すために大事なことは? インシデント解決のプロセス + 議論によるレビューの強化 Copyright 2015NTT DATA Corporation 19

21 Copyright 2015 NTT DATA Corporation 21 見える化の特長 CC-Case_i は 3 つの見える化の特長をもつ. 1. 主張と証跡の見える化 : ゴールとしての主張とその主張の正しさを裏付ける証跡が存在すること GSN はトップゴールの主張を満たすことを可視化できる手法だから 2. 論理の見える化 : 前提条件, 戦略, ゴールの関係性の明示により, トップの主張から証跡までの論理が明確化されること GSN は図の最下層に主張が正しいことを示す証跡を記述するから更にインシデントの本格対応に適したモデルとして CC-Case_i を提案 3. 保証ストーリーの見える化 : プロセスと実施事項の明確化によりインシデント全体の解決ストーリーの可視化 CC-Case_i は管理プロセスと各インシデントへの対処がつながる統合方法論プロセスアプローチによるインシデント抽出, 分析, 管理は定性的にも定量的にも適用可能であり, インシデント解決の適切性を保証できる

22 Copyright 2015 NTT DATA Corporation 22 使い方の工夫 CC-Case_i の使い方の 3 つの工夫議論のツール : ステークホルダ間の認識の食い違いを防ぐできる限り 1 枚の図で論理の全体像を表記し, インシデント解決ストーリーをステークホルダで共通認識ができるようにする.( 実用性にこだわりあり.) セキュリティ保証のツール : インシデント解決の妥当性確認の一連のプロセスと結果が要件を満たすことを確認するツールである. 単に要件に対する検証を実施するだけでなく, ステークホルダ間の議論による妥当性確認が可能である. 脅威と対策の資産化ツール : 証跡単位で DB 化して脅威と対策のノウハウを資産化できる. ( CC-Case は一連のプロセスを形式化しているため ) 利用者が自社等のシステムにおいて資産化を進めることにより, 将来的に自社システムにおけるプロアクティブな対処につなげられる可能性がある

24 実用性にこだわり 11 枚の図で論理の全体像を表記 4 証跡単位で DB 化して脅威と対策のノウハウを資産化できる. プロアクティブな対処 2 各項目の詳細内容にはリンクを張って参照できる Copyright 2015 NTT DATA Corporation リンク XXXXXXX 1.XXXX 2.XXXX 3 進捗段階に応じ妥当性確認を完了した決定事項と計画段階の未決定段階を区別内容を書き換えていく 24

ACR-C 保証継続報告書独立行政法人情報処理推進機構原紙理事長藤江一正押印済変更 TOE 申請受付日 ( 受付番号 ) 平成 24 年 1 月 12 日 (IT 継続 2077) 認証番号 C0312 申請者コニカミノルタビジネステクノロジーズ株式会社 TOEの名称日本語名 :bi

ACR-C 保証継続報告書独立行政法人情報処理推進機構原紙理事長藤江一正押印済変更 TOE 申請受付日 ( 受付番号 ) 平成 24 年 1 月 12 日 (IT 継続 2077) 認証番号 C0312 申請者コニカミノルタビジネステクノロジーズ株式会社 TOEの名称日本語名 :bi 保証継続報告書独立行政法人情報処理推進機構原紙理事長藤江一正押印済変更 TOE 申請受付日 ( 受付番号 ) 平成 24 年 1 月 12 日 (IT 継続 2077) 認証番号 C0312 申請者コニカミノルタビジネステクノロジーズ株式会社 TOEの名称日本語名 :bizhub C652 / bizhub C652DS / bizhub C552 / bizhub C552DS / bizhub