つながる世界のセキュリティ設計入門 ～セキュリティ要件の見える化～ 2016.3.23 情報セキュリティ大学院大学客員研究員 金子 朋子 1 目次 • • • • • • • • • • • • • IoTの特徴 IoTセキュリティの現状・課題 安全なシステム・ソフトウェアの開発 上流工程でのセキュリティ設計 セキュリティコンセプトの策定 セキュリティ要求分析の特徴 脅威の特定・分析手法（STRIDE、ミスユースケース、Attack Tree） 脅威に対するリスクの見積もり及び評価（FMEA、CVSS、ｉ*Liu 法、SARM） セキュアプログラミング セキュリティレベルの指標 セキュリティ設計の評価・認証（コモンクライテリア、セキュリティ要件） ロジカルな設計品質の説明（アシュアランスケース） 演習編参考資料 2 IoTの特徴 IoT：モノのインターネット（Internet of Things） IoTの特徴：多様な機器・システムがつながること →より複雑なセキュリティ要件をもつことになる 3 3 IoTセキュリティの現状 IoTシステムへの脅威事例は日増しに増加 • HDDレコーダーの踏み台化は情報家電に対する初期の攻撃事例 （2004年） • 心臓ペースメーカの不正操作（2013年） • Jeepを車載のインフォメーションシステムを経由してインターネットから操作 できる研究（2013年） • スマホでATMから現金を引き出すウイルス（2014年） • Black Hat • HW／組込み，IoT，スマートグリッド／インダストリ・IoT関連テーマ がカテゴリに登場 →IoTハッキング技術を身につけ，実践をはじめるハッカーが増加 4 IoTセキュリティの課題 • 業界，製品・システムごとに要件が異なるため，セキュリティの対応レベルが異なり， 標準化の動向も異なっている • 対象が情報だけでなく，実体を伴うモノになるため．与える被害も致命的であり，攻 撃の被害は甚大にならざるを得ない→IoTセキュリティの確保は重大事 • IoTセキュリティの対象となる機器やシステムに対する脅威には盗聴や不正アクセスに よる情報漏えいやプライバシー侵害，データやソフトウェア改ざんによる誤動作や予期 せぬ停止など，様々なものが想定される • 事故の発生や顧客の信頼失墜，機器交換・システム改修コストなど多大な損害も 懸念 • IoTのセキュリティを確保するための技術や手法，標準，基準はまだ確立されていな い（脅威となる対象の洗い出し・目標を設定するセキュリティ要求分析手法・リスク評 価の手法，要件を可視化する技術が必要） 5 安全なシステム・ソフトウェアの開発 より巧妙化する脅威に対して，より安全なソフトウェアを開発す るにはどうしたらよいか？ 解決方法 開発者に対する教育と訓練 経験の伝達 プロジェクト管理の徹底 運用管理の向上 セキュリティ方針の厳密化 開発方法論・プロセス セキュリティ by デザイン システム内ソフトウェアの中に脅威への対抗手段を含める ことがより根本的な対策になりうるから 6 上流工程でのセキュリティ設計 上流の段階におけるセキュリティ設計の手法がセーフティ設計と比較 して普及していない セーフティとセキュリティの設計プロセス セーフティとセキュリティの コンセプトの策定及び周知 リスク分析、評価及びリスク低減策検討 （セーフティとセキュリティの要件定義） セーフティとセキュリティの設計 （アーキテクチャ設計） セーフティとセキュリティの設計 （ソフトウェア設計） 信頼性の高いソフトウェアの実装 Ｖ字開発モデル 評価 システム化の方向性・ システム化計画 運用・評価 検証 要件定義 運用テスト 検証 システム設計 検証 ソフトウェア設計 システムテスト ソフトウェア テスト プログラミング 運用段階で脆弱性が発見されると機器の交換、システムの改修が必要となるため、 設計・開発段階と比べ、膨大なコストがかかる。 →上流工程でのセキュリティ対応が重要！！ セキュリティコンセプトの策定 利用者（調達者） 一般の機 ・スピード（早く） 能要求 ・費用（安く） ・品質（良いものを） ・使いやすく セキュリ ティ要求 VS 問題点 開発者（ベンダー） 変換時に ギャップ ・仕様の固まり具合 ・利害関係者の合意 ・ＩＴ技術・方式 ・ｽｷﾙ・再利用 ・セキュリティは難しいので任せる 更に が費用がかかるのは困る 大きな ・特別な要求はないけど、個人情 ギャップ 報漏えいは困る ・内部統制も一緒に考えてほしい ・社内の犯行は想定外 ・リスクの洗い出しに 漏れはないか不明 ・各工程ごとに何をどこまで やればいいのかわからない ・新たな脅威への対処は 現行の設計では無理 ・リスク対策の費用を お客様は負担してくれない セキュリティ機能は非機能要件であり、 お客様に納得していただき、ギャップを埋めるのは難しい 8 セキュリティ要求分析の特徴 セキュリティ特有の課題：攻撃者の存在 攻撃：脅威を意図的に実現する手段 一般的な要求分析：ステークホルダ（利害関係者）の意 図をシステムにより実現するのが目的 攻撃者の意図に対しては、逆に妨害することが目的 セキュリティ要求分析：顧客は要求に基づく機能要件の分 析に加えて攻撃者の存在を考慮した非機能要件の分析を 必要とする．そこでセキュリティ要求はアセットに対する脅威と その対策の記述が必須となる 9 脅威の特定・分析手法(1) ＳＴＲＩＤＥ： マイクロソフトが定義する脅威モデル。アプリケーションに対するセキュリティ上の脅威の分 類名の頭文字から成る語。アプリケーションの脆弱性や未知の攻撃のタイプを理解するた めに脅威を 6つのカテゴリに分類 Ｓ Spoofing identity なりすま し コンピュータに対し、他のユーザーを装うこと。なりすましにより、攻撃者は不 法にアクセスを行い、ユーザー名やパスワードなど、他のユーザーの認証情 報を使用する Ｔ Tampering 改ざん データを意図的に操作すること。データベースに保持されている永続データ を承認を受けずに変更したり、インターネットなどのオープンなネットワークを 介してコンピュータ間で伝送されるデータを改ざんすることなど Ｒ Repudiation 否認 ユーザーがあるアクションを行ったこと否認し、相手はこのアクションを証明 する方法がないこと。禁止された操作をトレースする能力がないシステムで、 ユーザーが不法な操作を行うことなど Ｉ Information 情報の Disclosure 暴露 アクセス権限を持たない個人に情報が公開されること。アクセスを許可され ていないファイルを読むことができたり、侵入者がコンピュータ間で伝送され ているデータを読むことができる場合など Ｄ Denial of Service サービス 攻撃により正規のユーザーへのサービスが中断される。Web サーバーを一 時的に使用できない状態にするなどがDoS攻撃。 不能 Ｅ Elevation of 権限の Privilege 昇格 権限のないユーザーがアクセス権限を得ること。システム全体を使用不可に したり、破壊するために十分なアクセス権限を得ること。 10 脅威の特定・分析手法(2) ミスユースケース： ユースケースに攻撃者を追加したミスユースケース図を作成し、攻撃 者が対象の機器やシステムに対して攻撃する目的や得ようとする利 益を想定することで、脅威を特定する手法 11 脅威の特定・分析手法(2) Attack Tree： 攻撃者のゴールを設定し、ゴールに至る攻撃手順をツリー上に展開する ことで脅威分析を行う手法 攻撃者の目 標（ゴール） 手法1 手法2 手法2-1 攻撃者の手順にそって 上からツリーを記述 手法3 最初の手順 次の手順 手法2-2 手法2-2-1 その次の手順 12 脅威に対するリスクの見積もり及び評価(1) ハザード分析手法を利用したリスク評価： ＦＴA、FＭＥＡ、HAZOPなどのセーフティ手法の利用 金融証券会社のシステム Potential Failure Mode and Effects Analysis (Design FMEA) Key Date 2008/10/26 潜 在 的 故 障 モ ード 潜在的故障影響 S e v 潜在的故障原因・ メカ ニズ ム P r o b 現在の設計・ 工程管理予防・ 検出 D e t 口座登録情報の漏 不正アクセスの発生 えい 4 保護されていないデータパケットは途 4 中で傍聴されて変更される 重要なデータの保護、保護した データの安全な伝送 4 口座登録情報の漏 不正アクセスの発生 えい 4 保護されていないデータパケットは途 4 中で傍聴されて変更される 重要なデータの保護、保護した データの安全な伝送 4 注文情報の改竄 6 保護されていないデータパケットは途 4 中で傍聴されて変更される 重要なデータの保護、保護した データの安全な伝送 4 8 ユーザの認証シーケンスを盗用した 8 り、再現することで、なりすまし攻撃を 行う 攻撃者がバッファオーバフローの脆 6 弱性等を利用してアプリケーションと 同じセキュリティコンテキストで有害な コードを実行する可能性がある 強力な認証手段を使用すること 4 なりすましによる誤 注文 誤った注文による損失 悪意の攻撃者がパスワー ドを盗用して、ユーザーに なりすます 仲買人・管理人へ アプリケーションやデータ の権限昇格 の中でユーザがアクセスで きない部分への特権アクセ スをユーザが取得してしま う 商品注文への否認 ユーザが商品注文を否認 し、利益が下がる システムへのＤｏｓ攻 正当なサービス要求を処 撃等 理できなくなるほど大量の トラフィックをシステム上に 発生させる。 8 ユーザが注文した商品を否認するこ とで、虚偽に利益を得ようとする。 10 T CP /IP プロトコルの欠点を利用し 6 たり、オペレーティング システムにお ける T CP /IP の実装のバグを突い たりする方法を取る 4 8 アプリケーションはできる限り低い 6 セキュリティコンテキストで動作す るようにしておく必要がある。 R P N 推奨処置 64 ①ハッシュとデジタル署名を使用して 暗号化する ②ＳＳＬ／ＴＬＳやＩＰｓｅｃなどの安全な エンドツーエンドプロトコルの使用 64 ①ハッシュとデジタル署名を使用して 暗号化する ②ＳＳＬ／ＴＬＳやＩＰｓｅｃなどの安全な エンドツーエンドプロトコルの使用 96 ①ハッシュとデジタル署名を使用して 暗号化する ②ＳＳＬ／ＴＬＳやＩＰｓｅｃなどの安全な エンドツーエンドプロトコルの使用 256 kerberos認証やクライアント認証証明 書の使用 288 バッファ オーバーフローが発生する のを防ぐ 権限のないユーザに今後は行わ 4 96 デジタル署名とタイムスタンプの使用 せたくない行動を記録しておく。 DoS 攻撃は撃退することが困難 10 800 ファイアウォールを使用してパケットの フィルタ処理を行い、正当なパケットと なだけでなく、予測することさえ困 有害なパケットを分離する 難。更にDoS 攻撃は簡単に実行 可能。 13 脅威に対するリスクの見積もり及び評価(2) CVSS(Common Vulnerability Scoring System): 共通脆弱性評価システム CVSS は、情報システムの脆弱 性に対するオープンで汎用的な評価手法｡ベンダーに依存し ない共通の評価方法を提供。CVSSを用いると、脆弱性の 深刻度を同一の基準の下で定量的に比較できる｡ベンダー、 セキュリティ専門家、管理者、ユーザ等の間で、脆弱性に関 して共通の言葉で議論できる｡ CVSSv2は、攻撃対象となるホストや システムにおいての「脆弱性による深刻 度」を評価｡ CVSSv3では、仮想化やサンドボックス 化などが進んできていることから、コン ポーネント単位で評価する手法を取り 込んだ仕様｡ IPA資料 CVSSとは？より 14 脅威に対するリスクの見積もり及び評価(3) ｉ＊（ＬＩＵ法）： ゴール指向要求分析手法のひとつであるi*（アイスター）手法を拡張したセキュリティ 要求分析手法。通常のアクターおよびゴールの特定に加えて、悪意のあるアクター およびゴールも特定することで、セキュリティ攻撃方法と対策を特定する。 なりすましによる不正注文のｉ＊（ＬＩＵ法）図 15 脅威に対するリスクの見積もり及び評価(4) アクタ関係表に基づくセキュリティ要求分析手法（ＳＡＲＭ）: ＳＡＲＭとは、攻撃と通常のシステム機能との間のセキュリティ上の関係を分析する ための要求分析手法 一般者Ａ 一般者Ｂ 攻撃者C 一般者Ａ ○Gab, Gac ◇ □- ☆Iab ◇ □ ☆Ic ◇ □ -- 一般者Ｂ ☆Iba ◇ □ ○Gba,Gb ☆Ibc c ◇ ◇ □ -□ 攻撃者Ｃ ★Ica ◆ → ++対策 ：A ★cb ◆&◆ &◆ ｜◆ ＊一般者（アクタ）を機器に置き換えると 複数機器の相互作用分析に応用可能。 ＜一般者のマーク＞ ○：期待としてのゴール ☆：ソフトゴール ◇：タスク、機能 □：資源情報 ＜攻撃者のマーク＞ ●：攻撃者の期待としての ゴール ★：攻撃者のソフトゴール ◆：攻撃者のタスク、機能 ■：攻撃者の資源情報 <論理関係性のマーク＞ ＆：論理積（and） ｜：論理和(or) 一般者Ａのゴー ル（対角要素） 一般者Ｂの一般者 Ａへのゴール（非対 角要素） 攻撃者、悪意、攻撃方 法、脆弱性の特定を行う 他者に対する攻撃者の タスクを挙げる 攻撃者に対する対策案 の特定を行い、ユーザに 提示する → +対策： B ● Gca, Gcb ◆ →対策 ：C 16 ＊【参考1】に詳細を示す。 セキュア・プログラミング Webアプリケーションの脆弱性対策にはさまざまなものがあり、実装段階で考慮すれば済むもの もあれば、設計の上流段階から考慮したほうがよいものもある。 IPA資料セキュア・プログラミング講座より セキュリティレベルの指標 コモンクライテリアにおけるセキュリティ機能の評価保証レベル： ＥＡＬ（保証要求内容） 想定されるセキュリティ保証レベル EAL1（機能テスト） クローズドな環境での運用を前提に安全な利用や運用が保証された 場合に用いられる製品の保証レベル EAL2（構造化テスト） 利用者や開発者が限定されており、安全な運用を脅かす重大な脅威 が存在しない場合に用いられる保証レベル EAL3（方式的テスト及び チェック） 不特定な利用者が利用できる環境、不正対策が要求される場合に 用いられる製品の保証レベル EAL4（方式的設計、テス ト及びレビュー） 商用機器やシステムにおいて高度なセキュリティ確保を実現するために、 セキュリティを考慮した開発と生産ラインを導入して生産される製品の 保証レベル EAL5（準形式的設計及 びテスト） 特定の分野の商用製品・システムにおいて、最大限のセキュリティ確保 をするためにセキュリティの専門家の支援により開発、生産された製品 の保証レベル EAL6（準形式検証済み 設計及びテスト） 重大なリスクに対応して高い価値のある資産を保護するために、開発 環境にセキュリティ工学技術を適用して開発された特別性の製品の保 証レベル EAL7（形式的検証済み 設計及びテスト） 非常にリスクが大きい環境や高い開発費用に見合う資産を保護するた めに開発された製品の保証レベル セキュリティ設計の評価・認証(1) 保証とは？ 「保証」を英語でいうと assurance 「製品が品質基準に合致しているかを、設計・試 作・製造・検査の全ての工程で確認する仕組みが あり、それを実行していることを保証する、請合う、自 信をもって言うこと」 warranty 「出荷後製品が故障したら，無料で修理又は 取り替えをする事を利用者に対して保証するこ と」 guarantee 「もし保証したことが出来なければ、賠償責任が生 じるような保証」 19 セキュリティ設計の評価・認証(2) 情報セキュリティと保証①（規格準拠） 情報セキュリティとは「正当な権限をもつ個人や組織が、情報を適切に管理できる」こと 個人情報や機密情報を防露されたり、システムの稼働を妨害されたりすることがないように、 情報を管理する機能=情報セキュリティ機能 セキュリティ機能には以下のことが要 情報セキュリティ機能の確からしさを確保するのがセキュリティ保証 ：セキュリティ機能が正確に動作し、有効に機能することの保証 求される 動作しないことはない 不当な干渉をうけることはない 動作不能に陥ることはない 一般のＩＴ機能 確認可能 ？ 開発者がセキュリティ保証を 検証しなければならない 利用者は一般のＩＴ機能については、実際に利 用してみることで保証されていることを確認できる セキュリティ機能 利用者が不測の事態を発生させてセキュリティ機能が 正確かつ有効に動くことを確認することは困難 このセキュリティ保証を確 認するのが、セキュリティ 評価（by第三者） セキュリティ評価の国際規格 コモンクライテリア（ＣＣ）の保証 20 セキュリティ設計の評価・認証(3) コモンクライテリア（ＣＣ）とは？ ＣＣパート１ 概説と一般モデル セキュリティ目標（ＳＴ） ST概説 適合性主張 セキュリティ課題定義 脅威 組織のセキュリティ方針 前提条件 セキュリティ対策方針 TOEのセキュリティ対策方針 運用環境のセキュリティ対策方針 セキュリティ対策 拡張コンポーネント定義 セキュリティ要件 セキュリティ機能要件 セキュリティ保証要件 セキュリティ要件根拠 TOE要約仕様 プロテクションプロフェイル（ＰＰ） ＣＣパート２ 機能コンポーネント ＣＣパート３ 保証コンポーネント ＣＥＭ 情報セキュリティ評価方法 CCはITセキュリティ評価の国際 標準（ISO/IEC15408） •開発者が主張するセキュリ ティ保証の信頼性に関する評 価の枠組みを規定 STはセキュリティ保証の目標を規 定した文書 •評価対象のシステムが装備 するセキュリティ機能を定義 •必須のセキュリティ評価対象 ＣＣﾊﾟｰﾄ２ （セキュリティ 機能要件） ＣＣﾊﾟｰﾄ３ （ＥＡＬ保 証要件） ＊【参考2】に詳細と 関連事項を示す。 21 ロジカルな設計品質の説明(1) 情報セキュリティと保証②（品質説明力の強化） セキュリティ機能へのお客様の納得←セキュリティ機能の品質説明力の強化 ソフトウェア＝目に見えないもの ソフトウェアの品質保証→困難（なぜならばどのような機能をどのように実現して、 それがどのような投資効果をもつのかを示す必要がある） 情報セキュリティに関する品質保証→より困難（新たな脅威がどのように発生す るか予測不可能なため） 目に見えないものであるソフトウェアに対し，理論 的な論理関係と根拠を示すことによって品質説 明力を強化し，お客様の納得を得ることでお客 様と合意した内容について保証が必要 理論的な論理関係と根拠を示す アシュアランスケース （Assurance Case）の保証 22 ロジカルな設計品質の説明(2) アシュアランスケース（ISO/IEC15026）とは？ テスト結果や検証結果をエビデンスとしそれらを根拠にシステム の安全性，信頼性を議論し，システム認証者や利用者など に保証する，あるいは確信させるためのドキュメント アシュアランスケースの構造と内容の要求 事項（最低限） • システムや製品の性質に対する 主張(claim) • 主張に対する系統的な議論 （argumentation） • この議論を裏付ける証跡 (evidence) • 明示的な前提（explicit assumption） • 議論の途中で補助的な主張を 用いることにより、最上位の主張 に対して、証跡や前提を階層的 に結び付けることができる *GSNは代表的な アシュアランスケース手法 ＊【参考3】に関連事項を示す。 23 【参考1】 例）ＳＡＲＭ＿Ａ表 なりすましによる不正注文 利用者ALICE 脆弱性のあるシステムＢＯＢ 攻撃者EVE 利用者 ALICE ☆色々なサイトを閲 覧したい □COOKIE情報 ☆BOBのサイトを閲覧したい &◇BOBのサイトのトップページにアクセスする &◇ログインをする ☆EVEのサイトを閲覧したい ◇BOBのサイトにログインしたま まＥＶＥのサイトをクリックする 脆弱性 のある システ ムＢＯＢ ☆正当な利用者にア クセスさせる &○利用者情報を保護する □利用者情報 &○利用者ごとの管理をする &◇許可された利用者に情報へのアクセスを許可する □認証データ &◇ALICEにセッションＩＤを割り当てCOOKIE情報を通知す る &◇COOKIE情報を管理する □ -- COOKIE情報 &○商品の販売をする ☆正当ではない利用者にはアクセ スさせない ◇偽造された認証データの使用 を 検知または拒否する |◆ＸＳＳの脆弱性によりALICEのCOOKIE情報をＥＶＥに送信 ■--ＸＳＳの脆弱性 攻撃者 EVE ★ALICEにEVEのサ イトをクリックさせた い ◆利用者ALICEに EVE のサイトをクリ ックさせる ★ALICEになりすましてBOBのシステムで商品を注文し、商品 を手に入れたい &◆ALICEのｾｯｼｮﾝIDを盗む ■--COOKIE情報 ｜◆Script Insertion ｜◆ＨＴＴＰレスポンス攻撃 ｜◆ＸＳＳ &◆ＡＬＩＣＥになりすまして、商品の注文をする ★ALICEになりすましてBOBのシ ステムで商品を注文し、商品を手 に入れたい &◆Cookie情報窃盗スクリプトを 起動 &◆Cookie情報内のｾｯｼｮﾝIDを 利用する 【参考1】 A2 A3 S2 G1 G3 G2 G4 G5 S8 T1 R2 T2 T4 T5 S37 T6 S7 T4 R1 R3 i*-Liu法 S1 S3 S5 S４ A1 G6 S6 スパイラルレビュー T3 SARM 2つの手法は同じ内容を記述可能。図と表の長所を活 かしより効果的な要求分析を実施するために, i*-Liu 法とSARMの両方を使用したスパイラルレビューを提案 。 【参考2】 CCのセキュリティ機能要件の構成 11クラスに分類されている。 1 セキュリティ監査 (Security audit :FAU) 2 通信 (Communication :FCO) 3 暗号サポート (Cryptographic support :FCS) 4 利用者データの保護 (User data protection :FDP) 5 識別と認証 (Identification and authentication:FIA) 6 セキュリティ管理 (Security management :FMT) 7 プライバシー (Privacy :FPR) 8 TSFの保護 (Protection of the TSF :FPT) 9 資源利用 (Resource utilization :FRU) 頭文字の‘F’はFunction（機能）のF 10 TOEアクセス (TOE access :FTA) 11 高信頼パス／チャネル (Trusted path / channels :FTP) 26 【参考2】 公開されているPPの例 27 IPA2014年度版 ＳＴ作成講座資料より 【参考2】 従来のPPとcPPの違い PP cPP 技術分野 対象範囲 製品分野 作成者 調達者（政府機関・認証 機関） 国際的テクニカルコミュニティ（製品ベン ダ，調達者，評価者，認証者） 評価保証レベル EAL3～4 原則EAL1～EAL2 評価期間 18か月～ 6か月以下（米国は90日以下を目標 に推進中） 評価品質 評価者の能力に強く依存 具体的なテスト，評価手法をサポート （評価機関・国によるバラツ 文書として規定することで，必要な品質 キ） を確保 暗号評価 CC/CEMに詳細な規定なし サポート文書に詳細なテスト方法を記載． 将来的にCC/CEMに盛り込む計画 【参考2】 cPP適合評価に備えたアクション 情報収集：CCUFへ参加し，情報収集(現在，参加費無料) 1)ウェブ及びメーリングリストによる情報共有 2)年3回のFace To Face 会合 【参考】 3)電話会議等への参加 cPP開発への参画：特定の技術分野に関するcPPの開発 1)認証機関との連携（cPPの提案） 2)発足したiTCへの参画 3)海外CCRA加盟の政府機関との連携（調達者のみ） 4)国内外の業界各社との連携（ベンダのみ） cPPまたはPPに基づく調達の実施 調達要件に該当するcPP又はPPを記載(調達者のみ) 【参考2】 国内：経産省の通達とセキュリティ要件 「IT製品の調達のためのセキュリティ要件リスト」 現在日本国内で実績のある6分野が対象。 ①デジタル複合機， ②ファイアウォール， ③IDS/IPS， ④OS（サーバーOS）， ⑤データベース管理システム， ⑥スマートカード（ICカード） ＊USBメモリ は拡充候補 セキュリティ 要件リスト ISO/IEC 15408 （CC） ベース認証 【参考2】 CCRA(Common Criteria Recognition Arrangement) • セキュリティ評価における相互認証を実現（CCRA） – ある国が、ISO/IEC15408の認証を与えた製品については、他の国でも同じレベルで通用する主 旨の協定。 – 評価・認証にかかるコストを削減することがねらい。 日 本 イギリス カナダ フランス アメリカ オーストラリア ドイツ ニュージー ランド フィンランド ハンガリー ギリシャ イスラエル オーストリア チェコ パキスタン デンマーク 認証書受入国：8カ国 オランダ ノルウェー 韓 国 スペイン ＊シンガポールは6月19日に加盟 を自主的に取り止め。 スウェーデン イタリア トルコ マレーシア 認証書生成国：17 か国 インド 認証国 : 自国に認証制度を持つ国々 31 認証受入国 : 自国に認証制度を持たない国々 【参考2】 ITセキュリティ評価及び認証制度 （JISEC） 32 【参考2】 政府機関の情報セキュリティ対策のための統一基準 33 IPA2014年度版 ＨＰより 【参考3】 CC-Caseのライフサイクルプロセスの概要 要件 定義 設計 要求段階のCC-Caseはこのプロセスに相当 実装 テスト 34 【参考3】 一般のシステム開発プロセス・セキュリティ対応プロセスとＣＣ-Ｃａｓｅの対応 設計・ 開発 企画・要件定義 テスト サービ ス提供 セキュリティ仕様のアシュアランスケース セキュリティコン セプト定義段階 入 力 顧客 の要 求 セキュリティ対策立案段階 セキュリティ仕様化段階 ＣＣﾊﾟｰﾄ２ （セキュリティ 機能要件） 過去の ＰＰ事 例集 ＣＣﾊﾟｰﾄ３ （セキュリティ 保証要件） 要求のプロセス 要求抽出 手 順 証 跡 セキュリ ティコン セプトの 定義 ST概説・ 適合主 張・EAL 組織のセ キュリティ方 針の検討 組織のセキュ リティ方針・ 前提条件 要求分析 脅威 分析 脅威分 析結果 セキュリ ティ対策 の選択 セキュリ ティ対策 の検討 TOE・運用 のセキュリ ティ対策 方針 要求仕様化 セキュリ ティ対策 方針根拠 要求妥当性確認 セキュリティ 要件の仕 様化 拡張コン ポーネン ト定義 セキュリ ティ機 能要件 ①セキュリ ティ仕様検 討のプロセ ス明示化 要約仕 様化 セキュリ ティ保証 要件 TOE 要約 仕様 要求管理 ②セキュリティ保証要件 ③顧客との合意 EAL選択 保証要件確定 EALに応 じた設 計・実装 評 価 認証 35 演習編参考資料 36 【演習用記入欄】 ＜アシュアランスケースの表記法＞ 金融証券システムがセキュリティを満たすことを示すアシュアランスケースを作成。 37 CC-CaseとCC-Case_iの定義 CC-Caseの定義 CC-Caseの目的 セキュリティ要求分析と保証 の統合開発方法論 （CC認証時に適用） 開発のセキュリティ上の課 題を解決するため、セキュア なシステム開発への対応を 実施すること CC-Case_iの目的 CC-Case_iの定義 CC認証を伴わないセキュリ ティインシデントの本格対処に 適した「セキュリティ要求分析 と保証」をサポートするプロセ スと記法の統合手法 インシデントの本格対応も 含め、CC認証を伴わない一 般的な開発におけるセキュ リティ上の課題解決に役立 てること CC-Case_iの構造・適用対象 CC-Case_iは CC-Caseと論理構造は 同じ！！ 論理モデルと具体モデルに分 類される 証跡 CC-Case_iの適用対象 はシステムまたは製品。仕 様を決める際に承認を取 る特定の顧客がいない場 合は要件を決めるうえでの 関係者と読み替える． CC-Case_iの論理モデルと具体モデル ＣＣ基準から、 インシデント対応用のプロセスに変えた！！ セキュリティインシデントとそのプロセス セキュリティインシデント：事業運営に影響を与えたり、情報セキュリティを 脅かしたりする事件や事故のこと セキュリティインシデント対応 「1. 平時におけるインシデント対応の準備」 • インシデントに対応する際の目的と目標事項，通知体制の確立が必要 →セキュリティポリシーに記載すべき事項 「2. 情報セキュリティ侵害を検出」 • インシデントであることと，その重要性に対するインシデントの識別が必要 「3. 情報セキュリティインシデント対応」 • 暫定的対応 • 本格的対処 →システムの改修や運用方法の変更を伴うことも多い． • セキュリティインシデントの本質的原因は？→いろいろあり 脅威分析・システム リスク評価が不十分 • 各フェーズ間のセキュ リティに関する分析の 一貫性欠如 セキュリティ対策の検 証方法のあいまいさ 設計・実装時のレビュー が不十分でシステムバグ を見つけ切れていない ・・・ 解決方法は？→様々なケースがある 運用で カバー 同様なインシデント を防ぐ仕組みの確 立が必要 インシデントが起きた システム自体の大 単なる問題解決だ 装置・システムだけで 規模な技術的改 けでなく今後のリス なく他装置への影響 修が必要 ク対処が必要 検討が必要 ・・・ 原因も解決方法も多様なため、インシデントの解決は難しい。 では解決方法が妥当であることを示すために大事なことは？ インシデント解決の プロセス ＋ 議論による 「レビューの強化」 42 CC-Case_iのプロセス 段 階 ゴール 目的 入力 手続き 出力 出力に対 する確認 XXｼｽﾃﾑのセキュリ セキュリティインシデント G-2からG-6までのゴールがす ・インシデン ・インシデント解 妥当性確 G-1 ティインシデント解決 の解決方法の妥当性 べで満たされていることを確認 トの発生 決の評価 認 方法は妥当である を確認する する インシデントを認識し， インシデント認識は ・セキュリティ 基準に基づき、結果を評価す ・一時対処の実 妥当性確 G-2 一時対処が妥当であ 妥当である 方針 る 施結果 認 ることを確認する G-3 現状調査と原因分 本格対処に必要な現 ・設計書 ・システム構成装置や機能等 ・ｼｽﾃﾑとｼｽﾃﾑ間 妥当性確 析は妥当である 状調査・分析を行う ・保護資産 に分けて脅威分析する の脅威分析結果 認 ・技術と運用の対策に分けて、 対策立案と選択は 洗い出した脅威に対策をたて G-4 妥当である 最適な対策を選択する ・前提条件 る ・基準に基づき、対策を選択 する 対策実施は妥当で ・選択した 実施状況を管理し，対策を G-5 対策を着実に実行する ある 対策 実施する ・対策選択根拠 ・選択対策への 妥当性確 承認結果 認 ・残存リスク ・実施結果 妥当性確 認 結果の評価は妥当 基準に基づき、結果を評価す 実施結果を評価し， ・実施状況の評 妥当性確 G-6 である ・実施結果 る 次の改善につなげる 価結果 認 グループ演習 ？ 参考文献 1)独立行政法人情報処理推進機構：つながる世界のセーフティ＆セキュリティ設計入門ーIoT時代のシステム 開発『見える化』,IPA(2015） 2）金子朋子,山本修一郎,田中英彦,アクタ関係表に基づくセキュリティ要求分析手法（SARM）を用いたスパ イラルレビューの提案，情報処理学会論文誌（ジャーナル）Vol.52 No.9（2011） 3)田渕治樹：国際規格による情報セキュリティの保証手法,日科技連（2007） 4)セキュリティ評価基準（CC/CEM)：http://www.ipa.go.jp/security/jisec/cc/index.html 5) 政府機関の情報セキュリティ対策のための統一基準（平成26年度版）, http://www.nisc.go.jp/active/general/kijun26.html 6) IT製品の調達におけるセキュリティ要件リスト， http://www.meti.go.jp/press/2014/05/20140519003/20140519003.html 7)金子朋子，山本修一郎，田中英彦：CC-Case―コモンクライテリア準拠のアシュアランスケースによるセキュ リティ要求分析・保証の統合手法, 情報処理学会論文誌(ジャーナル)Vol.55No.9（2014） 8) Kaneko,T.,Yamamoto, S. and Tanaka, H.: CC-Case as an Integrated Method of Security Analysis and Assurance over Life-cycle Process, IJCSDF 3(1): 49-62 Society of Digital Information and Wireless Communications, 2014 (ISSN:2305-0012) 9)金子朋子，村田松寿：セキュリティ基準コモンクライテリアが変わる-ユーザもベンダも乗り遅れるな！, 情報処 理学会デジタルプラクティス．Vol6 No.1（2015) 10)非機能要求の見える化と確認の手段を実現する「非機能要求グレード」の公開, IPA,https://www.ipa.go.jp/sec/softwareengineering/reports/20100416.html 11)金子朋子,より安全なシステム構築のために～CC-Case_iによるセキュリティ要件の見える化,日本セキュリ ティ・マネジメント学会2016：JNSA15周年記念論文 学術部門優秀賞受賞論文 12)金子朋子,髙橋雄志,勅使河原可海, 田中英彦,CC-Caseを用いたIoTセキュリティ認証方法の提 45 案,CSEC研究会論文,2016
© Copyright 2024 Paperzz
