Computer Security Symposium 201611 - 13 October 2016

CC-Case を用いた IoT セキュリティ認証方法の提案
金子朋子†1

髙橋雄志,†2

勅使河原可海, †2 田中英彦,†1

概要：モノのインターネットといわれる IoT システムは今後急激な普及・拡大が見込まれる．しかし，つながる世界は様々なリスクも抱えており，セキュリティ設計技術，認証技術，標準化はつながる世界では更に重要になる．筆者
らは，IoT セキュリティ認証方法として，コモンクライテリア（CC）とアシュアランスケースを用いてセキュリティ
要求分析と保証を実現する手法である CC-Case の利用を提案する．IT セキュリティ評価基準である CC による認証技術と品質説明力の強化を図れるアシュアランスケースの統合が，IoT の複雑なセキュリティ要件を可視化する認証技
術となりうると考えるからである．
キーワード： IoT，認証技術，アシュアランスケース，セキュリティケース，コモンクライテリア，CC-Case

Proposal of an IoT Security Certification Method Using CC-Case
KANEKO TOMOKO†1
TAKAHASHI YUJI†2
TESHIGAWARA YOSHIMI†2 TANAKA HIDEHIKO†1
Abstract: Abstract: IoT, Internet of Things, systems are expected to be in widespread use rapidly all over theworld. However, the connected world using the Internet has various risks. The security design technology, thecertification technology, and the standardization become more important in such the connected world. We propose
an IoT certification method by applying the CC-Case which realizes security requirement analysis and assurance
by using the Common Criteria (CC) and the assurance case. The CC is an IT security evaluation standard and theassurance case can strengthen quality description. Therefore, we are convinced that the integration of the CC andthe assurance case can be an effective certification technology to describe precisely complicated security
requirements of IoT.
Keywords: IoT, certification technique, Assurance Case, Security Case, Common Criteria, CC-Case

ずく製品・システムの中で動くソフトウェア自体の開発の1. はじめに仕組みの中に脅威への対抗手段を含めることがより根本的

現代のシステムはネットワークを介して様々な機器やな対策になりうると考える．

クラウドと連携しながら動作している．このように異なる

つながる世界である IoT にとって，現在最も求められて分野の製品や産業機械などがつながって新しいサービスをいるのはセキュリティ脅威に対して安全・安心を確保する

創造するモノのインターネット（IoT: Internet of Things）はための開発指針であり，開発技術である．そして開発指針

新産業革命とまで言われ，大きな期待を集めている．IoTと開発技術を伴うセキュリティ認証方法であると筆者らはは家電，自動車，各種インフラ業者など新規プレーヤーの考える．なお，詳細は 4.1 節に示すが，本論文でいう認証登場を産み，その取り込みは加速化している．しかし相互とは「IoT 製品・システムのセキュリティ機能が正当な手につながる際に最も懸念されるのは，IoT システムへのセ続きでなされたことを証明すること」である

キュリティ上の脅威である．IoT システムにおいても攻撃者はシステムの脆弱性を突いて攻撃を仕掛けてくるためである．
IoT システムへの脅威に対して，より安全な機器，システムを開発するにはどうしたらよいだろうか？解決方法として，開発者に対する教育と訓練，経験の伝達，プロジェ
クト管理の徹底，運用管理の向上，セキュリティ方針の厳密化などとともに，開発方法論からの対応が必要である.
図 1 に、開発方法論・プロセスからの対応を示す．なかん

図1

開発方法論・プロセスからの対応

筆者らは，コモンクライテリア（CC：Common Criteria.
†1 情報セキュリティ大学院大学
INSTITUTE of INFORMATION SECURITY†2 東京電機大学
TOKYO DENKI UNIVERSITY

ISO/IEC15408 と同義）[1][2][3]とアシュアランスケース（ISO/IEC15026）[4]を用い，セキュリティ仕様を顧客と合－ 120 －

意の上で決定する手法 CC-Case[5] [6]を提案している．また（ TOE:Target Of Evaluation ） の セ キ ュ リ テ ィ 機 能 要 件

CC-Case は CC とアシュアランスケースを用いてセキュリ（SFR：Security Functional Requirement）が規定されている．

ティ要求分析と保証を実現する手法である．これまでの準形式化するために，CC パート 2 には機能要件がカタロ

CC-Case では，CC 認証を伴うセキュリティ要件定義中心をグ的に列挙されており，選択等の操作にパラメータやリス

主たる目的として提案してきたが，本来，要求，設計，実トを特定することにより，準形式的な記載ができる．図 3

装，テスト，保守の各段階からの対応ができ，全開発工程に CC パート 2 の規定、図 4 に準形式的な記載事例を示す．

に対して安全性を考慮した方法論[6]であり，本論文ではラ

図 3 に示すように，機能要件 FIA_AFL1.1 で TOE セキュリ

