PowerPoint プレゼンテーション

Transcription

1 つながる世界のセキュリティ設計入門 ~ セキュリティ要件の見える化 ~ 情報セキュリティ大学院大学客員研究員金子朋子 1

2 自己紹介 金子朋子博士 ( 情報学 ) 公認情報セキュリティ監査人 (CAIS) 情報セキュリティ大学院大学客員研究員 2013 年情報セキュリティ大学院大学博士後期課程修了. 文部科学省認定プログラム サーティフィケート取得者 ( 情報セキュリティスペシャリスト, ソフトウェアスペシャリスト ) 日本ネットワークセキュリティ協会 (JNSA) 優秀論文賞受賞 (2015 年 )

3 目次 IoT の特徴 IoT セキュリティの現状 課題 安全なシステム ソフトウェアの開発 上流工程でのセキュリティ設計 セキュリティコンセプトの策定 セキュリティ要求分析の特徴 脅威の特定 分析手法 (STRIDE ミスユースケース Attack Tree) 脅威に対するリスクの見積もり及び評価 (FMEA CVSS i*liu 法 SARM) セキュアプログラミング ロジカルな設計品質の説明 ( アシュアランスケース ) アシュアランスケースの表記法 セキュリティ設計の評価 認証 ( コモンクライテリア セキュリティ要件 ) IoT セキュリティ認証に対する CC-Case の特長 3

4 IoT の特徴 IoT: モノのインターネット (Internet of Things) IoT の特徴 : 多様な機器 システムがつながること より複雑なセキュリティ要件をもつことになる 4 4

5 この脅威事例は本当 スマホでATMから現金を引き出 すウイルスでハッキングしたのは 14歳の少年だった か か 5

6 答えは 6

7 14 year olds hack BMO bank. machine; staff doesn't believe 引用 them CCDS 資料より 7

8 IoT セキュリティの現状 IoT システムへの脅威事例は日増しに増加 HDD レコーダーの踏み台化は情報家電に対する初期の攻撃事例 (2004 年 ) 心臓ペースメーカの不正操作 (2013 年 ) Jeep を車載のインフォメーションシステムを経由してインターネットから操作できる研究 (2013 年 ) スマホで ATM から現金を引き出すウイルス (2014 年 ) Black Hat HW/ 組込み,IoT, スマートグリッド / インダストリ IoT 関連テーマがカテゴリに登場 IoT ハッキング技術を身につけ, 実践をはじめるハッカーが増加 8

9 IoT セキュリティの課題 業界, 製品 システムごとに要件が異なるため, セキュリティの対応レベルが異なり, 標準化の動向も異なっている 対象が情報だけでなく, 実体を伴うモノになるため. 与える被害も致命的であり, 攻撃の被害は甚大にならざるを得ない IoT セキュリティの確保は重大事 IoT セキュリティの対象となる機器やシステムに対する脅威には盗聴や不正アクセスによる情報漏えいやプライバシー侵害, データやソフトウェア改ざんによる誤動作や予期せぬ停止など, 様々なものが想定される 事故の発生や顧客の信頼失墜, 機器交換 システム改修コストなど多大な損害も懸念 IoTのセキュリティを確保するための技術や手法, 標準, 基準はまだ確立されていない ( 脅威となる対象の洗い出し 目標を設定するセキュリティ要求分析手法 リスク評価の手法, 要件を可視化する技術が必要 ) 9

10 安全なシステム ソフトウェアの開発 より巧妙化する脅威に対して より安全なソフトウェアを開発する にはどうしたらよいか 開発者に対する教育と訓練 解決方法 経験の伝達 プロジェクト管理の徹底 運用管理の向上 セキュリティ方針の厳密化 開発方法論 プロセス セキュリティ by デザイン システム内ソフトウェアの中に脅威への対抗手段を含める 10 ことがより根本的な対策になりうるから

11 セーフティよりセキュリティの方が重要である か か? 11

12 答えは 12

13 セーフティとセキュリティは両輪の輪!! どちらも大事です ただし要件が相反することもある ので注意が必要です 13

