セキュリティ・バイ・デザインとIoT時代の脅威分析の意義

情報セキュリティ大学院大学

大久保 隆夫

セキュリティ・バイ・デザインとは

ソフトウェアやシステム開発の過程程で開発の早期段階(分析、設計)からセキュリティを作りこむ

対義語？ セキュアプログラミングプログラミング工程での脆弱性排除

2

Security by DesignPrinciples(OWASP) https://www.owasp.org/index.php/Security_by_Design_P

rinciples アーキテクト、ソリューションプロバイダがセキュアなアプリ

ケーションを設計から構築するためのガイダンス 資産の整理

攻撃者に対する知識

情報セキュリティの基本概念(CIA(機密性/完全性/可用性)) セキュリティアーキテクチャ

通常利用と異常時の双方に対応

セキュリティの原則アタックサーフェスの最小化/デフォルトセキュア/最小特権/多層防御/セキュアなエラー処理/サービスを信用しない/職掌分離/security by obscurityの回避/できるだけシンプルな実現/セキュリティ問題の適切な対処

3

セキュリティ・バイ・デザインの必要性(1)

ソフトウェア、システム開発における一般的法則問題解決が後工程になるほど、解決コストが急激に増大

プログラミングやテストで見つかった問題を修正するのには、費用、工数がかかる場合によっては、修正不可能な場合も設計にまで遡らなければならない場合も

要件定義 設計 プログラム開発

結合テスト

受入テスト

運用

相対修正コスト

4

セキュリティ・バイ・デザインの必要性(2)

要件定義 設計 プログラム開発

結合テスト

受入テスト

運用

相対修正コスト

早ければ早いセキュリティ対策ほどコストがかからない！

5

セキュリティ・バイ・デザインの困難さ

必要なこと要求仕様、設計仕様へのセキュリティの組み込み

従来の分析、設計ではなぜ難しいか？

要求:他の要求との違い(難しさ) 要求策定者、利害関係者(ステークホルダー)ではない他者(悪意を持つ者)の

要求に基づく

特定の攻撃に対する対策を考慮した要求が必要(になる場合あり) 設計:他の設計との違い(難しさ)

悪意を持つ者=攻撃者がどのような手段(攻撃)で要求を達成するかを把握

適切な対策仕様を設計

上記は、いずれも従来とは異なる知識とその活用手段が必要

6

セキュリティ・バイ・デザインのライフサイクル

検収

システムテスト要求定義

システム設計

プログラム設計

ソフトウェア要求

サブシステム

プログラム

モジュール

要求の提示

結合テスト

単体テスト

プログラミング/デバッグ実装

セキュリティ要求分析

脅威分析

セキュリティ設計

検証

セキュアプログラミング

セキュリティテスト

セキュリティテスト

セキュリティテスト

7

NIST special publication 800-160Systems Security Engineering

システムをセキュアに構築するための技術

ISO/IEC/IEEE 15288に対応Systems and Software Engineering-- System life cycle processesシステム開発のライフサイクルのプロセスを規定

設計問題としてのシステムセキュリティコンピュータシステムを十分にセキュリティの制御ができるかは、システム設計の問題である。

網羅的セキュリティの実現にはハードウェア、ソフトウェア、物理的、人的、管理プロセス的保護が必要である。特に、ソフトウェアによる保護だけでは、十分な対策にはならない。

‐‐ The Ware ReportDefense Science Board Task Force on Computer Security, 1970.

8

ISO/IEC/IEEE 15288のプロセス

9

脅威分析

10

脅威分析とは

対象のソフトウェアやシステムに対する脅威を識別し、その影響を評価し、対策を策定する分析

「脅威」が、第三者の悪意に基づくため、このような(通常の開発にはない)分析が必要

分析工程における脅威分析=論理層対象=セキュリティ要求工学

設計工程における脅威分析=物理層対象

11

セキュリティ要求分析

主なアプローチ

1. 攻撃者のゴールベースの分析攻撃者は何を狙っているか？

2. 被害ベースの分析このシステムで何をされると困るか

3. 資産ベースで分析する守るべき対象を明確にして分析

12

攻撃者の目標(1)

STIX(Structured Threat Information Expression) version 1.2のCampaign(作戦)→Intended Effect(意図)参考情報処理推進機構:脅威情報構造化記述STIX概説https://www.ipa.go.jp/security/vuln/STIX.html※STIX2.0では、Campaign→Objective(目標)https://oasis-open.github.io/cti-documentation/stix/intro

