講演資料

第13回クリティカルソフトウェアワークショップ
チュートリアル
つながる世界のセキュリティ
2016/1/20
情報セキュリティ大学院大学
大久保隆夫
概要
IoTで実現される「つながる世界」のセキュリティとは
 セキュアなシステム開発のライフサイクル
 ソフトウェアセキュリティの方法論
 IoTへの適用
 つながるセキュリティ事故事例
 IT系のセキュリティとIoTセキュリティの相違
 IoTに対する脅威
 対策
 IoTにおける対策
第13回クリティカルソフトウェアワークショップ
2
セキュアなシステム開発のライフサイ
クル
第13回クリティカルソフトウェアワークショップ
3
セキュリティ開発
ライフサイクル
Blackbox
ファジング
モデル検査
ミスユースケース
要求策定
要求検証
脅威分析
FTA
ゴール指向
脅威モデリング
アーキテクチャ
設計
アーキテクチャ
設計検証
セキュアプログラミング
コーディング規約
詳細設計
セキュリティパターン
モデル駆動開発
実装
実装検証
詳細設計
検証
静的解析
モデル検査
機能テスト
静的解析
モデル検査
第13回クリティカルソフトウェアワークショップ
4
セキュリティ要求は
アーキテクチャ依存
ネットでやらなければ通信盗聴はない
Webでやらなければクロスサイトスクリプティ
ングもない
データベース使わなければSQLインジェク
ションもない
じゃ、要求分析で、どれだけ脅威が出せる
の？または対策が定義できるの？
第13回クリティカルソフトウェアワークショップ
5
B.NuseibeghのTwin
Peaksモデル
 要求仕様とアーキテクチャを交互に詳細化する
 概念的なモデル
第13回クリティカルソフトウェアワークショップ
6
セキュリティ要求分析
技術
故障木分析(FTA)
FMEA
ゴール指向(KAOS)の応用
エージェント指向の応用
UMLの応用
ミスユースケース
第13回クリティカルソフトウェアワークショップ
7
故障木分析
Fault Tree Analysis (FTA)
故障木を使って脅威の分析を行う
故障(脅威)が起こる原因をOR/AND の観点
により詳細化
障害が起きる脅威
⇒脅威を防ぐ対策を定め、セキュリティ要求
仕様として定義
第13回クリティカルソフトウェアワークショップ
8
FTAをセキュリティに用
いる場合の問題点
故障率
物理事象、ヒューマンエラーは確率の数値化
可能
攻撃者が人為的に操作できる場合、故障の
確率は算出可能？
多重故障を本来より高い確率で可能になる
危険
第13回クリティカルソフトウェアワークショップ
9
Attack tree分析
attack treeも基本的にはFTAやゴール指向、
後述の脅威木と同じ
トップレベルのアタックから細分化する
第13回クリティカルソフトウェアワークショップ
10
UMLの拡張：
ミスユースケース
 2000年、Sindre,Opdahlが提案
 UMLユースケース図の拡張
 ミスユーザ：意図しないことをするアクタ
 ミスユースケース：意図しない挙動(脅威)
※必ずしも、悪意があるとは限らない
 対策：ユースケースで表記
 脅威とその関係者、対策の関係が明確
 書き方(脅威抽出)の方法を記述するものではない
 何に対する脅威かが明確ではない
