つながる世界のセキュリティ設計入門 - 情報処理推進機構 ソフトウェア

つながる世界のセキュリティ設計入門
~セキュリティ要件の見える化~
2016.3.23
情報セキュリティ大学院大学客員研究員
金子 朋子
1
目次
•
•
•
•
•
•
•
•
•
•
•
•
•
IoTの特徴
IoTセキュリティの現状・課題
安全なシステム・ソフトウェアの開発
上流工程でのセキュリティ設計
セキュリティコンセプトの策定
セキュリティ要求分析の特徴
脅威の特定・分析手法(STRIDE、ミスユースケース、Attack
Tree)
脅威に対するリスクの見積もり及び評価(FMEA、CVSS、i*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
上流工程でのセキュリティ設計
上流の段階におけるセキュリティ設計の手法がセーフティ設計と比較
して普及していない
セーフティとセキュリティの設計プロセス
セーフティとセキュリティの
コンセプトの策定及び周知
リスク分析、評価及びリスク低減策検討
(セーフティとセキュリティの要件定義)
セーフティとセキュリティの設計
(アーキテクチャ設計)
セーフティとセキュリティの設計
(ソフトウェア設計)
信頼性の高いソフトウェアの実装
V字開発モデル
評価
システム化の方向性・
システム化計画
運用・評価
検証
要件定義
運用テスト
検証
システム設計
検証
ソフトウェア設計
システムテスト
ソフトウェア
テスト
プログラミング
運用段階で脆弱性が発見されると機器の交換、システムの改修が必要となるため、
設計・開発段階と比べ、膨大なコストがかかる。
→上流工程でのセキュリティ対応が重要!!
セキュリティコンセプトの策定
利用者(調達者)
一般の機 ・スピード(早く)
能要求
・費用(安く)
・品質(良いものを)
・使いやすく
セキュリ
ティ要求
VS
問題点
開発者(ベンダー)
変換時に
ギャップ
・仕様の固まり具合
・利害関係者の合意
・IT技術・方式
・スキル・再利用
・セキュリティは難しいので任せる
更に
が費用がかかるのは困る
大きな
・特別な要求はないけど、個人情 ギャップ
報漏えいは困る
・内部統制も一緒に考えてほしい
・社内の犯行は想定外
・リスクの洗い出しに
漏れはないか不明
・各工程ごとに何をどこまで
やればいいのかわからない
・新たな脅威への対処は
現行の設計では無理
・リスク対策の費用を
お客様は負担してくれない
セキュリティ機能は非機能要件であり、
お客様に納得していただき、ギャップを埋めるのは難しい
8
セキュリティ要求分析の特徴
セキュリティ特有の課題:攻撃者の存在
攻撃:脅威を意図的に実現する手段
一般的な要求分析:ステークホルダ(利害関係者)の意
図をシステムにより実現するのが目的
攻撃者の意図に対しては、逆に妨害することが目的
セキュリティ要求分析:顧客は要求に基づく機能要件の分
析に加えて攻撃者の存在を考慮した非機能要件の分析を
必要とする.そこでセキュリティ要求はアセットに対する脅威と
その対策の記述が必須となる
9
脅威の特定・分析手法(1)
STRIDE:
マイクロソフトが定義する脅威モデル。アプリケーションに対するセキュリティ上の脅威の分
類名の頭文字から成る語。アプリケーションの脆弱性や未知の攻撃のタイプを理解するた
めに脅威を 6つのカテゴリに分類
S Spoofing
identity
なりすま
し
コンピュータに対し、他のユーザーを装うこと。なりすましにより、攻撃者は不
法にアクセスを行い、ユーザー名やパスワードなど、他のユーザーの認証情
報を使用する
T Tampering
改ざん
データを意図的に操作すること。データベースに保持されている永続データ
を承認を受けずに変更したり、インターネットなどのオープンなネットワークを
介してコンピュータ間で伝送されるデータを改ざんすることなど
R Repudiation 否認
ユーザーがあるアクションを行ったこと否認し、相手はこのアクションを証明
する方法がないこと。禁止された操作をトレースする能力がないシステムで、
ユーザーが不法な操作を行うことなど
I Information 情報の
Disclosure
暴露
アクセス権限を持たない個人に情報が公開されること。アクセスを許可され
ていないファイルを読むことができたり、侵入者がコンピュータ間で伝送され
ているデータを読むことができる場合など
D Denial of
Service
サービス 攻撃により正規のユーザーへのサービスが中断される。Web サーバーを一
時的に使用できない状態にするなどがDoS攻撃。
不能
E Elevation of 権限の
Privilege
昇格
権限のないユーザーがアクセス権限を得ること。システム全体を使用不可に
したり、破壊するために十分なアクセス権限を得ること。
10
脅威の特定・分析手法(2)
ミスユースケース:
ユースケースに攻撃者を追加したミスユースケース図を作成し、攻撃
者が対象の機器やシステムに対して攻撃する目的や得ようとする利
益を想定することで、脅威を特定する手法
11
脅威の特定・分析手法(2)
Attack Tree:
攻撃者のゴールを設定し、ゴールに至る攻撃手順をツリー上に展開する
ことで脅威分析を行う手法
攻撃者の目
標(ゴール)
手法1
手法2
手法2-1
攻撃者の手順にそって
上からツリーを記述
手法3
最初の手順
次の手順
手法2-2
手法2-2-1
その次の手順
12
脅威に対するリスクの見積もり及び評価(1)
ハザード分析手法を利用したリスク評価:
FTA、FMEA、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
なりすましによる誤
注文
誤った注文による損失
悪意の攻撃者がパスワー
ドを盗用して、ユーザーに
なりすます
仲買人・管理人へ アプリケーションやデータ
の権限昇格
の中でユーザがアクセスで
きない部分への特権アクセ
スをユーザが取得してしま
う
商品注文への否認 ユーザが商品注文を否認
し、利益が下がる
システムへのDos攻 正当なサービス要求を処
撃等
理できなくなるほど大量の
トラフィックをシステム上に
発生させる。
8
ユーザが注文した商品を否認するこ
とで、虚偽に利益を得ようとする。
10 T CP /IP プロトコルの欠点を利用し
6
たり、オペレーティング システムにお
ける T CP /IP の実装のバグを突い
たりする方法を取る
4
8
アプリケーションはできる限り低い 6
セキュリティコンテキストで動作す
るようにしておく必要がある。
R
P
N
推奨処置
64 ①ハッシュとデジタル署名を使用して
暗号化する
②SSL/TLSやIPsecなどの安全な
エンドツーエンドプロトコルの使用
64 ①ハッシュとデジタル署名を使用して
暗号化する
②SSL/TLSやIPsecなどの安全な
エンドツーエンドプロトコルの使用
96 ①ハッシュとデジタル署名を使用して
暗号化する
②SSL/TLSやIPsecなどの安全な
エンドツーエンドプロトコルの使用
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*(LIU法):
ゴール指向要求分析手法のひとつであるi*(アイスター)手法を拡張したセキュリティ
要求分析手法。通常のアクターおよびゴールの特定に加えて、悪意のあるアクター
およびゴールも特定することで、セキュリティ攻撃方法と対策を特定する。
なりすましによる不正注文のi*(LIU法)図
15
脅威に対するリスクの見積もり及び評価(4)
アクタ関係表に基づくセキュリティ要求分析手法(SARM):
SARMとは、攻撃と通常のシステム機能との間のセキュリティ上の関係を分析する
ための要求分析手法
一般者A
一般者B
攻撃者C
一般者A
○Gab,
Gac
◇
□-
☆Iab
◇
□
☆Ic
◇
□ --
一般者B
☆Iba
◇
□
○Gba,Gb ☆Ibc
c
◇
◇
□ -□
攻撃者C
★Ica
◆
→ ++対策
:A
★cb
◆&◆
&◆
|◆
*一般者(アクタ)を機器に置き換えると
複数機器の相互作用分析に応用可能。
<一般者のマーク>
○:期待としてのゴール
☆:ソフトゴール
◇:タスク、機能
□:資源情報
<攻撃者のマーク>
●:攻撃者の期待としての
ゴール
★:攻撃者のソフトゴール
◆:攻撃者のタスク、機能
■:攻撃者の資源情報
<論理関係性のマーク>
&:論理積(and)
|:論理和(or)
一般者Aのゴー
ル(対角要素)
一般者Bの一般者
Aへのゴール(非対
角要素)
攻撃者、悪意、攻撃方
法、脆弱性の特定を行う
他者に対する攻撃者の
タスクを挙げる
攻撃者に対する対策案
の特定を行い、ユーザに
提示する
→ +対策:
B
● Gca,
Gcb
◆
→対策
:C 16
*【参考1】に詳細を示す。
セキュア・プログラミング
Webアプリケーションの脆弱性対策にはさまざまなものがあり、実装段階で考慮すれば済むもの
もあれば、設計の上流段階から考慮したほうがよいものもある。
IPA資料セキュア・プログラミング講座より
セキュリティレベルの指標
コモンクライテリアにおけるセキュリティ機能の評価保証レベル:
EAL(保証要求内容) 想定されるセキュリティ保証レベル
EAL1(機能テスト)
クローズドな環境での運用を前提に安全な利用や運用が保証された
場合に用いられる製品の保証レベル
EAL2(構造化テスト)
利用者や開発者が限定されており、安全な運用を脅かす重大な脅威
が存在しない場合に用いられる保証レベル
EAL3(方式的テスト及び
チェック)
不特定な利用者が利用できる環境、不正対策が要求される場合に
用いられる製品の保証レベル
EAL4(方式的設計、テス
ト及びレビュー)
商用機器やシステムにおいて高度なセキュリティ確保を実現するために、
セキュリティを考慮した開発と生産ラインを導入して生産される製品の
保証レベル
EAL5(準形式的設計及
びテスト)
特定の分野の商用製品・システムにおいて、最大限のセキュリティ確保
をするためにセキュリティの専門家の支援により開発、生産された製品
の保証レベル
EAL6(準形式検証済み
設計及びテスト)
重大なリスクに対応して高い価値のある資産を保護するために、開発
環境にセキュリティ工学技術を適用して開発された特別性の製品の保
証レベル
EAL7(形式的検証済み
設計及びテスト)
非常にリスクが大きい環境や高い開発費用に見合う資産を保護するた
めに開発された製品の保証レベル
セキュリティ設計の評価・認証(1)
保証とは?
「保証」を英語でいうと
assurance
「製品が品質基準に合致しているかを、設計・試
作・製造・検査の全ての工程で確認する仕組みが
あり、それを実行していることを保証する、請合う、自
信をもって言うこと」
warranty
「出荷後製品が故障したら,無料で修理又は
取り替えをする事を利用者に対して保証するこ
と」
guarantee
「もし保証したことが出来なければ、賠償責任が生
じるような保証」
19
セキュリティ設計の評価・認証(2)
情報セキュリティと保証①(規格準拠)
情報セキュリティとは「正当な権限をもつ個人や組織が、情報を適切に管理できる」こと
個人情報や機密情報を防露されたり、システムの稼働を妨害されたりすることがないように、
情報を管理する機能=情報セキュリティ機能
セキュリティ機能には以下のことが要
情報セキュリティ機能の確からしさを確保するのがセキュリティ保証
:セキュリティ機能が正確に動作し、有効に機能することの保証
求される
 動作しないことはない
 不当な干渉をうけることはない
 動作不能に陥ることはない
一般のIT機能
確認可能
?
開発者がセキュリティ保証を
検証しなければならない
利用者は一般のIT機能については、実際に利
用してみることで保証されていることを確認できる
セキュリティ機能
利用者が不測の事態を発生させてセキュリティ機能が
正確かつ有効に動くことを確認することは困難
このセキュリティ保証を確
認するのが、セキュリティ
評価(by第三者)
セキュリティ評価の国際規格
コモンクライテリア(CC)の保証
20
セキュリティ設計の評価・認証(3)
コモンクライテリア(CC)とは?
 CCパート1 概説と一般モデル
セキュリティ目標(ST)
ST概説
適合性主張
セキュリティ課題定義
脅威
組織のセキュリティ方針
前提条件
セキュリティ対策方針
TOEのセキュリティ対策方針
運用環境のセキュリティ対策方針
セキュリティ対策
拡張コンポーネント定義
セキュリティ要件
セキュリティ機能要件
セキュリティ保証要件
セキュリティ要件根拠
TOE要約仕様
プロテクションプロフェイル(PP)
 CCパート2 機能コンポーネント
 CCパート3 保証コンポーネント
 CEM 情報セキュリティ評価方法
CCはITセキュリティ評価の国際
標準(ISO/IEC15408)
•開発者が主張するセキュリ
ティ保証の信頼性に関する評
価の枠組みを規定
STはセキュリティ保証の目標を規
定した文書
•評価対象のシステムが装備
するセキュリティ機能を定義
•必須のセキュリティ評価対象
CCパート2
(セキュリティ
機能要件)
CCパート3
(EAL保
証要件)
*【参考2】に詳細と
関連事項を示す。
21
ロジカルな設計品質の説明(1)
情報セキュリティと保証②(品質説明力の強化)
セキュリティ機能へのお客様の納得←セキュリティ機能の品質説明力の強化
ソフトウェア=目に見えないもの
ソフトウェアの品質保証→困難(なぜならばどのような機能をどのように実現して、
それがどのような投資効果をもつのかを示す必要がある)
情報セキュリティに関する品質保証→より困難(新たな脅威がどのように発生す
るか予測不可能なため)
目に見えないものであるソフトウェアに対し,理論
的な論理関係と根拠を示すことによって品質説
明力を強化し,お客様の納得を得ることでお客
様と合意した内容について保証が必要
理論的な論理関係と根拠を示す
アシュアランスケース
(Assurance Case)の保証
22
ロジカルな設計品質の説明(2)
アシュアランスケース(ISO/IEC15026)とは?
テスト結果や検証結果をエビデンスとしそれらを根拠にシステム
の安全性,信頼性を議論し,システム認証者や利用者など
に保証する,あるいは確信させるためのドキュメント
アシュアランスケースの構造と内容の要求
事項(最低限)
• システムや製品の性質に対する
主張(claim)
• 主張に対する系統的な議論
(argumentation)
• この議論を裏付ける証跡
(evidence)
• 明示的な前提(explicit
assumption)
• 議論の途中で補助的な主張を
用いることにより、最上位の主張
に対して、証跡や前提を階層的
に結び付けることができる
*GSNは代表的な
アシュアランスケース手法
*【参考3】に関連事項を示す。
23
【参考1】
例)SARM_A表 なりすましによる不正注文
利用者ALICE
脆弱性のあるシステムBOB
攻撃者EVE
利用者
ALICE
☆色々なサイトを閲
覧したい
□COOKIE情報
☆BOBのサイトを閲覧したい
&◇BOBのサイトのトップページにアクセスする
&◇ログインをする
☆EVEのサイトを閲覧したい
◇BOBのサイトにログインしたま
まEVEのサイトをクリックする
脆弱性
のある
システ
ムBOB
☆正当な利用者にア
クセスさせる
&○利用者情報を保護する
□利用者情報
&○利用者ごとの管理をする
&◇許可された利用者に情報へのアクセスを許可する
□認証データ
&◇ALICEにセッションIDを割り当てCOOKIE情報を通知す
る
&◇COOKIE情報を管理する
□ -- COOKIE情報
&○商品の販売をする
☆正当ではない利用者にはアクセ
スさせない
◇偽造された認証データの使用
を
検知または拒否する
|◆XSSの脆弱性によりALICEのCOOKIE情報をEVEに送信
■--XSSの脆弱性
攻撃者
EVE
★ALICEにEVEのサ
イトをクリックさせた
い
◆利用者ALICEに
EVE のサイトをクリ
ックさせる
★ALICEになりすましてBOBのシステムで商品を注文し、商品
を手に入れたい
&◆ALICEのセッションIDを盗む
■--COOKIE情報
|◆Script Insertion
|◆HTTPレスポンス攻撃
|◆XSS
&◆ALICEになりすまして、商品の注文をする
★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
S4
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年度版 ST作成講座資料より
【参考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年度版 HPより
【参考3】
CC-Caseのライフサイクルプロセスの概要
要件
定義
設計
要求段階のCC-Caseはこのプロセスに相当
実装
テスト
34
【参考3】
一般のシステム開発プロセス・セキュリティ対応プロセスとCC-Caseの対応
設計・
開発
企画・要件定義
テスト
サービ
ス提供
セキュリティ仕様のアシュアランスケース
セキュリティコン
セプト定義段階
入
力
顧客
の要
求
セキュリティ対策立案段階
セキュリティ仕様化段階
CCパート2
(セキュリティ
機能要件)
過去の
PP事
例集
CCパート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の論理モデルと具体モデル
CC基準から、
インシデント対応用のプロセスに変えた!!
セキュリティインシデントとそのプロセス
セキュリティインシデント:事業運営に影響を与えたり、情報セキュリティを
脅かしたりする事件や事故のこと
セキュリティインシデント対応
「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