イフサイクルごとのモデルを提示する． CC-Case は製品・ティ機能（TSF: TOE Security Functions）は、[割付：認証事

システム自体のセキュリティ機能を保証する基準としては象のリスト]となっているので，図 4 の事例のように「最後CC をベースにするが，製品（システム）と製品（システに成功した認証以降の各クライアント操作員の認証」，「最ム）の関係性や運用時の変更要求管理・インシデント管理

後に成功した認証以降の各サーバ管理者の認証」のパタメを通じた製品（システム）の脆弱性対処においては，CCータの割り付けをする． CC のパート 3 にはセキュリティの応用とは異なるソリューションを想定している．また CC保証要件（SAR：Security Assurance Requirement）が規定さ認証制度が個々の製品のセキュリティ目標（ST: Securityれている． CC はセキュリティ機能自体の形式化を図るこ

Target）中心の評価から、プロテクションプロファイル（PP:とにより、IT セキュリティを評価する基準であり、特にパProtection Profile）のひな型を利用する効率的な評価へ移行

ート１に規定されたセキュリティ目標を作成するプロセス

される現状に応じて，CC-Case 自体を用いた認証方法が効は、CC 認証を伴わないセキュリティ要求仕様においても率化できることを述べる．さらに多様な機器の組合せによ

汎用的に利用可能である．

って生じる IoT の複雑性への対処可能性については，
CC-Case が IoT の複雑なセキュリティ要件をアシュアラン
スケースの利用によって可視化し，品質を保証する認証技
術となりうることを示す．

2. 関連研究2.1 IoT セキュリティの現状

図2

CC 構成と ST の記載内容

IoT システムへの脅威事例[7][8][9]]は日増しに増加している．2004 年の HDD レコーダーの踏み台化は情報家電に対する初期の攻撃事例である．この事例では HDD レコー
ダーが外部サーバアクセス機能を有していたため踏み台として利用された．2013 年の心臓ペースメーカの不正操作は無線通信で遠隔から埋め込み型医療機器を不正に操作でき

図3

CC パート 2 の規定

図4

準形式的な記載事例

る脅威を示したものである．また 2013 年にはジープを車載のインフォメーションシステム経由でインターネットから操作できる研究も発表され，自動車メーカーを驚かせた．
2014 年にはスマホで ATM から現金を引き出すウイルスを用いて 14 歳少年が ATM 管理モードに入り表示画面を書き換える事件も起きている．また世界中からハッカーの集ま

2.3 アシュアランスケース

る Black Hat では HW／組込み，IoT，スマートグリッド／

アシュアランスケース（assurance case）とは，テスト結インダストリといった IoT 関連テーマが登場し，注目され果や検証結果をエビデンスとしてそれらを根拠にシステムている．今後 IoT ハッキング技術を身につけ，実践をはじの安全性，信頼性を議論し，システム認証者や利用者など

めるハッカーが増えることは想像にかたくない．

に保証する，あるいは確信させるためのドキュメントであ

2.2 コモンクライテリア(CC)る[20]．アシュアランスケースは欧米で普及しているセー

IT セキュリティ評価の国際標準である CC[2]は,開発者がフティケース[21]から始まっており，近年，安全性だけで主張するセキュリティ保証の信頼性に関する評価の枠組みなく，ディペンダビリティやセキュリティにも使われ始めを規定したものである[4]．CC のパート 1 には評価対象のている．アシュアランスケースは ISO/IEC15026 や OMG のセキュリティ目標（ST）やプロテクションプロファイル

ARM [22]と SAEM [23]などで標準化がすすめられている．

(PP)に記載すべき内容が規定されている．図 2 に，CC 構成

アシュアランスケースの構造と内容に対する最低限のと ST の記載内容を示す． CC のパート 2 に評価対象

要求は，システムや製品の性質に対する主張(claim)，主張－ 121 －

に対する系統的な議論（argumentation），この議論を裏付けしてほしい．cPP については、4.2 節で詳しく述べる．CCる証跡(evidence)，明示的な前提（explicit assumption）が含は認証制度のコスト負担の問題などで利用しづらい基準とまれること，議論の途中で補助的な主張を用いることによみなされることもあるが，CC のもつセキュリティ基準とり，最上位の主張に対して，証跡や前提を階層的に結び付しての汎用性，国内外の CC 活用動向を元に考えると，やけることができることである．代表的な表記方法は，欧州

はり CC は大変重要な基準である．

で約 10 年前から使用されている GSN [24]であり，要求を抽出した後の確認に用い，システムの安全性や正当性を確認することができる．他に法律分野でアシュアランスケースの理論的背景となる Toulmin Structures[25]や要求，議論，

3. CC-Case の IoT セキュリティ認証への適用
方法
3.1 IoT セキュリティ認証の特徴にあった基準

証跡のみのシンプルなアシュアランスケースである

では多様な機器・システムがより複雑に関連するというASCAD[26]もある．日本国内では GSN を拡張した D-CASE

