IPAサイバーセキュリティシンポジウム2017
2017年2月8日
「つながる世界の開発指針」の
産業展開に向けて
独立行政法人 情報処理推進機構
技術本部 ソフトウェア高信頼化センター
中尾 昌善
目次
1.今後の「つながる世界」
2.「つながる世界の開発指針」を策定
3.開発指針の普及展開活動
3-1.国のIoT政策への展開
3-2.産業界への展開
3-3.IoT高信頼化要件の具体化
3-4.国際標準化に向けた活動
「Cyber Physical “society”(CPS(超情報化)社会)の概念図 【出典】平成27年4月 産業構造審議会
異なる分野の機器がつながって新
しいサービスを創造(IoT)
機
器
と
コ
ン
ピ
ュ
ー
タ
が
デ
ー
タ
で
つ
な
が
る
(C
P
S
)
1.今後の「つながる世界」
SECでは、「つながる世界」≒「IoT時代」という意味で、この用語を用い
ています。
「つながる世界の開発指針」の特徴
※本開発指針は、2016年3月24日に公開(PDF版)
http://www.ipa.go.jp/sec/reports/20160324.html
つながる世界の17個の開発指針
製品の開発ライフサイクル全体
において考慮すべき17の指針を
策定
目次
第一章 つながる世界と開発指針の目的
第二章 開発指針の対象
第三章 つながる世界のリスク想定
第四章 つながる世界の開発指針(17指針)
第五章 今後必要となる対策技術例
※指針は、ポイント、解説、対策例を記述
大項目
指針
方
針
つながる世界の安
全安心に企業とし
て取り組む
指針1 安全安心の基本方針を策定する
指針2 安全安心のための体制・人材を見直す
指針3 内部不正やミスに備える
分
析
つながる世界のリ
スクを認識する
指針4 守るべきものを特定する
指針5 つながることによるリスクを想定する
指針6 つながりで波及するリスクを想定する
指針7 物理的なリスクを認識する
設
計
守るべきものを守
る設計を考える
指針8 個々でも全体でも守れる設計をする
指針9 つながる相手に迷惑をかけない設計をする
指針10 安全安心を実現する設計の整合性をとる
指針11 不特定の相手とつなげられても安全安心を確保
できる設計をする
指針12 安全安心を実現する設計の検証・評価を行う
保
守
市場に出た後も守
る設計を考える
指針13 自身がどのような状態かを把握し、記録する機
能を設ける
指針14 時間が経っても安全安心を維持する機能を設け
る
運
用
関係者と一緒に守
る
指針15 出荷後もIoTリスクを把握し、情報発信する
指針16 出荷後の関係事業者に守ってもらいたいことを
伝える
指針17 つながることによるリスクを一般利用者に知っ
てもらう
開発指針の記載内容
各指針の
ポイントは必ず検討すべき内容
開発指針
対策の実施は当事者の判断
・コスト(事業性)や問題の大小も考慮
に入れて判断
・実施する場合は各指針の対策例を参考
開発指針の基本的考え方
3. 開発指針の普及展開活動
・WGを立ち上げて実装要件を検討
・分野間連携における高信頼化機能の確認
(分野間実証実験)
・以下のテーマも併せて検討
利用時品質(今年度)
データの信頼性、IoT試験基準等(次年度)
③IoT高信頼化要件の具体化
・業界仕様への開発指針の要件盛り込み
(POS、車載器、ATMなど)
・各企業における適用(チェックリスト)
②産業界への展開
・IoTセキュリティガイドライン(IoT推進
コンソーシアム作成)への提案
・国際標準化に向けた体制構築
・独国IESEと標準化及び実証実験の協議
・米国NISTとの連携協議
④国際標準化
①国の政策への反映
◆つながる世界の開発指針
・WGで策定【主査:名大)高田教授】
企業の有識者、CCDS、EI協議会、
JSSEC、機械振興協会
3-1.国のIoT政策への展開
(各種ガイドラインとの関係)
サイバーセキュリティ基本法(平成26年11月12日) 改正:H28.4.22
※サイバーセキュリティに関する基本的な計画を定める
サイバーセキュリティ戦略(H27.9.4)
内閣サイバーセキュリティセンター(NISC)
※IoTシステムのセキュリティに係る総合的な
ガイドラインや基準の整備を行う
具体化
安全なIoTシステムのためのセキュリティ
に関する一般的枠組(H28.6.10)
内閣サイバーセキュリティセンター(NISC)
※IoTセキュリティの基本原則、取組方針
具体化
IoTセキュリティガイドライン
(H28.7.5)
IoT推進コンソ(経産省、総務省)
※NW構築・サービスを含むガイドライン
つながる世界の開発指針
(H28.3.24)
情報処理推進機構(IPA)
※IoT機器・システム開発の要件
提案
製品分野別セキュリティガイドライン
(H28.6.8)
重要生活機器連携セキュリティ協議会(CCDS)
※車載器、IoT-GW、ATM、POS分野のセキュリティガイドライン
産業分野に展開
提案
サイバーセキュリティマネジメントシステム
日本情報経済社会推進協会(JIPDEC)
ネットワークセキュリティの要件
3-1.IoTセキュリティガイドラインへの提案
出典:経済産業省 商務情報政策局 情報処理振興課(2015年11月)
3-2.産業界への展開
3-2.各企業における開発指針の適用例
(1) IoT製品やシステム開発時の
チェック項目として活用
⇒【チェックリスト】(付録)
(2) 受発注の要件確認に活用
(英語版も公開しているので、オフショアにも適用可能)
(3) チェック結果を取組みのエビデンス
として活用
(4) IoT製品の安全性を説明する
営業ツールとして活用
3-3.IoT高信頼化要件の具体化
施策1
施策2
施策3
IoT高信頼化要件を検討(~3末までWG)
⇒議論の模様は、HP上で公開
分野間連携実証実験(実施中)
⇒次ページ
IoTの利用時品質を検討(~3末までWG)
⇒議論の模様は、HP上で公開
ORiN
FA機器
①H27年度:開発指針に記載した対策例に関して、特定分野を対象に対策技術の実装例を確認
②H28年度:国内異分野の情報連携環境での高信頼化機能の実証
③H29年度:海外連携に拡大。⇒IESE(独国)と趣旨同意し、検討に着手
・特定分野の実装例を先導的に示すことで、各分野での普及展開を図る
・分野間連携や海外連携を通じて仲間作りを行い、標準規格化につなげる
PC
PC
FA機器
FA機器
①FA分野のORiNで実証実験を実施(H27年度)
③OPC-UAとの連携:IESE(独国)との共同実験を提案
(H28年度に仕様検討、H29年度実証試験開始を想定)
目的
拡
大
異分野連携
OPC-UA
FA機器
FA機器
拡
大
海
外
連
携
②他分野との連携(H28年度に実施)
ECHONET Lite
スマート家電
IESE:
独国フラウンホーファ協会実験的
ソフトウェアエンジニアリング研究所。
独国のIoT推進の中心。
実証実験の内容
・接続の妥当性判断
・障害の早期発見
・障害の波及防止
(異常機器の遮断)
施策2関連:今回の実証実験の位置づけ
GW/コントローラー
スマート家電
3-4.国際標準化に向けた活動
施策1
施策2
施策3
産業界を中心とした提案体制の整備
・国のフォロー 日米協力、日独協力
・IPAの支援体制
米独機関との仲間作り
・米国 NIST、IIC
・独国 RAMI
提案規格の内容とレベル合わせ
⇒後述(各規格類の比較)
IoT 推進勢力図
規格/団体
概要
主要参加メンバー等
共
通
・
汎
用
規
格
IEEE P2413
IoT に お い て ド メ イ ン 横 断 の プ ラ ッ ト
フォームを検討
-ISO/IEC 30141
JTC1 SWG5の後をうけてWG10でリファ
レンスアーキテクチャを検討
-NIST CPS PWG
CPSのFramework検討のためのPublic
WG
-oneM2M
世界の主要7標準化団体の共同プロ
ジェクト。従来の垂直統合型M2Mサー
ビスを共通PFで水平統合型に展開
Continua、HGI、OMA等業
界団体約200社
代
表
的
な
業
界
別
・
特
定
規
格
Industrie 4.0
ドイツ政府が製造業のイノベーション政
策として主導
Siemens 、 Bosch 、 SAP 、
他
IIC
エネルギー、医療、製造、運輸、行政に
焦点
GE、AT&T、IBM、Cisco、
Intel等、約150社
AllSeen Alliance
家電製品、モバイル端末向け規格
Qualcomm 、 LG 、 MS 等 、
約50社
OCF
家庭、企業における多様なデバイス間
の相互運用のための規格
Intel 、 サ ム ス ン 電 子 、
Cisco、MS、他
HomeKit
iOS(スマホ)と機器をつなぐ規格
Apple、他約20社
Industrie 4.0
Industrial Internet
現状の標準化への課題
・アーキテクチャの構造の違いからくるIoTの世界の意識合わせ
→ アーキテクチャのすり合わせ
→ 言語 (Vocabulary)の統一
→ 統一したセキュリティ・セーフティの規定
IIRAとRAMIの補完関係
[出典]IIC
日米独のIoT開発に関するアーキテクチャ比較
抽象度
日本
米
独
要求、推奨
アクション
開発指針
NIST CPS
Framework
⇒日米比較はPart1
I4SG
⇒未
アーキテク
チャ、仕様
IoT高信頼化要
件(開発指針
の技術参考)
IISF・IIRA・IIoT
⇒日米比較はPart2
RAMI4.0
⇒日独比較はPart3
IoT関連で、各国がセキュリティ・セーフティ等に関して順守すべきアーキテクチャー、要求、
仕様を、日(IoTセキュリティガイドライン≒つながる世界の開発指針)、米(NIST CPSや
Industrial Internet Consortium)、独(インダストリー4.0)で発表している。これらの関係
を示すとおおむね以下の通り。
参考としたのは、米ではNISTが官民共同タスクフォースで作成したNIST CPS Framework、
Industrial Internet Consortiumが作成した開発スコープ IIRA(Industrial Internet
Reference Architecture)、そのセキュリティ要件 IISF(Industrial Internet Security
Framework)、開発の視点を整理したIIoT(Industrial IoT)。独では、Industrie4.0PFが策定
したアーキテクチャモデル RAMI4.0(Reference Architecture Model for Industrie 4.0)、
現在策定中のI4SG(Industrie 4.0 Security Guidelines)(想定)。
【Part1】NIST CPS Frameworkと開発指針の主な対応関係
① NIST CPS FrameworkのTrustworthinessではCybersecurity、Privacy、Safety、Reliability、
Resilienceが対象となっているが、開発指針ではCybersecuriy、Safety、Reliability
② Trustworthinessのうち、Safety、Reliability、ResilienceについてはV1.0版では未記載
③ Trustworthinessについて、OpportunitiesとDesign Responseは指針レベルまでなっておらず、
Challenges中心
④ Cross Property Risk Managementについては、開発指針では指針10でCybersecurityと
Safetyの設計の整合性について記載
CPS Cybersecurity and Privacy Risk
Cybersecurity challenges
Privacy challenges
Opportunities
Design Response
Cross Property Risk Management
Safety(未記載)
Reliability(未記載)
Resilience(未記載)
【NIST CPS Frameworkにおける
Trustworthiness】
【開発指針】
①
②
③
④
(参考)NIST CPS Framework
CPSが適用されるDomains、システムエンジニアリングプロセスの責任分界点を示すFacets、
Aspects、Facets横断的な関心事(Concerns)を示すFacetsで整理
TrusworthinessではCybersecurity、Privacy、Safety、Reliability、Resilienceをカバー
•
ただし、V1.0の段階ではSafety、Reliability、Resilienceについては記載されていない
NISTのCPS Frameworkは課題中心に記載し
ており、指針レベルまでは記述していない。
開発指針は、課題と対応指針の両方を記載し
ている
【Part2】IISF等と開発指針の対応関係
IoT高信頼化要件
NIST CPS Framework
IISFはセキュリティ等の機能要件を示
しており、開発指針の具体化として検
討中の「IoT高信頼化要件」が対応
IIRA Functional Viewは概念構成を、
IIoT System Viewはシステムのレイヤ
構造を示したもので、IoT高信頼化で検
討中のIoTの「基本モデル」が対応
IISF,IIRA,IIOTの関係
(上位概念の整理)
(参考)IIC Security Framework(IISF)
Industrial IoT(II
oT)=IT+OT(図1参照)のためのフレームワーク
•
IIRAから拡張されてNIST CPS Frameworkと同様にTrustworthiness(Security, Safety,
Reliability, Resilience, Privacy)が対象となっている
•
参考:IIRAでは「Safety」と、「Security、Trust and privacy」という分類
対象読者は、オーナー、オペレータ、システム、システム構築者、ビジネス判断をする者、
アーキテクト、セキュリティに関するステークホルダー
IIRAのFunctional Viewとの関係は図2。IISFの構成要素は以下
• Security Model & Policy
⁃
Data Protection
Security & configuration Management,
Security Monitoring & Analysis
Communication & Connectivity Protection
Endpoint Protection(Edge-Cloud)
図1
図2
【Part3】RAMI4.0と開発指針の比較
【RAMI4.0の3つの軸】
(※RAMIを議論の対象領域を示すためのものとして捉えた)
レイヤ
バリューチェーン
ライフサイクル
階層レベル
ビジネス、
機能
、
情報、
通信、統合、設備
バリューチェーンライフサイクルと、
開発指針のライフサイクルはほぼ同様
RAMIでは、左記に示す7個のレイヤを考
えているが、開発指針ではビジネスを除
くレイヤに相当
市場を除く階層が、開発指針と対応
企画、試作、設計、製
造、使用
市場、
企業、部門、工
程、制御、計測、製造
【つながる世界の開発指針】
IoT高信頼化要件
ERP
基幹システム
MES
製造実行システム
SCADA
生産監視制御システム
PLCシーケンサ
機器制御装置
I/O入出力
FA機器、センサー等
(参考)Reference Architecture Model for Industrie 4.0
(RAMI4.0)
「RAMI4.0」をもとに経済産業省が作成した図(左図)に右図説明を追記。
【出典】経済産業省2015年度版ものづくり白書本文
http://www.meti.go.jp/report/whitepaper/mono/2015/honbun_pdf/pdf/honbun01_03_02.pdf
RAMI4.0はスマートグリッドアーキテクチャモデル(SGAM)を踏襲した立方体の形式で定義
•
立方体の横方向はPLM(プロダクト・ライフサイクル・マネジメント)。
•
立方体の奥行方向はTIA(トータリー・インテグレイティッド・オートメーション)。
•
立方体の垂直方向は相互接続の求められるサービスや機能をそれぞれのレベルに応じて配
置することを意味する。
製品
設計
生産
設計
生産管理・
在庫管理
実行系/計画系/統合計画
販売
管理
保守・保全
アフター
サービス
TIA
PLM
ご清聴ありがとう
ございました。
対象製品名称: 記入者部署・氏名: 記入日: 年 月 日 ポイント チェックポイント (プルタブ)実施状況 概要 (ドキュメント名)エビデンス 記入日 備考 1)つながる世界のセーフティに係る基本方針は策定/ 周知/実現状況把握/見直しされているか 未着手 セーフティの基本方針はあるが、つながる世界は未対応。 2015/11/9 2)つながる世界のセキュリティに係る基本方針は策定/ 周知/実現状況把握/見直しされているか 対策中 策定、周知を図っており、現在、実現状況を把握中。 2015/11/9 2015年12月中に完了予定。 1)つながる世界のセーフティに係る基本方針は策定/ 周知/実現状況把握/見直しされているか 2)つながる世界のセキュリティに係る基本方針は策定/ 周知/実現状況把握/見直しされているか 1)問題の検討や対策のための体制は整えられているか 2)問題への対策を検証・評価するための環境は整えら れているか 3)人材の確保を行っているか 4)人材の育成を行っているか 1)社員が内部不正に走る要因を把握しているか 2)内部不正の抑制や対策を検討しているか 3)関係者のミスを防ぐ対策を検討しているか 4)ミスがあっても安全安心を守る対策を検討しているか 1)守るべき情報を特定しているか 2)守るべき本来機能を特定しているか ②つなげるための機能(IoT機能)についても、本来機能や情報の 安全安心のために、守るべきものとして特定する。 3)守るべきIoT機能を特定しているか 1)機器やシステムがIoTにつなげられた場合のリスクを 検討しているか 2)クローズドなネットワーク向けの機器やシステムも対 象としているか 3)保守時のリスクを想定しているか 4)保守用のツールの悪用によるリスクを想定しているか 1)脅威や故障の影響がつながりにより波及するリスクを 想定しているか 2)複数のIoTに共同利用された場合のリスクを想定して いるか 3)対策レベルが低い機器やシステムが攻撃の入口にな るリスクを想定しているか 4)対策レベルが低い機器やシステムを特定しているか 1)盗まれたり紛失したIoT機器等に起因するリスクを想 定しているか 2) 管理者のいない場所で物理的に攻撃されるリスクを 想定しているか 3)廃棄された機器等から守るべきものを読み出されるリ スクを想定しているか 4)中古の機器に不正な仕組みが埋め込まれているリス クを想定しているか [指針4] 守るべきものを特定する [指針6] つながりで波及するリスクを想 定する [指針7] 物理的なリスクを認識する 記 載 例 ①つながる世界における安全安心上の問題を統合的に検討でき る体制や環境を整える。 [指針2] 安全安心のための体制・人材を 見直す ②そのための人材(開発担当者や保守担当者など)を確保・育成 する。 指針 ①経営者は、つながる世界の安全安心の基本方針を企業として 策定し、社内に周知するとともに、継続的に実現状況を把握し、 見直していく。 [指針1] 安全安心の基本方針を策定す る [指針1] 安全安心の基本方針を策定す る ①経営者は、つながる世界の安全安心の基本方針を企業として 策定し、社内に周知するとともに、継続的に実現状況を把握し、 見直していく。 ②保守時のリスク、保守用ツールの悪用によるリスクも想定す る。 [指針5] つながることによるリスクを想定 する ①セキュリティ上の脅威や機器の故障の影響が、他の機器とつ ながることにより波及するリスクを想定する。 ①盗まれたり紛失した機器の不正操作や管理者のいない場所で の物理的な攻撃に対するリスクを想定する。 ①クローズドなネットワーク向けの機器やシステムであっても、IoT コンポーネントとして使われる前提でリスクを想定する。 ②中古や廃棄された機器の情報などの読み出しやソフトウェアの 書き換え・再販売などのリスクを想定する。 ②特に、安全安心対策のレベルが低い機器やシステムがつなが ると、影響が波及するリスクが高まることを想定する。 分 析
つながる世界の開発指針チェックリスト Ver.1.00
[指針3] 内部不正やミスに備える 方 針 ①つながる世界の安全安心を脅かす内部不正の潜在可能性を 認識し、対策を検討する。 ②関係者のミスを防ぐとともに、ミスがあっても安全安心を守る対 策を検討する。 ①つながる世界の安全安心の観点で、守るべき本来機能や情報 などを特定する。1)外部インタフェース経由のリスクに対して対策を検討 しているか 2)内包リスクに対して対策を検討しているか 3)物理的接触によるリスクに対して対策を検討している か 4)守るべきものの重要度に応じた対策が行われている か ②個々のIoTコンポーネントで対応しきれない場合は、それらを含 む上位のIoTコンポーネントで対策を検討する。 5)上位のIoTコンポーネントで対策を検討しているか 1)異常を検知できる設計を検討しているか 2)異常検知の方法は妥当か、負荷が増加しないか 3)異常を検知したときに最初にやるべきことを検討して いるか 4)異常の影響の波及を抑止する設計を検討しているか 5)機能を縮退した上で動作を継続する設計を検討して いるか 6)再起動・再接続する設計を検討しているか ①安全安心を実現するための設計を見える化する。 1)設計の見える化をしているか ②安全安心を実現するための設計の相互の影響を確認する。 2)セーフティとセキュリティの対策は、しているか 相互の影響を確認 [指針11] 不特定の相手とつなげられて も安全安心を確保できる設計をする ① IoTコンポーネントがつながる相手やつながる状況に応じてつ なぎ方を判断できる設計を検討する。 1)つながる相手やその状況に応じてつなぎ方を判断で きる設計を検討しているか 1)関係する指標や基準により検証・評価を行っているか 2)運用関係者等から得た新たな脅威やハザード情報を 元に再評価を行っているか ①自身の状態や他機器との通信状況を把握して記録する機能を 検討する。 1)ログを記録する機能を検討しているか ②記録を不正に消去・改ざんされないようにする機能を検討す る。 2)ログの記録を守る機能を検討しているか 1)アップデート機能の搭載を検討しているか 2)アップデート機能に起因する負荷や脅威などの影響 の低減を検討しているか 1)欠陥や脆弱性、事故やインシデントの最新情報を収 集しているか 2)収集した情報を適切な手段で分析しているか 3)収集した情報や分析結果を社内の関係者と共有して いるか 4)収集した情報や分析結果を必要に応じて外部に発信 しているか 1)導入時のセキュリティ対策の周知を図っているか 2)運用・保守時のセキュリティ対策の周知を図っている か 3)リユース・廃棄時のセキュリティ対策の周知を図って いるか ①不用意なつなぎ方や不正な使い方をすると、自分だけでなく、 他人に被害を与えたり、環境に悪影響を与えたりするリスクがあ ることを一般利用者に伝える。 1)不用意なつなぎ方や不正な使い方によるリスクを利 用者に伝えているか ②安全安心を維持していくために一般利用者に守ってもらいたい ことを伝える。 2)安全安心のためのいるか お願いや注意点を利用者に伝えて [指針10] 安全安心を実現する設計の整 合性をとる [指針8] 個々でも全体でも守れる設計を する [指針16] 出荷後の関係事業者に守って もらいたいことを伝える ①導入、運用、保守、廃棄で守ってもらいたいことを直接それらの業務に関わっている担当者や外部の事業者に伝える。 運 用 [指針13] 自身がどのような状態かを把 握し、記録する機能を設ける [指針15] 出荷後もIoTリスクを把握し、情 報発信する [指針14] 時間が経っても安全安心を維 持する機能を設ける 設 計 [指針17] つながることによるリスクを一 般利用者に知ってもらう ①経年で増大するリスクに対し、アップデートなどで安全安心を 維持する機能を検討する。 保 守 ①欠陥や脆弱性、事故やインシデントの最新情報を常に収集・分 析する。 ②必要に応じて社内や関係事業者、情報提供サイトなどへリスク の情報を発信し共有する。 ①外部インタフェース経由/内包/物理的接触によるリスクに対 して個々のIoTコンポーネントで対策を検討する。 [指針9] つながる相手に迷惑をかけない 設計をする ①つながる機器やシステムは、IoTならではのリスクも考慮して安 全安心の設計の検証・評価を行う。 [指針12] 安全安心を実現する設計の検 証・評価を行う ①IoTコンポーネントの異常を検知できる設計を検討する。 ②異常を検知したときの適切な振る舞いを検討する。