14 上流工程でのセキュリティ設計 上流の段階におけるセキュリティ設計の手法がセーフティ設計と比較 して普及していない セーフティとセキュリティの設計プロセス Ｖ字開発モデル セーフティとセキュリティの コンセプトの策定及び周知 リスク分析 評価及びリスク低減策検討 セーフティとセキュリティの要件定義 セーフティとセキュリティの設計 アーキテクチャ設計 セーフティとセキュリティの設計 ソフトウェア設計 信頼性の高いソフトウェアの実装 システム化の方向性 システム化計画 評価 要件定義 システム設計 ソフトウェア設計 運用 評価 検証 運用テスト 検証 システムテスト 検証 ソフトウェア テスト プログラミング 運用段階で脆弱性が発見されると機器の交換 システムの改修が必要となるため 設計 開発段階と比べ 膨大なコストがかかる 上流工程でのセキュリティ対応が重要

15 セキュリティコンセプトの策定 利用者 ( 調達者 ) VS 問題点 開発者 ( ベンダー ) 一般の機能要求 スピード ( 早く ) 費用 ( 安く ) 品質 ( 良いものを ) 使いやすく 変換時にギャップ 仕様の固まり具合 利害関係者の合意 IT 技術 方式 スキル 再利用 セキュリティ要求 セキュリティは難しいので任せるが費用がかかるのは困る 特別な要求はないけど 個人情報漏えいは困る 内部統制も一緒に考えてほしい 社内の犯行は想定外 更に大きなギャップ リスクの洗い出しに漏れはないか不明 各工程ごとに何をどこまでやればいいのかわからない 新たな脅威への対処は現行の設計では無理 リスク対策の費用をお客様は負担してくれない セキュリティ機能は非機能要件であり お客様に納得していただき ギャップを埋めるのは難しい 15

16 セキュリティ要求分析の特徴 セキュリティ特有の課題 : 攻撃者の存在 攻撃 : 脅威を意図的に実現する手段 一般的な要求分析 : ステークホルダ ( 利害関係者 ) の意図をシステムにより実現するのが目的 攻撃者の意図に対しては 逆に妨害することが目的 セキュリティ要求分析 : 顧客は要求に基づく機能要件の分析に加えて攻撃者の存在を考慮した非機能要件の分析を必要とする. そこでセキュリティ要求はアセットに対する脅威とその対策の記述が必須となる 16

17 セキュリティ要求分析プロセス どのような脅威が想定されるかを洗い出し 各々の脅威に対して適切な対策方針を検討する 1. 分析範囲の決定 2. 関係者の決定 3. 保護すべき資産の抽出 4. 前提条件の検討 5. 脅威の洗い出し 6. 対策方針の検討 脅威の特定 分析手法 STRIDE ミスユースケース Attack Tree 脅威に対するリスクの見積もり及び評価 ハザード分析手法を利用したリスク評価 CVSS i*(liu 法 ) SARM

18 脅威の特定 分析手法 (1) STRIDE: マイクロソフトが定義する脅威モデル アプリケーションに対するセキュリティ上の脅威の分類名の頭文字から成る語 アプリケーションの脆弱性や未知の攻撃のタイプを理解するために脅威を 6 つのカテゴリに分類 S Spoofing identity なりすまし コンピュータに対し 他のユーザーを装うこと なりすましにより 攻撃者は不法にアクセスを行い ユーザー名やパスワードなど 他のユーザーの認証情報を使用する T Tampering 改ざん データを意図的に操作すること データベースに保持されている永続データを承認を受けずに変更し たり インターネットなどのオープンなネットワークを介してコンピュータ間で伝送されるデータを改ざん することなど R Repudiation 否認 ユーザーがあるアクションを行ったこと否認し 相手はこのアクションを証明する方法がないこと 禁止 された操作をトレースする能力がないシステムで ユーザーが不法な操作を行うことなど I Information Disclosure 情報の暴露 アクセス権限を持たない個人に情報が公開されること アクセスを許可されていないファイルを読むことができたり 侵入者がコンピュータ間で伝送されているデータを読むことができる場合など D Denial of Service サービス不能 攻撃により正規のユーザーへのサービスが中断される Web サーバーを一時的に使用できない状態にするなどが DoS 攻撃 E Elevation of Privilege 権限の昇格 権限のないユーザーがアクセス権限を得ること システム全体を使用不可にしたり 破壊するために十分なアクセス権限を得ること 18