IoT セキュリティ特徴にあった基準，標準は何だろうか？

[27] [28]が JST CREST DEOS プロジェクトで開発されていここではセキュリティ規格の比較の観点から IoT セキュリる． また宇宙航空研究開発機構（JAXA）ではアシュアラ

ティ認証の特徴にあった基準を考えてみたい．
IoT は多様な機器・システムがつながるため，個別の機ンスケースを用いた検証活動への効果的な活用がなされている[29]．

器，個別の業界の基準のみではサポートできない部分が発

2.4 セキュリティケース

生する．そこでより汎用的で広く認知されたセキュリティ

GSN を提唱した Kelly ら[30]がセキュリティアシュアラ

基準として国際規格である CC と ISMS[37]を比較してみる．

ンスケースの作成に関する既存の手法とガイダンス，セーCC は製品・システムセキュリティ機能の保証に関するラ

フティケースとセキュリティケースの違いなどを述べていイフサイクルサポート規格である．一方 ISMS（ISO/IEC

るが，具体的に作成したセキュリティケースの事例は示し

27001）は，ISMS の確立及び実施については、それをどのていない．Goodenough [31]らはセキュリティに対するアシように実現するかという方法ではなく，組織が何を行うべュアランスケース作成の意味を説明している. Lipson H[32]

きかを主として記述しているマネジメント規格であり，IoT

らは信頼できるセキュリティケースには保証の証跡こそがセキュリティ機能を評価する規格ではない.製品（システム）

重 要 で あ る と 主 張 し て い る ． Ankrum[33] ら は CC ， やが利用される段階になって，管理する際には ISMS は重要

ISO14971，RTCA/DO-178B という 3 つの製品を保証するたであるが，IoT のセキュリティ機能の認証においては CC

めの規格を ASCAD でマップ化し，ASCE などのアシュアの方が用途にあっている．

ランスケースツールが有効であり，保証規格を含むアシュ

IoT セキュリティにはつながる対象となる個々の製品のセアランスケースは似た構造をもつことを検証している．

キュリティ機能保証が不可欠である．従って IoT セキュリ

CC-Case[5] は IT セキュリティ評価基準(CC)に基づくセキ

ティ基準は相互につながる機器・システム上のセキュリテュリティケースであり，セキュリティに関する事例として

ィリスクに対して．個々のセキュリティ機能がどのように有用である[7]．

実現されたのかを示して，その安全性を示す必要がある．

2.5 CC の動向

何故ならば相互に依存する機器・システムはその 1 つ 1 つ政 府 に お け る IT 製 品 ・ シ ス テ ム の 調 達 に 関 し て ，ISO/IEC 15408（CC）に基づく評価・認証がされている製が安全であり，相互依存関係においても安全でなければ，
セキュリティ上の保証ができないからである．

品の利用が推進されており，注目すべき最新の CC の動向

CC は製品・システムのセキュリティ機能の安全性を第として，情報セキュリティ政策会議で決定された「政府機三者に示し，保証することができる基準であり，これをベ関の情報セキュリティ対策のための統一基準（平成 26 年度

ースに用いて，個々のセキュリティ機能を示すことと，そ版）」[34]が挙げられる．

れらの相互依存関係の保証を行うことにより，システム全本統一基準の「5.2.1 情報システムの企画・要件 定義」
において、機器調達時には「IT 製品の調達におけるセキュ
リティ要件リスト」を参照し，適切なセキュリティ要件を体としての保証を示すのが適切であると考える．

4. IoT セキュリティ認証への CC-Case の有効性

策定することが求められている．経済産業省より公開されている「IT 製品の調達におけるセキュリティ要件リスト」[35]では、指定したセキュリティ要件が満たされていることの確認手段として，CC 認証のような国際基準に基づく
第三者認証を活用することを推奨している．
CC における認証制度や cPP（Collaborative PP)活用で想

本章では，本論文のテーマである「認証とは何か？」そして「IoT セキュリティ認証には何が必要か？」について考察したうえで，IoT セキュリティ認証方法としての CCの有効性及び今までハイレベルの枠組みしか定義されていなかった CC-Case のライフサイクルにおける方針を述べる．

定される今後の動向については,筆者らの論文[36]を参考に－ 122 －

4.1 IoT セキュリティの認証と必要な要素成に基づいて考えると，製品（システム）自体の機能と製大辞泉によると認証とは以下の 2 つの意味を持つ．
「1 一品（システム）と製品（システム）の関係性に分けること

定の行為または文書の成立・記載が正当な手続きでなされができる. さらに製品（システム）と製品（システム）のたことを公の機関が証明すること．2 コンピューターやネ

関係性は通信など製品（システム）と製品（システム）のットワークシステムを利用する際に必要な本人確認のこと．

間に存在する関係と機器対機器の相互作用の 2 つを示して通常，ユーザ名やパスワードによってなされる．」本論文でいる．そこで Goal:L1 は「Goal:L2 製品（システム）のセキ