13

攻撃者の目標(2)

優位に立つ

経済的に

軍事的に

政治的に

盗む

知的財産

認証情報

識別情報

アカウントのっとり

信用へのダメージ

競争で優位

サービス品質の劣化

否認、欺瞞

破壊

名誉毀損

暴露

恐喝

詐欺

ハラスメント

制御システムの操作

抜け道

認可されていないアクセス

14

資産の識別

資産の識別

1. ユースケースの作成

2. ユースケースシナリオから資産候補の抽出

3. 資産候補が攻撃者の目標or被害に合致するか検証→資産として抽出

15

資産識別の例(3)

自動ブレーキにおける資産候補

コントローラ

ブレーキ

ブレーキ信号

衝突可能性情報

16

攻撃者の目標とつきあわせ→資産抽出ブレーキ+制御の不正な操作

=危険！

ブレーキは資産として抽出

同時に、「ブレーキに対する不正操作」を脅威として識別

17

更なる脅威抽出

ガイドワードの適用

エンティティへのSTRIDE適用→攻撃者目標を達成するか

なりすまし

エンティティの改ざん

18

ガイドワード候補

STRIDESTAMP/STPAのガイドワード

19

STRIDE

エントリポイントにおいて脅威を発見するための

ヒント、脅威分類

Spoofing(なりすまし)Tampering(改竄)Repudiation(否認) Information disclosure(情報の漏洩)Denial of service (DoS攻撃)Elevation of privilege(権限昇格)

20

STRIDEのガイドワードとしての役割

21

外部エンティティ0 プロセス0データ0

エンティティ(外部エンティ

ティ、プトセス、データストア)に対するガイド

ワード

データフローに対するガイド

ワード

エンティティからの情報漏洩フローからの情報漏洩

STPAのガイドワード

与えられるとハザード

与えられないとハザード

早すぎる/遅すぎるとハザード

長すぎる/短かすぎるとハザード

22

STPAのヒントワード

23

出典:IPA「はじめてのSTAMP/STPA(実践編)」

セーフティ系ガイドワードを脅威分析に活かすには

STPAのガイドワード:攻撃者の目標ないし被害事象に直結

No/More…の原因になるセキュリティ脅威を導出する

ex)改ざん(T)により、Nol(More)情報漏洩系は非対応

STPAのヒントワード:セーフティ寄りで、セキュリティ脅威分析には不向き

24

脅威の詳細化

判明している情報のみで詳細化する

25

ブレーキを不正操作

コントローラののっとり

衝突検知信号の改ざん(なりすまし)

ブレーキ信号のなりすまし

ミスユースケースによる脅威、対策記述

26

運転者

センサー

ブレーキを踏

む

衝突を検知す

る

<<include>>

アクター2

ブレーキに対

する不正操作

不正操作防止

対策

ブレーキ信号

のなりすまし

コントローラ

ののっとり

ユースケース

6

衝突検知信号

の改ざん

改ざん防止対

策

のっとり対策

脅威

対策

論理層のみの分析で十分か通常のソフトウェア開発では、アーキテクチャの選定は設計時に行う

しかし、誤ったアーキテクチャ選択はセキュリティに致命的な(対処不可能な)リスクを生む可能性がある

27

組込み系における開発

28

要求分析

システム設計

ハードウェア設計 ソフトウェア設計

ハードウェア実装 ソフトウェア実装

×

後戻り困難特にH/W系

クリティカルな手戻りの例

29

要求分析

システム設計

ハードウェア設計 ソフトウェア設計

ハードウェア実装 ソフトウェア実装

プロセッサバスの選択

データ保護のためAES暗号化

必要

現行のH/WではAES暗号化性能,

不足

手戻りを防ぐには

要求分析後、設計前にハードウェア、ソフトウェアのアーキテクチャ候補を列挙

それぞれの候補についてリスク評価を行う

CVE、CWEなどの評価を参考

明確な脆弱性がないか

データ保護、アクセス制御などを実現可能か

30

脅威分析

設計段階においては、資産ベースの分析よりも、モデルベースの分析を重視

脅威モデリング

セキュリティ要求を侵害しそうな脅威を識別し、対策する

アーキテクチャ選択時に、想定済の典型的脅威を利用

31

脆弱性分析と脅威分析脆弱性分析=既存のシステムの脆弱性を調べる

脅威分析:通常は原因となる脅威+リスクについて調査