第13回クリティカルソフトウェアワークショップ
11
ユースケース図
第13回クリティカルソフトウェアワークショップ
12
ミスユースケース図
第13回クリティカルソフトウェアワークショップ
13
各手法の浸透度
ヨーロッパでは、ゴール指向、i*、一部では
Problem Frameがよく使われる
ミスユースケースも、欧米を中心に浸透
前述のBSIMMでも用いられる
国内のITシステム開発現場では、
あまり聞かない
一部でFTA等が使われる
第13回クリティカルソフトウェアワークショップ
14
各分析手法の教育
国立情報学研究所トップエスイー
トップSEを対象とした教育の中の「安全要求
分析」の中で、各手法を紹介している
ミスユースケース
ゴール指向(KAOS)
エージェント指向l(i*、Secure Tropos)
FTA、FMEA、HAZOP
CC
http://www.topse.jp/syllabus/09/html/sre_12014.htm
第13回クリティカルソフトウェアワークショップ
15
私見
脅威の識別、詳細化、対策方針策定とその
共有では、手法を分けた方がいいように思え
る
脅威の識別
ミスユースケース、I*
脅威の詳細化
FTA、FMEA、HAZOP、ゴール指向、脅威木
対策方針策定と共有
ミスユースケース
第13回クリティカルソフトウェアワークショップ
16
セキュリティ設計技術
第13回クリティカルソフトウェアワークショップ
17
設計に必要なこと
要求仕様通りに設計
要求仕様通りに設計できているかの確認
セキュリティ脆弱性が生じにくい設計
第13回クリティカルソフトウェアワークショップ
18
課題
 要求仕様通りに設計⇒困難!
 どうやって確認する？
 要求仕様通りに設計できているかの確認⇒困難!
 設計の結果新たにセキュリティ脅威が発生
 設計仕様やシステム構成の要求仕様との相違の検出？
 セキュリティ脆弱性が生じにくい設計⇒困難!
 脆弱性を未然に予測？
その他
 標準化したモデルや設計標準が存在しない
第13回クリティカルソフトウェアワークショップ
19
セキュリティ設計のため
の技術
脅威分析手法
要求仕様通りに設計できているかの確認
設計の結果生じる新たなセキュリティ脅威の発見
設計手法
要求を満たす具体的な設計手法
検証手法
設計仕様が要求仕様を満たしているかを検証す
る手法
第13回クリティカルソフトウェアワークショップ
20
脅威分析
対策を明らかにするために必要な作業
守るべきもの(資産)は何か
資産に対してどのような脅威があるか
脅威によりどのようなリスクが発生するか
リスクに対してどのような対策をすれば目標を達
成できるか
21
【ご参考】
脅威分析研究会
脅威分析手法の勉強、共有を目的として
2015年に立ち上げ
2016/1/12に第1回を開催(参加者:36名)
脅威分析チュートリアル
ツールの紹介
企業における脅威分析の紹介
Web:(参加希望は下記参照)
https://sites.google.com/site/sigstaweb/
第13回クリティカルソフトウェアワークショップ
22
脅威モデリング
Microsoftが提案
現在はSecure Development Lifecycleに組
み込まれている
参考書
 M.ハワード et al. Writing Secure Code第2版上, 日経
BP社, 2004.
ISBN-10: 4891004460
 A.SHostack. Threat Modeling: Designing for Security,