いう認証とは「IoT 製品・システムのセキュリティ機能がュリティ機能を保証できる」ことと「Goal:L3 製品（シス

正当な手続きでなされたことを証明すること」である．こテム）と製品（システム）の通信と相互作用を保証できる」

れは 2 を含んだ 1 に近い．理由は CC-Case のスコープが 2に分解することができる．さらに製品（システム）のリスの個人認証だけでなく，製品（システム）のセキュリティ

クに基づいて考えると IoT 製品（システム）のセキュリテ

機能，及び製品（システム）と製品（システム）の相互依

ィの認証に必要な要素は，「Goal: L4 運用時の変更要求管存の関係性に相当する通信と相互作用，運用時の脆弱性対理・インシデント管理を通じて製品（システム）の脆弱性

処の保証を包括的に含んでいるが，認証制度ではなく，認に対処できる」こととなる．

証方法であるため，公の機関による証明までは求めていな
いからである．

つまり個々の製品（システム）の機能がセキュアである
こと，個々の製品（システム）の通信と相互作用がセキュアであること，さらに運用時の変更要求管理・インシデン
ト管理を通じて製品（システム）の脆弱性に対処できることで網羅性をもったセキュリティ確保が可能となるのである．
4.2 IoT セキュリティ認証に対する CC の有効性
CC-Case の主要な技術要素である CC は基準としてさらには認証制度として，IoT セキュリティ認証に対して，どのような有効性をもちうるかに対して考察する．
CC に対し「CC に基づく認証はコスト高であり、認証を求めると IoT 製品のコストに跳ね返るため、適用は難しい」という懸念が現状多くなされている．この懸念に対する筆者らの見解を述べたい．

図 5 IoT セキュリティ認証で明確化すべき要素

筆者らはまず第 1 に認証制度の運用方法と認証の方式やIoT 製品・システムのセキュリティ認証において，考慮参照とする基準は分けるべきだと考える．CC への批判のすべき点の１つは特に業界分野における取組状況の違いで大部分は今の認証制度の運用方法からくるコスト増である．

ある．IoT 製品・システムは多種多様であり，自動車，家

このコスト増は認証機関が時間をかけて審査しているため、

電，携帯電話，制御システム，ヘルスケア等つながるモノ

発生しているものである．しかしながら、認証制度の課題の自体の対策状況は業界分野においても異なっている[9]．

と CC 自体のセキュリティ基準としての価値は別に考える

自動車業界は米国や欧州のメーカーやサプライヤによる委べきである．CC は IT セキュリティ評価の汎用的な国際的員会等で標準化と検討が幅広く進んでいるが，ヘルスケア，

規格として，現状最も浸透しており､すぐれた基準である．

家電の分野では標準検討段階中であるなど，業界分野ごと

従って，この審査上の非効率を改めることも含め利用範囲，にセキュリティ対応レベルも異なり，標準の動向も異なっ

利用方法等に関する更なる検討は必要だが，IoT のためのている．しかしながらインターネットを通じてつながる世

認証方法のベースとしてはセキュリティ機能要件と保証要

界は業界分野ごとに限定された基準のみで保証できるわけ

件を規定している CC を利用したい．

ではない．そこで業界分野による状況の違いを踏まえたう

第 2 に PP 利用によるセキュリティ仕様明確化のしやすえで共通的に製品（システム）を保証する必要が生じていさである．CC では個々の製品・システムのセキュリティ

る．その保証は単に製品単体だけでなく，製品（システム）要件を記述したセキュリティ目標（ST）を作成するが，ST相互の関係性，製品出荷後の対応までに及ぶべきであるとを作成しやすくできる PP という ST の雛型も存在している

筆者らは考える．

（図 6）．PP とはある評価対象のタイプ（OS，ファイアウ

そこで IoT 製品・システムのセキュリティ認証に必要な

ォール，スマートカード等）に対するセキュリティの設計要素を網羅的にアシュアランスケースで示すと図 5 のよう仕様書であり, PP は具体的な実装方法には依存しないため，になる.「Goal:L1

多数の ST で再利用することができる．

IoT 製品（システム）のセキュリティの認証に必要な要素を洗い出す」は，製品（システム）の構－ 123 －

数存在することとなり，PP による機能の要件の不一致等の問題が表面化してきた．そこで CCRA では各国制度の承認のもとに PP を各技術分野ごとに世界共通化したひな型である cPP を作成することになった．表 2 に従来の PP と cPPの違いを示すこの cPP は 2 年後には必須となることが決定されている．従来の PP では評価期間に 18 か月以上かかっていたのが cPP を用いた場合，米国では 90 日以下で認証可能になっている．
IoT セキュリティ認証に対しては，CC 認証制度と同じ枠
図 6 PP とは何か？

組みで行うことは必ずしも必要ではない．ただし現在の CC

PP の目的は、利用者側のセキュリティに関する要求を明では作成されていない個々の IoT 製品の各技術分野に対す