19 脅威の特定 分析手法 (2) ミスユースケース : ユースケースに攻撃者を追加したミスユースケース図を作成し 攻撃者が対象の機器やシステムに対して攻撃する目的や得ようとする利益を想定することで 脅威を特定する手法 19

20 脅威の特定 分析手法 (3) Attack Tree: 攻撃者のゴールを設定し ゴールに至る攻撃手順をツリー上に展開することで脅威分析を行う手法 攻撃者の目標 ( ゴール ) 攻撃者の手順にそって上からツリーを記述 手法 1 手法 2 手法 3 最初の手順 手法 2-1 手法 2-2 次の手順 手法 その次の手順 20

21 脅威に対するリスクの見積もり及び評価 (1) ハザード分析手法を利用したリスク評価 : FTA FMEA HAZOP などのセーフティ手法の利用 金融証券会社のシステム Potential Failure Mode and Effects Analysis (Design FMEA) Key Date 2008/10/26 潜在的故障モード 口座登録情報の漏えい 口座登録情報の漏えい 潜在的故障影響 S e v 潜在的故障原因 メカニズム 不正アクセスの発生 4 保護されていないデータパケットは途 中で傍聴されて変更される 不正アクセスの発生 4 保護されていないデータパケットは途 中で傍聴されて変更される 注文情報の改竄 誤った注文による損失 6 保護されていないデータパケットは途 中で傍聴されて変更される なりすましによる誤注文 仲買人 管理人への権限昇格 商品注文への否認 システムへの Dos 攻撃等 悪意の攻撃者がパスワードを盗用して ユーザーになりすます アプリケーションやデータの中でユーザがアクセスできない部分への特権アクセスをユーザが取得してしまう ユーザが商品注文を否認し 利益が下がる正当なサービス要求を処理できなくなるほど大量のトラフィックをシステム上に発生させる 8 ユーザの認証シーケンスを盗用したり 再現することで なりすまし攻撃を行う 8 攻撃者がバッファオーバフローの脆弱性等を利用してアプリケーションと同じセキュリティコンテキストで有害なコードを実行する可能性がある P r o b 現在の設計 工程管理予防 検出 4 重要なデータの保護 保護したデータの安全な伝送 4 重要なデータの保護 保護したデータの安全な伝送 4 重要なデータの保護 保護したデータの安全な伝送 D e t R P N 推奨処置 ハッシュとデジタル署名を使用して暗号化する 2SSL/TLS やIPsecなどの安全なエンドツーエンドプロトコルの使用 ハッシュとデジタル署名を使用して暗号化する 2SSL/TLS やIPsecなどの安全なエンドツーエンドプロトコルの使用 ハッシュとデジタル署名を使用して暗号化する 2SSL/TLS やIPsecなどの安全なエンドツーエンドプロトコルの使用 8 強力な認証手段を使用すること kerberos 認証やクライアント認証証明 書の使用 6 アプリケーションはできる限り低いセキュリティコンテキストで動作するようにしておく必要がある バッファオーバーフローが発生するのを防ぐ 6 ユーザが注文した商品を否認することで 虚偽に利益を得ようとする 4 権限のないユーザに今後は行わせたくない行動を記録しておく 4 96 デジタル署名とタイムスタンプの使用 10 TCP/IP プロトコルの欠点を利用し 8 DoS 攻撃は撃退することが困難 ファイアウォールを使用してパケットの たり オペレーティングシステムにお なだけでなく 予測することさえ困 フィルタ処理を行い 正当なパケットと ける TCP/IP の実装のバグを突い 難 更にDoS 攻撃は簡単に実行 有害なパケットを分離する たりする方法を取る 可能 21