Wiley, 2014.
ISBN-10: 1118809998
23
脅威モデリング(2)
設計したシステムにおける脅威分析(脅威の
抽出、評価)を行う手法
Data Flow Diagram(DFD)を用いた脅威
抽出
STRIDEによる脅威分類
脅威ツリー、DREADによる脅威評価
24
脅威分析の手順
1.
2.
3.
4.
5.
資産の識別
セキュリティ目標の設定
脅威の識別
脅威の評価
対策設計
第13回クリティカルソフトウェアワークショップ
25
例:オンラインバンク
インターネット経由で口座所有者が自身の口
座にアクセス
何が脅威？
第13回クリティカルソフトウェアワークショップ
26
脅威の識別(1)
データフロー(データの流れ)を書いてみる
残高情報
ブラウザ
送金
オンライ
ンバンク
第13回クリティカルソフトウェアワークショップ
27
脅威の識別(2)
境界(物理、信頼)を設定する
残高情報
ブラウザ
送金
オンライ
ンバンク
第13回クリティカルソフトウェアワークショップ
28
脅威の識別(3)
攻撃ポイントを識別する
残高情報
ブラウザ
送金
オンライ
ンバンク
第13回クリティカルソフトウェアワークショップ
29
脅威の識別(4)
攻撃ポイントで起きる脅威を考える
漏洩？
残高情報
ブラウザ
送金
オンライン
バンク
改ざん？
第13回クリティカルソフトウェアワークショップ
30
脅威分類
脅威を識別するための参考分類
STRIDE
Spoofing(なりすまし)
Tampering(改竄)
Repudiation(否認)
Information disclosure(情報の漏洩)
Denial of service (DoS攻撃)
Elevation of privilege(権限昇格)
第13回クリティカルソフトウェアワークショップ
31
脅威評価(1)
脅威の細分化:具体的条件、攻撃手段の検証
脅威木/アタックツリー/故障木
第13回クリティカルソフトウェアワークショップ
32
脅威木
なりすまし
される
ID、パスワー
ドが盗まれる
AND
IDが盗まれる
パスワードを
推測される
パスワードが
盗まれる
パスワード盗
聴
総当たり
第13回クリティカルソフトウェアワークショップ
33
脅威評価(3)
脅威の影響を評価
DREAD:評価のための指標
Damage potential(潜在的な損害)
Reproductivity(再現可能性)
Exploitability(攻撃利用可能性)
Affected users(影響ユーザ)
Discoverability(発見可能性)
第13回クリティカルソフトウェアワークショップ
34
セキュリティテスト技術
第13回クリティカルソフトウェアワークショップ
35
ファジング
(fuzzing)(1)
ソフトウエアのバグを発見するテクニック
ブラックボックステストの一種
エラーになりそうなデータを生成し、大量、自
動入力によりテストする
⇒いかに、「エラーになりそうな」データを作れ
るかがポイント
基本的には、「見つかればラッキー」というテ
スト
第13回クリティカルソフトウェアワークショップ
36
ファジング
(fuzzing)(2)
 ツール(有償)
 Codenomicon Defensics
http://www.toyo.co.jp/it/codenomicon/
 FFR Raven
http://www.ffri.jp/products/raven/
 制御、組み込みへの対応
 IPAが情報家電や自動車をターゲットにしたファジングテ
ストに使われるデータについて解説
http://www.ipa.go.jp/files/000035160.pdf
 ツールの一部では、制御系のSCADA対応を謳っている
 車載等にも広げたいもくろみは各社あるようだ
 参考:脆弱性対策：ファジング(IPA)