確にすることである．この PP は日本にはほとんど存在しる世界共通のひな型である cPP の方式も参考にし，認証対なかったが，最近，表 1 にみられるように各種の PP が作象の形式化とよりコストのかからない運用制度を考える事成されてきている．この PP を利用することにより，CC のは必要であろう．さらに認証機関によるものでなくても，

ST は非常に簡単に作成可能となる．図 7 に示すようにこのアシュアランスケースで準形式的に示し，自己検証ができ

ひな形があれば PP 利用で ST の第 2 章から第 6 章というほることも認証と認めるなどの緩和処置を施すことで認証コ

とんどの部分をコピーして使用できるようになる．それにストを抑えることができるはずである．

より製品開発側はその製品の具体的仕様をセキュリティ機

表 2 従来の PP と cPP の違い

能要件（SFR）のパラメータで示し，個別仕様に関して追記してセキュリティ仕様を書くことだけで ST を記述可能なのである．
表 1 公開されている PP の例

4.3 IoT セキュリティ認証に必要な要素を満たすためのCC-Case の方針
4.1 節で示したように IoT セキュリティ認証に必要な要素は，個々の製品のセキュリティ機能の認証，製品（システム）の通信と相互作用の認証と運用時の脆弱性対処に分けて考えることができる．
そこで CC-Case により，これらの要素を満たすために，どのようなことをするべきであるかを(1)セキュリティ機能の保証,(2)製品（システム）の関係性の保証，(3)運用時の脆弱性対処の 3 つの観点から述べる．
(1)セキュリティ機能の保証
前述のように業界分野ごとの取り組み状況の違いを踏
まえたうえで，共通的に製品（システム）自体と製品（シ
図 7 適合 ST の作成イメージステム）の通信と相互作用，製品出荷後の対応を保証する

この PP は汎用的に各種製品のセキュリティ機能に対し必要が生じている．筆者らが提案する CC-Case による IoTて作成可能であり，CC は IoT セキュリティ認証に対して，

セキュリティ認証とは特定の分野に閉じた認証ではない．

実用的な有効性をもちうる．

インターネットを通じてつながる IoT に共通な認証基盤となお，PP は国ごとに個別に作成されてきたため、同じ製

して，CC-Case とその拡張を推奨している．しかし現実に品 分 野 の 異 な る PP が CC 承 認 ア レ ン ジ メ ン ト

多様な製品（システム）がつながる以上，まずはその製品（CCRA :Common Criteria Recognition Arrangement）内に複（システム）の(1)セキュリティ機能の保証が必要であると－ 124 －

考える．このため「Goal: L2 製品（システム）のセキュリ

していくことが必要になる．

ティ機能を保証できる」がゴールとしてあげられる．
「Goal: L2 製品（システム）のセキュリティ機能を保証できる」を達成するために CC-Case を利用すると 3 つの戦略に基づくゴールが考えられる（図 8）．
1 つめは，セキュリティ機能のアシュアランスケースを作成することにより，「G_1 個々の製品（システム）のセキ
ュリティ機能の見える化ができる」ことである．証跡は可視化されたセキュリティ仕様となる．各製品固有のセキュリティ機能全体に対してセキュリティ要件の見える化を図ることでその製品自体の保証が可能となる． 見える化の手段として安全性分野で欧州を中心に広く用いられているア
シュアランスケースを用いる．従来から安全性は自然に発

図 8 セキュリティ機能の保証

生する故障や人為的なミスを対象としているが，セキュリ(2) 製品（システム）と製品（システム）の通信と相互ティは悪意を持った攻撃を対象にすることが大きく異なる．

作用の保証

セーフィティとセキュリティの設計は独立したプロセスで「Goal: L3 製品（システム）と製品（システム）の通信と実現されることが多いと想定されるが，IoT でつながる世

相互作用を保証できる」を達成するために以下の 2 つの戦

界においては双方を切り離すのではなく，共に関係性をも略に基づくゴールの達成が必要と考えられる（図 9）．

って推進されることが必要である．セキュリティ要求のア

1 つめは，製品（システム）・製品（システム）間の通信

シュアランスケースである CC-Case は安全性分析の延長線のセキュリティ確認にアシュアランスケースを作成するこ

上に悪意を持った攻撃への対応を可能とする手法となってとにより，「G_4 インターネット，クラウド，通信の脆弱いる．そのため安全性手法との親和性が高く実用的である．

性と暗号化などの対処を見える化できる」ことである．証

2 つめはセキュリティ機能要件単位の準形式化を現在，跡は通信上の安全性の保証となる．今までの CC-Case はセPP で対応している製品だけでなく，IoT 製品に拡張するこ

キュリティ製品（システム）の機能の保証をテーマとしてとにより，「G_2 分野・製品ごとに適した SFR や cPP を適きており，通信上の安全性の保証は検討範囲に入っていな用できる」状態にすることである．現在，製品（システム）