22 脅威に対するリスクの見積もり及び評価 (2) CVSS(Common Vulnerability Scoring System): 共通脆弱性評価システム CVSS は 情報システムの脆弱性に対するオープンで汎用的な評価手法 ベンダーに依存しない共通の評価方法を提供 CVSS を用いると 脆弱性の深刻度を同一の基準の下で定量的に比較できる ベンダー セキュリティ専門家 管理者 ユーザ等の間で 脆弱性に関して共通の言葉で議論できる CVSSv2 は 攻撃対象となるホストやシステムにおいての 脆弱性による深刻度 を評価 CVSSv3 では 仮想化やサンドボックス化などが進んできていることから コン ポーネント単位で評価する手法を取り込んだ仕様 IPA 資料 CVSS とは? より 22

23 脅威に対するリスクの見積もり及び評価 (3) i*(liu 法 ): ゴール指向要求分析手法のひとつである i*( アイスター ) 手法を拡張したセキュリティ要求分析手法 通常のアクターおよびゴールの特定に加えて 悪意のあるアクターおよびゴールも特定することで セキュリティ攻撃方法と対策を特定する なりすましによる不正注文のi*(LIU 法 ) 23図

24 脅威に対するリスクの見積もり及び評価(4) アクタ関係表に基づくセキュリティ要求分析手法 ＳＡＲＭ : 攻撃と通常のシステム機能との間のセキュリティ上の関係を分析するための要求分析手法 一般者 アクタ を機器に置き換えると 複数機器の相互作用分析に応用可能 一般者のマーク 一般者Ａのゴール 期待としてのゴール 対角要素 ソフトゴール タスク 機能 一般者Ｂの一般者 資源情報 Ａへのゴール 非対 角要素 攻撃者のマーク 攻撃者の期待としてのゴール 攻撃者 悪意 攻撃方法 攻撃者のソフトゴール 脆弱性の特定を行う 攻撃者のタスク 機能 他者に対する攻撃者の 攻撃者の資源情報 タスクを挙げる <論理関係性のマーク 攻撃者に対する対策案 論理積 and の特定を行い ユーザに 論理和(or) 提示する 一般者Ａ 一般者Ｂ 攻撃者C 一般者Ａ Gab, Gac - Iab Ic -- 一般者Ｂ Iba Gba,Gbc Ibc -- 攻撃者Ｃ Ica ++対策 A cb & Gca, Gcb 対策 C & +対策 B 24

25 セキュア プログラミング IPA 資料セキュア プログラミング講座より Web アプリケーションの脆弱性対策にはさまざまなものがあり 実装段階で考慮すれば済むものもあれば 設計の上流段階から考慮したほうがよいものもある

26 ロジカルな設計品質の説明(1) 情報セキュリティと保証② 品質説明力の強化 セキュリティ機能へのお客様の納得 セキュリティ機能の品質説明力の強化 ソフトウェア 目に見えないもの ソフトウェアの品質保証 困難 なぜならばどのような機能をどのように実現して それ がどのような投資効果をもつのかを示す必要がある 情報セキュリティに関する品質保証 より困難 新たな脅威がどのように発生するか予測不可能な ため 目に見えないものであるソフトウェアに対し 理論 的な論理関係と根拠を示すことによって品質説 明力を強化し お客様の納得を得ることでお客 様と合意した内容について保証が必要 理論的な論理関係と根拠を示す アシュアランスケース Assurance Case の保証 26

27 アシュアランスケースの表記法 アシュアランスケースを表記するときに基本ルールを説明します 主張説明主張主張 前提 主張 説明 主張 主張 主張 証拠 証拠 未定義要素 主張 説明 主張 主張 前提 主張 前提 説明 説明 主張 証拠 未定義要素

28 アシュアランスケースの表記法 主張 は 説明 を用いて 下位の 主張 に展開することができます ( 例 ) 主張説明主張主張 木構造を用いてシステムが満たすべき 主張 が最下位の 証拠 と 前提 によって成立することを確認します なお 最下位が 未定義要素 となるときもあります ( 例 ) 前提 主張 証拠 主張説明主張主張証拠未定義要素 矢印は と の 2 種類あります 前提は主張または説明に付与されます ( 例 ) 前提 主張 前提 説明 主張 説明 説明 主張 主張 証拠 主張 未定義要素 参考 : 松野 高井 山本 D-Case 入門 ~ ディペンダビリティ ケースを書いてみよう!~