http://www.ipa.go.jp/security/vuln/fuzzing.html
第13回クリティカルソフトウェアワークショップ
37
IOTセキュリティにおける課題
第13回クリティカルソフトウェアワークショップ
38
課題
安全性とセキュリティの問題
IoT機器特有の問題
認証
処理能力
ファームウェア更新
第13回クリティカルソフトウェアワークショップ
39
安全性(セーフティ)
とセキュリティ
セキュリティで安全性をカバーできるか
セキュリティ分析の能力
安全性重視の解析ではない
IT系との相違
セキュアブート？
車載には「off」の瞬間がない
スペック上の制約(帯域、メモリ、コスト…)
第13回クリティカルソフトウェアワークショップ
40
クルマが「安全」とは？
衝突安全
自動ブレーキ
位置情報を盗
まれない
ナビ情報を
改竄されない
ブレーキ踏ん
でないと
発進しない
第13回クリティカルソフトウェアワークショップ
41
衝突安全
位置情報を盗
まれない
自動ブレーキ
セーフティ
ブレーキ踏ん
でないと
発進しない
セキュリティ
ナビ情報を
改竄されない
第13回クリティカルソフトウェアワークショップ
42
セーフティ
本質安全(Inherent Safety)
根源からリスクをなくして達成される安全
機能安全(Functional Safety)
機能による安全
機能を導入し、許容できるレベルの安全を確保す
る
機能の安全
機能が故障しない、あるいは壊れても安全を確
保できる
第13回クリティカルソフトウェアワークショップ
43
(情報)セキュリティ
「情報資産」が中心
個人情報、機密情報
情報セキュリティのCIA
機密性、完全性、可用性
CIAに対する脅威
盗聴、改竄、DoS攻撃…
第13回クリティカルソフトウェアワークショップ
44
「情報セキュリティ」に足
りないもの
物理的安全（特に人命）を資産として考える
人命に対する脅威を最優先
コンプライアンス：製造物責任法(PL法）
第13回クリティカルソフトウェアワークショップ
45
「セーフティ」に足りない
もの
 「悪意」「故意」という観点
⇒多重故障、フェールセーフでは守れない？
 情報資産に対する脅威がもたらすもの
 安全性優先の結果、それ以外の脅威が軽視される可能性
最終的にエンジン停止すれば安全確保できる
⇒でも、攻撃により頻繁に停止してしまったら？
 安全性の基盤であるソフトウェアの置きかえ
⇒前提が崩れないか？
来るべき信号が来ないことへの対応⇒〇
偽の信号が来たら⇒？
 安全性の最後の責任を人に帰着する
異常があったら警告灯表示
⇒では、改ざんにより警告灯が出ないようにされたら？
第13回クリティカルソフトウェアワークショップ
46
認証の必要性
すべてがインターネットにつながることによる
危険
見知らぬ機器からの攻撃
踏み台にされ、他の機器に攻撃
情報漏えい
本来なら、信頼できない機器からの(への)通
信は遮断したい
第13回クリティカルソフトウェアワークショップ
47
認証における問題
人が人を認証するのでない、機器間認証が
ほとんど
⇒誰のか分からないのに、認証できる？
実装(性能)上の制約、コスト
第13回クリティカルソフトウェアワークショップ
48
SSL/TLS(1)
Secure Socket Layer
Transport Layer Security
 インターネット上で通信を暗号化、送受信す
るプロトコル
暗号化通信する上で、重要なこととは？
暗号通信を第三者に解読されない
SSL/TLSでは、AESなどが利用可能
他には…？
第13回クリティカルソフトウェアワークショップ
49
SSL/TLS(2)
⇒相手が信頼できる(なりすましでない)か確
認する！
信頼のおけない相手に暗号化で送っても無
意味
SSL/TLSでは、事前に共通鍵の交換を行っ
た上で、その鍵を用いて暗号化する
↑の前に、相手が正しい相手か確認が必要
⇒認証手続き(ハンドシェイク)
第13回クリティカルソフトウェアワークショップ
50
SSLにおける証明書
サーバ/クライアントが正当であることを証明
するもの
受け取った側が、証明書を検証する
証明書が正当かどうかは、認証局(CA)が保
証してくれる
第13回クリティカルソフトウェアワークショップ
51
IoTで
SSL/TLSは？
SSL/TLS証明書は、発行者から購入するも
の
数千円/年〜
自己発行証明書で運用してもよいが、第三者は
認証できない
メモリ、ハードウェア、性能…
証明書を置くメモリ
証明書を安全に保管するしくみ
暗号、検証のためのメモリと性能
第13回クリティカルソフトウェアワークショップ
52
メッセージ認証コード
(MAC)
メッセージが正しい(正当な相手先からのもの
である)ことを確認するためのもの
電子署名と似ているが、MACの場合は生成
と検証には共通鍵が用いられる
安全性の典拠⇒暗号アルゴリズムの安全性
第13回クリティカルソフトウェアワークショップ
53
組み込みでMACは？
 車載などの閉じたシステム内であれば可能
 ECU置き換え、なりすまし対応
 暗号化は？
 組み込み機器向け暗号ライブラリが提供
三菱電機etc
http://www.mitsubishielectric.co.jp/corporate/randd/information_t
echnology/security/core/core02_b.html
 通信帯域は？
 CAN:64bit
 AES:128bit
 チップのコスト
第13回クリティカルソフトウェアワークショップ
54
家庭やSOHO向けルータの多
数に深刻なセキュリティ問題
米セキュリティコンサルタントIndependent
Security Evaluators（ISE）が指摘
ルータ13台についてテストした結果、13台と
もローカルネットワーク経由で制御される恐
れのあることが判明
11台にはリモートからの制御に利用可能な重
大な脆弱性が見つかった
第13回クリティカルソフトウェアワークショップ
55
家庭やSOHO向けルータの多
数に深刻なセキュリティ問題
問題を悪用された場合
リモートの攻撃者にルータの設定を完全にコント
ロール
ネットワークトラフィックの傍受や改ざん
ITmediaエンタープライズ
http://www.itmedia.co.jp/enterprise/articles/1304/19/news040.html
第13回クリティカルソフトウェアワークショップ
56
ファームウェア更新の
問題
ファームウェアが更新されない
自動的に更新されない限り、家庭用機器の更新
は利用者に期待できない(家電と同じ感覚≠PC)
強制的に更新させるしかない
ネットに接続していないと更新が困難
脆弱性発覚⇒どうやって通知する？
利用者登録してなければ、直接通知は困難
販売終了製品でも、提供し続けなければなら
ない
第13回クリティカルソフトウェアワークショップ
57
IOTにおけるセキュリティ対策
第13回クリティカルソフトウェアワークショップ
58
知財保護
回路では、基盤ごと複製されると、偽物で商
売されてしまう
(せっかくコストかけて開発して、特許出して
作った技術が…)
回路ごと複製されないための防止技術
PUF(Physical Unclonable Function)
第13回クリティカルソフトウェアワークショップ
59
PUF
LSIの個体によって異なる電子回路のわずか
な差異を利用し、その回路の「指紋」を作る
不純物の状態によるトランジスタ特性の差異
デジタル回路の0と1が変わるタイミング」の差異
を利用(Glitch PUF(三菱電機))
SRAMに電源を入れた直後の初期値の差異
指紋は偽造困難
登録された指紋以外のもの
第13回クリティカルソフトウェアワークショップ
60
PUFの応用:IoT暗号
前述の「指紋」を使い、固有の暗号鍵を生成
その個体でしか、暗号復号できなくなる
前述の不正な回路複製等への対応が可能
第13回クリティカルソフトウェアワークショップ
61
まとめ
第13回クリティカルソフトウェアワークショップ
62
最後に
システム開発ライフサイクルに沿って、セキュ
リティ品質確保を行うための手法、技術につ
いて事例とともに紹介
IoTに適用する場合ではそのままではうまくい
かず、変化や一部適用となる場合も
第13回クリティカルソフトウェアワークショップ
63
つながる世界の開発指針（IPA）
IoTを構成するコンポーネント（自動車、家電、ヘルスケア機器、製造機器等）
が何とつながっても安全安心を保てるような設計を推進。
現時点の開発指針（案）
大項目
IoTコンポーネントへの脅威
攻撃
物理的接触
⑤物理的接触
本来機能
メンテナ
ンス用I/F
(サーバ､GW､
アクチュエータ等)
攻撃
通常I/F
異常や
ウイルス
IoT機能
(通信､連携､集約等)
攻撃
データ
その他
（内部犯行等）
(商品､現金､部品等)
非正規I/F
内包リスク
攻撃
つながる世界指針1 安全安心の基本方針を策定する
方の安全安心に
針企業として取り指針2 安全安心のための体制・人材を見直す
組む
指針3 内部不正や情報漏えいに備える
指針4 つながる世界で守るべきものを特定する
つながる世界
指針5 つながることによるリスクを想定する
分
析のリスクを認識指針6 つながりで拡大するリスクを想定する
する
指針7 物理的なリスクを認識する
指針8 個々でも全体でも守れる設計をする
守るべきものを指針9 つながる相手に迷惑かけない設計をする
設守る設計を考指針10 安全安心を実現する設計の整合性をとる
計える
指針11 知らない相手でも安全安心につなげられる
設計をする
指針12 安全安心を実現する設計の評価・検証を行う
市場に出た後指針13 自身がどのような状態かを把握し、記録する
保
守も守る設計を
指針14 時間が経っても安全安心を維持する
考える
運関係者と一緒
用に守る
Copyright © 2015 IPA, All Rights Reserved
開発指針（案）
指針15 最新のIoTリスクを把握し、情報共有する
指針16 各ライフサイクルの関係者と協力し、安全
安心を維持する
指針17 ユーザにつながることによるリスクを伝える
Software Reliability Enhancement Center
64
http://www.iisec.ac.jp
第13回クリティカルソフトウェアワークショップ
65

Download Report