かった．アシュアランスケースを利用してインターネット，のセキュリティ機能は業界分野ごとに製品（システム）のクラウド等の通信上の安全性を見える化することは可能で特性に応じたセキュリティ機能基準を定めていく方向性にあろう．ただし各種通信プロトコル規格，暗号規格とそのある．この流れにあわせて業界分野ごとに準形式化された脆弱性（リスク）に照らして，現状起こりうる脅威，必要

セキュリティ機能要件を各 IoT 製品分野で作成していくこ

な対策，残すべき証跡を的確に洗い出し，論理モデルを構とを推奨したい．準形式化されたセキュリティ機能要件と築することが必要になる．その上で，その製品（システム）いう基準で各業界分野の製品（システム）が共通的に作成の利用シーンに応じた具体モデルを構築することになろう．

されるならば，相互理解が容易となり，業界分野の違う製

またスマートグリッドなどの社会インフラ制御システ

品も共通的に保証することが可能となる．さらに 4.3 節でムにおいてはサーバに複数の組込みシステムが接続される

あげたメリットを享受できよう．証跡は準形式化されたセ形態が大多数であり，組込みシステムはクラウド化がすす

キュリティ機能要件となる．

んでいる[41]．そのため，組込み機器向けの対策以外にサ

3 つめは CC の保証要件(EAL)の適用により，「G_3 製品

ーバ向けの対策が必要になる．

ごとに適した保証要件を選択できる」ことである．証跡は

2 つめは相互作用の脅威分析を行うことにより，「G_5 機ライフサイクルにおける保証の提示となる．CC 保証要件

器対機器の相互作用から生じる脅威へ対処できる」ことでの EAL レベル 7 では形式的検証済み設計，およびテストがある．証跡は機器対機器の脅威分析結果である．相互作用必須となっている．よりセキュアな組込み機器のセキュリの脅威分析に関しては，「アクタ関係表に基づくセキュリテ

ティ機能を形式手法によって開発することも今後の検討事

ィ要求分析手法（SARM）」の拡張により対応可能と考えて項となろう．

いる．SARM は CC-Case におけるセキュリティ要求分析手

上記のセキュリティ機能の保証の中で，製品ごとに適し法である，今後詳細を公開していく．SARM[15]は複数アク

た SFR や cPP を作成していくこと以外は従来から CC-Case

タ対複数アクタの関係で相互の意図を表形式の交差する欄での実現方法を IoT 製品（システム）に拡張的に適用するに記入していく「アクタ関係表（ARM）」を利用し，そのことで可能であるが，いずれのゴールに対しても今後具体

アクタに攻撃者を記述することで攻撃者の意図を表記する

的に適用を具体的に行い，その評価を行って，事例を増やセキュリティ要求分析手法である．このアクタに対して，－ 125 －

人物ではなく機器（システム）を設定することにより，複

ただし IoT の場合，その知識資産化は IoT センサー機器か雑に絡む機器（システム）対機器（システム）の関係性を

らの情報収集を必要とし複雑で大容量となることは想像に網羅的に表形式に整理して表現することが可能となる．セ

難くない．そのためビッグデータ，人工知能の利用等の先キュリティ要求分析手法である SARM は，要求分析手法で端 IT 技術を用いた知識資産化により「G_6 IoT インシデンあるアクタ関係表を拡張して，悪意を持った攻撃手法の分トに対する的確な対応や予防対処ができる」ことが望まれ析も可能にした手法であり，セーフティとセキュリティのる．さらに確実な知識資産化のためには，IoT の複雑な要両方の分析ができる．

件をマネジメントし，継続的に改善を実施していくための

IoT 製品・システムのセキュリティ認証において，考慮

新たな品質マネジメントシステムも必要になろう．証跡とすべき点としてセキュリティ上の対象（守るべき資産）のしては，IoT 事例知識資産化方法，予防対処方法となる．

違いがある．情報セキュリティの対象は情報である．これ

上記の運用時の脆弱性対処には，CC-Case の運用時の手法

は情報セキュリティの CIA はいずれも情報の特質に着目しである CC-Case_i や CC-Case では明示されてこなかった

た特質であることからも明らかである．これに対して IoT

IoT インシデントの事例活用が必要であり，具体的な提示

セキュリティが対象としているのはモノである．ここでいは今後の課題である．

うモノとは自動車，家電機器などの製品の場合，人の生命，

2 つめは，運用時にアシュアランスケースの適用を実施

健康，財産を含むが，情報は財産の一部であるに過ぎない．

することにより,プロセスアプローチに基づいた「G_7 製品

プラントなどの制御システムの場合，対象は情報ではなく、（システム）提供後に発生する変更要求やインシデント対設備、製品などのモノと連続稼働を必要とするサービスに処の見える化ができる」ことである．長期に渡り利用するなる．そこで IoT 製品のセキュリティ認証は情報以外の対ことが前提となる生活機器，制御システム等の場合，新た象に対しても保証が必要性である．情報以外のモノ，サーな脆弱性の発見，攻撃者による新たな手法の開発，技術進