29 記述基本規則 主張 ( ゴール ) は S + V の形をした 命題である システムはディペンダブルである ゴールは命令であったり挨拶などではない プログラムを実行せよ, こんにちは 説明 ( 戦略 ) はゴールをサブゴールに分割するときの議論の仕方を説明する 識別されたハザードごとに議論する, ライフサイクルフェーズごとに議論する, 証拠は物 ( ドキュメント ) であり 文章ではない 証拠はゴールを最終的に論拠付けるものである テスト結果, 専門家の意見, 運用訓練結果, 前提はシステム運用環境 定義などをゴールまたは戦略を議論する上での前提となる情報 例 : 運用環境 リスクのリスト システム構造 ディペンダビリティ要求リスト, 語彙の定義 前提はそれが付与されたゴールや戦略以下のサブツリー全体にかかる 29

30 アシュアランスケースの表記法 例題 間違った表記について指摘してください 参考 : 松野 高井 山本 D-Case 入門 ~ ディペンダビリティ ケースを書いてみよう!~

31 アシュアランスケースの表記法 ~ 解答 ~ 参考 : 松野 高井 山本 D-Case 入門 ~ ディペンダビリティ ケースを書いてみよう!~

32 アシュアランスケースの表記法 例題 間違った表記について指摘してください 参考 : 松野 高井 山本 D-Case 入門 ~ ディペンダビリティ ケースを書いてみよう!~

33 アシュアランスケースの表記法 ~ 解答 ~ 参考 : 松野 高井 山本 D-Case 入門 ~ ディペンダビリティ ケースを書いてみよう!~

34 アシュアランスケースの表記法 例題 間違った表記について指摘してください 参考 : 松野 高井 山本 D-Case 入門 ~ ディペンダビリティ ケースを書いてみよう!~

35 アシュアランスケースの表記法 ~ 解答 ~ 参考 : 松野 高井 山本 D-Case 入門 ~ ディペンダビリティ ケースを書いてみよう!~

36 アシュアランスケースの表記法 例題 間違った表記について指摘してください 主張と証拠より

37 アシュアランスケースの表記法 ~ 解答 ~ 参考 : 松野 高井 山本 D-Case 入門 ~ ディペンダビリティ ケースを書いてみよう!~

38 セキュリティ設計の評価 認証 (1) 保証 を英語でいうと何? assurance 製品が品質基準に合致しているかを 設計 試作 製造 検査の全ての工程で確認する仕組みがあり それを実行していることを保証する 請合う 自信をもって言うこと warranty 出荷後製品が故障したら, 無料で修理又は取り替えをする事を利用者に対して保証すること guarantee もし保証したことが出来なければ 賠償責任が生じるような保証 38

39 セキュリティ設計の評価 認証(2) 情報セキュリティと保証① 規格準拠 情報セキュリティとは 正当な権限をもつ個人や組織が 情報を適切に管理できる こと 個人情報や機密情報を防露されたり システムの稼働を妨害されたり することがないように 情報を管理する機能=情報セキュリティ機能 セキュリティ機能には以下が要求される 情報セキュリティ機能の確からしさを確保するのがセキュリティ保証 セキュリティ機能が正確に動作し 有効に機能することの保証 確認可能 一般のＩＴ機能 利用者は一般のＩＴ機能については 実際に利 用してみることで保証されていることを確認できる セキュリティ機能 利用者が不測の事態を発生させてセキュリティ機能 が正確かつ有効に動くことを確認することは困難 動作しないことはない 不当な干渉をうけることはない 動作不能に陥ることはない 開発者がセキュリティ保証を 検証しなければならない このセキュリティ保証を確認するのが セキュリティ評価 by第三者 セキュリティ評価の国際規格 コモンクライテリア ＣＣ の保証 39