脅威分析は既存のものが対象の場合と、これから開発するものが対象の場合と双方ある

どんな弱みがあるかと、弱みをつくどんな脅威があるかを調べるのは質的に異なる作業

脅威モデリング

Microsoftが考案した脅威分析手法

脅威分析の中では一般に最もよく使われている

設計したシステムにおける脅威分析(脅威の抽出、評価)を行う手法

Data Flow Diagram(DFD)を用いた脅威抽出

STRIDEによる脅威発見

アタックツリー等による脅威のリスク評価

アーキテクチャが明確なとき、脅威抽出の手法としては有効

参考書

[HL04]M.Howard, D.LeBlanc: WRITING SECURE CODE, Microsoft press,2004.

[Swiderski05] Swiderski, F. and Snyder, W. : 脅威モデル ― セキュアなアプリケーション構築, 日経BPソフトプレス (2005).

[Sho14] A.Shostack: Threat Modeling , Wiley (2014).

33

DFD

34

外部エンティティ

データ

境界プロセス

データストア

出典：M.Howard et al: “Writing Secure Code”, Microsoft press

DFD境界の意味データ送受信の相手が信頼できるか？を考える

物理的境界を越えてくるデータは信頼できない

外部エンティティから来るデータは信頼できない

信頼できない相手にデータを送るのは危険

エントリポイント:脅威の起きそうなポイント

境界とデータフローの交点

境界を越えてデータがやりとりされる時に脅威が発生しやすい

信頼できない相手から来たデータ:改ざんされているかも？

信頼できない相手にデータを送る→流出するかも？

35

エントリポイント

36

出典：M.Howard et al: “Writing Secure Code”, Microsoft press

アタックツリー

脅威分析手法の一つ

脅威をTree状に詳細化していく

具体的な攻撃手段とその可能性を明確化

⇒対策の糸口

原典 [SCH99] B. Schneier, “Attack trees: modeling security

threats,” Dr. Dobb’s Journal, December 1999. [MEL01] B A. P. Moore, R. J. Ellison, and R. C. Linger,

“Attack modeling for information security and survivability,” CMU/SEI-2001-TN-001, March 2001.

37

アタックツリー分析の手順上位の攻撃を考える

その攻撃を実現する手段や条件を下位ノードとして接続

下位ノードが独立である場合:線で接続するのみ

下位ノードの組み合わせで上位が実現できる場合:and関係で接続

38

アタックツリー分析の手順

39

金庫を開ける

ピッキングダイアルの組み合わせを知る

金庫を切断 不適切な設置

ダイアルの組み合わせのメモを見つける

持ち主から組み合わせ情報を得る

脅迫 詐欺メール 盗聴 賄賂

会話から聞き取る 持ち主に言わせる

and

リスク評価と対策

アタックツリーの末端ノード(葉)の攻撃が起きうるリスクを考える

攻撃の可能性があるか

攻撃にかかるコストはどのくらいか

リスクの高い(攻撃される可能性が高く、コストも低い)ノードについては対策を考える

40

アタックツリーの例

41

金庫を開ける

ピッキングダイアルの組み合わせを知る

金庫を切断 不適切な設置

ダイアルの組み合わせのメモを見つける

持ち主から組み合わせ情報を得る

脅迫 詐欺メール 盗聴 賄賂

会話から聞き取る 持ち主に言わせる

and

セキュリティとセーフティの統合は IoT、組み込み機器、システム開発時におけるsecurity,safety双方のリスク分析の統合の可能性を模索

security,safety双方の既存のリスク評価手法について調査

Securityでは、発生確率はほとんど用いられないため、そのままでの統合は困難

今後、別の統合手法を検討していく

42

参考:STPA-sec

STPAのセキュリティ拡張

unsafe control actionの他にunsecure control actionを想定し分析

セキュリティとセーフティのより複合的な分析については十分ではない

セキュリティ脅威→セーフティへの影響

セーフティハザード→セキュリティへの影響

43

44

45

脆弱性分析

脅威分析

インパクト分析

ヤング氏の焦点はトップレベル＝防衛

情報セキュリティで対象とするのは脅威分析

46

まとめ

組込み、IoTシステムの安全品質の実現のた

めに必要なセキュリティ・バイ・デザインと脅威分析について紹介

組込みの場合、従来の機能安全的手法に加え、セキュリティも考慮しなければならない

セキュリティ、セーフティ双方の分析にSTPAを用いる可能性について、STPA-secの例を紹介

47