ビス等対象に対しても脅威分析が可能となるように SARM

歩に伴う搭載されたセキュリティ技術の陳腐化などによるを拡張する必要がある．

脆弱性への対応が必要である[7]．脆弱性への対応するため

上記の製品（システム）の通信と相互作用の保証は，要にはセキュリティ更新作業等の変更要求への対処が必要で件定義段階が中心である従来の CC-Case では明示されてこある．運用時はインシデント対応を含めて，製品（システ

なかった範囲であるが，IoT セキュリティ認証に必要な要ム）提供後に発生する変更要求に対処するプロセスを定義素であり，具体的な提示が今後の課題である．

しているが，今後より具体的なアプローチを定めていくことにより有用性が期待できる．証跡として製品（システム）
提供後のインシデント対処方法となる．

図 9 セキュリティ機能の保証
図 10(3)運用時の脆弱性対処
セキュリティ機能の保証と製品（システム）の関係性の保証は製品（システム）の出荷・運用開始前の状態での保運用時の脆弱性対処

5. おわりに
本論文では，CC-Case を、IoT セキュリティ認証に適用証を指している．しかし，運用時の脆弱性対処は製品（シする方法を示し，①CC-Case がアシュアランスケースを利ステム）の出荷・運用開始後の状態を指す．
運用時の製品（システム）のリスクに基づいて考えると用しているという特徴から利用により、複雑な個々の IoT「Goal: L4 運用時の変更要求管理・インシデント管理を通製品の認証が簡便にできる可能性があることと，②IoT 製

じて製品（システム）の脆弱性に対処できる」を達成する

品ごとの PP 及び cPP 作成を利用すること有効性等を示しために以下の 2 つの戦略に基づくゴールの達成が必要と考た．そして今後，より具体的なセキュリティ要求・設計・えられる（図 10）．

運用基盤として推進するための方向性を提示した．実際に1 つめは，インシデントの事例を知識資産化すれば，脅は IoT セキュリティ認証方法はまだ定まっておらず，本論威に対してより効果的な予防処置をとることができよう．

文で取り上げたこと以外に多くの検討が必要であろう．筆－ 126 －

者らは今後，IoT 対応に適したモデルとして，CC-Case 設
計段階の具体的詳細化を進めていく．また個々の IoT 製品に適した PP をセキュリティ機能要件（SFR）の利用と拡張により作成できることを示し，実際の IoT 製品で実証研究を行っていきたい．本研究が現在のセキュリティ認証の課
題解決に役立ち，世の中で広く利用されていくことを念願するものである．

参考文献
1) Common Criteria for Information Technology Security Evaluation,
http://www.commoncriteriaportal.org/cc/2) セキュリティ評価基準（CC/CEM)
http://www.ipa.go.jp/security/jisec/cc/index.html
3) 田淵治樹：国際規格による情報セキュリティの保証手法,日科技連，2007 年 7 月
4) ISO/IEC15026-2-2011,Systems and Software
engineering-Part2:Assurance case5) 金子朋子，山本修一郎，田中英彦： CC-Case～コモンクライテ
リア準拠のアシュアランスケースによるセキュリティ要求分析・保証の統合手法, 情報処理学会論文誌 55 巻 9 号(2014)
6) 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 WirelessCommunications, 2014 (ISSN:2305-0012)
7) 独立行政法人情報処理推進機構,つながる世界のセーフティ＆セキュリティ設計入門～IoT 時代のシステム開発『見える化』, 20158) 後藤厚宏, IoT 時代のセーフティ・セキュリティ確保に向けた課題と取組み,IPASEC セミナー（2015)9) 伊藤公祐, IoT 時代のセキュリティの確保に向けて, IPASEC セ
ミナー（2015)
10) Sindre, G. and Opdahl. L. A. : Eliciting security requirements withmisuse cases, Requirements Engineering, Vol.10, No.1, pp. 34-44(2005).
11) Mouratidis, H. : Secure Tropos homepage, (online), available from<http://www.securetropos.org/>.
12) Liu, L., Yu, E. and Mylopolos, J. : Security and Privacy
Requirements Analysis within a Social Setting, Proc. IEEE International
Conference on Requirements Engineering (RE 2003),
pp.151-161(2003).
13) Li, T. Liu, L. Elahi, G. et al. : Service Security Analysis Based oni*: An Approach from the Attacker Viewpoint, Proc. 34th Annual IEEE
Computer Software and Applications Conference Workshops , pp.
127-133 (2010).
14) Lin, L. Nuseibeh, B. Ince, D. et al. : Introducing Abuse Frames forAnalysing Security Requirements, Proc. IEEE International Conference
on Requirements Engineering (RE 2003), pp.371-372 (2003).
15) 金子朋子，山本修一郎，田中英彦：アクタ関係表に基づくセキュリティ要求分析手法（SARM）を用いたスパイラルレビューの提案,情報処理学会論文誌 52 巻 9 号(2011)16) Kaneko,T.,Yamamoto, S. and Tanaka, H.: Specification of Whole
Steps for the Security Requirements Analysis Method (SARM)- From
Requirement Analysis to Countermeasure Decision -,Promac201117) Mead, N. R., Hough, E. and Stehney, T. :Sequrity Qualty
Reqirements Engineering(SQUARE)
Methodology(CMU/SEI-2005-TR-009),
www.sei.cmu.edu/publications/documents/05.reports/05tr009.html
18) Mead, N. R, 吉岡信和: SQUARE ではじめるセキュリティ要
求工学,「情報処理」Vol.50 No.3（社団法人情報処理学会，2009 年
3 月発行）
19) Steve Lipner ,Michael Howard,:信頼できるコンピューティングのセキュリティ開発ライフサイクル,