40 セキュリティ設計の評価 認証 (3) CC パート 1 概説と一般モデルセキュリティ目標 (ST) ST 概説適合性主張セキュリティ課題定義脅威組織のセキュリティ方針前提条件 セキュリティ対策方針 TOE のセキュリティ対策方針運用環境のセキュリティ対策方針 拡張コンポーネント定義 セキュリティ要件セキュリティ機能要件セキュリティ保証要件 セキュリティ要件根拠 セキュリティ対策 コモンクライテリア (CC) とは? CC は IT セキュリティ評価の国際標準 (ISO/IEC15408) 開発者が主張するセキュリティ保証の信頼性に関する評価の枠組みを規定 ST はセキュリティ保証の目標を規定した文書 評価対象のシステムが装備するセキュリティ機能を定義 必須のセキュリティ評価対象 TOE 要約仕様 プロテクションプロフェイル (PP) CC パート 2 機能コンポーネント CCパート3 保証コンポーネント CEM 情報セキュリティ評価方法 CC ハ ート 2 ( セキュリティ機能要件 ) CC ハ ート 3 (EAL 保証要件 ) 40

41 セキュリティレベルの指標 コモンクライテリアにおけるセキュリティ機能の評価保証レベル ＥＡＬ 保証要求内容 想定されるセキュリティ保証レベル EAL1 機能テスト クローズドな環境での運用を前提に安全な利用や運用が保証された場合に用いられる製 品の保証レベル EAL2 構造化テスト 利用者や開発者が限定されており 安全な運用を脅かす重大な脅威が存在しない場合に 用いられる保証レベル EAL3 方式的テスト及びチェッ ク 不特定な利用者が利用できる環境 不正対策が要求される場合に用いられる製品の保 証レベル EAL4 方式的設計 テスト及び レビュー 商用機器やシステムにおいて高度なセキュリティ確保を実現するために セキュリティを考慮し た開発と生産ラインを導入して生産される製品の保証レベル EAL5 準形式的設計及びテス ト 特定の分野の商用製品 システムにおいて 最大限のセキュリティ確保をするためにセキュリ ティの専門家の支援により開発 生産された製品の保証レベル EAL6 準形式検証済み設計及 びテスト 重大なリスクに対応して高い価値のある資産を保護するために 開発環境にセキュリティ工 学技術を適用して開発された特別性の製品の保証レベル EAL7 形式的検証済み設計及 びテスト 非常にリスクが大きい環境や高い開発費用に見合う資産を保護するために開発された製品 の保証レベル

42 コモンクライテリア ＣＣ のIT セキュリティ評価における 相互認証国は１２か国である か か 42

43 答えは (25 か国 ) 43

44 CCRA(Common Criteria Recognition Arrangement) セキュリティ評価における相互認証を実現 CCRA ある国が ISO/IEC15408の認証を与えた製品については 他の国でも同じレベルで通用する主 旨の協定 評価 認証にかかるコストを削減することがねらい 日 本 カナダ イギリス アメリカ オランダ ノルウェー フランス オーストラリア ドイツ ニュージー ランド フィンランド ハンガリー ギリシャ イスラエル オーストリア チェコ パキスタン デンマーク 認証書受入国 8カ国 スウェーデン イタリア 韓 国 トルコ スペイン マレーシア 認証書生成国 17 か国 インド シンガポールは6月19日に加盟 を自主的に取り止め 認証国 : 自国に認証制度を持つ国々 44 認証受入国 : 自国に認証制度を持たない国々

45 CC-Case とは? CC とアシュアランスケースの長所を統合したセキュリティ要求分析手法かつ保証手法 CC-Case の定義 セキュリティ要求分析と保証の統合開発方法論 CC-Case の目的 開発のセキュリティ上の課題を解決するため セキュアなシステム開発への対応を実施すること < 構造 適用対象 > 論理モデルと具体モデルに分類される 適用対象はシステムまたは製品 仕様を決める際に承認を取る特定の顧客がいない場合は要件を決めるうえでの関係者と読み替える. 45

46 IoT セキュリティ認証に対する CC-Case の特長 CC-Case は 3 つの見える化の特長をもつ. 1. 主張の見える化 : ゴールとしての主張とその主張の正しさを裏付ける証跡が存在すること GSN はトップゴールの主張を満たすことを図の最下層に証跡として示すことで可視化する手法だから 2. 論理の見える化 : 前提条件 戦略 ゴールの関係性の明示により, トップの主張から証跡までの論理が明確化されること IoT 対応に際しては当該製品の技術分野に適した PP を利用して当該製品のセキュリティ機能の論理を見える化し, 証跡としてセキュリティ仕様を提示する 3. 保証ストーリーの見える化 : アシュアランスケースの論理モデル ( プロセスと実施事項の明確化 ) による可視化 CC に規定されたセキュリティ保証要件に対応し, セキュリティ機能に対してどのレベルまでの対応が達成できているのかを提示して保証