http://msdn.microsoft.com/ja-jp/library/ms995349.aspx,2005
20) 松野裕，高井利憲，山本修一郎，D-Case 入門，～
ディペンダビリティ・ケースを書いてみよう！～, ダイテックホールディング, 2012 ，ISBN 978-4-86293-079-8
21) T P Kelly & J A McDermid, “Safety Case Construction
and Reuse using Patterns”, in Proceedings of 16th
International Conference on Computer Safety, Reliability
and Security (SAFECOMP'97), Springer-Verlag, September
199722) OMG, ARM, http://www.omg.org/spec/ARM/1.0/Beta1/23) J.R.Inge.The safty case,its development and use un the United
Kingfom.In Proc.ISSC25,2007.OMG, SAEM,
http://www.omg.org/spec/ SAEM/1.0/Beta1/
24) Tim Kelly and Rob Weaver, The Goal Structuring Notation – A
Safety Argument Notation, Proceedings of the Dependable Systems andNetworks 2004 Workshop on Assurance Cases, July 2004
25) Stephen Edelston Toulmin, “The Uses of Argument,” Cambridge
University Press,1958
26) The Adelard Safety Case Development (ASCAD), Safety Case
Structuring: Claims, Arguments andEvdence,http://www.adelard.com/services/SafetyCaseStructuring/index.
html27) DEOS プロジェクト, http://www.crest-os.jst.go.jp
28) 松野 裕 山本修一郎: 実践 D-Case～ディペンダビリティ
ケースを活用しよう！～,株式会社アセットマネジメント，2014 年
3月29) 梅田浩貴,第 3 者検証におけるアシュアランスケース入門～
独立検証及び妥当性確認(IV&V)における事例紹介 , ETwest(2015)30) Rob Alexander, Richard Hawkins, Tim Kelly，“Security Assurance
Cases: Motivation and the State of the Art，”，High Integrity Systems
Engineering Department of Computer Science University of YorkDeramore Lane York YO10 5GH，201131) Goodenough J, Lipson H, Weinstock C. “Arguing Security Creating Security Assurance Cases,”2007.
https://buildsecurityin.us-cert.gov/bsi/articles/knowledge/assurance/643BSI.html
32) Lipson H, Weinstock C. “Evidence of Assurance: Laying theFoundation for a Credible Security Case, “，2008.
https://buildsecurityin.us-cert.gov/bsi/articles/knowledge/assurance/973BSI.html
33) T. Scott Ankrum, Alfred H. Kromholz, ”Structured Assurance
Cases: Three Common Standards, “Proceedings of the Ninth IEEE
International Symposium on High-Assurance Systems Engineering(HASE’05), “ 200534) 政府機関の情報セキュリティ対策のための統一基準（平成26 年度版）, http://www.nisc.go.jp/active/general/kijun26.html
35) IT 製品の調達におけるセキュリティ要件リス
ト,http://www.meti.go.jp/press/2014/05/20140519003/20140519003.ht
ml36) 金子朋子，村田松寿：セキュリティ基準コモンクライテリア
が変わる-ユーザもベンダも乗り遅れるな！, 情報処理学会デジタ
ルプラクティス．Vol6 No.1(Jan.2015)37) 島田裕次, ISO27001 規格要求事項の解説とその実務―情報セキュリティマネジメントの国際認証制度への対応,日科技連,(2006)38) 吉岡信和, Bashar Nuseibeh，セキュリティ要求工学の概要と展
望 情報処理 Vol.50 No.3(2009).
39) 金子朋子，より安全なシステム構築のために～CC-Case_i によるセキュリティ要件の見える化,JNSA,201540) 梶本一夫,家電業界におけセーフィティ＆セキュリティ, 第
40 回 ISS スクエア水平ワークショップ
41) 金井遵,組込みシステムにおけるセキュリティの課題～セキュアプラットフォーム研究開発の取組み～, 第 40 回 ISS スクエア
水平ワークショップ－ 127 －