47 スマートハウスの脅威分析と対策の検討例 スマートハウス 家庭内機器を一元管理することによって 省エネルギーを実現するIoT システム

48 脅威 対策候補 発生箇所脅威名対策名他のガイドとの関係 スマートハウス ( 屋内 ) HEMS コントローラ OTA ウイルス感染脆弱性対策 OTA4,OTA5 アンチウイルス ソフトウェア署名 OTA6 OWASP9 セキュア開発 OTA7 ホームルータ不正アクセス脆弱性対策 OTA5 無線通信 ( 特定小電力 WiSUN Wi-Fi) ユーザ認証 FW 機能 OTA11,OTA12,OTA1 3,OTA14 OWASP OWASP2,OWASP8 OWASP3 DoS 攻撃 DoS 対策 OWASP3 盗聴 改ざん通信路暗号化 OTA1 OWASP8 タブレット端末 不正利用 ユーザ認証 OTA11,OTA12,OTA1 3,OTA14 遠隔ロック ウイルス感染脆弱性対策 OTA4,OTA5 アンチウイルス ソフトウェア署名 OTA6 OWASP9 セキュア開発 OTA7 OWASP2,OWASP8

49 Context: C_1 スマートハウス分野の動向 特徴全体構成図 Goal: G_1 スマートハウスのセキュリティ設計は安全である Strategy: S_1 脅威分析の洗い出しと対策を示す Goal: G_2 スマートハウスの脅威分析は妥当である S_2 スマートハウスの機器ごとに脅威を洗い出す Goal: G_3 スマートハウスの脅威に対する対策立案と選択は妥当である S_3 機器間の通信ごとに脅威を洗い出す G_4 屋内の HEMS コンロトーラの脅威を洗い出せている G_5 屋内のホームルータの脅威を洗い出せている G_6 屋外のタブレット端末の脅威を洗い出せている G_7 屋外のスマートメータの脅威を洗い出せている G_8 ユーザのスマートフォンの脅威を洗い出せている G_9 無線通信 ( 特定小電力 WiSUN Wifi) の脅威を洗い出せている G_10 モバイル通信 (LTE 等 ) の脅威を洗い出せている G_11 クラウドサービスの脅威を洗い出せている E_1 ウイルス感染 E_2 1 不正アクセス 2Dos 攻撃 E_4 1 不正アクセス 2 情報漏えい E_3 1 不正利用 2ウィルス感染 E_5 1 不正利用 2 ウィルス感染 E_6 盗聴改ざん E_7 盗聴改ざん E_8 1 不正アクセス 2Dos 攻撃 3 情報漏えい

50 Goal: G_3 スマートハウスの脅威に対する対策立案と選択は妥当である S_4 対策ごとに分けて論証する S_5 対策選択に合意する S_6 残存リスクを影響分析する G_12 ウイルス感染対策は妥当である G_13 不正アクセス対策は妥当である G_14 Dos 攻撃対策は妥当である G_15 不正利用対策は妥当である G_16 情報漏えい対策は妥当である G_17 盗聴 改ざん対策は妥当である G_18 選択された対策が妥当である G_19 残存リスクが妥当である E_1 脆弱性対策アンチウイルスソフトウェア署名セキュリティ開発の実施方法 E_3 Dos 対策 E_2 の実施方法脆弱性対策ユーザ認証 FW 機能 *IDS/IPS/ サーバセキュリティ ( クラウドサービスの場合 ) の実施方法 E_4 ユーザ認証遠隔ロックの実施方法 E_45 データ暗号化出荷時状態リセットセキュア消去耐タンパ H/W 耐アンパ S/W の実施方法 E_6 通信路暗号化の実施方法 E_7 選択対策への承認結果 E_8 残存リスク一覧

51 Thank you Danke