Comments
Description
Transcript
平成26年度サイバーセキュリティ経済基盤構築 事業
平成２６年度サイバーセキュリティ経済基盤構築 事業（スマートメーター・システムのセキュリテ ィ評価手順に係る検討） 報告書 みずほ情報総研株式会社 目次 はじめに ....................................................................................................................... 1 報告書の目的 ................................................................................................................ 1 報告書の概要（エグゼクティブ・サマリー） ............................................................... 2 第 1 章 海外調査........................................................................................................... 4 1.1. 調査概要................................................................................................................ 5 1.2. その他の調査 ........................................................................................................ 5 1.3. 海外調査................................................................................................................ 6 1.3.1 米国・欧州各国の基準・検査機関・法整備等の現状 ................................... 6 1.3.2 米国における実地調査 ................................................................................11 1.3.3 欧州オランダにおける実地調査 ..................................................................30 1.3.4 欧州フィンランドにおける実地調査 ...........................................................33 1.3.5 その他の調査の詳細 ...................................................................................40 第２章 スマートメーター・システムのリファレンスモデルの構築 ........................... 45 2.1. メタモデルの説明 ............................................................................................... 46 2.1.1 メタモデルの位置付け ................................................................................46 2.1.2 メタモデルの利用と効果 ............................................................................47 2.1.3 提案で用いる UML 記法の解説 ..................................................................49 2.1.4 メタモデル構築の方針 .................................................................................50 2.1.5 メタモデルの全体象 ...................................................................................53 2.2. リファレンスモデルについて .............................................................................. 54 2.2.1 国内の利用環境に対応したリファレンスモデル .........................................54 2.2.2 海外事例との対比 .......................................................................................55 2.3. コンセプトモデルについて ................................................................................. 55 2.3.1 セキュリティに関連する諸概念のモデル....................................................55 2.3.2 海外事例との対比 .......................................................................................56 2.4. 本基準案で提示するセキュリティ対策のモデル.................................................. 57 2.4.1 セキュリティ対策のモデル .........................................................................57 2.4.2 セキュリティ評価のモデル .........................................................................58 2.5. 提案するメタモデルの詳細説明 .......................................................................... 59 2.5.1 リファレンスモデル関連モデル群 ..............................................................59 2.5.2 コンセプトモデル関連モデル群 ..................................................................60 2.5.3 セキュリティ基準案関連モデル群 ..............................................................61 2.5.4 NIST IR 7628 のメタモデルと提案メタモデルとの比較 .............................62 2.5.5 提案メタモデルの妥当性の検証 ..................................................................69 第３章 我が国の状況に適したセキュリティ評価手順等の検討 .................................. 74 3.1. スマートメーター・システムに関連する脅威 ..................................................... 75 3.1.1 スマートメーター・システムに関連する脅威の考え方...............................75 3.1.2 脅威の検討方法 ..........................................................................................75 3.2. スマートメーター・システムのセキュリティ対策 .............................................. 75 3.2.1 セキュリティ対策の策定 ............................................................................75 3.2.2 セキュリティ対策の検討 ............................................................................76 3.2.3 対策評価の検討項目 ...................................................................................77 3.2.4 管理基準（案）のフォーマット ..................................................................77 3.2.5 事業者における管理基準（案）の活用 .......................................................78 第４章 スマートメーター・システムのセキュリティ検証を支援するツール環境のデー タベース化.................................................................................................................. 79 4.1. 検証ツールの調査と DB 化 ................................................................................. 79 4.1.1 DB 化の作業................................................................................................79 4.2. ツールの調査 ...................................................................................................... 81 4.2.1 調査概要 .....................................................................................................81 4.2.2 調査にあたってのツールの分類 ..................................................................82 4.2.3 規格・標準・ガイド類について ..................................................................87 4.3. ツールの活用事例の調査 ..................................................................................... 89 4.3.1 解析型ツールの活用事例 ............................................................................91 4.3.2 疑似攻撃型ツールの活用事例 ...................................................................103 4.3.3 証拠保全型ツールの活用事例 ...................................................................106 4.4. ツール提供企業へのインタビューによる調査 ................................................... 112 4.5. 検証ツールの利用シナリオの作成 ..................................................................... 113 4.5.1 スマートメーター・システムの開発・運用プロセス ................................114 4.5.2 開発・運用プロセスと検証ツールの利用シナリオ....................................116 4.6. 検証ツールのデータベース（DB）化 ............................................................... 122 4.6.1 検証ツールの一覧 .....................................................................................122 4.6.2 データベースの見方 .................................................................................123 はじめに 報告書の目的 スマートメーター・システムの導入を推進する米国や欧州では、スマートメーターを取 り巻く環境を考慮して参照すべきセキュリティ要件や評価手順等を国が関与して定め、ス マートメーターのセキュリティを確保する取り組みが進められている。スマートメータ ー・システムとは、スマートメーターと電力事業者をつなぐ、スマートメーターを含む機 器やネットワークで構成されるシステムである。我が国では、電力事業者がそれぞれ、既 存の海外基準等を参考としながら、スマートメーター・システムの導入を進めている。 我が国で今後導入が進むスマートメーター・システム及び想定されるリスクを踏まえる と、スマートメーター・システムの導入で先行する諸外国の取り組み状況を調査した上 で、我が国のスマートメーター・システムを取り巻く環境・リスクを考慮して、参照すべ きセキュリティ評価手順等を検討する必要がある。また、どのような機関が、どのように して評価手順を策定しているのかについても併せて調査することが、同様の仕組みを我が 国に導入する上で大きな参考となる。 図 1 事業の相関図 本事業では、これらの課題について「海外調査」、「スマートメーター・システムのリ ファレンスモデルの構築」、「我が国の状況に適したセキュリティ評価手順等の検討」、 「スマートメーター・システムのセキュリティ検証を支援するツール環境のデータベース 1 化」を通じて、セキュリティを考慮したスマートメーター・システムを運用するために必 要となる対策及び評価手順を策定した。 報告書の概要（エグゼクティブ・サマリー） 第 1 章の海外調査では、スマートメーター・システムセキュリティで広く参照され ている NIST IR 7628 に記載されているモデルにおいては、社会変容への対応及びス マートグリッド・セキュリティの進歩への対応が求められている状況が判明した。一 方、このモデルは我が国の電力業界構造とは異なるモデルであるため、このモデルを そのまま我が国の基準に適用することは困難であることも判明した。この問題につい ては、第 2 章のリファレンスモデルの検討によって、我が国におけるスマートメータ ー・システムのセキュリティに関する実態調査及び本事業で設置した有識者検討会に おいて内容を精査し、我が国のスマートメーター・システムを反映したリファレンス モデルの構築及び検証を行った。 上記の結果をもとに、第 3 章にて、我が国のスマートメーター・システムのセキュ リティ対策の考え方及びセキュリティ評価の考え方を検討した。検討の結果として、 セキュリティ管理基準案を示した。さらに、米国の NIST の調査によると、セキュリ ティ管理の基準の他にも評価のための手引書（アセスメント・ガイドライン）が求め られている状況であり、我が国における評価の考え方について検討した結果をまとめ た。また、フィンランドの調査では、セキュリティ対策を検討するためには、具体的 な脅威と対策の関係及び事故からの学習も重要であることが判明し、本調査では、想 定脅威と対策の関係について検討した結果を報告する。 具体的な評価検討の一環として、第 4 章ではスマートメーターのセキュリティ検証ツ ールについて、利用可能状況、ツールの特性や機能、適用事例等を容易に検索することの できるデータベースを作成した結果をまとめた。また、検証ツールの分野ではシステムの セーフティ（機能安全）の検証ツールが、セキュリティ検証に利用できる機能や性能を有 する場合もあるため、データベースにはそれらのツールの情報を必要に応じて含めた。ツ ールの調査結果として、セキュリティ検証に可能なツールを、解析型ツール、疑似攻撃型 ツール、証拠保全型ツールの 3 種類に分類し、スマートメーター・システムの開発プロセ スを考慮して、設計＆実装フェーズ、テストフェーズ、運用フェーズでのツールの利用シ ナリオを示した。 2 図 2 成果の相関図 NIST IR 7628 の対象はスマートグリッドであり、本調査の対象であるスマートメータ ー・システムの範囲より広いこと、1 つの事業者が運営するシステムではなく、複数の事 業者が共同運営する仕組みであることから、対象となるシステムや機器、利害関係者など が大きく異なることが判明した。その中で「スマートメーター・システムの機器及び業 務」に限定して参照した。 今後、スマートメーター・システムの運用が本格的に始まる中で、海外基準をうまく取 り入れることができるモデルとするために、リファレンスモデルだけではなく、コンセプ トモデルを構築することとした。これはリファレンスモデルを策定する中で、対象となる 機器や業務、利害関係者などが変化した場合でも揺るぎない基盤を設定することで、本調 査で提示する対策や評価手順が長期にわたって利用できるようにし、目的を見失うことな く、対策の策定や評価を繰り返し実施できるようにするためである。 コンセプトモデルでは脅威やそれに伴う対策だけではなく、影響度についても取り扱っ ている。これは、事業者毎にリスクの大小を判断し、適切な対策を実施することができる ように影響度をそれぞれの事業者で判断できるようにするためである。 このようにして、脅威、影響度、セキュリティ対策という 3 つの視点で具体的な対策を 検討できるような仕組みとした。また、これらの実施状況を客観的に説明できるように評 価のポイントについても例示している。また、評価を正しく実施できるように、評価ツー ルのデータベースも策定した。 3 第 1 章 海外調査 エネルギーの自由化を先行する欧米を中心に、多くの都市や地域で、スマートメーターの 導入が進んでいる。例えば、米国では、2013 年 7 月時点で、米国世帯数の 40%を超える 4,600 万台が導入された。また、欧州では、2020 年までに 80%以上の家庭へスマートメー ターを導入するという数値目標を掲げている。また、各国でスマートメーターに関するセキ ュリティインシデントが報告されるようになり、世界的にセキュリティ対策の取り組みが 始まっている。 本事業では、海外におけるスマートメーター・システムに係る実地調査を行い、基礎デー タを収集するとともに、参考にすべき先行事例や基準を有する米国と欧州の複数国を対象 として、各国の評価手順が想定している背景（基準、規定、検査機関、法整備等）の現状を 調査した。 米国においては、メリーランド大学及び国立標準技術研究所 NIST（National Institute of Standards and Technology）を調査した。メリーランド大学（Atif Memon 教授）では、 スマートメーター・システムを対象とした、システム検証技術、セキュリティ確保のための テストや検証の技術、及びツールを用いたテストや検証の自動化が重要であることが判明 した。さらに、NIST（Victoria Pillitteri、 Michaela Iorga 他）では、NIST IR 7628 作成 者への調査によって、NIST IR 7628 において記載されているモデルやいくつかの想定は、 社会変容への対応及びスマートグリッド技術の進歩への対応が必要なため、環境の基づい た定期的な見直しが重要であることが判明した。また、基準の他に評価のための手引書（ア セスメント・ガイドライン）が必須であり、米国では NIST SP 800-37 の利用を想定してい た。 オランダにおいては、欧州サイバーセキュリティ非営利組織 ENCS（European Network for Cyber Security）を対象に、スマートメーター・セキュリティの第三者検証、人材育成 等について調査した。欧州の各国では、セキュリティに問題のある機器の製造者に対する罰 則を科す制度が施行され始めていた。しかし、制度施行後も、安価なスマートメーターによ る実装ミス、ファジング・テスト時の機器の異常停止などが頻発しており、脆弱性を調査す る第三者機関や検査を支援する自動化ツールの整備が重要であると考えられる。欧州全体 としては、スマートメーターの製造コストの削減要求が強く、セキュリティ機能の強化や改 善は後手に回っている。一方、ドイツでは、通信モジュールを対象とした、コモンクライテ リアをベースとした独自認証を義務化し、セキュリティ確保を実現している。その結果、欧 州域内で開発コストに 10 倍の差が生じており、欧州各国の足並みが揃わない状況であった。 スマートメーターに対する想定脅威とリスクに関する情報は、ENCS が関与して管理され ている。共有が必要な情報は、ENCS 発行のホワイトペーパーを通じて会員に配布される など、具体的な脅威情報を収集・管理・共有の方法が重要であると考えられる。 フィンランドにおいては、Codenomicon 社及び Finland National CERT を調査した。 Codenomicon 社では、ファジングツール Defensics（通信耐性テスト用の疑似攻撃ツール） 開発を行っている。第三者検証のために、通信耐性テスト用の疑似攻撃ツールを利用する場 合は、併せて既知の脆弱性テスト用の疑似攻撃ツールを利用することが推奨される。 4 Codenomicon 社では、既知の脆弱性テストのために開発した AppCheck がすでに利用可能 である。通信プロトコルの独自仕様への対応について、国内企業とツールベンダとの技術提 携なども計画していた。Codenomicon 社のツールを活用した調査研究やインシデント対応 を行っている Finland National CERT では、監視を通じた「情報収集」段階から「識別（ト リアージ）」さらに「報告作成（リポーティング）」の完全自動化も推進されており、広範 な対象の監視を行うために国内法を整備すること、具体的な脅威と事故との関連性を示す こと、一連の手続きでボトルネックを作らないことが重要であることが判明した。 1.1. 調査概要 本調査は、先行事例や基準を有する米国と欧州を対象とした。海外でのオンサイト調査は、 次に示す調査 1（米国 7 件） 、調査 2（オランダ 1 件） 、調査 3（フィンランド 3 件）からな る。 調査 1－① 調査 1－② 調査 1－③ 調査 1－④ 調査 1－⑤ 調査 1－⑥ 調査 1－⑦ Atif Memon（メリーランド大学・教授） システム検証技術 Michaela Iorga、Victoria Yan Pillitteri （NIST） クラウドセキュリティ Hildegard Ferraiolo（NIST） 内部不正対策 Victoria Pillitteri、Michaela Iorga（NIST） NISTIR 7628、7823 Andrew Regenscheid（NIST） ハードウエア・ルート・オブ・トラスト Michael Cooper（NIST）暗号モジュール認証プログラム及び自動化試験 David Waltermire（NIST）連続モニタリング、ソフトウエア ID、セキュリ ティ対策の自動化 調査 2－① ENCS スマートメーター・セキュリティの第三者テスト、セキュリティ 人材育成 調査 3－① Codenomicon ファジングツール開発の現状 調査 3－② Codenomicon Cybersecurity Center インシデント対応 調査 3－③ Oulu University ファジング技術、セキュア・ネットワーク技術他 1.2. その他の調査 海外オンサイト調査に併せて、イギリスから来日していたメタモデリング技術の専門家 Tim Kelly（ヨーク大学・教授）に対して、スマートメーター・セキュリティを取り巻く我 が国の環境をモデル化する技術と、その適用のあり方について、国内でヒアリングによる調 査 を 実 施 し た 。 Tim Kelly 教 授 の 研 究 及 び 専 門 に つ い て は 、 ホ ー ム ペ ー ジ （http://www.cs.york.ac.uk/people/tpk）を参照されたい。 5 1.3. 海外調査 1.3.1 米国・欧州各国の基準・検査機関・法整備等の現状 米国・欧州各国の状況（組織・機関） 米国では、2009 年に、官民交流を目的とした団体 SGIP（Smart Grid Interoperability Panel スマートグリッド相互運用性パネル）を発足した。NIST の協力の下、2010 年に、 SGIP の下部組織 CSWG（Cyber Security Working Group）が米国のスマートグリッド・ セキュリティ標準 NISTIR 7628 を作成し、2014 年に NISTIR 7628 を改訂した。また、 NERC（North American Electric Reliability Corporation 北米電力信頼度協議会）は、2006 年 に は 電 力 安 定 供 給 に お け る セ キ ュ リ テ ィ 対 策 基 準 CIP （ Critical Infrastructure Protection）を作成し、2008 年に FERC（Federal Energy Regulatory Commission 連邦 エネルギー規制委員会）の承認を受け、2009 年に NERC CIP を発行した。 欧州の状況は、各国毎に異なる。ドイツでは、BSI（Federal Office for Information Security 連邦電子情報保安局）が、スマートメーター・ゲートウェイ（日本のスマートメ ーターでは、通信モジュールに相当）に対して、国際規格であるコモンクライテリア （Common Criteria、以下 CC）に基づくプロテクションプロファイルを作成し、セキュリ ティ認証を義務化している。CC 認証は、エネルギー産業法及びエネルギーパッケージ（独 連邦議会で可決）で義務化が定められている。セキュリティの水準は EAL4+ と定められ ている。EAL4+とは、CC の評価保証レベル EAL Level 4 に求められる要求に加えて、脆 弱性分析の要求が加味されたテストとレビューを行う。 英国では、DECC（Department of Energy & Climate Change エネルギー・気候変動省） が、2012 年に電力とガスのスマートメーターのセキュリティ要求（SMETS 1）を策定し、 2014 年に改訂した。このセキュリティ要求は、認証制度 CPA（Commercial Product Assurance）で参照される。国の機関である CESG（Communications-Electrics Security Group 通信電気セキュリティグループ）は、CPA の認証仕様を参照して、Smart Metering Security Characteristics と呼ばれるスマートメーターのセキュリティプロファイルを定 めた。 英国政府は、サイバー・エッセンシャルズ（Cyber Essentials）を推進している。サイバ ー・エッセンシャルズとは、政府が各機関に対し、情報セキュリティへの適切な対応を推進 するための政府計画で、2014 年に、ビジネス・イノベーション・職業技能省が策定した。 サイバー・エッセンシャルズには、ISO27001 や IASME と整合性の取れた保証の枠組みと 情報システムのためのセキュリティ管理策が含まれている。 フランスでは、CC に基づく CSPN（第一水準安全認証）という認証スキーム/認証仕様が 検討されている（http://www.ssi.gouv.fr/administration/produits-certifies/cspn/）。フラン スでは、スマートグリッドを制御システムとみなしている。軍事計画法では、重要インフラ のセキュリティ水準を高めるための行政の関与が強化された。こうした背景から、フランス 6 内閣府に設置された ANSSI（情報システムセキュリティ局）が、制御システムの等級付け （区分）の枠組みや制御システム分野における規則等を定めている。 オランダでは、配電・送電事業者団体である Netbeheer Nederland が、スマートメータ ーに対する要求事項（Dutch Smart Meter Requirements, DSMR）をまとめている。初版 では、セキュリティやプライバシーは主要な事項として扱われていなかったが、DSMR の 改訂版では、セキュリティとプライバシーの要求が付加されている。オランダでは、ドイツ と同様に CC に基づくプロテクション・プロファイル（PP）の策定を検討している。ノル ウェーやスウェーデンでも、CC に基づく PP の策定を計画している。 他の北欧や南欧の国々では、セキュリティの第三者評価または認証制度を、現在検討中で ある。 欧州連合 EU と欧州自由貿易連合 EFTA では、欧州での統一的なセキュリティ制度の整 備を推進している。欧州連合のセキュリティ専門機関 ENISA（European Union Agency for Network and Information Security 欧州ネットワーク情報セキュリティ機構）は、スマー トグリッドの EU 統一セキュリティ認証に関する提言（Smart Grid Security Certification in Europe, Challenges and recommendations, ENISA, 2014 December ： https://www.enisa.europa.eu/media/press-releases/smart-grid-security-certification-ineurope-challenges-and-recommendations）をまとめて、2014 年 12 月に公開している。 欧州における、スマートメーター・システム及びスマートグリッドのセキュリティへの対 応は、下図の通りである。 Copyright © 産業技術総合研究所 図 3 欧州各国のスマートメーター・スマートグリッドセキュリティへの対応 7 国際標準・基準と各国の対応 スマートメーター・システム及びスマートグリッド・セキュリティに関連する認証スキー ムに関連する国際基準・制度及び各国の規準・制度を、3 つのレイヤー（組織、システム、 機器）に分類した表を以下に示す。 表 1 スマートメーター・スマートグリッドに関連するセキュリティ認証スキーム レイ ヤー 組織 シス テム 機器 対象 国際基準・制度の略称 各国の基準・制度の略称 事業者 運用者 ISO/IEC 27001（基 準） IEC 62443-2-1（基準） IEC 62443-3-3（基準） SSA（民間制度） IEC 62443-4-1（基準） IEC 62443-4-2（基準） EDSA（民間制度） 英 IASME（基準） 構築事 業者 機器ベ ンダ 米 NERC CIP（業界基準） 米 NISTIR 7628（基 準） 米 CMVP（制度） 独 PP77（基準） 英 SMETS1（基準） CPA（制度） 仏 CSPN（制度） 蘭 DSMR（基準） GPRS（制度） 米 NEMA SG-AMI-1-2009 （業界基準） また、上記の表に挙げた各基準・制度の具体的内容を、以下にまとめる。 略称 名称、発行年 発行元 目的 略称 名称、発行年 発行元 目的 ISO/IEC 27001 Information technology - Security Techniques - Information security management systems, 初版 2005, 最新版 2013 年 ISO (国際標準化機構)/IEC (国際電気標準会議) 組織の ISMS を認証するための要求事項 IEC 62443 Industrial communication networks - Network and system security, 第一部分発行 2007 年, 最新部分 2013 年 IEC (国際電気標準会議) 汎用制御システムのセキュリティ 8 略称 名称、発行年 発行元 目的 SSA System Security Assurance ISCI (The ISA Security Compliance Institute) 制御システムのセキュリティの認証制度 略称 名称、発行年 発行元 目的 EDSA Embedded Device Security Assurance ISCI (The ISA Security Compliance Institute) 制御機器のセキュリティの認証制度 略称 名称、発行年 英 IASME The standard for information assurance for small and medium sized enterprises, 2013 年 IASME Consortium Limited 中小規模事業者の情報セキュリティ保証 発行元 目的 略称 名称、発行年 発行元 目的 略称 名称、発行年 発行元 目的 略称 名称、発行年 発行元 目的 米 NERC CIP NERC CIP (critical infrastructure protection)最新版 2015 年 NERC (North American Electric Reliability Corporation, 北米電力信 頼性評議会) 電力業界において重要インフラ事業遂行時に実施すべきセキュリティ規 準 米 CMVP Cryptographic Module Validation Program（暗号モジュール認証制 度）、1995 年 NIST (米国国立標準技術研究所), CSEC (カナダ通信安全保障部) 安全な暗号製品を政府調達すること 独 PP77 Protection Profile for the Security Module of a Smart Meter Gateway, Certification-ID BSI-CC-PP-0077, 2013 October Bundesamt für Sicherheit in der Informationstechnik (連邦電子情報保 安局) スマートメーター・ゲートウェイ（日本のスマートメーターでは、通信 モジュールに相当）に対する、CC（Common Criteria）に基づくプロ テクションプロファイル 9 略称 名称、発行年 発行元 目的 英 SMETS1 Smart metering equipment technical specifications: second version, Department of Energy & Climate Change, UK, 2014 November Department of Energy & Climate Change, UK, (エネルギー・気候変 動省) 電力とガスのスマートメーターのセキュリティ要求 目的 英 CPA Commercial Product Assurance, 最新版 2013 年 CESG（Communications-Electrics Security Group 通信電気セキュリ ティグループ） 商用製品の開発者に対する、製品のセキュリティの認証 略称 名称、発行年 発行元 目的 仏 CSPN Certification de Sécurité de Premier Niveau (第一水準安全認証) ANSSI (Agence nationalie de la securité des système d’information) 機器等のセキュリティ認証制度 略称 名称、発行年 発行元 目的 蘭 DSMR Dutch Smart Meter Requirements, 最新版 2011 年 Netbeheer スマートメーターの機能要求 略称 名称、発行年 米 NEMA SG-AMI-1-2009 NEMA SG-AMI 1-2009, Requirements for Smart Meter Upgradeability, 2009 年 NEMA (米国 National Electrical Manufacturers Association) 現地、及び遠隔でのスマートメーターのソフトウエア更新の要求 略称 名称、発行年 発行元 発行元 目的 略称 名称、発行年 発行元 目的 米 NISTIR 7628 NISTIR 7628 Guidelines for Smart Grid Cyber Security, 初版 2010 年, 改訂版草稿 2014 年 NIST (米国国立標準技術研究所) スマートグリッドのセキュリティ要求 10 1.3.2 米国における実地調査 ●調査 1－① システム検証技術 訪問日時： 2015 年 2 月 4 日（水曜） 訪問先： メリーランド大学 訪問対象：Atif Memon （メリーランド大学教授） 訪問先・対象の概要： スマートメーター・システムのセキュリティを確保するためには、次の 3 種類の検証が 必要である。 ・ Conformance testing：セキュリティ要求を満たすシステムであることの確認。 ・ Functional testing：セキュリティ機能が正しく実装されていることの確認。 ・ Interoperability testing：機器同士の接続性に異常がないことの確認。 Memon 教授は、ソフトウエア工学とエンピリカル・ソフトウエア工学の分野において、 メリーランド大学計算機科学科を拠点として、テスト技術と検証技術の研究を高いレベル で 実 施 し て い る 。 Memon 教 授 の 研 究 及 び 専 門 に つ い て は 、 ホ ー ム ペ ー ジ （http://www.cs.umd.edu/~atif/）を参照されたい。 調査 1－①の概要： テストや検証についての技術とツールの現状、及び過去の産業界におけるプロジェクト での経験について、Memon 教授へのヒアリングにより調査した。また、ATM やクレジッ トカードリーダに適用した Memon 教授のテスト技術がスマートメーターにも適用可能か 等、機器レベルのテスト技術の最新動向について情報を収集した。 インタビュー対応者： Adam Porter（UMD, Fraunhofer） Atif Memon（Computer Science Department） Rance Cleveland（UMD, Fraunhofer） Mikael Lindvall（Fraunhofer） Alan Sussman (UMD) Dieter Rombach（Fraunhofer） インタビューまとめ： 11 テストとアンドロイド・ソフトウエア・プラットフォームの専門家である Adam Porter 教授（UMD、Fraunhofer）の意見は、以下の通りである。 もし全てのスマートメーターが同じプラットフォーム上に実装されると、特定の脆弱性 が全国的に影響を及ぼすことになるというソフトウエア・モノカルチャーの問題が発生す る。一方、各電力会社は大きな顧客基盤を持つため、たとえ機種が異なるスマートメータ ーが配備されたとしても、それらに対する攻撃が及ぼす影響は大きい。従って、プラット フォームの数を制限することで開発コストを共有するのが良いかもしれない。 Android OS について興味深いのは、過去 10 年で多くのハードウエアプラットフォー ムが登場したことである。ハードウエアベンダは必ずしも古いハードウエア上で新しい 版の Android OS をサポートできるわけではない。その結果、最低でも 6 種類の版（及び それぞれについてのマイナーリビジョン）の Android OS が、最新のものから 5 年前の ものまでの各プラットフォーム上で使用されるという状況になっている。 参考 https://developer.android.com/about/dashboards/index.html ただし、基本機能はここ数年で落ち着く傾向にあるので、今後出る新しい版では機能追 加や既存機能の洗練がなされることになるだろう。もしスマートメーター・ベンダが、 （信頼性のための）必須の機能と（より良いユーザ経験やビジネスユースのための）オプ ショナル機能とを注意深く区別すれば、たとえソフトウエアが進化し続けても、長いハー ドウエア寿命を達成することが可能であろう。 Android OS には、互換性維持のため満たすべきコア・テストセットがある。従ってソ フトウエア・プラットフォームの高度な自動テストがスマートメーターについても重要 なゴールとなる。 次に、ソフトウエアテストの専門家である Atif Menon 教授（UMD）の意見は、以下 の通りである。 ケーブルテレビのセットトップボックスを開発した経験から、いかにして比較的長寿 命の製品を開発するかについての示唆を得られた。しかし、セットトップボックスは、ス マートメーターに比べると、寿命も短く信頼性もさほど重要ではない。 テストに関しては、もし入力空間が既知であり（かつ機械可読なモデルで表現されてい れば）、テストの自動化が現在のところうまくいっている（常にとは言えないまでも）。 入力空間の発見を行う実験的なテストツールの研究から得られた概念は、スマートメー ター・ネットワークにも応用できる。ネットワーク構成は動的であるため初期時にはその 構成は不明である。そこで、主となるテストケースから始め、テストケースの生成中に新 しいスマートメーターへの可能な接続を"sniff out" (嗅ぎ出す)ことである。また、スマー トメーター・ネットワークの監視についてもアイデアがあり、研究の 1 つとして、各ユ ーザのプロファイルを作成することで通常の動作からの逸脱を検出するということを行 っている。現在、米国陸軍システムの監視にこの手法が使われており、スマートメータ ー・ネットワークにも応用可能なはずである。 12 次に、自動車システムの専門家である Rance Cleveland 氏（UMD、Fraunhofer）の意 見は、以下の通りである。 家電機器はそれぞれ特有の電力消費パターンを持つため、旧式の単純な装置によって も、各家庭がどんな機器（古い家電機器も含め）でどのくらい電力を消費しているかの情 報を集めることが可能である。 各デバイスが中央の政府組織によってテストし保証されるべきか、それとも独立した 組織によってなされるべきかという問題もある。 また、モデルベースの開発によりソフトウエアの品質が改良され、長い目で見たらコス トを削減できることが、ケーススタディにより示された。しかし、コード生成はプラット フォームに合わせて注意深く調整する必要があり、それには専門家の知識が必要となる。 逆に、アウトソーシング開発は、高い信頼性と領域特有のノウハウを必要とするシステム には勧められない。 フランホーファー研究所の技術部長である Mikael Lindvall 氏の意見は、以下の通り である。 最近の研究において、要求の形式的解析により、要件の不完全性、抜け、重複が明らか にできることを発見した。通常、形式的解析の結果得られる要件はその過程を経ないもの より良いものになる。さらに、ドローンのセキュリティに関するプロジェクトでは、形式 的手法を用いることで無危険性を示すことができた。実際、これまのでのところでは、そ のシステムは適用フィールドにおいてセキュアであることが示されている。 ソフトウエア・コンポーネント、そして特に最近は協調的テストの研究プロジェクトに 従事している Alan Sussman 教授（UMD）の意見は、以下の通りである。 大半のソフトウエア・コンポーネントは他のコンポーネントに依存するため、1 つのコ ンポーネントをテストすると他のコンポーネントの一部も実行される。そのような情報 を開発者の間で共有すれば、重複したテストが避けられるため、テストのコスト削減に役 立つ。そのようなツールは、内部的に（つまりデータを共有することなく）使う場合にお いても、複数のモジュールにまたがるテスト実行を最適化できる。また、同じ構成の異な るコンピュータについての問題にも対処できる。可視化技術を使って異なるコンピュー タが確実に同じ構成になるようにすることで、一貫したテスト結果を得るのである。この ツールは現在プロトタイプの状態であるが、オープンソースであり、同教授のプロジェク トでも利用できるかもしれない。 Dieter Rombach 氏は 10 年以上にわたってカールスルーエのフランホーファー研究所 の所長である。フランホーファー研究機構は全体では 20,000 人以上の科学者と技術者を 雇用しているが、同氏の研究所はソフトウエア工学の分野で 250 人を雇用している。同 氏の意見は、以下の通りである。 最も大きな問題の 1 つとして、安全性が重要なシステム（例えば埋め込みソフトフェ ア）は今やネットワークでつながったデータセンターと切り離せないので、そのセキュリ ティがますます重要となっていることがある。最近の研究で作成した"software safety 13 cage"は、ロボティクス由来の「フェンス」という概念をソフトウエア構成に適応したも のであり、これにより、特定のコンポーネントの更新によって他のコンポーネントが安全 でない状態に陥るという事態を避けることができる。 モデル化という作業はソフトウエア開発のプロセスに統合すべきである。もしモデル が自動的に生成されたりすると、そのモデルを人間が理解可能なものにするためのリバ ース・エンジニアリングに払わなければならない労力が、少なくとも現状の技術では、大 きくなりすぎる。メリーランドのフランホーファー研究所では、近い将来、モデルベース のテストが主な研究課題となるだろう。TUV のような未だに旧来の手法を取っている組 織においても、モデルベースのテストは、システムテストにおいて高い可能性を秘めてい る。 データ利用に関してはプライバシーが非常に重要である。データの抽象化と集合化が プライバシー問題の一部の解となるが、 （先進的なデータ解析や新しいビジネスモデルの ための）情報の可用性を、エンドユーザが期待するプライバシーのレベルとうまくバラン スさせるのは非常に難しい。スマートメーターの領域では、すでにシステムが実用化され ている医療システムから学ぶことができるかもしれない。 ヨーロッパでは、非集中的エネルギー管理システムのためのアーキテクチャを開発す るプロジェクトが実行中である。ドイツでは再生可能エネルギー（電力事業者と家庭がエ ネルギーの生産者でありかつ消費者でもあるモデル）という考え方が重要になりつつあ る。新しいエネルギー・モジュール（新しいスマートグリッドの構成要素）が既存のグリ ッドに過大な負荷を生じないよう注意すべきである。 しかし、需要と供給をバランスさせるために集中的なグリッドを使うべきか分散的な ものにすべきかについてはまだ明確な解答は得られていない。研究の結果、そのようなシ ステムの複雑かつ動的な振る舞いに対処するためには自己制御メカニズムが必要となる ことが明らかになった。 ●調査 1－② クラウドセキュリティ 訪問日時： 2015 年 2 月 5 日（木曜） 訪問先：国立標準技術研究所 NIST - Computer Security Division (CSD) 訪問対象： Michaela Iorga、Victoria Yan Pillitteri 訪問先・訪問対象者の概要： NIST は、1901 年 7 月に国立標準局（National Bureau of Standards）として設立 し、1988 年に改称して、現在の国立標準技術研究所（National Institute of Standards and Technology）となる。現在、6 つの研究ユニットで構成されている： エンジニアリング・ラボラトリ、情報技術ラボラトリ、材料計測ラボラトリ、物理計 測ラボラトリ、ナノスケール科学技術センター、中性子研究センター。 NIST は米国内のスマートグリッド・サイバーセキュリティ問題に対応する方針を定 めるため、国内外から広く意見を集め、スマートグリッド・サイバーセキュリティ・ガ 14 イドライン NISTIR 7628（Guidelines for Smart Grid Cyber Security）を編纂、公開し ている。他にもサイバーセキュリティ関連文書やクラウドコンピューティング関連文書 を公開している。 NISTIR 7628 等のセキュリティ関連規約は、情報技術ラボラトリのコンピュータセ キュリティ部門（Computer Security Division）が主に担当する。現在、コンピュータ セキュリティ部門は、以下の 5 グループで構成されている： Cryptographic Technology Group (CTG) Security Components and Mechanism Group (SCMG) Secure Systems and Applications Group (SSAG) Security Outreach and Integration Group (SOIG) Security Testing, Validation and Measurement Group (STVMG) コンピュータセキュリティ部門では、セキュリティ関連規約の作成の他に、暗号技術、 個人認証、セキュリティ設定共通化手順（Security Content Automation Protocol）等セ キュリティに関する技術開発を行っている。 Iorga 氏はクラウドコンピューティングの規格化や関連制度に従事しており、本課題 に関連する下記の文書の著者または著者の一人である。 NIST IR 8006 DRAFT NIST Cloud Computing Forensic Science Challenges NIST IR 7956 Cryptographic Key Management Issues & Challenges in Cloud Services SP 500-299 NIST Cloud Computing Security Reference Architecture Pillitteri 氏 は NISTIR 7628 の現 編集 者 であ る。 2010 年 に初 代 編集者 Lee 氏 （Annabelle Lee）が作成した NISTIR 7628 初版を、2014 年に Pillitteri 氏らが改訂し た。今後の改訂作業についても、調査時点では責任者の立場であった。 ・ NIST IR 7628 Rev. 1 Guidelines for Smart Grid Cybersecurity 調査 1－②の概要： 我が国のスマートグリッドでは、当面、スマートメーターから送られるデータは事業者 の MDMS（Meter Data Management System）に格納される。スマートメーターと MDMS 間の通信経路上においては通信傍受とデータ捏造による中間者攻撃等の脅威を 想定する必要がある他、スマートメーターに対する一種の中央監視システム SCADA （Supervisory Control And Data Acquisition）である MDMS はプライベート・クラウ ドによって提供されることから、通常のクラウドサービスに準じたリスク評価を行う必 要がある。 NISTIR 7628 初版が公開された 2010 年は、クラウドサービスの黎明期である。当時 はまだ、クラウド事業者やその利用者が関与するセキュリティ事故がほとんど表面化し 15 ておらず、脅威の特定が困難であった。そのため NISTIR 7628 初版ではクラウド利用に 対する管理策を定めていなかったが、2010 年改訂版ではクラウド利用に関するスマート グリッド特有の問題意識を列挙する内容が追加され、最新の 2014 年改訂版ではプライバ シーリスクの指摘及びセキュリティ要件分類とクラウドセキュリティの対応表が追加さ れた。しかしながら、いずれもやや高い概念レベルでの指摘に留まっており、クラウドサ ービスに関するセキュリティを詳細に記述した NIST 文書として NISTIR 7956、8006 及 び SP800-144 があるものの現時点では NISTIR 7628 には融合されていない。 我が国では、2011 年に経済産業省が、クラウドセキュリティ・ガイドラインを公開し、 クラウドサービス由来のセキュリティ事故の教訓をもとに、2014 年に改訂した。2015 年 には、同ガイドラインをベースとした国際標準 ISO/IEC 27017 が発行される。これは組 織の情報システムを対象とした情報セキュリティマネジメントシステムのガイドライン ISO/IEC 27002 のクラウドセキュリティ版ともいえる。スマートグリッド／スマートメ ーターのセキュリティの取り組みと独立してクラウドセキュリティの取り組みが存在す る点で、NIST と類似の状況にある。 クラウドサービスのリスクに対処するには、可能な限りの脅威を洗い出し、対する脆弱 性を勘案してリスクを算定し、リスクマネジメントのための評価基準を作るという、リス クベース・アプローチが主流である。NISTIR 7628 も、リスクベース・アプローチを採 用している。そこで、NISTIR 7628 の今後の改訂におけるクラウドサービスへの対応方 針について、また関連課題への取り組みについて、担当者にインタビューを実施した。 インタビュー対応者：Michaela Iorga、Victoria Yan Pillitteri インタビューまとめ： 情報セキュリティマネジメントシステムの要件規格として ISO/IEC 27001、ガイドラ イン規格として ISO/IEC 27002 があるが、NIST はそれらの範囲を併せ持つ、連邦政府 機関向けの SP 800-53A Revision 4 という文書を昨年発行した。これはクラウドに限定 するものではなく、全ての情報システムに対応するものである。クラウドセキュリティの ガイドラインは SP 800-144 である。 NIST はリスク管理フレームワークの標準規格 SP 800-37 も発行している。それに基 づきシステムの構築時にシステム管理策を決定し、実装し、その実装の評価・試験を行い、 要件を満たしていることが検証できれば認証が与えられる。運用時には連続モニタリン グによりシステムの健全性を常時確認する必要がある。しかしクラウドの場合はユーザ による実装や試験はできないので、別のリスク管理が必要となる。SP 500-299 はそのた め に ク ラ ウ ド 向 け リ ス ク 管 理 フ レ ー ム ワ ー ク （ Cloud-adapted Risk Management Framework、以下 CRMF）をまとめたドラフト文書である。この文書をまとめる作業中 に、CSA（Cloud Security Alliance クラウドセキュリティ連合）という国際的な団体が すでに標準と認証制度を開発していることがわかり、NIST はその成果も取り入れた。 16 自分でクラウドを作るのでなければ、自分の要件に合ったクラウドサービスを探す必 要がある。連邦政府機関は、FedRAMP と呼ばれる、彼らの代わりにクラウドプロバイダ を調査する機関を利 用できる。クラウドシ ステムを連邦政府機関 に販売するには FedRAMP を通す必要がある。スマートメーターに関連するクラウドの問題意識にも対 応できる。 例えば Email サービスをクラウドに移行する場合、どのような通信が行われるのか、 どのくらい機密性があるのか、どのように実装するのか、などを決めるのは自分達の責任 である。CRMF 標準はそのような決定を助けるために作成された。現在、この CRMF を 国際標準化するための準備が進められている。 これまで NIST は、欧州 CSA や日本 CSA と議論を重ね、次の方向性を検討している。 それぞれが活動の軸とする NIST SP 文書と ISO 文書でアプローチが異なるが共通点も あり、クラウドのセキュリティ SLA（Service Level Agreement サービス品質保証）、 セキュリティ指標、CCM（Cloud Control Matrix クラウド管理策対応表）の整備につ いて協力していく可能性がある。 さらには両制度間で相互承認を構築する可能性もある。この考え方はスマートグリッ ドやスマートメーターにも適用可能と考えられる。事業者のプライベート・クラウドが攻 撃された場合、その部分を効果的に隔離する必要があることに注意すべきである。 ●調査 1－③ 内部不正対策 訪問日時： 2015 年 2 月 6 日（金曜） 訪問先： 国立標準技術研究所 NIST - Computer Security Division （CSD） 訪問対象： Hildegard Ferraiolo 訪問先・訪問対象者の概要： NIST が制定した FIPS 201 は連邦政府機関や契約業者が本人認証を行うための IC カー ド＝PIV（Personal Identity Verification）カードの連邦規格文書である。連邦政府施設へ の入退室管理やアクセス認証だけでなく、電子署名のための非対象鍵暗号機能も備えてい る。 Ferraiolo 氏は NIST の FIPS 201 文書を含む PIV プロジェクト責任者であり、下記文書 の共著者・共同編集者である。 FIPS 201-2 Personal Identity Verification (PIV) of Federal Employees and Contractor SP 800-157 DRAFT Guidelines for Derived Personal Identity Verification (PIV) Credentials SP 800-85 B-4 DRAFT PIV Data Model Conformance Test Guidelines SP 800-79 2 DRAFT Guidelines for the Authorization of Personal Identity Verification Card Issuers (PCI) and Derived PIV Credential Issuers (DPCI) 17 SP 800-78-4 DRAFT Cryptographic Algorithms and Key Sizes for Personal Identity Verification SP 800-73-4 DRAFT Interfaces for Personal Identity Verification NIST IR 7981 DRAFT Mobile, PIV, and Authentication NIST IR 7863 DRAFT Cardholder Authentication for the PIV Digital Signature Key NIST IR 7817 A Credential Reliability and Revocation Model for Federated Identities 調査 1－③の概要： スマートグリッドでは、セキュリティ上重要な建物の入退室や設備のアクセスを行う者 が適切な権限を有しているか、内部不正が行われてないか、などを見極めるために、個人認 証が重要となる。PIV カードのような認証カードや関連アイデンティティ管理の取り組み は、このようなスマートグリッドの諸問題と関連があると考えられることから、調査 1－③ では、米国での電力事業者における内部不正防止に果たす認証カードの役割と、スマートグ リッド・セキュリティへの対応について、Ferraiolo 氏へのヒアリングにより調査した。 インタビュー対応者：Hildegard Ferraiolo インタビューまとめ： SP 800-157 でドラフト仕様が公表されている派生 PIV 証明物 （Derived PIV Credential） について、連邦政府職員は、印刷面の提示による顔写真付き ID 視認、連邦施設への入退場 （鍵カード）、電子システムアクセス認証や署名行為、あるいは秘匿暗号化等のため PIV カ ードを日々使用している。情報機器が小型化して常に持ち歩けるようになると、その携帯情 報機器に PIV カードの機能を持たせる方が合理的な場面が増えてきた。それには、接触イ ンターフェースや非接触インターフェース（NFC）カードリーダを通じて PIV カードの証 明物（Credential 1）を認識させる方法と、PIV カード上にない派生証明物（Derived PIV Credential）を使う方法があり、それぞれ SP 文書に規定してある（前者は SP 800-73 シリ ーズ、後者は SP 800-157）。運用はまだ開始されていない。 米国行政管理予算局（OMB）が 4 つのアイデンティティ保障レベル（LoA: Level of Assurance）を規定しており、それを利用するシステムでは重要データは高い LoA（4 が最 高）の証明物を持たないとアクセスできない。PIV カードはそれを持つ者によって異なる LoA の証明物を持つ。あるいは派生証明物を携帯機器の TPM（Trusted Platform Module） に保持させたりしてセキュリティ上の保護を施して利用する。携帯機器はそのような証明 物に対するインターフェースのみを持つこともあり、前述のように PIV カード等と組み合 わせた使い方も許容されることになる。派生証明物を持てる機器はハードウエアあるいは ソフトウエア実装された暗号モジュールを持つノート PC、 タブレット PC、 USB ドングル、 1 身元識別情報（および場合によってはそのほかの属性）と、特定の人物が所持し管理しているトーク ン（認証要求者が所持し管理しているなんらかの情報であり、通常は鍵またはパスワード等）とを公的に 結び付けるオブジェクト。 18 SD カード、UICC（=SIM）などであり、そこに収められる PKI 電子証明書が派生証明物 となる。連邦政府機関の用途では、暗号モジュールは FIPS 140 認証されている必要があ る。ハードウエア証明物は LoA4 となり、ソフトウエア証明物は LoA3 となる。 表 2 OMB M-04-04（E-Authentication Guidance for Federal Agencies）の LoA 定義 Level 1 (Low) 2 (Medium) 3 (High) 4 (Very high) 説明 Little or no confidence in the asserted identity 身元確認不要、仮名（ユーザの同一性保証）、有効期限なし 例：whitehouse.gov の Web サイトでのオンラインディスカッションに 参加 Some confidence in the asserted identity 身元識別（身分証明書）、単一要素認証、失効処理、平文 PW 保持× 例：社会保障 Web サイトを通じて自身の住所記録を変更 High confidence in the asserted identity 多要素認証（ソフトトークン可） 例：特許弁理士が特許商標局に対し、機密の特許情報を電子的に提出 Very high confidence in the asserted identity 対面による発行、ハードウエアトークン、認証後の暗号化の強化 例：法執行官が、犯罪歴が格納されている法執行データベースにアクセ ス 調査によれば、連邦政府はこれまで高いセキュリティを保ちつつ効率的な業務を可能と する技術として PIV カードを用いてきたようである。つまり、その強力なアクセス制御や 暗号技術の利用により、内部・外部犯罪の抑止に一定の効果があったと考えられる。そして 技術の変遷に追従して携帯情報機器に PIV カードの役割を担わせる方法を検討してきた成 果が SP 800-157 であり、効果はそのままに、さらに業務効率を向上させようとする姿勢が 伺える。今後、派生証明物の実導入で何らの問題は生じないか、従来通りあるいはそれ以上 の内部・外部犯罪抑止効果などが見られるのか、などについて継続的に注視する必要がある だろう。日本における活用可能性について検討を続けていくことが望ましい。 ●調査 1－④ NISTIR 7628、7823 訪問日時： 2015 年 2 月 5 日（木曜） 訪問先： 国立標準技術研究所 NIST - Computer Security Division （CSD） 訪問対象： Victoria Pillitteri、Michaela Iorga 訪問先・訪問対象者の概要： Pillitteri 氏は、NISTIR 7628 の現編集者である。調査 1－②に引き続いてインタビュー を実施した。 Iorga 氏は、調査 1－②のクラウドコンピューティングに加え、米国スマートメーターの ファームウェアアップデートのセキュリティ検証手順をまとめた Draft NISTIR 7823 の 19 現編集者である。同文書は、米国電気機器製造協会 NEMA がまとめた規約 NEMA SG-AMI 1-2009（以下に示す）に基づき、セキュリティ要求事項の検証手順の指針を規約文書化した ものである。 NISTIR 7823 DRAFT Advanced Metering Infrastructure Smart Meter Upgradeability Test Framework Requirements for Smart Meter Upgradability (スマートメーターのソフトウ エア・アップグレードに関するセキュリティ要求事項), Smart Grid Standards Publication SG-AMI 1-2009, NEMA, 2009 調査 1－④の概要： 調査 1－④では、以下の(1)、(2)について調査した。 (1) (2) 米国では、2013 年 2 月に、スマートグリッドを含む重要インフラ施設の情報セキュ リティ強化を目的とした米国大統領令 EO-13636 が出され、国家的なセキュリティ 管理策の整備を進めた。2014 年 2 月には、既出のセキュリティ規約をもとに、業界 横断的に情報セキュリティ対策をまとめた「サイバーセキュリティ・フレームワー ク（Cybersecurity framework）」が公開された。 そこで、サイバーセキュリティ・フレームワークとの対応について、NISTIR 7628 の今後の改訂で、どの程度反映していくかを、Pillitteri 氏へのヒアリングにより調 査した。 米国のスマートグリッドアーキテクチャは 7 つのドメインで構成されるが、今回の 調査では我が国のスマートグリッド事情に合わせ、3 つのドメイン（運用、顧客、 サービスプロバイダ）の話題に絞った。7628 初版作成時の状況や、そのような文書 を作り上げていく方法論などについても意見交換した。 NISTIR 7628 では、スマートグリッドの運用、システム、機器の全てのレベルの管 理策を、vol.1～vol3 にまとめている。「運用」は、ISO/IEC 27001 をベースにして いる。「システム」や「機器」については、2010 年頃に一般的であったアーキテク チャを想定して、当時、受容可能なセキュリティ管理策を取り上げて、「運用」と ともに、22 分類に整理して vol1～vol3 に収録している。近年のスマートメーター のシステム化技術の進歩により、例えば、スマートメーターのファームウェアを遠 隔でアップデートする技術（遠隔ソフトウエア更新）が実用化された。遠隔ソフト ウエア更新については、 NEMA 規約をもとにセキュリティ検証手順を NISTIR 7823 で定めるのみに留まり、NISTIR ではセキュリティ基準を定めていない。 スマートグリッドにおけるスマートメーター・システムでは、システムの端末が需 要家端での管理となることから、サイバーセキュリティに関する特別な配慮が必要 となる。ファームウェアを更新する際にマルウェアが入り込むことがあれば MDMS を通じてネットワーク全体に広がってしまう。スマートメーターは遠隔で電力を遮 断できる機能を持っており、その機能をマルウェアに悪用される恐れがある。我が 国ではスマートメーターに関する適切な標準が未整備だったため電力会社がそれぞ れ異なるスマートメーター・システムを構築していることも問題となっている。そ のような問題に対処するため米国ではどのように標準化に取り組んでいるか、特に 遠隔ソフトウエア更新等、新技術への対応について、NISTIR 7628 や 7823 の今後 20 の改訂で、どの程度反映していくかを、Pillitteri、Iorga 両氏へのヒアリングにより 調査した。 インタビュー対応者：Victoria Pillitteri、Michaela Iorga インタビューまとめ： スマートグリッド・サイバーセキュリティ・ガイドライン（NISTIR 7628 Guidelines for Smart Grid Cybersecurity） NIST は 2014 年に NISTIR 7628 の最新改訂版（Revision 1 上記文書）を発表した。 2007 年から 2008 年にかけて初版作成時に広く協力を呼びかけて作成したユースケース 集を、さらに少し拡張した。NISTIR 7628 で作成したスマートグリッドアーキテクチャ では構成要素を 7 種のアクターに分類したが、日本が 3 種で良いのであれば議論のスコ ープを限定できる。NISTIR 7628 にはユーザガイドと呼んでいる要約版もあり、やはり 2014 年に作成した。 NISTIR 7628 の 3 巻目 （Volume 3） では、 スマートメーター （AMI Advanced Metering Infrastructure）のセキュリティユースケースを扱っている。セキュリティ問題は、スマ ートメーター機能毎に分類できる。NIST のスマートグリッド文書では、既知の管理策そ れぞれの個別の要件を見極めるアプローチを採っているが、同様の方法がスマートメー ターにも適用できる。より具体的には、Regenscheid 氏が相互トラストの問題として議 論する（調査 1－⑤）。 NISTIR 7628 は今後も 2、3 年毎に見直し、必要に応じて改訂する。スマートグリッ ドはサイバーフィジカルシステムの一種なので、将来の改訂ではスマートグリッドとは 呼ばずサイバーフィジカルシステムと呼んでいるかもしれない。 サイバーセキュリティ・フレームワークについてはまだ抽象的な概念である。クラウ ド、スマートグリッド、及びアプリケーションの領域で検討しているが、そのうち詳細な 実装の議論になる。情報システムに関する標準化では、影響レベル（Impact level）に基 づいたシステムの分類も必要である。低、中、高の影響レベルがあり、例えば重要インフ ラは高影響レベルに含まれるので高影響レベルのクラウド等を利用することになる。政 府機関用の連続モニタリングシステムの構築を考えるなら、そこで扱われるデータの重 要性を考えて高影響レベルシステムを使う必要がある。しかし電子メールなら必要以上 のコストをかけず中影響レベルで良く、必要なシステム毎のベースラインを考慮すれば 良い。FIPS 199 の分類法（連邦政府機関用情報システムのセキュリティ分類）が参考に なる。 日本が新たに標準の制定に取り組むなら、プライバシー管理も重要検討課題となる。重 要性レベルの異なるアクター毎のユースケースがある。エンドユーザに近いところでは プライバシーリスクが高くなり、サーバやハードウエアとは異なるセキュリティに取り 組む必要がある。 21 NISTIR 7628 の構築に見られるような、自発的な取り組み、規制、及び標準規格の間 の関係は、複雑な文書を効率的に作り上げるのに有効に機能している。NISTIR 7628 初 版作成に先立ち、2007 年にエネルギー自給・安全保障法（EISA 2007）が制定され、NIST にサイバーセキュリティを含めスマートグリッドの諸問題の調査と取り組みをとりまと める使命が与えられた。そのため NIST は、外部の専門家に協力を呼びかけワークショ ップを開催し、パブリックコメントを求め、オープンで協調的な共同開発体制を築いてサ イバーセキュリティ管理策や論理参照モデルを作り上げた。その中で各セクターにもリ ーダーシップを求め、数回にわたるワークショップを開催してきている。この方法を SGIP（スマートグリッド相互運用協議会）でも採っている。そのようにコミュニティに 主体的に参加してもらい、パブリックコメントを募集し、人々が理解していることを確認 し、それを繰り返すことで、効果的に続いている。 AMI スマートメーター・アップグレーダビリティ・テスト・フレームワーク（Draft NISTIR 7823 Advanced Metering Infrastructure Smart Meter Upgradeability Test Framework） 各社がそれぞれ独自の方式でスマートメーターを作ってしまうのは米国も同様である。 標準規格は存在するが、それに沿いながらも異なる仕様が生まれてしまう。NISTIR 7823 ではファームウェアのアップグレード機能に関する検証手順を規定しているが、スマー トメーターの仕様の違いの多さに対応するのは困難なので、スマートメーターそのもの の要件ではなく、将来のアップグレード機能に関する要件としている。 米国では、当時実施されたマッチングファンド制度により 2009 年から 2010 年の間に 大量のスマートメーターが設置されたが、それから 5 年の間に技術は進み、異なる会社 の異なる技術レベルのスマートメーターが混在している。今後も同様に新しいスマート メーターの設置が進み、それらは 10 年、20 年と稼働を続ける必要があることから適宜 適切なアップグレードを行う必要がある。標準化はそのような時間の変化にも対応する 必要があり、NISTIR 7823 はその問題に気を配っている。日本でこれから標準を作り、 それに沿ったスマートメーターを作ろうとするなら、すでに設置したスマートメーター の扱いをどうするかが問題となる。このような観点から、アップグレード機能に関する取 り組みは標準化対象課題の 1 つとして重要である。 ●調査 1－⑤ ハードウエア・ルート・オブ・トラスト 訪問日時： 2015 年 2 月 5 日（木曜） 訪問先： 国立標準技術研究所 NIST - Computer Security Division （CSD） 訪問対象： Andrew Regenscheid 訪問先・訪問対象者の概要： NISTIR 7628 や NISTIR 7823 にも、スマートグリッドやスマートメーターのセキュリ ティでルート・オブ・トラストのコンセプトが重要である旨の記述がある。Regenscheid 22 氏は相互トラストやルート・オブ・トラスト技術の専門家であり、下記文書の共著者であ る。 SP 800-155 DRAFT BIOS Integrity Measurement Guidelines SP 800-164 DRAFT Guidelines on Hardware-Rooted Security in Mobile Devices 調査 1－⑤の概要： NIST CSD は、サイバーセキュリティの技術要素の 1 つとしてハードウエア・ルート・ オブ・トラスト（信頼性の基点）の研究も行っている。サイバーセキュリティは、セキュ リティ機構のどこか一点でも破られるとそこからシステムへの侵入やデータアクセスを 許してしまう。現代の複雑な情報機器やシステムを設計・製造するには、複数の部品、モ ジュール、ソフトウエア等を組み合わせる必要があるが、全ての構成要素それぞれに高い セキュリティ機能を持たせるのは現実的ではない。そこでシステムの中核に、ルート・オ ブ・トラストとして単一の部品により高いセキュリティ機能を実現させ、その周囲の構成 要素をそのセキュリティ機能で保護し、さらにその周りへセキュリティ保護の連鎖を広げ ていくことにより、コスト増加を抑制しながら全体で高いセキュリティを実現する方法が 採られる。スマートグリッドやスマートメーターのセキュリティにおけるルート・オブ・ トラストのコンセプトの重要性を調べるため、Regenscheid 氏にインタビューを実施した。 インタビューまとめ： 情報システムのルート・オブ・トラストはシステム全体のサイバーセキュリティの要と なる構成要素である。下位レイヤーから上位レイヤーのセキュリティ・アーキテクチャに おいて、全てのセキュリティ機能が、最下位レイヤーに位置するルート・オブ・トラスト のセキュリティ機能が十分信頼できることに依存している。従ってシステムを設計し実 現するには、設計思想から実装の詳細に至るまで、そのアプローチを統一的に意識するこ とが重要である。 ルート・オブ・トラストは、典型的には例えば TCG（Trusted Computing Group）が 仕様を策定した TPM（Trusted Platform Module）と呼ばれる IC チップとして実現され る。この TPM は暗号機能、暗号鍵生成・保管機能、攻撃対処機能等を狭い範囲に実装す ることでコスト抑制と高セキュリティを両立している。システムは、この TPM を基点と して、信頼できるオペレーティングシステムを起動し、信頼できるユーザを認証し、信頼 できるアプリケーションを実行し、信頼できる暗号化通信を行う。 ルート・オブ・トラストの重要な役割の 1 つは、システムの完全性（Integrity）の検 証である。例えば TPM 等の内部に、外部記憶装置に保存されているオペレーティングシ ステム・ソフトウエアが本物であるかどうか、すなわち完全性を証明するハッシュ値を保 存し、オペレーティングシステム起動前にそのソフトウエアを調べてハッシュ値を計算 し、保存してある値と比較して一致すれば改ざんされていない本物として実行を許可す る。 23 ハードウエア・ルート・オブ・トラストではファームウェアの保護が役割に含まれる。 組込みシステム等では一旦ハードウエアとともに組み込まれたソフトウエア（＝ファー ムウェア）が繰り返し同じ機能を実行するが、ファームウェアのアップデートは通信回線 やポータブル記憶装置などによって、（ファームウェア提供者から見て）遠隔的に行われ る。この時に意図的に改ざんされたファームウェアやたまたま異なるファームウェアが 混入する恐れがあるため、信頼できる通信手段により正しいハッシュ値を送り、ファーム ウェアから計算できるハッシュ値と比較してファームウェア完全性を検証する。パーソ ナルコンピュータでは従来、オペレーティングシステムを起動し管理する、さらに基本的 なシステムソフトウエアとして BIOS と呼ばれるファームウェアの使用が一般的だった が、近年では完全性を検証する TPM との統合性を高めてセキュアブートを実現する UEFI（Unified Extensible Firmware Interface）の採用が増えつつある。 また、複雑なシステムでは外部記憶装置等の外部デバイスを追加したり交換したりす る機会がある。システムのセキュリティを守るには、その時に新たに接続されたデバイス が信頼のおけるものであるか確認する必要がある。ハードウエア・ルート・オブ・トラス トではファームウェア完全性とともにデバイス完全性の検証が重要な役割となる。 インタビューを踏まえると、スマートメーターはそれ単体で一個の組込みシステムで あり、ハードウエア・ルート・オブ・トラストのアプローチは当然有効であり、必要であ ると考えられる。また、単体だけでなく、多くのスマートメーター間や集中ユニットとの 通信にもセキュリティが必要であり、その部分にもルート・オブ・トラストの設計思想が 波及していることが重要である。スマートメーター・セキュリティ検証手順の検討にはそ の観点の議論が必要であると考えられる。 ●調査 1－⑥ 暗号モジュール認証プログラム及び自動化試験 訪問日時： 2015 年 2 月 6 日（金曜） 訪問先： 国立標準技術研究所 NIST - Computer Security Division （CSD） 訪問対象： Michael Cooper 訪問先・訪問対象者の概要： NIST CSD は、FISMA 法のもとで暗号モジュールセキュリティ要件 FIPS 140-2 を発行 し、その準拠試験認証制度である CMVP を運用している。Cooper 氏は、CMVP を運用す るセキュリティ試験・認証・測定グループ（Security Testing, Validation and Measurement Group）のグループ長である。同グループは暗号モジュールセキュリティ要件の標準規格 （FIPS 140-2）と認証基準を策定するとともに、暗号モジュール認証プログラム（CMVP） を実施している。また、その基準適合試験を行う第三者試験機関の認定業務に関わってい る。 ・ FIPS 140-2 Security Requirements for Cryptographic Modules 調査 1－⑥の概要： スマートメーターには、セキュリティを実現するために暗号モジュールを内蔵する。暗 号モジュールがスマートメーター内部でセキュリティ機能の要となる要素であることと、 24 CMVP がスマートメーター認証手順策定の参考になると考えられることから、Cooper 氏 へのインタビューを実施した。また、Cooper 氏が重要視している自動試験技術について スマートメーター認証と関連がある可能性があることから、追加で議論を行った。 インタビュー対応者：Michael Cooper インタビューまとめ： 暗号モジュール認証ではモジュール境界の定義が重要となる。暗号モジュールはソフ トウエアライブラリの形式を採るものや、実際のハードウエア製品全体であることもあ り、どのような形式であってもモジュール境界が定義されその境界で試験が行われる。モ ジュール境界の内側に変更があれば、その都度、再試験と再認証が必要となる。従ってそ のような変更が頻繁に生じることが予想されるのであれば、なるべくモジュール境界は 小さくすることが望ましいが、マーケティングの目的によってはあえて製品全体を認証 対象とすることが選択されることもある。 セキュリティ要件は FIPS 140-2（連邦政府機関による遵守義務がある規格。産業界に 対する規制や義務を課すものではない）及び ISO/IEC 19790（FIPS 140-2 の国際標準化 版）で定義されている。現在、国際標準化版をもとにして FIPS 140-2 を改訂する作業が 行われている。暗号モジュールが FIPS 140-2 に準拠しているかどうかを試験し、合格し たモジュールに認証を与える制度が CMVP である。CMVP ではこれまでに約 5,500 個 の暗号モジュールに対して約 2,200 件の認証が与えられた。 認証に長時間かかることが従来問題とされ、以前は 9 ヶ月かかっていたが、グループ の人的リソースの増強と業務改善により現在は 2 ヶ月まで短縮された。現在は、暗号モ ジュール製品の改良・改訂に伴う再認証への対応を容易にするため、自動化試験の導入が 重要課題となっている。 試験の自動化のためには、暗号モジュールに関して 2 つの問題がある。1 つは多くの企 業が試験対象となるソフトウエアを自社外に出すことを拒み、その結果試験機関内での 試験が実施できなくなることである。もう 1 つは、暗号モジュールの試験項目によって は出力を検証するだけでなく、ソフトウエアの内部記述を確認する必要があることであ る。 前者の問題は、自動試験ツールを暗号モジュールベンダに提供して自社内で試験させ るか、認証者が提供する試験サーバへの Web インターフェースを通じて暗号モジュール を試験させることができれば、解決可能である。Web インターフェース方式の方が試験 場所の制約がないメリットがあるが、多様なプラットフォームに対応するためのインタ ーフェース開発が障壁となっている。 後者の問題は、通常、静的解析かコード挿入解析によって解決される。静的解析は暗号 強度に関わるデータフローを調べるもので、コード挿入解析は通常隠蔽されている内部 データを調べるものである。しかしながら、どちらの手法もソースコードへのアクセスを 必要とすることから技術情報の漏えいの危惧があり、 （ツールを実装した仮想マシンを提 25 供するなどして）暗号モジュールベンダ側で実施するような方式さえも拒否されること がある。このアプローチによる自動化導入には、認証にかかる時間の短縮要求の優先度が 技術情報保護策の要求を上回るようになる機運を待つ必要がある。 試験ケース及びデータを自動生成する試験実施プラットフォームや技術は現在検討中 である。NIST 内部では、すでにストリーム暗号などの特定の機能を対象としたランダム 試験データを生成するツールをいくつか開発済みである。これらの機能はリファレンス 実装されたコードに対して試験が行われる。このアプローチはこの種の機能に適してい るため、今後も継続されると考えられる。 下位レイヤーの機能だけでなく、高位のステートフルなプロトコルにもデータを扱う ものがある。例えば、認証（authentication）はデータアクセスの前に行われる必要があ る。この種のプロトコルに対しては、専用の試験ツールが存在する。例えば、産総研が開 発した Modbat と呼ばれるツールはそのようなプロトコルのモデル化に利用できる。 Modbat は C や Java 等で記述された任意のソフトウエアに接続できるため、他のツール やプラットフォームと組み合わせて専用のソリューションを作成することが可能である。 Cooper 氏はこの産総研のような取り組みは CMVP が必要としていた技術であると指摘 した。 NISTIR 7628 では、推奨セキュリティ要件として FIPS 140-2 が指定されている。 Cooper 氏によれば、これまでのところ、CMVP において暗号モジュールとして認証され たスマートメーターあるいはその内部機構はないが、今後認証製品が出てくる可能性は あるとのことである。 インタビューを踏まえると、第三者試験に基づくスマートメーターのセキュリティ認 証制度の 1 つの参考形態として、CMVP は適切な調査対象であり、今後さらに詳細な調 査と検討を進めるべきであると考えられる。自動化試験技術については我が国が強みを 持つ部分を見極めつつ、我が国のスマートメーターのセキュリティ認証制度に取り入れ ることの検討の他、NIST 等と連携して国際的な標準化の検討も始めることが望ましい。 ●調査 1－⑦ 連続モニタリング、ソフトウエア ID、セキュリティ対策の自動化 訪問日時： 2015 年 2 月 6 日（金曜） 訪問先： 国立標準技術研究所 NIST - Computer Security Division （CSD） 訪問対象： David Waltermire 訪問先・訪問対象者の概要： Waltermire 氏は、セキュリティ対策のための連続モニタリングと自動化、及び SWID に 代表されるソフトウエア ID 等の専門家である。また NIST CSD におけるセキュリティ自 動化チームの計画責任者であり、下記の文書の共著者である。 NIST IR 7823 DRAFT Advanced Metering Infrastructure Smart Meter Upgradeability Test Framework 26 NIST IR 7800 DRAFT Applying the Continuous Monitoring Technical Reference Model to the Asset, Configuration, and Vulnerability Management Domains SP 800-117 Rev. 1 DRAFT Guide to Adopting and Using the Security Content Automation Protocol (SCAP) Version 1.2 NIST IR 7799 DRAFT Continuous Monitoring Reference Model Workflow, Subsystem, and Interface Specifications NIST IR 7756 DRAFT CAESARS Framework Extension: An Enterprise Continuous Monitoring Technical Reference Architecture NIST IR 7831DRAFT Common Remediation Enumeration (CRE) Version 1.0 NIST IR 7670 DRAFT Proposed Open Specifications for an Enterprise Remediation Automation Framework NIST IR 7698 Common Platform Enumeration: Applicability Language Specification Version 2.3 NIST IR 7697 Common Platform Enumeration: Dictionary Specification Version 2.3 NIST IR 7696 Common Platform Enumeration : Name Matching Specification Version 2.3 NIST IR 7695 Common Platform Enumeration: Naming Specification Version 2.3 NIST IR 7694 Specification for the Asset Reporting Format 1.1 NIST IR 7693 Specification for Asset Identification 1.1 NIST IR 7692 Specification for the Open Checklist Interactive Language (OCIL) Version 2.0 調査 1－⑦の概要： 情報システムの規模が大きくなると、セキュリティ監査対応やセキュリティアップデ ートの作業が膨大かつ複雑なものになる。それらを人手で行うと作業に漏れが生じる可 能性が高まり、その結果セキュリティリスクが大きくなることから、自動化されること が望ましい。セキュリティ対策の自動化のためにはシステム全体が統一的な自動化関連 の規格に対応する必要があり、NIST CSD はその規格やガイドラインを整備している。 連続モニタリング：2002 年の FISMA 施行以来、連邦政府情報システムの FISMA セ キュリティ監査は人的要因によるセキュリティインシデントを防ぐ目的で行われている。 しかしその作業量は膨大になる一方で、結局監査だけでは全てのインシデントを防ぐこ とはできず、監査ベースの対策の限界が指摘されてきた。そこで 2010 年から FISMA の 運用に新たな対策として連続的システム監視が導入された。このコンセプトはシステム の操作、変更、通信等を常時監視するもので、Continuous Monitoring として NIST SP 800-137 文書に定義されている。 ソフトウエア ID：情報システムに含まれるコンピュータの台数が増えてくると、それ らにインストールされたソフトウエアの資産管理やバージョン管理が非常に煩雑になる。 セキュリティアップデート作業に漏れが生じるとセキュリティリスクが高まることから、 27 それらの管理は自動化されることが望ましい。ソフトウエア ID は、そのような自動化 を促進するために、インストールされているソフトウエアの製品名、プラットフォーム 情報、バージョン番号、構成オプション等の組み合わせに対応する固有の ID 番号を定 義するコンセプトである。 NIST CSD では、スマートメーター・システムでは、システムの規模に加えて、遠隔 でセキュリティ対策を行う必要性から、自動化の導入は必須であると考えている。セキ ュリティ対策の効率化と自動化を目的とした連続モニタリングとソフトウエア ID の規 格化の取り組みについて Waltermire 氏から話を聞いた。 インタビュー対応者：David Waltermire インタビューまとめ： NIST は、セキュリティ管理プロセスの自動化に取り組んでいる。ソフトウエアのイン ストール状況の把握、ソフトウエア脆弱性やシステム設定の監視、セキュリティ対策権限 の設定、ソフトウエアインストールの承認、更新の確認などの手順について、多くの標準 文書を制定している。またそれらを実現するための低レベル通信プロトコルを開発して いる。IETF や ISO でも積極的に国際標準化を行っている。ISO 19770-2: Software ID Tag（SWID Tag）の制定にも取り組んでいる。これはソフトウエアベンダがソフトウエ ア製品に対しユニーク ID（=SWID）を割り当て、ユーザがそのソフトウエアを特定でき るようにするものである。SWID は実行イメージやライブラリイメージなどのフットプ リント、またバージョン番号や追加オプションほか多くのメタデータから生成される。イ ンストールされたソフトウエアの SWID を通信で収集することにより、組織の中で使わ れているソフトウエアを把握できる。SWID 自体は XML ファイルである。 従来のセキュリティ脆弱性発見手段はネットワークスキャナやファイルシステム解析、 レジストリ解析などであった。SWID はソフトウエア導入時の情報だけではなく、パッ チの情報も一緒に扱う。産業用制御システム（ICS）においては監視システム自らがデバ イスと直接通信をするとリソースを消費しシステムの運転状態に影響を与える恐れがあ るが、SWID の通知機能はその必要がなく複雑度を減らすことから有用であることがわ かっている。SWID はソフトウエアベンダの利益改善に役立つことから、マイクロソフ トをはじめ、多くのソフトウエア製品ベンダ企業が採用を始めている。Debian（Linux デ ィストリビューション）では未採用だが、Redhat とは採用に関する検討をしている。 NIST の NCCoE（National Cybersecurity Center of Excellence）では、ソフトウエア 資産管理基本要素（Software Asset Management Building Block）プロジェクトを進め ている。これは SWID をもとにしてソフトウエアの資産台帳を作り、組織のシステムの 完全性を検証する仕組みである。 NIST はセキュリティ対策のセキュリティ自動化規格である SCAP（Security Content Automation Protocol）にも取り組んでいる。CPE（Common Platform Enumeration） は SCAP の中で使われる構成要素の名称体系でありソフトウエアの ID 付与の役割があ る。IPA 等によるソフトウエア脆弱性データベースでも利用されている。SWID は CPE の機能を包含することから将来は SWID に入れ替わっていくと考えられる。 28 ソフトウエア設定変更を検出する定期脆弱性スキャンニングは従来からあるセキュリ ティ対策手法である。しかし定期スキャニングモデルにはスキャンタイミングの間で起 こりえるスキャン漏れの問題がある。そこで連続モニタリング（Continuous Monitoring） に取り組んでいる。 スマートメーターでは末端（Endpoint）問題がある。スマートメーターは需要家端の 環境に置かれることからセキュリティ対策が不十分になりがちである。攻撃者の攻撃が 成功してしまうと間違ったデータを送られたりする。その対策の 1 つが、スマートメー ターにわざと嘘をつかせることである。それで嘘であるかどうかチェックする。メッシュ ネットワークの問題では、デバイスの振る舞いがソフトウエア構成と相関があることを 利用した対策がある。スマートメーター同士で監視して正常動作であるかチェックする 方法もある。 さらに、シグネチャベースの検出技術は限界があるため、ビッグデータ技術を用いた攻 撃検知について研究している。システムコールを監視してプロファイルと比較するもの である。 インタビューを踏まえると、ソフトウエアをファームウェアと読み替えれば、これらの 取り組みは全て、スマートメーターのセキュリティ対策として検討が可能なものである。 今後精査の上、セキュリティ検証の標準化の中で検討していくことが望ましい。 29 1.3.3 欧州オランダにおける実地調査 ●調査 2－① スマートメーター・セキュリティの第三者テスト、セキュリティ人材育成 訪問日時： 2015 年 2 月 10 日（火曜） 訪問先： 欧州サイバーセキュリティ非営利組織 ENCS 訪問対象： Benessa Defend （ENCS、Research Consultant） 訪問先・訪問対象者の概要： 民間出資の非営利機関である ENCS（European Network for Cyber Security）は、ハ ーグ（オランダ）に拠点を置く。電力分野の制御システム機器のテストや脆弱性検証を事 業として行うとともに、セキュリティ人材の育成にも注力する。 調査 2－①の概要： オランダは、民間委託のセキュリティ第三者検証の仕組みが、定着しつつある国として 知られている。ENCS が、オランダ他の EU 諸国のセキュリティ第三者検証に果たす役割 について、Defend 氏へのヒアリングにより調査した。 また、オランダで評価手順が想定している背景（基準、規定、検査機関、法整備等）の 現状、評価手順を事業者が活用するための施策（義務付け、インセンティブ付け等）につ いても調査した。 特に、米国では、想定脅威を NIST SP 800-82 として規約文書化し、情報を公開してい る。欧州では、スマートメーター（スマートグリッド）に対する想定脅威とリスクを、ど のように管理し、参照しているのか、その仕組みについても調査した。 インタビュー対応者： Klaus Kursawe（Director Research & Development、現在は CTO） 、 Michael John（Senior Security Consultant） 、 Benessa Defend（Research Consultant） インタビューまとめ： ENCS は、当初、人材育成を目的として設立された。設立当初から、非営利組織である。 現在は、ハーグ（オランダ）の SEIMENS 社の一角をオフィスとしている。ENCS の業 務は、コンサルティング、テスト、人材育成、情報共有の 4 つである。具体的には、次の 通りである。 1. コンサルティング 依頼者のマネジメントレベルに合わせた、セキュリティレベルの設定の仕方等を支 援する。例えば、欧州会議が 2012 年にまとめた欧州統一のスマートメーターのセ キュリティの要求事項案に基づき、依頼者のセキュリティ基準の整備を支援する等。 30 2. 3. 4. テスト 欧州統一のスマートメーターのセキュリティの要求事項等に基づくセキュリティ 基準への適合性を評価するために、テストを支援すること。近年、ペネトレーショ ン・テストの支援に力を入れている。 人材育成 重要インフラ事業者を対象として、攻撃-防御型（red/blue team）サイバーセキュ リティ演習を開催すること。 情報共有 ENCS 会員企業向けに、ホワイトペーパーを定期発行すること。また、会合を開催 すること。 他に、ブロック暗号研究等、研究活動も行っている。 ENCS の業務の対象は、重要インフラ事業者である。オランダは、国土の 1/4 が海面よ り低く、排水ポンプを常時稼働して国土を維持していることから、排水ポンプ（オランダ の重要インフラ）に関連する依頼もある。研究の対象は、スマートメーター、変電所（サ ブステーション）、電気自動車が主である。 ENCS の研究では、スマートメーターのプロトコルの設計と実装、テスト、3G 無線通 信、鍵管理等のテーマが含まれる。変電所を対象とした研究では、セキュリティ・アーキ テクチャ、ベンダへのセキュリティ要求事項、モニタリング、通信インフラ、リモート端 末ユニット（RTU）設計が含まれる。電気自動車の研究では、マルチステークホルダー環 境下のセキュリティ・アーキテクチャ、プロトコル設計（HEMS とのインターフェース） 等が含まれる。 欧州プロジェクト FP7 の事業が、現在 3 件、稼働している。欧州では、各国で、スマー トメーター等機器の、セキュリティ認証が義務付けられ始めている。例えば、ドイツでは、 スマートメーター・ゲートウェイ（日本のスマートメーターの通信モジュールに相当）へ のセキュリティの認証が義務化されている。フランスでは、スマートメーターとコンセン トレータのセキュリティ認証が 2014 年から義務化された。こうした背景があるにも関わ らず、EU 域内では安価なスマートメーターにおける ・ 実装のミス ・ ファジング・テスト時の機器の異常停止 等が頻繁に発生している。こうした背景もあり、現在の業務は、スマートメーターに係る 依頼が多い。また、欧州全体で、スマートメーターに関しては、機器の製造コストの削減 要求が強く、セキュリティ機能の強化や改善は後手に回っている。 ドイツでは、コモン・クライテリア（CC）の認証仕様に基づく認証が義務付けられたた め、南欧の同様機器と比べて機器の製造コストに大きな開きが生じており、EU 域内にお けるセキュリティへの取り組みに対し、足並みが揃わないという問題が生じている。 31 現在、欧州全体で、統一のスマートメーターのセキュリティ基準を検討している。欧州 会議が 2012 年に作成したスマートメーターのセキュリティの要求事項案をもとに（以下）、 セキュリティ要求事項をまとめ、セキュリティ基準の欧州合意を目指している。 Recommendations, Commission Recommendation of 9 March 2012 on preparations for the roll-out smart metering systems ENCS は、組織が管理するスマートメーターに対する想定脅威やリスクに関する情報に 関与している。ENCS では、ENCS の会員組織に共有が必要な情報を、ENCS 発行のホ ワイトペーパーを通じて会員に配布するなどして、セキュリティへの注意喚起や啓発活動 を行っている。 32 1.3.4 欧州フィンランドにおける実地調査 本 節 の 調 査 3- ① ～ ③ は 、 日 本 で の リ セ ラ ー で あ る 東 陽 テ ク ニ カ を 通 じ て 、 Codenomicon、Codenomicon Cybersecurity Center、Oulu University への往訪調査を 実現した。Codenomicon のコーディネーターは、東アジア担当の Chang Kyu Kim （Director）。National Cyber Security Centre への調査は Codenomicon の手配によ り行われ、Codenomicon から Teemu Vaskivuo が同席した。 ●調査 3－① インシデント対応 訪問日時： 2015 年 2 月 11 日（水曜） 訪問先： National Cyber Security Centre（通称、NCSC-FI：正式名称は、Finland National Cyber Security Coordination Centre） 調査 3－①の概要： Codenomicon 社のツールを活用して調査研究などを実施している Finland National CERT では、フィンランド国内のインシデント対応を実施している。 広範な対象の監視を行うためにネットワークを活用した監視のためにはプライバシー などに配慮する必要があり、そのため国内法整備が重要である。また、全ての情報を網羅 的に判断するために情報収集段階から、識別（トリアージ）、報告作成（リポーティング） の完全自動化も推進されていた。これらはよりリアルタイムな監視を継続的に行うことが 重要であることを示している。その結果として、具体的な脅威と事故との関連性を示すこ とができるようになっていた。このように事故からの学習を効果的に行うためにも、一連 の手続きで情報収集に置けるボトルネックを作らないことが重要であることも加えてい た。そのためには収集する情報を想定し、あらかじめそれらの情報を収集できるような仕 組みをネットワーク上、また端末上に設定しておくことも必須であり、これらが IoT など のシステムに役立つことも判明した。 インタビュー対応者： Juhani Eronen （Senior Specialist） Sami Orasaari （Information Security Specialist） インタビューまとめ： Finland National Cyber Security Coordination Centre（NCSC-FI）は、フィンランド の政府系コンピュータ緊急対応チーム（政府系 CERT）として、2002 年に設立した。当 初、電信サービスを対象に CERT 活動を開始した。現在では、240 名が所属し、重要イン フラを含む社会インフラの情報セキュリティを対象に活動している。フィンランドの重要 33 インフラは、information society, energy logistics, food/health care, finance 等の 7 セク ターが指定されている。 政府系 CERT として、政府からの資金的支援を受けて、主に、監査（audit）、調整 （regulation）、監視（monitoring）の業務を行っている。CERT 発足時は、監視業務に おける運営上の問題があった。 具体的には、NCSC-FI には、脆弱性情報や脅威情報が日常的に 1000 件以上寄せられ る。NSCS-FI 設立当時、全てを詳細に分析・対応するためには、体制が不十分であった。 現在では、情報収集や報告を得ると、順序づけ（triage）し、アビューズ情報として取り 扱うか、調査対象として取り扱うかなどの報告が自動作成される。 この自動サマリー化（auto-report system）は、Codenomicon の技術的支援により実現 した。現在では、Codenomicon が同等の機能をパッケージ化して、AbuseSA（製品名） という製品で一般に入手可能である。 近年では、セキュリティインシデント数は、年間を通じてほぼ一定だが、新種のコンピ ュータウイルスの出現等によりピークが生じるというのも通例である。ピーク時の例外を 除き、自動サマリー化の実現により、通常時の監視業務は滞りなく行えている。 フィンランドでは、人口 500 万人に対して 200 万台のスマートメーターがすでに導入 されている。Eronen 氏は、我が国のスマートメーターの数が非常に多く、都市部ではス マートメーターがマルチホップ無線通信によりネットワークを構成することが、前例に ないため、無線ネットワークの監視、特に、異常な振る舞いの監視の実施計画について 関心を持っていた。 フィンランドでの実例をもとに Eronen 氏から「悪意を持つ第三者は、まず攻撃対象 を入手しようとする」という助言を得た。具体的に、納品、設置、廃棄などのシステム 運用サイクルにまでセキュリティ対策の対象を広げることが、我が国のスマートメータ ーのセキュリティを検討する上で重要であるという提案を受けた。 ●調査 3－② ファジングツール開発の現状 訪問日時：2015 年 2 月 12 日（木曜） 訪問先： Codenomicon Ltd. 訪問先・訪問対象者の概要： Codenomicon Ltd.（以下、Codenomicon と略す）は、ネットワーク機器の堅牢性テス トツールの開発・販売を手がける独立系ツールベンダである。2001 年に設立されて、フ ィンランドの Oulu（オウル）に本社と開発拠点がある。アジアでは、シンガポールに東 アジア拠点が置かれている。米国 ISASecure SSA 認証制度及び EDSA 認証制度から認定 を受けているファジングツール Defensics を開発し、我が国の自動車など主要な産業分野 での利用が検討されている。 ファジングとは、不正なパターンを含む信号を検査対象の装置に入力し、装置が想定外 の振る舞いをするかを確認することである。ファジングのための入力パターンは無数に存 34 在するため、効率よく様々な種類の入力パターンを生成し、テストする機能が、ファジン グツールに求められる。 図4 Codenomicon Abuse Situation Awareness 調査 3－②の概要： 欧州の第三者検証では、同社のツールが利用されている場合が多いと考えられる。世界 的には、これまで、WurldTech（カナダ）の Achilles Test Platform が利用実績を上げて いた。しかし、2014 年 5 月に WurldTech が GE（米国）に M&A されたことを期に、 Achilles Test Platform の今後の開発継続性が危惧され始めた。 本調査では、第三者検証の目的で、ファジングツールを利用することを想定して、 Codenomicon のツールの利用実績、活用事例、利用スキームについて調査した。特に、我 が国の電力事業者らが採用する、スマートメーター・システムの通信プロトコルの独自仕 様の部分への Codenomicon の対応についても調査した。 インタビュー対応者： Rauli Kaksonen （Founder, CTO） Lauri Piikivi （Director of Engineering） Teemu Vaskivuo （Solution Enginner） インタビューまとめ： 35 Codenomicon は、 システムのセキュリティ上の脆弱性を洗い出すためのツールとして、 Defensics を開発している。不正な入力に対して、製品としてのシステムが安定的に稼働 するかどうかを確認するための支援ツール、というのが Defensics の位置付けである。こ れに対して、既知の脆弱性に対応できているかを確認するための支援ツールがあり、 Codenomicon では AppCheck という製品を提供している。各ツールの機能の詳細は、後 述のツール DB の章を参照されたい。 Defensics と AppCheck は、相補的な関係に有り、ISASecure EDSA 認証仕様におけ る、CRT（通信耐性テスト）と VIT（脆弱性識別テスト）の関係に相当する。 Defensics のツール適用手順は、次の 8 ステップからなる：Basic configuration（基本 設定）→ Interoperability（相互運用性） →Advanced Configuration（応用設定）→ Instrumentation（計装） → Test cases（テストケース生成）→ Test run（テスト実行） → Results（結果出力）→ Remediation（修正）。最終ステップの Remediation は、テ スト結果をシステム開発者やベンダに送付することを意味しており、直ちにシステムの 脆弱性を修正するという意味ではない。ツールのユーザインターフェースは英語のみで、 今後も国際化、日本語への対応などの予定はない。 ファジングのためのテストパターン生成は、ミューテーションベース、モデルベースの 2 種類ある。ミューテーションベースのパターン生成は、技術的に実現容易である。 Defensics は、独自に開発した Attack Simulation Engine の技術により、モデルベース のテストパターン生成を実現している。Defensics は、すでに広い分野のプロトコルに対 応しているが、モデルベース・アプローチを採用しているため、ユーザ定義のプロトコル にも容易に対応可能である。また、現段階では IPv6 プロトコルには未対応だが、同様に 対応は可能である。 現在、Codenomicon は、およそ 200 名の社員を擁している。新しいプロトコルに対す るテストシナリオの生成には、 これまで 1～3 ヶ月で対応している。事前の相談があれば、 特段の依頼に対する対応体制を整えることは可能である。 AppCheck は、ベンダが公開しているバイナリファイルを対象に、既知の脆弱性への対 応を静的解析（Binary analysis）する。脆弱性が知られているソフトウエア・コンポー ネント、主にライブラリが含まれていると、該当する脆弱性が表形式で出力される。検査 に使用する脆弱性情報は Codenomicon でデータベース化して管理し、毎日 6 回の更新作 業を行っている。AppCheck はソースコード不要で、あらゆるソフトウエアを解析対象と することを目指している。現在では、C、C++、JAVA のソフトウエアの大半に対応して いる。また、よく知られているソフトウエア（例えば Firefox 等）に対しては、大きな変 更後の数日以内に AppCheck が適用であるかの確認を行っている。 脆弱性識別テストを支援するツールとしては、Nessus が知られている。Codenomicon は、Nessus はシステムレベルの脆弱性識別ツール、AppCheck はコンポーネントレベル の脆弱性識別ツールという棲み分けがあると考えている。 36 図5 図6 Codenomicon Defensics のテスト画面 Codenomicon Defensics のテスト結果表示 37 ●調査 3－③ ファジング技術、セキュア・ネットワーク技術他 訪問日時： 2015 年 2 月 13 日（金曜） 訪問先： オウル大学 Oulu University 訪問対象：セミナー（Christian Wieser 主催） 訪問先の概要： オウル大学は、Codenomicon の技術開発の拠点、ヘルシンキから飛行機で 1 時間ほど離 れた大学街に位置しており、ファジングの技術研究とツール化を行っている。近年では、大 規模なネットワークを介して、セキュリティ情報を効果的に収集・分析する技術に注目して いる。オウル大学では、コンピュータネットワーク上の迷惑行為またはその迷惑行為（アビ ューズ）を通報する窓口から得られる情報の選別や視覚化を支援する技術も研究開発して いる。 調査 3－③の概要： Defensics、Abuse Situation Awareness 等、本事業に関連する検証支援ツールの要素技 術について、研究者らを対象にヒアリングによる調査を行い、今後のツール化を予測する情 報を収集した。 調査まとめ： ●セキュアプログラミング・グループ Christian Wieser 氏 セキュアプログラミング・グループは 1996 年に創設され現在 15 名の研究者及び学生が 所属している。このグループの注目すべきスピンオフ会社として Codenomicon （2001）と Clarified Networks （ 2006 ） が あ る 。 こ の グ ル ー プ は 現 在 主 に FRONTIER と PROTOS/MATINE というプロジェクトを実施している。前者は通信プロトコルの複雑性 を管理するものであり、後者はヒューマン・アクターが介在するシステムの脆弱性をよりよ く理解しようとするものである。 FRONTIER プロジェクトにおける主な問題は、複数の通信プロトコルがしばしば予期せ ぬ相互作用を起こす点である。この研究の技術的な側面は、そのようなシステムにおけるイ ベントと通信パターンの因果関係を明らかにすることで、予期せぬ振る舞いを検出しよう とするものである。同グループは、この技術を用いて RFID の実装の評価・監査を行ってき た。 PROTOS/MATINE プロジェクトでは、構造的に変異を発生させて脆弱性を明らかにす るという高度ファジングと、プロトコルの依存性の解析と可視化という、2 方向の研究を進 めている。 ●TUT : Tampere University of Technology Jari Seppala 氏 Jari Seppala 氏（TUT:Tampere University of Technology）は、TUT 及び彼の研究であ る「Securing Industrial Control Systems」について紹介した。TUT は 1965 年に創設さ れ、 現在約 10,000 人の学生が在籍し、デジタル操作環境（Digital Operating Environment） 、 38 エネルギー・環境効率（Energy and Eco-Efficiency）、産業効率化（Industrial Effectiveness）、 健康技術（Health Technology）の 4 領域を扱っている。 Seppala 氏はオートメーション科学技術部でオートメーション・セキュリティの研究を 行っている。近代的な産業制御システムは、今やインターネットに接続されているため、潜 在的に多くの攻撃の的になる。そのようなシステムは寿命が長いため、一部の部品は大昔に 外部との接続など考慮せずに設計されており、多くのセキュリティ上の問題を持つ。にもか かわらず、アップグレードは（コストがかかる）システム停止を伴う上、予期せぬ障害が発 生する可能性があるため、これらのシステムがアップグレードされることはまれである。し かも、セキュリティ違反がない限りは「触らぬ神に祟りなし」がこの業界の主な考え方であ る。 しかし、最近 Stuxnet が産業界にセキュリティをもたらす契機となった。産業関係者は ワークショップに参加し、開発のアプローチを再考しつつある。バグの修正とソフトウエア のアップデートが開発と展開における標準的なプラクティスとなりつつある。ただし、未だ にセキュリティは多くの要因の 1 つに過ぎず、経済的影響の可能性をもとに評価される場 合が大半である。 ●セキュアプログラミング・グループ Haataja 氏、Annti Husas 氏 Aki Helin 氏、Thomas Wahlberg 氏、Marko Aki Helin 氏は Radamsa というオープンソースのツールを紹介した。これは、データの 型（文字列や数値等）と区切り文字（引用符や括弧等）に基づき入力データのフォーマット を推定するもので、Android OS その他のプラットフォームの脆弱性の発見に成功している。 Thomas Wahlberg 氏は、ネットワークデータの可視化のために設計されたツールのプロ トタイプを紹介した。これはサーバや開放されているポートの空間的ビューを提供するも のであるが、まだ開発の初期段階にあり詳細は示されなかった。 Marko Haataja と Annti Husas の両氏は CAN（Controller Area Network、自動車内部 の通信ネットワーク）バスハッキング・プロジェクトを紹介した。コモンバスの採用により 車の配線や重量はかなり削減されてきたが、今やそれに付随する情報システムが攻撃の主 な標的になっている。リバース・エンジニアリングによって脆弱性を探ろうとする試みは、 プラットフォームの複雑性と巨大化に阻まれてうまくいかなかったため、彼らはバスにデ ータを投入するという手法に移行した。学生達は、Arduino ボード（廉価なスタンドアロー ンの PC ボード）を使ってバスにコマンドを投入することができる。この方法で可能となる コントロールは限定的ではあるが、Wifi や Bluetooth といったプロトコルを利用すること で新しいコンポーネントを簡単に接続することができるため、物理的なアクセスはまった く必要ない。 39 1.3.5 その他の調査の詳細 我が国では、2024 年までに全国の小口需要家（一般家庭）に、スマートメーターが段階 的に設置される。このため、スマートメーターを取り巻く環境は、今後 10 年間に継続的な 変化があると予想される。 スマートメーターを取り巻く我が国の環境をモデル化するためには、視覚的に理解しや すく、社会変容への対応が容易で、少ないコストで管理できる「モデル」であることが望ま しい。米国では、スマートグリッド関連事業者が多いため、NISTIR 7628 に掲載されてい るリファレンスモデルは非常に複雑である。 そこで、メタモデリング技術の専門家 Tim Kelly（ヨーク大学・教授）に対して、スマー トメーター・セキュリティを取り巻く我が国の環境をモデル化する技術と、その適用のあり 方について、国内でヒアリングによる調査を実施した。 調査日時： 2015 年 1 月 29 日（木曜） 調査対象：Tim Kelly（ヨーク大学・教授） 調査の概要： Kelly 教授へのヒアリング調査の背景は、次の通りである。 ・ 近年、ガイドラインや基準の適用範囲を明確にするため、ステークホルダやシステム を構成要素とする全体像を図的にモデル化するケースが増えている。 ・ 米国のスマートグリッド・セキュリティ基準 NISTIR 7628 では、ロジカル・リファ レンスモデルと呼ばれるステークホルダやシステムの関係図が、NISTIR 7628 の冒 頭に掲載されている。 ・ NISTIR 7628 のモデルは、基準における前提や、管理策とステークホルダ等との関 連付けを表している。 ・ 管理策と同様に、社会の変容に合わせて、モデルに対してもステークホルダの追加や 管理策との関連付けの変更といった修正が必要である。 ・ 事業分野によっては、短期間に変更の必要が生じる、モデルが複雑で変更が容易にで きない、という状況が発生する。 Kelly 教授は、システムの設計等工学分野で利用されている「メタモデリング技術」の第 一人者である。メタモデリング技術は、自動車分野の機能安全規格 ISO 26262 のモデル化 や、鉄道分野の安全性とセキュリティの統合分析に利用された実績がある。 インタビュー対応者：Tim Kelly インタビューまとめ： この調査は、本事業で作成した NISTIR 7628 を対象とした 3 種類のモデルを説明し、そ のモデルに対する技術的助言を得ることが目的である。 40 調査に使用したモデルは、NISTIR 7628 に忠実なモデルで、構造化されている。また、 調査には、次の 3 種類のモデルを使用した：（1）セキュリティに関する概念のモデル、 （2） 論理的アーキテクチャとロジカル・インターフェースのモデル、（3）高水準のセキュリテ ィ要求のモデル。 調査で得られた助言は、本事業のモデル作成で利用された。実際に、モデルのどの箇所の コメントであるかを明確にするために、モデルの関連部分を関連図として掲載し、その内容 に関する助言と、その対応案を示す。 【モデルに関する指摘】 表 3 モデルの関連 コメント 【関連図-１】 C1 C2 C3 今後の対応 関連図-1、 「7628_HighLevelSecurityRequiremnet」 は、 ユーザが定義可能にしておいた方が良いのではな いか（通常、要求は、規格から与えられただけで はなく、利用者も定義するので）。 規格に対して忠実なモデ ルを作成する方針であ り、そのような概念は含 まれていないのでモデル の対象になっていない。 今後、意見は参考にする。 上図、「7628_HighLevelSecurityRequirement」に 各概念間の関連について 対して、「7628_LogicalInterfaceCategory」との関 は、再度検討して、改訂す 係が「コンポジション」であるのはおかしいのでは。 る。 「7628_HighLevelSecurityRequirement」は、例え ば Criticality などの属性とは関係付けられていな いのか。 41 関連図-3 において、 CIA は定義されているが、直 接は関係がない。 【関連図-2】 C4 C5 C6 関連図-2、 「7628_Impact」と「7628_Incident」と の関係において多重度が定義されていないが、 「7628_Incident」に対して 1 で「7628_Impact」 に対しては 1..* になる必要があるではないか（セキ ュリティのインシデントに対して、複数のインパク トがあると考えられるので）。 上図の 「7826_Actor」と「 7826_Vulnerability」 の間の関連リンクの矢印は逆ではないか。 なぜ、ステレオタイプ（<<inherent in>>）を使った モ デ リ ン グ を し て い る の か （ 「 7628_Actor 」 と 「7628_Vulnerability」の間の関連リンクに定義さ れている）。 多重度については、まだ モデルとして開発中で、 付けられていない。意味 的に明確に付けられると ころは今後、追加する。 検討して、改訂する。 関連、サブクラス等で記 述できないものはステレ オタイプを使ったが、こ の点は改訂する。 【関連図-3】 C7 関連図-3 の「7628_Threat」と 「7628_LogicalInterface」の間には関連がないの はおかしいのでは。 42 直接関連はないが、中間 の概念を通してつながっ ている。関連するものを 全て直接つなぐのは、モ デリングとしてできない が、今後、可能かどうかを 検討する。 【関連図-4】 C8 C9 関連図-4 の 「7628_HighLevelSecurityRequirement」と 「RequiredUTR」、「RequiredCTR」、 「RequiredGRC」との間の関連が「集約」である が、これらは 「7628_HighLevelSecurityRequirement」のサブ タイプになるのではないか？ 関連図 3 と 4 における「7628_Vulnerability」が 特定の「7628_Threat」に関連しないでインパクト が決められるのか？ 検討して、改訂する。 規格の記述において、明 確な定義となっているか どうかを検討し、今後、改 訂を行う。 【関連図-5】 C10 関連図-5、 LIC18 に対して U24 や U64 は具体的 な Logical Interface ならば、サブタイプであるこ とはおかしいのでは？ 43 サブタイプとするか、イ ンスタンスとしてモデル 化するかについては、検 討して必要に応じて改訂 する（クラス図とインス タンス図の両方を利用す ると、モデルが複雑にな るので） モデル全体に関するコメントを、以下にまとめる。 【モデル化のアプローチ】 複数の規格策定に参加しているが、モデルがないと何か問題が起こった時に何が問題 なのかがわからない。そのため、このようにモデルを作成するアプローチの方が、従来 の紙ベースの方法より概念的な明晰さを持つ。 セキュリティモデリングについては、 CMU/SEI の D. Firesmith [5] によるものがあ るが、それに類似している。 モデル化することでツールでの支援ができる。 UML モデルは簡単に理解できないが、Eclipse ツール等を利用することで、簡単に処 理ができる。 本事業でモデル化に採用した UML 表現は、システム開発の現場で標準的に用いられて いるものである。従って、システム開発になじみがないと、UML 表現は、独特な表現形式 に感じられるかもしれない。この調査により、本事業で作成するモデルは、概念や関係の構 造を正確に表して、作成したモデルを基準案等の理解の助けとして活用するという指針が 得られた。 Tim Kelly 教授からも、本事業で作成するモデルは、規格等の付録（通常 Informative セ クションになる）として、本文には簡約版のモデルを記載するのが良いという指摘を受け、 第２章を構成した。 【参考資料】 [1] OPENCOSS ホームページ：http://www.opencoss-project.eu/ [2] Jose Luis de la Vara, Rajwinder Kaur Panesar-Walawege: SafetyMet: A Metamodel for Safety Standards. MoDELS 2013: 69-86 [3] NISTIR 7628 Revision 1: Guidelines for Smart Grid Cybersecurity: Volume 1 Smart Grid Cybersecurity Strategy, Architecture, and High-Level Requirements, 2014 [4] Donald G Firesmith: Common Concepts Underlying Safety Security and Survivability Engineering, CMU/SEI-2003-TN-033 (2003) 44 第２章 スマートメーター・システムのリファレンスモデルの構築 セキュリティ規格の策定をする際の問題は、基本となる概念をどのように整理し、相互 の整合性を考慮し、体系化することである。例えば、「脆弱性」「インシデント」「障 害」などセキュリティに関係する用語は、その文脈によって使用者の意図する意味が異な ったり、異なる用語でも同じ意味を指したりする場合がある。スマートメーター・システ ムにおいては、リファレンスモデルを構築することで、規格の策定者間の共通理解の確立 や、規格の利用者への容易な理解を可能にすることが期待できる。さらに、スマートメー ター・システムの構築を完了した後の、メンテナンス（保守）フェーズにおいて、新たな 問題が発生し、その対策を取る必要性が生じた場合なども、問題の報告者や対策を取る責 任者、さらに開発時の担当者などがリファレンスモデルを参照することにより、迅速な対 応を取れることが期待できる。 本事業の海外調査においても、スマートメーターに関する社会変容に対応することが重 要であり、スマートメーター・システムのリファレンスモデルを検討する必要があること を示した。一方で、スマートメーター・システムのモデルとしては、米国の NIST IR 7628 が存在するが、このモデルを我が国へ適用することは困難である。例えば、日本の 電力事情とは異なるモデルになっていること。また、モデルとしての汎用性に欠けるこ と、さらに、大きなモデルになると煩雑化し、作成及び解読するために非常に大きな労力 が必要になること等の問題がある。 本調査では、米国のスマートグリッドに関するリファレンスモデルを提案手法により記 述し、その拡張及び修正として我が国で利用可能なスマートメーターのリファレンスモデ ルを構築した。この拡張・修正を実施するため、我が国におけるスマートグリッドのセキ ュリティに関する業界事情の調査及び本事業で設置した有識者検討会において内容を精査 し、我が国のスマートメーター・システムを反映していることを検証できた。 45 2.1. メタモデルの説明 本調査では、スマートメーター・システムのセキュリティを考える上で必要となるリフ ァレンスモデル及び概念モデルについて説明する。はじめに、モデル化にあたって採用し たメタモデル手法の概要と意義を説明する。次に提案するリファレンスモデル及び概念モ デルの構築方針を述べた後、それらの想定利用シナリオをいくつか述べる。最後に、今回 のモデルのベースとなった NIST IR 7628 に対するモデルと今回提案するモデルの比較に ついてまとめる。 2.1.1 メタモデルの位置付け 規格や基準を策定する目的の 1 つに、重要な概念の共有がある。例えば、セキュリティ に関する重要な概念に、事故や脆弱性、脅威などがあり、セキュリティに関する規格や基 準では、それらの概念を規定することにより、関係者間の意思疎通を促進することが期待 される。一般に、規格において概念は、自然言語（日本語や英語）による定義を与えるこ とによって規定されるが、多くの概念が複雑に関係している場合には、個々の自然言語に よる定義の曖昧さが残るため、結果として、関係者間で共通の概念を得ることが困難にな りうる。メタモデルによる概念規定はそのような状況を避けるために導入される。 本基準案は、スマートメーター・システムのセキュリティ基準を与えることを目的とす るため、少なくとも次の 2 つの領域に関する概念の共有が求められる。 1. 対象とするスマートメーター・システム 2. セキュリティに関係する諸概念 「スマートメーター・システム」と一言でいっても、諸外国と我が国では諸制度からハ ードウエア、ソフトウエア、運用に至るまで様々な面で異なり、さらに、我が国において も電力事業者毎に状況が異なる。基準案を与えるにあたって、関係者が共有可能な参照モ デルを与えることが期待される。また、基準案では、セキュリティに関して関係者が満た すべき対策を規定することになるが、それらの対策を提議するために必要なセキュリティ 上の諸概念に共通の理解がなければ、基準案になりえないため、それらの定義を与えるこ とが期待される。 メタモデルという用語は、ソフトウエア技術の国際標準化団体の 1 つである OMG （Object Management Group）において規定されているため、ここで参照する。メタモ デルは、表 4 に示すようなモデル間の階層の 1 つである。まず、表中 M0 が、モデルが表 す実体の層であり、スマートメーター・システムの文脈でいえば、各事業者が持つシステ ムそのものや、運用体制、組織そのものを意味する。M1 は、それらのモデルを表し、何 らの表現で実体を表現するものとなる。M2 階層のメタモデルは、それらモデルに現れる 概念を規定するものである。モデルで利用される概念を規定するという意味でメタモデル と呼ばれる。M3 階層は、一般的なメタモデルの記述法を規定したものであり、OMG が 発行するメタモデルの規格である MOF（Meta Object Facility）を指す。 46 表 4 メタモデルの位置付け M3 Meta Object Facility (MOF)規格。メタモデルの記述法を規定 M2 メタモデル。モデルに表れる概念を規定 M1 モデル。各事業者のシステムや運用業務、用語体系などを規定 M0 概念が表すもの。実体。各事業者の個別システムや運用業務その ものなど メタモデルにおける概念は、各概念について定義を与えるのではなく、規定する複数の 概念の概念間の関係を与えることにより、各概念の意味を明らかにする。これにより、自 然言語による定義の曖昧さを避けることができる。また、少なくとも、概念間の関係を明 示的に与えることにより、多くの概念が複雑に関係している場合でも、少なくとも、それ らの関係について共通の理解を得ることができる。 また、メタモデルはソフトウエアのツールなどで扱うことが可能な図的な表現によって 提供されるため、複雑な概念について視覚的かつ直感的な理解を得ることができ、また、 メタモデルを管理、更新する際のソフトウエアによるツール支援が期待できる。 2.1.2 メタモデルの利用と効果 メタモデルに期待される効果は、今後この基準案をもとに規格を策定する際に関係者間 における概念の共有を助けることにある。以下、スマートメーター・システムのセキュリ ティ基準案に対するメタモデルを提供することにより期待される効果について述べる。 2.1.2.1 関係者間での対象システムの理解の共有 「スマートメーター・システム」と呼ばれるものは、その文脈によって大きく異なりう る。例えば、スマートメーターの機器についてだけでも、遠隔検針ができることをもって 特徴付けることもあるし、負荷開閉装置の遠隔操作までを含めることもある。ネットワー クについても、NIST IR 7628 のように、機器間の抽象化された論理的な関係を考慮すれ ば良いのか、具体的な通信方式やプロトコルまで考慮すべきなのかを決めておかなけれ ば、基準の対象とする範囲（スコープ）について、共通の理解を得ることはできない。対 象システムそのものだけでなく、それに関係する利害関係者の係わり方についても、米国 のように複数の認可機関や送電や運用などの各種地域事業者の可能性を考慮しなければな らない場合とそうでない場合では、基準の意味も異なる。メタモデルでは、このような対 象システムとその周辺環境の想定について、参照モデルを与えることにより、関係者間の 理解の共有を助けることが期待される。 47 2.1.2.2 関係者間でのセキュリティ関係概念の共有 セキュリティや保安、安全性、信頼性に係わる用語は、使用される分野や文脈毎に異な り多様である。安全性の分野で事故と呼ばれる事象は、セキュリティにおいてはインシデ ントなどと呼ばれ、またインシデントは、損失を伴わない事象であるイベントと区別され る。信頼性の文脈における欠陥は、セキュリティでは脆弱性などと呼ばれる。その他、安 全性におけるハザードやセキュリティにおける脅威など、指し示す事象は多くの場合同じ であっても、単純に対応付けが難しい場合などもありうる。このように、特に電力事業に 係わるセキュリティに関する基準案を提供するにあたっては、用語やそれらが示す概念が 共有されていることが不可欠であり、メタモデルによりそれが実現されることが期待され る。 2.1.2.3 本基準案と他規格との比較 規格に規定される基準や概念は、その規格内だけで理解されるものではなく、他の規格 などとの比較により、その特徴がより明確に理解される。しかし一般には、規格の要求事 項の記述だけから、規格間の概念比較などを行うことは難しく、その規格の背景や明示さ れていない想定などの知識が必要になるなどする。一方、規格に対して、そこに使用され ている用語の概念を表すメタモデルが用意されていれば、それらのメタモデルを比較する ことにより、規格間の考え方の相違点や共通点などが明らかになることが期待できる。本 調査においてはこの効果を例示するため、本基準案のベースとなっている NIST IR 7628 に対するメタモデルも試みに作成し、本基準案のメタモデルとの比較を例示している。 2.1.2.4 事業者の個別事情と基準案との対応の明確化 前述した通り、本基準案においては、想定する対象システムを表す参照モデルが提供さ れる。ここで、参照モデルがメタモデルにより提供されることにより、各事業者は、事業 者毎のシステムと参照モデルとの比較を通じて、基準の準拠を検討することができる。対 象システムは、スマートメーター単体の機器だけでなく、そこに含まれるソフトウエアや ネットワーク、コンセントレータから MDMS などの関連システム、また、それらの運用 業務や運用に携わる組織体制なども関連し、それらスマートメーター周辺の環境について も事業者毎に異なることが予想され、それらについてもメタモデルとの比較が可能にな る。さらに、基準案に係わるセキュリティなどの用語体系についてもメタモデルが提供さ れるため、事業者固有の用語などが存在する場合でも、客観的な比較を通じて、基準案へ 適合性評価が容易になると期待される。ただし、本基準案は各事業者が事業者毎のモデル を構築・管理することを求めるものではない。 2.1.2.5 基準案の見直しに伴う影響範囲の明確化 一般に、セキュリティに係わる規格は、新たな脅威の出現や、新たな脆弱性の発見、新 しい対応策の開発に応じて随時更新する必要がある。本基準案でも、新たな脅威が出現し た際の基準案の見直し手順案が示されている。ここで、それら状況の変化により、参照モ デルが変化したり、セキュリティに関する用語体系を変更したりする必要が多かれ少なか れ生じることが予想される。このような場合でも、メタモデルが存在していれば、変化の 影響範囲について、規定されている概念間の関係に基づき、客観的に決定できたり、関係 者間で共通の理解を得ることが容易になったりすることが期待できる。さらに、それら変 化について、メタモデルの変化によって事業者等に示されることにより、基準への準拠状 況への影響についても、客観的に分析することが可能になることが期待できる。 48 また、本基準案で提供するメタモデルは、抽象的な概念を表す階層と、それらに比べる と具体的な階層など、複数の階層からなり、さらにそれと直交する形で、参照モデルに係 わるもの、セキュリティ上の概念に係わるもの、セキュリティ対策に係わるものの 3 つの モデルのグループからなる。これらのメタモデル内の構造により、より影響範囲の分析が 効率化されることが期待できる。 2.1.2.6 事業者の変化に伴う影響の明確化 事業者においても、機器を更新したり、運用体制を変更したりすることは随時ありえ る。このような場合にも、基準への準拠状況を再確認する際に、メタモデルとの対応関係 を見直すことを通じて、より効率的に影響範囲の分析が実施できることが期待される。 2.1.3 提案で用いる UML 記法の解説 本節では、本基準案のメタモデルを記述する際に用いた記法について解説する。用いた 記法は、UML（Unified Modeling Language）と呼ばれる、ソフトウエアの要求仕様や設 計を記述する際に汎用的に用いられる記述法のセットの 1 つであるクラス図である。ここ では、本調査で使用した範囲でクラス図の解説を行う。なお、本節で表れるクラスは、 UML の説明のための例であり、本調査で提示するメタモデルそのものではない。 クラス図の基本要素はクラスであり、次のような図で表す。 図 7 クラスの例 ここで、クラス「スマートメーター」は、一般にはスマートメーターという概念を表す ものと解釈される。スマートメーターという概念は、スマートメーターと呼ばれるものの 集まりを表すという解釈もできるため、クラスと呼ばれる。クラス図を用いた概念規定で は一般にクラス自体に説明を加えることはあまりせず、クラス間の関係を与えることによ り、クラスを特徴付ける。 図 8 クラス間の関係を表す図の例：汎化関係 49 上図における白抜き矢印は、汎化関係を表し、B→A の時、A は B のより一般的な概 念、つまり、B は A の特殊な場合であることを表す。A と B とを集合と解釈する場合に は、B は A の部分クラスであることを表す。上図の例では、スマートメーターは機器の一 種であるし、機器はアクターの一種であることを表す。クラス間の関係として、本調査で は汎化関係の他には、集約関係及び関連関係を用いる。 図 9 クラス間の関係を表す図の例：集約関係 集約関係は、部分と全体の関係を表すものであり、図 9 では、セキュリティ対策の一部 として、管理目的や対象、管理策、影響などを含むものであることが表現されている。 図 10 クラス間の関係を表す図の例：関連関係 関連関係は、クラス間の任意の関係を表すもので、関係名が付加される。図 10 におい ては、事故は脅威によって引き起こされ、脅威はセキュリティ対策によって対応されうる ことを表現している。 2.1.4 メタモデル構築の方針 本節では、本調査で示すメタモデルの構築方針について述べる。方針は大きく分けて 2 つある。 1. NIST IR 7628 をベースラインとする 2. 階層的なモデルとする 以下にそれぞれ述べる。 50 2.1.4.1 ベースライン: NIST IR 7628 メタモデルの構築を効果的、効率的に実施するため、まずは米国のスマートグリッドに 関する規格のリファレンスモデルを提案手法により記述し、その拡張及び修正として、我 が国で利用されるスマートメーターのリファレンスモデルを構築することを試みる。この ように、まったくゼロからの構築ではなく、すでに確立された規格から構築したメタモデ ルの拡張により、目的とするメタモデルを構築することにより、構築コストが削減できた だけでなく、ベースとした規格との比較が容易になった。 米国におけるスマートグリッドのセキュリティに関する規格である NISTIR 7628 [3][4] に含まれる概念を次の図 11 及び図 12 に示す。図 12 は図 11 の詳細版である。 図 11 論理参照モデル（１）（[3]より引用） 51 図 12 論理参照モデル（１）（[3]より引用） 2.1.4.2 階層的なモデル 本調査で示すメタモデルは、前述した通り UML におけるクラス図によって記述してお り、いくつかのクラス図からなる。これらクラス図の全体像を把握しやすくするため、ク ラス図の間に抽象度による階層関係を持たせた。階層関係により、基準案に変更の必要性 が生じた場合に、影響範囲を最小化することも期待できる。具体的には、まず最も基本と なる抽象的なレベルのメタモデルを表すクラス図を次の 2 つからなるものとした。 1. リファレンスモデル： セキュリティの対象となるスマートメーターを含むシス テムや運用業務の標準的なモデルを規定する際に使用する概念を規定する。「2.2. リ ファレンスモデルについて」において詳しく説明する。 2. コンセプトモデル: 事故や脆弱性、脅威など、スマートメーター・システムのセ キュリティに関係する概念を規定するメタモデルである。「2.3. コンセプトモデルに ついて」において詳しく説明する。 これら抽象的なモデルにおいては、メタモデルを定義する際に使用する概念を定義して おり、例えば、「機器」や「人員」といった概念は表れるが、「スマートメーター」や 「利用者」といった概念は下記のより具体的なレベルで規定される。具体的なレベルのメ タモデルは、次の 3 つのグループからなる。 a) リファレンスモデルの詳細 b) コンセプトモデルの詳細 c) 基準案の詳細 52 上の a)には、対象システムに含まれる機器やネットワーク、保守や運用などに係わる人 員などについて規定する。b)のコンセプトモデルの詳細においては、本基準案で対象とす る脅威や脅威による影響の分類などについて規定する。一般的にセキュリティの 3 つの副 属性として認識されている機密性や完全性、可用性の規定はここに含まれる。c)の基準案 の詳細においては、本基準案で提示する基準の構成について規定する。メタモデルの全体 像については本節後半の「2.1.5 メタモデルの全体象」で示す。 2.1.4.3 命名規則 メタモデル内のクラス名には、次の形式を持つ。 接頭語_日本語名 接頭語はメタモデルをソフトウエアツールなどで扱う際に利用することを想定した識別 子であり、通常は日本語名で呼ぶ。本調査でも、例えば、 EQ_SM_スマートメーター というクラスを指し示す時でも、単に「スマートメーター」と参照する。クラス図やクラ スの集まりには、接頭語 JP を付与しているが（例えば、図 13 など）、本文中ではこの接 頭語も省略する。 2.1.5 メタモデルの全体象 下図にメタモデルの全体像を示す。「リファレンスモデル関連モデル群」「コンセプト モデル関連モデル群」「セキュリティ基準案関連モデル群」はそれぞれ、2.1.4.2 階層的 なモデルで述べた a)b)c)のクラスの集まりを表し、「抽象レベルモデル群」は、リファレ ンスモデルとコンセプトモデルの 2 つのクラス図からなる。矢印は依存関係を表し、A→ B の時、A は B に依存していると読む。 図 13 メタモデルの全体像 53 2.2. リファレンスモデルについて 2.2.1 国内の利用環境に対応したリファレンスモデル 本調査では、スマートメーター・システムにおける A ルートにおける情報セキュリティ 対策の検討を行った。また、対象を機器、ネットワーク、人員に分類した。一方、本メタ モデルのベースとした NIST IR 7628 においては、それらセキュリティ対策の対象となり うるものを Actor という概念で呼んでいる（図 12 参照）。本メタモデルでも Actor の用 語を採用し、「アクター」として導入している（図 14 参照）。 図 14 リファレンスモデル ここで、「機器」、「ネットワーク」、「人員」以外に、人員が所属する「組織」も導 入した。アクターは、セキュリティ対策の対象であるとともに、セキュリティ対策を担う 主体でもあるため、組織を導入している。セキュリティ対策の対象となりうるものは、ア クターを含めて次の 3 つである。 a) アクター b) 保護資産 c) 運用業務 保護資産は、情報セキュリティマネジメントシステムの規格である ISO/IEC27000 シリ ーズやコモンクライテリアの規格である ISO/IEC15408 シリーズでも欠かせない概念であ り、情報セキュリティ対策を担う主体ではないが、情報セキュリティの対象であるため、 アクターとは別に導入している。運用業務もアクターと同じく情報セキュリティの対象で もあり、情報セキュリティ対策の主体でもあるが、我が国では、運用業務をアクターとみ なすことになじみがないこと、本基準案では、報告体制や文書化、事故対応など運用業務 による対策が重要な役割を果たすことから、アクターからは分離した。運用業務は、その 対象と主体が関係する概念として規定されている。 さらに、それらセキュリティ対策の対象や主体とは別の概念として、「利害関係者」を 導入しており、電力事業者や通信事業者、利用者などを想定している。メタモデルにおい ては別の概念として導入しているが、実体レベルにおいては、例えばある組織が利害関係 者としての側面と、アクターとしての側面の両方を持つことはありうる。 54 2.2.2 海外事例との対比 ここで、本基準案のメタモデルのベースとなった NIST IR 7628 におけるリファレンス モデルに相当するモデル（下図参照）との比較を行う。今回試みに構築した NIST IR 7628 のメタモデルの全体像は、2.5.4 NIST IR 7628 のメタモデルと提案メタモデルと の比較を参照してほしい。 図 15 試みに作成した NIST IR 7628 のメタモデルにおけるリファレンスモデルに相当する部分 以下、試みに作成した NIST IR 7628 のメタモデルに表れるクラスには、接頭語として 7628 を付加しているが、以下では接頭語を除いたクラス名でクラスを参照する。Actor は、図 14 のリファレンスモデルのアクターに対応するが、NIST IR 7628 においては、各 種管理システムや運用なども含むため、本調査で提示するリファレンスモデルでいう運用 業務も含む。また、Asset は、保護資産に相当する。NIST IR 7628 では Actor は Domain （領域）と呼ぶ概念によって分類されており、本調査で提案するリファレンスモデルと異 なる。さらに、NIST IR 7628 で重要な概念が Logical Interface と呼ばれるもので、 Actor 間の関係に関する分類であるが、ネットワークの物理的特性やプロトコルの種類等 による分類ではなく、セキュリティの観点から見た論理的な分類であり、これに、本調査 で提示するセキュリティ対策に相当する High-level security requirement が対応付けら れることが特徴である。これは、NIST IR 7628 が、スマートメーターだけでなく、広く スマートグリッドに対する参照モデルを提示する必要があるためこのようなアプローチを 採用していると考えられる。本基準案では、対象をスマートメーターに関係するシステム に限定していることや、セキュリティ対策については直接アクターに相当する機器や人員 に課すため、NIST IR 7628 のような論理的なインターフェースの概念は採用していな い。 2.3. コンセプトモデルについて 2.3.1 セキュリティに関連する諸概念のモデル 図 16 にコンセプトモデルを示す。 55 図 16 コンセプトモデル 本基準案において中心となる概念は「脅威」と「セキュリティ対策」である。脅威は想 定脅威として基準案で示され、脅威に対応して基準案の本体であるセキュリティ対策が示 される。脅威とセキュリティ対策の関係は、「対応する」という関連関係で表現してい る。基準案で提示するセキュリティ対策にはいくつか項目が含まれるが、概念レベルで重 要なものは、「セキュリティ対策の対象」と「セキュリティ対策の影響」である。セキュ リティ対策の対象は、リファレンスモデルにおいて定義したアクター、保護資産、または 運用業務である。セキュリティ対策の影響は、「影響度」を持つ。この影響度を説明する ために、脅威に戻る。脅威は、「事故」を引き起こすことによって特徴付けられる。ま た、事故は「影響」を与えることによって特徴付けられる。ここでの影響は、セキュリテ ィ上望ましくない影響であり、「機密性」「可用性」「完全性」に関するものがあり、ま た、影響の対象は、アクターや運用業務、保護資産であり、セキュリティ対策の対象と重 なる。先ほどの「影響度」は、この影響の程度を表す概念であり、その対策を適用しなか った場合に想定される影響を意図しており、基準案の利用者が、その対策を選択する際の 採用基準になる。さらに、セキュリティ対策の対象であるアクターや運用業務、保護資産 は、セキュリティ上の弱点としての「脆弱性」を持ち得る。脆弱性には、それによって引 き起こされる潜在的な影響を対応付けることができる。 2.3.2 海外事例との対比 ここで、本基準案のメタモデルのベースとなった NIST IR 7628 におけるリファレンス モデルに相当するモデル（下図参照）との比較を行う。 56 図 17 試みに作成した NIST IR 7628 のメタモデルにおけるコンセプトモデルに相当する部分 High-level security requirement 、Threat、Incident、Impact 及び Vulnerability が、本調査で提示する基準案におけるセキュリティ対策、脅威、事故、影響、及び脆弱性 にそれぞれ対応する。High-level security requirement が Threat に対応（counter） し、Threat が Incident を引き起こし（cause）、Incident が Impact を与える、という関 係は本調査で提示する本基準案のメタモデルと同じである。また、影響の種類として、 Confidentiality、Availability、Integrity の 3 つを考慮する点も同一である（図では省略 している）。NIST IR 7628 においては、図 16 のコンセプトモデルのように、Threat が Actor や Asset などセキュリティ対策と関連付けられることはない一方、脆弱性に関して は、High-level security requirement が対応付けられている。 2.4. 本基準案で提示するセキュリティ対策のモデル 2.4.1 セキュリティ対策のモデル 下図にセキュリティ対策のモデルを示す。 57 図 18 セキュリティ対策のモデル セキュリティ対策は、次の情報を持つことが表現されている。 1. 2. 3. 4. 5. 6. 管理目的 セキュリティ対策の対象 セキュリティ対策の管理策 セキュリティ対策の影響 セキュリティ評価 セキュリティ対策実施者 「セキュリティ対策の対象」と「セキュリティ対策の影響」については、コンセプトモ デルですでに表れている。「セキュリティの管理策」は、セキュリティ対策の具体的な定 義が含まれるものであり、セキュリティ対策の対象毎に定義されることが表現されてい る。また、本基準案は、セキュリティ対策毎に「セキュリティ評価」の方法が対応付けら れることが特徴である。セキュリティ評価については次節で述べる。以上の情報は、本基 準案のセキュリティ対策の定義に基づいている。 2.4.2 セキュリティ評価のモデル 下図にセキュリティ対策のモデルを示す。 58 図 19 セキュリティ評価のモデル セキュリティ評価は、次の情報を持つことが表現されている。 1. 2. 3. 4. 評価手順 評価の対象 評価の条件 セキュリティ評価者 「評価手順」は、「評価手法」及び「評価結果」からなる。評価の対象は「文書」であ り、文書は、「報告書」または「ログ」である。「評価の条件」は、「評価者のスキル」 と「評価に使用するツール」からなる。以上の情報は、本基準案のセキュリティ評価の定 義に基づいている。 2.5. 提案するメタモデルの詳細説明 2.5.1 リファレンスモデル関連モデル群 リファレンスモデル関連モデル群は次のクラス図からなる。 1. アクターモデル 2. 利害関係者モデル アクターモデルは、アクターの詳細を規定するモデルであり下図に示される。 59 図 20 アクターモデル 利害関係者モデルは、利害関係者の詳細を規定するモデルであり、下図に示される。 図 21 利害関係者モデル 2.5.1.1 利用環境のモデルについて 前節の図 20 で示したアクターモデルに現れるアクターが、スマートシステムの構成要 素を表すのに対して、図 14 のリファレンスモデルに現れるアクター以外の要素である、 利害関係者、運用業務、運用者、保護資産が、利用環境のモデルに相当する。ここで、利 害関係者については、前節の図 21 の利害関係者モデルにおいて、本基準案の想定を示し ている。また、今回の基準案の直接の利用者を想定した利害関係者しか含めていないが、 スマートメーター・システムについて利害関係を持つ、最終消費者や国民一般について も、本基準案の利用時には利害関係者に含めることも検討すべきである。 2.5.2 コンセプトモデル関連モデル群 コンセプトモデル関連モデル群は次のクラス図からなる。 1. 脅威モデル 2. 影響モデル 60 脅威モデルは、脅威の詳細を規定するモデルであり、下図に示される。 図 22 脅威モデル 影響モデルは影響の詳細を規定するモデルであり、下図に示される。 内容的には、コンセプトモデルに含まれるものであるが、機密性や可用性、完全性など のセキュリティの副属性が一般にもなじみが深く、コンセプトモデル上で示した方が他の 概念の理解の助けになるため、コンセプトモデル上にも表している。 図 23 影響モデル 2.5.3 セキュリティ基準案関連モデル群 セキュリティ基準案関連モデル群は以下のクラス図からなる。 1. セキュリティ対策モデル 2. セキュリティ対策の影響モデル 3. セキュリティ評価モデル この中で、「セキュリティ対策モデル」及び「セキュリティ評価モデル」についてはそ れぞれ 2.4.1 セキュリティ対策のモデルおよび 2.4.2 セキュリティ評価のモデルでそれぞ れ説明している。 下図にセキュリティ対策の影響モデルを示す。 61 図 24 セキュリティ対策の影響モデル セキュリティ対策の影響は、機密性に関するもの、完全性に関するもの、可用性に関す るものからなり、それぞれ、影響モデルにおいて規定している、機密性、完全性、可用性 に対応する影響の程度が対応付けられていることを表現している。 2.5.4 NIST IR 7628 のメタモデルと提案メタモデルとの比較 2.5.4.1 NIST IR 7628 のメタモデルの概要と本基準案のメタモデルとの比較 前述した通り、本基準案のメタモデルを構築するにあたり、ベースとして NIST IR 7628 のメタモデルを試みに構築した。本節では本基準案のメタモデルとベースとした NIST IR 7628 のメタモデルとの比較を行う。 試みに構築した NIST IR 7628 は次のクラスのグループからなる。 1. Security related concepts and issues related models 2. Logical architecture and interface related models 3. High-level security requirement related models 上の 1 の Security related concepts and issues related models は、次のクラス図の集ま りからなる。 a) b) c) d) Security related concept model Adversaries model Vulnerability model Impact model 上の 2 の Logical architecture and interface related models は、次のクラス図の集まり からなる。 e) f) g) h) i) j) k) l) Domain model Domain relation model Customer domain model Bulk generation domain model Distribution domain model Service provider domain model Logical interface category model Logical interface involving meter (1) model 62 m) Logical interface involving meter (2) model 上の 3 の High-level security requirement related models は、次のクラス図の集まりか らなる。 n) Meter related Security Requirement (1) model o) Meter related Security Requirement (2) model 下図に、NIST IR 7628 におけるセキュリティ関連の概念である上の a)の Security related concept model を示す。 図 25 NIST IR 7628 におけるセキュリティ関連概念を表すモデル まず、本基準案の脅威モデル（図 22）及び影響モデル（図 23）は、NIST IR 7628 を踏 襲している。さらに、脆弱性と影響についても変わるところはないが、NIST IR 7628 に おいては、脅威は特に Actor などと対応付けられていないが、本基準案では脅威の対象が 明示され、脆弱性については、NIST IR 7628 においては、スマートグリッドにおける Vulnerability が列挙され、それぞれ対応する High-level security requirement が記載さ れているが、本基準案では、脆弱性は個々の機器や運用体制に依存するとの立場から、標 準的なリストの提供などはしていない。 下図に、b)の Adversaries model を示す。 63 図 26 NIST IR 7628 における Adversary を表すモデル 下図に、c)の Vulnerability model を示す。 図 27 NIST IR 7628 における Vulnerability を表すモデル 下図に、d)の Impact model を示す。 64 図 28 NIST IR 7628 における Impact を表すモデル NIST IR 7628 においては、 Actor は Domain というグループに分類されている。下図 に、e)の Domain model を示す。 図 29 NIST IR 7628 における Domain を表すモデル Domain に含まれる Actor 間の通信の可能性は、図 11 のような図で、セキュアな通信路 と電流の流れが示されている。下図に、f)の Domain relation model を示す。 図 30 NIST IR 7628 における Domain 間の関係を表すモデル 下図に、g)の Customer domain model を示す。 65 図 31 NIST IR 7628 における Customer domain を表すモデル 下図に、h)の Bulk generation domain model を示す。 図 32 NIST IR 7628 における Bulk generation domain を表すモデル 下図に、i)の Distribution domain model を示す。 図 33 NIST IR 7628 における Distribution domain を表すモデル 下図に、j)の Service provider domain model を示す。 66 図 34 NIST IR 7628 における Service provider domain を表すモデル 下図に、k)の Logical interface category model を示す。 図 35 NIST IR 7628 における Logical interface category を表すモデル 下図に、l)の Logical interface involving meter (1) model を示す。 図 36 NIST IR 7628 における Meter に関連する Logical interface を表すモデル（１） 下図に、m)の Logical interface involving meter (2) model を示す。 67 図 37 NIST IR 7628 における Meter に関連する Logical interface を表すモデル（２） 下図に、n)の Meter related Security Requirement (1) model を示す。 図 38 NIST IR 7628 における Meter に関連する High-level security requirement を表すモデル （１） 下図に、o)の Meter related Security Requirement (2) model を示す。 68 図 39 NIST IR 7628 における Meter に関連する High-level security requirement を表すモデル （２） 2.5.5 提案メタモデルの妥当性の検証 今回作成した NIST IR 7628 のメタモデルについては、本調査にも報告されている Tim Kelly 教授へのヒアリングによるレビューを実施し、妥当性を検証している。そこで得ら れたコメントと、本調査で提示する NIST IR 7628 のメタモデルへの反映状況を示す。 第 3 回有識者委員会にて、本メタモデルの利害関係者の範囲に国民も含めるべきではな いかという意見があったが、今回の対象範囲である A ルートの基準案の利用者の中に直接 国民は含まれず、本調査では対象外としている。 しかしながら「2.5.1.1 利用環境のモデルについて」で解説した通り、国民を含めた範 囲となる場合でも、本メタモデルを活用して基準を策定できることは検討済みであり、本 基準案の利用時には、利害関係者に国民を含めることも検討すべきである。 69 表5 NIST IR 7628 のメタモデルに対する Kelly 教授からのコメントとその対応 また、提案メタモデルは、我が国の利用環境に合わせた部分以外、以下の観点から、 NIST IR 7628 のメタモデルを踏襲していることを確認している。 1. 主要なセキュリティ概念が一致している 2. 対象のモデルについて比較が可能である 3. 上記 1,2 に基づき、セキュリティ対策について比較が可能である 検証した結果を次に示す。 70 表6 NIST IR 7628 と策定したメタモデルとの概念比較 71 策定したメタモデル における概念 72 本表にある「コンセプトモデル」、「リファレンスモデル」、「リファレンスモデ ル関連モデル群」、「コンセプトモデル関連モデル群」は、今回提案したモデルが今 後の環境の変更に対応できるものとして実装することを目指して分類している。 モデルの骨子となる変更されない部分として「コンセプトモデル」を設定してお り、これが全体のフレームワークとなって機能する。つまり環境が変化してもこの部 分が変化しないことにより、環境の変化の前後での比較や関連性の説明ができるよう になる。 一方で「リファレンスモデル」については環境の変化に影響されやすいものをまと めており、さらにその詳細なものを「リファレンスモデル関連モデル群」として設定 している。リファレンスモデル関連モデル群に記載された機器や業務などをリファレ ンスモデルとしてまとめ、これをコンセプトモデルに反映して、セキュリティ対策を 検討することができるようになる。また、これによってセキュリティ対策の漏れなど が検証できるような仕組みを提供している。 「コンセプトモデル関連モデル群」は全体としては変化がないものだが、組織や団 体によって評価の基準が異なる可能性があるものを抽出した。今回のスマートメータ ーにおいては、これらは事業者に共通のものと考えられるが、今後の事業者の形態等 の変化により、変化が生じる可能性があるものとして抽出した。 これらを全て洗い出し、検討することによって社会的環境の変化に適応したモデル の変更を行うことができるようになる。 【参考資料】 [1] Unified Modeling Language(UML), http://www.omg.org/spec/UML/ [2] OMG's MetaObject Facility(MOF), http://www.omg.org/mof/ [3] Introduction to NISTIR 7628 Guidelines for Smart Grid Cyber Security, Sep 2010. [4] NISTIR 7628 Revision 1, Guidelines for Smart Grid Cyber Security, Sep 2014. [5] ISO/IEC27000: 2009, Information technology — Security techniques — Information security management systems — Overview and vocabulary. [6] ISO/IEC15408-1: 2009, Information technology — Security techniques — Evaluation criteria for IT security — Part 1: Introduction and general model. 73 第３章 我が国の状況に適したセキュリティ評価手順等の検討 本調査では、スマートメーター・システムにおける基準策定ですでに先行している海外 における調査結果、及び電力事業者やスマートメーター関連事業者（メーターメーカー、 システムベンダ等）、有識者、関連省庁等から構成される検討会での議論をもとに、我が 国のスマートメーター・システムのセキュリティ対策の考え方及びセキュリティ評価の考 え方を定め、ガイドラインとして取りまとめた。ガイドライン本体は非公開とするが、本 章では、その概要について示す。 海外調査においては、NIST IR 7628 に記載しているモデルに対して、社会変容への対 応及びスマートグリッド・セキュリティの進歩への対応が求められているが、我が国の電 力事情とは異なるモデルであるため、このモデルを我が国へ適用することは困難であるこ とが判明した。この問題については、リファレンスモデルの検討によって、我が国におけ るスマートグリッドのセキュリティに関する業界事情の調査及び本事業で設置した有識者 検討会において内容を精査し、我が国のスマートメーター・システムを反映し、その結果 をもとに、基準案を検討した。また、フィンランドの調査では、セキュリティ対策を検討 するためには、具体的な脅威と対策の関係及び事故からの学習も重要であることがわか り、想定脅威と対策の関係について示した。現在利用されている環境においても、これか ら構築される環境においても、考えうるリスクについて検討し、事故発生を未然に防止す るため、及び事故による影響を最小限にするため対策を提供する。 さらに、米国の NIST の調査において、セキュリティ管理基準の他にも評価のための手 引書（アセスメント・ガイドライン）が重要であることが判明したため、ガイドラインと して我が国における評価の考え方について検討した結果をまとめた。実施した対策が、ス マートメーター・システムを取り巻く環境・リスクを考慮して適切かどうか評価するため の手順も合わせて示した。 ガイドラインの活用により、電力業界及び関係業界等においてセキュリティレベルを向 上する取り組みが推進されることが望まれる。 なお、ガイドラインは、デマンドレスポンスの具体化等、スマートメーター・システム の機能変化等の社会変容やセキュリティインシデントの発生状況に合わせて、想定する脅 威を改め、継続的に見直しを行うものとする。 74 3.1. スマートメーター・システムに関連する脅威 3.1.1 スマートメーター・システムに関連する脅威の考え方 本調査時はスマートメーターの運用が本格的に始まっておらず、実際に発生した事 故について検討をしているわけではない。スマートメーターの運用が本格的に始まっ た時に実際の脅威が見えてくると考えられる。 想定脅威はスマートメーター・システムの機能の拡大や脅威の変化に応じて今後も 更新が必要である。 3.1.2 脅威の検討方法 脅威やぜい弱性と合致する管理策が継続的に検討できるよう、電力業界や関係業界 における最新の脅威についての情報共有が重要であり、事業者等が脅威を踏まえて自 主的かつスピーディにセキュリティレベルを向上する取組を行うことが必要である。 平行して、国においても、業界で検討される想定脅威を適切に管理し、必要な対策に 関する考え方・指針等を示していく必要がある。 3.2. スマートメーター・システムのセキュリティ対策 3.2.1 セキュリティ対策の策定 本調査では、今後の想定脅威に応じたセキュリティ対策の更新ができるように、情 報セキュリティマネジメントの基本的考え方（JIS Q 27001）や規範となる管理策 （JIS Q 27002）を基に、スマートメーターに関する海外基準で示される具体的な管 理策と同等レベルの管理策を策定した。また、各事業者においてリスク評価を行い、 対策の要否を判断するために、対策を実施しない場合の影響を提示した。 情報セキュリティ対策の目的は「予防」及び「被害の極小化」である。これは単に 予防だけではなく、万一事故が発生した場合の検知を迅速に行い、情報収集及びその 後の判断という事故対応も含む。これを行うために、事故発生時に必要な報告系統お よび判断組織を構築することも重要である。さらに、このような事故対応を含め、セ キュリティ対策に関しては、日常的に経営層がモニタリングを行い、その結果を評価 し、次の方向付けを行うことが望ましい。これは一般的に情報セキュリティガバナン スと呼ばれており、本調査においては情報セキュリティガバナンスを実現する体制づ くりについてもセキュリティ対策の範囲とする。すでにリスクマネジメント組織が作 られている場合でも、情報セキュリティマネジメントから情報セキュリティガバナン スへの移行を検討し、経営目標や経営課題に照らし合わせた内容が情報セキュリティ 対策に反映されることが望ましい。 75 また、今後スマートメーター・システムの機能の拡大や脅威の変化に応じて、管理 策を更新する必要があることから、セキュリティ対策についての継続的な改善と学習 が効果的である。そのため、「事故の対応」において特に学習することの重要性を反 映した管理策を示している。 スマートメーター・システムでは、電力量を正確に計測するだけではなく、電力供 給のための開栓、閉栓の機能を有している。不正な開閉が行われても電力供給支障が ない等、事業目的を明確にし、事業継続の視点を明確にすることも情報セキュリティ 対策としては重要なポイントとなる。 スマートメーター・システムの情報セキュリティ管理基準（案）では、これらを踏 まえて、「ガバナンスとマネジメント」「スマートメーター・システム」「事業継 続」（図 40）の要素を分類し管理策を整理した。 図 40 管理基準（案）の構成 3.2.2 セキュリティ対策の検討 管理基準（案）においては、情報セキュリティ対策の方向性について明確にするた めにそれぞれの「管理策」について「管理目的」を設定している。管理策および管理 目的は脅威と紐付けるために、スマートメーター・システムにおける想定脅威と管理 策の対応表を示している。 具体的な対応については例示的に「詳細管理策」を示しているが、これを選択する かどうかについては、各事業者においてシステムや業務の対象とその影響を検討した 上で判断する。 76 3.2.3 対策評価の検討項目 情報セキュリティ対策が有効であることを確認するためには評価を行う必要があ る。その手法については自己評価で行うことが可能な場合もあれば、第三者評価が必 要な場合もある。どちらが適しているかは、評価の目的や、対象における利害関係者 の範囲等によって異なる。評価結果の信頼性の裏付けとして、第三者評価が必要・あ るいは有効であることもある。 第三者評価においては、任意の監査法人やセキュリティの検査ベンダの活用や、必要 に応じて評価を総合的に行う第三者機関の活用も有効である。特に定期的な評価や点検 などにおいては、作業が形骸化しないような工夫として、環境に応じた検査項目の見直 しなども必要になる。 ガイドラインでは、評価が正しいことを示すために「評価手順」を明確にし、「評価 の条件」を策定している。 評価においては、手順を明確にするだけではなく、市販されているツールを利用する ことも必要になる。評価ツールには、ドキュメント解析型ツールやソースコード解析ツ ール、DoS 攻撃の模擬ツールやファジングツール等の擬似攻撃型ツール、証拠保全型 （フォレンジック）ツールなどがあり、目的に応じて利用することが望ましい。例えば、 すでに配布されているスマートメーターに対しては擬似攻撃型ツールでぜい弱性の有 無を判断した後に、運用面で補完業務を検討し、セキュリティレベルを高めるといった 形で利用できる。 3.2.4 管理基準（案）のフォーマット これまでに示したセキュリティ対策と評価の考え方を示すために、管理基準（案） のフォーマットに以下の項目を設定した。 管理策タイトル：管理策の名称 目的：管理策を実施する目的 対象：管理策を実施する対象 管理策（管理策、詳細管理策）： 目的達成のために実施が望ましい対策 各種基準等を参考に記載 管理策（X.X レベル）は基本的な対策 詳細管理策（X.X.X レベル）は管理策を例示的に具体化した対策 影響 評価手順、評価の条件 77 管理策タイトル 管理策の名称 目的 管理策を実施する目的 対象 管理策を実施する対象 管理策 目的達成のために実施が望ましい対策 各種基準等を参考に記載 管理策（X.Xレベル）：基本的な対策 詳細管理策（X.X.Xレベル）： 管理策を例示的に具体化した対策 影響 対策を実施しない場合の「機密性」・「完 全性」・「可用性」の観点での影響 評価手順・条件 対策の有効性を評価するための方法 1. 組織 1.1 報告体制 目的：組織の責任者が、適切にスマートメーターシステムの情報セキュリティに関する 決定を行うことができるようにするため。 対象：スマートメーターシステムを取り扱う組織 管理策：適宜に情報を集約し、指示を周知できるような報告体制を構築すること。これ により、スマートメーターシステムに関する組織のセキュリティガバナンスの構築を行 うこと。 1.1.1 情報セキュリティの目的 組織が情報セキュリティに関する意識を明確にし、共有できるように情報セキュリテ ィの目的を明確にし、文書化することが望ましい。 ＜対策を実施しない場合の影響の例＞ 情報セキュリティの目的を明確にしない場合、組織に属する人員がそれぞれの判断に おいて組織の目的に反した活動をしてしまう可能性がある。 ・ 機密性：— ・ 完全性：情報セキュリティ活動における目的の誤認により、他のセキュリティ対策 の効果を損なわせる ・ 可用性：— ＜対策の評価＞ □ 情報セキュリティの目的が文書化されていることを確認すること □ 情報セキュリティの目的が周知・徹底されていることを確認する 図 41 管理基準案のサンプル 3.2.5 事業者における管理基準（案）の活用 各事業者は、本調査で提示した管理策すべてを行う必要はないが、すべてを検討す る必要はある。つまり、要否についてすべての管理策を精査し、判断することが望ま しい。 管理策の選択のベースとなるのは、情報セキュリティの範囲の決定、そして脅威によ る影響を受け容れることができるかどうか、つまり「リスク受容レベル」によるものと なる。まずは情報セキュリティの範囲を明確にし、文書化した結果に基づいて、対象と なる管理策を精査する。次に予め設定したリスク受容レベル（事業目的、または経済的 に影響を受けないと判断できるレベル）と、各管理策に設定された「影響」を照らし合 わせて検討をする。対象となった管理策を自社に合わせた内容とすることで、それぞれ の組織のセキュリティ対策として活用することができる。 78 第４章 スマートメーター・システムのセキュリティ検証を支援す るツール環境のデータベース化 機器における情報セキュリティでは、機能要件だけではなく保証要件も重要な要素とな る。開発ベンダが基準に従って開発をする際や、利用企業が自らのセキュリティレベル （基準）に合わせた製品を選択する際、また機器が正常に動作していることを定期的かつ 継続的に検証するためには、検証を支援するソフトウエア（ツール）等の利用は必須とな る。 本調査においても海外調査にて検査の自動化ツールの重要性が指摘された。そのため、 スマートメーターのセキュリティ検証ツールについて、利用可能状況、ツールの特性や機 能、適用事例等を容易に検索することのできるデータベースを作成した。また、検証ツー ルの分野ではシステムのセーフティ（機能安全）の検証ツールが、セキュリティ検証に利 用できる機能や性能を有するものもあるため、データベースにはそれらのツールの情報を 必要に応じて含めた。 ツールの調査の結果として、解析型ツール、疑似攻撃型ツール、証拠保全型ツールの 3 種類に分類し、スマートメーター・システムの開発プロセスを考慮したツールの利用シナ リオとして設計＆実装フェーズ、テストフェーズ、運用フェーズでの利用を意識した。 4.1. 検証ツールの調査と DB 化 4.1.1 DB 化の作業 スマートメーター・システムのセキュリティ検証ツールの DB 化の業務の流れを図 42 に示す。DB 化にあたっての作業項目は以下の 4 つである。 ツールの調査 ツールの活用事例の調査 ツール提供企業へのインタビューによる調査 データベース(DB)の作成 79 図 42 検証ツールの DB 化の業務の流れ (1)ツールの調査 ツールの調査では、まず、その種類（解析型ツール、疑似攻撃型ツール、証拠保 全型ツール）によって大きく分類した上で、検証ツールの対象とする言語や OS （Operating System）、検証が可能な事象などの基本的な特徴や機能、性能を調 査した。 (2)ツールの活用事例の調査 検証ツールを実際の製品に活用して不具合や障害を発見した事例、活用の際のユ ーザ視点からの操作性について調査した。また、成功事例を分析することによっ て、ツールの最適な利用シナリオを検討した。 (3)ツール提供企業へのインタビューによる調査 検証ツールの利用者とは相反する立場であるツール提供企業に対してインタビュ ーを行うことで、検証ツールの全体像や最大限発揮できる機能や性能について調査 した。 (4)データベース（DB）の作成 上記(1)～(3)で得た情報を統合、整理した上で、開発ベンダや利用企業が汎用的 に検討できる項目を列挙し、比較検討ができるようなスマートメーター・システム のセキュリティ及びセーフティの検証ツールのデータベースを作成した。 80 4.2. ツールの調査 4.2.1 調査概要 現在、国内外では情報システムの開発、検証、保守に関する多種多様なツールが公開あ るいは市販されている。本調査ではまず、それらのツールの概要と主要機能を調査して、 スマートメーターのセキュリティ及びセーフティの検証に有効なツールを抽出した。 抽出にあたっては、プロジェクト計画の作成や人員管理など、システム開発業務の管 理、運用面でのみ利用されるツールは対象外とし、セキュリティ基準を満たす機能及び性 能に不具合がないか、情報漏えいを誘発するような機能障害がないか、などのセキュリテ ィとセーフティの技術的側面からシステムの検証が行えるツールを対象とした。 図 43 ツール調査概要 抽出したツールに対しては、以下の観点から詳細な調査を行った。 ・ ・ ・ ・ ・ ・ ・ ・ セキュリティ及びセーフティの検証に特化した検証機能の有／無と詳細 ファジング機能の有／無と詳細 静的解析／動的解析の区分 カバレッジ測定機能及び分析機能の有／無と詳細 テストケース生成機能の有／無と詳細 自動テスト／手動テストの有無と詳細 基盤となっている科学技術の有／無と種類 シミュレーション機能の有／無と詳細 81 ・ 再検証、継続検証の実施しやすさ なお、機器における情報セキュリティでは、機能要件だけではなく保証要件も重要な要 素となるため、開発ベンダや利用企業が機器の保証要件を責任持って定義できるよう、ツ ールの調査対象についても、いわゆるフリーソフトや試供版のツールは対象外として、動 作保証や保守、検証結果の正当性が確約された製品版としてのツールだけを対象とした。 4.2.2 調査にあたってのツールの分類 現在、国内外では情報システムの開発、検証、保守に関する多種多様なツールが公開あ るいは市販されている。本調査ではまず、スマートメーター・システムのセキュリティ検 証に利用できるツールとして、検証対象と検証手法を考慮して、それらを大きく 3 つに分 類した。検証ツールをうまく使いこなすためには、機能や性能だけでなく、どの対象に対 してどのように検証するかという観点が重要だからである。分類の 1 つ目は「解析型ツー ル」、もう 1 つは「疑似攻撃型ツール」である。さらに 3 つ目の分類として、企業におけ る機密情報や極秘情報の漏えい問題に対する処置と、導入によって問題の抑止効果を発揮 するとして近年注目されている「証拠保全型ツール」を本調査の対象とすることとした。 解析型ツール ＝ ドキュメント解析＋ソースコード解析ツール 疑似攻撃型ツール ＝ Dos 攻撃の模擬ツール、ファジングツールなど多数 証拠保全型ツール ＝ フォレンジックツール 解析型ツールには、ドキュメント解析ツールとソースコード解析ツールがある。ドキュ メント解析ツールはドキュメントの矛盾や曖昧さを検証するツールである。ソースコード 解析ツールは、ドキュメントに基づいてコーディングされたソフトウエアのソースコード を直接、静的あるいは動的に解析して不具合を発見するツールである。ソースコードの内 容を直接検証するためホワイトボックステスト（white box test）で用いるツールの 1 つ であると考えられている。 疑似攻撃型ツールは、検証対象に対して疑似的な攻撃を仕掛けて、その反応を検証する ことによって不具合を発見するツールである。DoS/DDoS 攻撃を模擬するツールやファジ ングツール、既知の攻撃を模擬するツールなど多種多様なツールが存在する。 証拠保全型ツールは、近年の情報漏えい問題やサイバー攻撃による緊急事案発生の増加 に伴い注目されているツールである。証拠保全型ツールはフォレンジックツールとも呼ば れている。フォレンジックツールはネットワーク上のデータや装置内に存在するデータを 取得して調査を行うツールである。疑似攻撃型ツールと証拠保全型ツールは、システムの ドキュメントやソースコードの内容を直接解析することなく、入力データと出力データ （応答、挙動など）だけに着目して検証するためブラックボックステスト（black box test）で用いるツールの 1 つであると考えられている。 82 検証対象と検証手法による分類は、スマートメーター・システムの開発ベンダと利用企 業のそれぞれの立場に応じて、以下のように対応付けることができる。 図 44 開発ベンダと利用企業へのツールの対応付け スマートメーター・システムの開発ベンダが、前述したセキュリティ基準に従ってって ソフトウエアを開発する際には解析型ツールを用いる。さらに、ソフトウエアをハードウ エアに組み込んだ後の製品版に対しては疑似攻撃型ツールを用いることができる。一方 で、プログラム設計書やソースコードの内容を知ることができない利用企業については、 自社のセキュリティ基準に合わせた製品を選択する際には疑似攻撃型ツールを用いるが、 利用している機器が正常に動作していることを定期的かつ継続的に検証するためには証拠 保全型ツールを用いることができる。 解析型ツール 解析型ツールのうち、ドキュメント解析ツールは論理的に記述された仕様書や設 計書の矛盾や、不具合混入のもととなる日本語の曖昧さを検証するツールである。 「曖昧さ」の簡単な例としては「小さな猫を抱いた少女」という文章が挙げられ る。小さな／猫を抱いた少女、と読むと小さいのは少女である。小さな猫を／抱い た少女、と読むと小さいのは猫となる。たった数文字の文章であるにもかかわら ず、文章を読む時の読み手の区切り位置によって意味が異なってしまう例である。 この例ではさらに、前者の場合は猫の大小は不明であり、後者の場合は少女が小柄 なのか大柄なのかがわからない。また、プログラムの例では「A and B or C」と 「A and (B or C)」は異なる条件での判定となってしまう。 ソースコード解析ツールは、開発者が製作したソフトウエアのソースコードを静 的あるいは動的に解析して不具合を発見するツールである。製作したソフトウエア を開発者自身が単体で検証できるだけでなく、開発チーム毎にまとめたソフトウエ アの検証や、ハードウエアと組み合わせる前のソフトウエアだけの総合的な検証等 が行えるため、スマートメーター・システムの開発の早い段階で不具合を検出して 改修につながることができる。本ツールではソフトウエアのバッファオーバーフロ ーや NULL ポインタの参照、無限ループ、未初期化の領域参照などの脆弱性を発 見することができる。ソースコード解析ツールの利用イメージ図を図 45 に示す。 83 図 45 ソースコード解析ツールの利用イメージ図 なお、静的解析とは、ソフトウエアを実際に動作させずにソースコードの記述内 容に対して検証を行うことである。実際に動作させないことから「静的」解析と呼 ばれている。一方で、「動的」解析はソフトウエアを疑似的あるいは実際に動作さ せて検証を行うことである。 本調査では比較的高機能なものや、情報システムの開発現場で普及していると考 えられる解析型ツールについて、詳細な情報を調査してデータベースに掲載した。 また、セーフティの分野で先行している自動車分野や社会インフラ分野、エンター プライズシステムの開発等で利用されている検証ツールについても、その概要を調 査してデータベースに掲載した。 疑似攻撃型ツール 疑似攻撃型ツールは、検証対象に対して疑似的な攻撃を仕掛けて、その反応を検 証することによって不具合を発見するツールである。DoS 攻撃の疑似攻撃を行うツ ールでは、検証対象やネットワークに対して装置や回線が麻痺してしまうような大 量のデータを一度に送り込み、その反応を見ることによって通信能力や処理能力の 検証を行う。DoS 攻撃よりも防御が困難な DDoS 攻撃は、大量の踏み台と呼ばれ るコンピュータから、サーバや装置に対して攻撃を行うことである。一般の DoS 攻撃であれば、攻撃を仕掛けてくる相手との通信を切断することによって対策でき るが、DDoS 攻撃では、大量のコンピュータから大量のデータが送出されるため、 個々の攻撃相手への対策が困難となる。攻撃が終了しても、サーバ側としては、不 本意ながら踏み台となってしまったコンピュータこそが攻撃元であると認識してし まう問題が起きるため、社会的な被害や混乱が大きくなる傾向にある。 また、近年、注目されているファジングツールはシステムに対して問題が発生す るようなデータを入力させて不具合を発見するツールである。ファズ（fuzz）と は、英語で“曖昧にする”等の意味を持つが、情報システムの検証では、問題が発 生する可能性のあるデータを検証対象とするソフトウエアに対して送信して、その データに対する応答や挙動を監視することでソフトウエアの脆弱性を検出する手法 84 と考えられている。ファジングツールは、問題を引き起こしそうなデータを様々な パターンで自動生成して、それらを検証対象であるソフトウエアに対して無作為に 出力する。データの内容や送信順序が無作為であるため、人為的に作成したテスト データでは発見が困難な不具合を発見することができる。 例えば、あるソフトウエアに通常の利用では想定していない巨大な数値や、非常 に長い文字列、緊急時の処理でのみ用いる制御コードやビット配列などのデータを 入力させた結果、その応答や挙動が、開発者の意図した動作とは異なる異常な動作 であった場合は、当該ソフトウエアに何らかの問題が内在している可能性がある。 本ツールを用いるにあたっては注意すべき点がある。本ツールは、ブラックボッ クステストで用いることができるツールである。一般的に組込みシステムのブラッ クボックステストでは、入手困難なソースコードではなく製品そのものを入手でき れば検証が行えると考えられている。さらに、近年、ファジングツールは他のツー ルに比べて自動化が進んでいるため、製品と本ツールがあれば、開発者以外の第三 者でも比較的容易に検証することができる。従って、悪意を持つ攻撃者がスマート メーター・システムの一部あるいはシステム稼働上で重要な製品などを入手するこ とができれば、本ツールを用いて脆弱性を発見し、攻撃目的でその脆弱性を悪用す る可能性があることに注意しなければならない。 本調査では、前述したように近年注目されているファジングツールを中心に詳細 な情報を調査してデータベースに掲載した。また、従来から利用されている、既知 の攻撃を模擬するツールや、直接的な攻撃はしないが何らかの手法によって既知の 脆弱性を発見することができる脆弱性検査ツールについても、その概要を調査して データベースに掲載した。 図 46 ファジングツールの利用イメージ図 85 証拠保全型ツール 証拠保全型ツールはフォレンジックツールとも呼ばれている。フォレンジック （Forensic)とは、犯罪捜査等で用いられてきた言葉であり「科学的犯罪捜査の」 「法医学的な」という意味を持つ。情報システムの検証では、サイバー攻撃や情報 漏えい等の有事の際に、コンピュータやネットワークシステムのデータや状態など の「法的な証拠能力を有する」情報を収集することである。フォレンジックツール は、それらの証拠収集を自動的に行うツールであり「証拠保全」「解析」「証拠提 出」の機能を有するのが一般的である。前述の解析型ツールと疑似攻撃型ツールで は難しい不正アクセスの追跡や情報漏えいインシデントの発見等を行うことができ る。フォレンジックツールは一般的に 2 つに分類される。ネットワークフォレンジ ックツールとコンピュータフォレンジックツールである。 ネットワークフォレンジックツール コンピュータフォレンジックツール ネットワークフォレンジックツールは、ネットワーク上を流れる全ての通信デー タを収集するツールである。どのコンピュータからどのネットワーク機器を通して 情報漏えいしたかを特定することができる。 一方で、コンピュータフォレンジックツールは、調査対象であるコンピュータの 情報を収集するツールである。攻撃者や情報漏えいを行った者が故意に消去したデ ータ等を復元することができる。ただし、本ツールは事後調査のためのツールであ り、不審なコンピュータや情報漏えいの経路を特定することはできない。 両ツールは、ネットワークフォレンジックツールが有する通信データの解析機能 も用いて不正なコンピュータの特定を行い、そこで特定された不正なコンピュータ をコンピュータフォレンジックツールで調査する、という使い方が一般的である。 図 47 フォレンジックツールの利用イメージ図 86 4.2.3 規格・標準・ガイド類について ツールのデータベースで登場する主な規格・標準・ガイド類と関係する組織等を以下に 示す。 (1) CERT ネットワークに関する不正アクセス、不正プログラム、システムの脆弱性問題等に関す る情報を収集して分析を行い、その結果を発表する組織である。米国カーネギーメロン大 学のソフトウエア工学研究所（Carnegie Melon University, Software Engineering Institute）に置かれている。 (2) CVSS（Common Vulnerability Scoring System） 共通脆弱性評価システム。情報システムの脆弱性に対するオープンで包括的、汎用的な 評価手法の確立と普及を目指し、米国インフラストラクチャ諮問委員会（NIAC: National Infrastructure Advisory Council ）のプロジェクトで 2004 年 10 月に原案が作成され た。その後、CVSS の管理母体として FIRST(Forum of Incident Response and Security Teams)が選ばれ、FIRST の CVSS-SIG(Special Interest Group)で適用推進や仕様改善が 行われており、2005 年 6 月に CVSS v1 が、2007 年 6 月に CVSS v2 が公開された。 (3) CWE（Common Weakness Enumeration） 共通脆弱性タイプ一覧。ソフトウエアにおけるセキュリティ上の弱点（脆弱性）の種類 を識別するための共通の基準を目指している。1999 年頃から米国政府の支援を受けた非 営利団体の MITRE が中心となり仕様策定が行われ、2006 年 3 月に最初の原案が公開さ れた。その後、40 を超えるベンダや研究機関が協力して仕様改善や内容拡充が行われ、 2008 年 9 月 9 日に CWE バージョン 1.0 が公開された。 CWE では、SQL インジェクション、クロスサイトスクリプティング、バッファオーバ ーフローなど、多種多様にわたるソフトウエアの脆弱性を識別するための、脆弱性の種類 （脆弱性タイプ）の一覧を体系化して提供している。 (4) CWE/SANS Top25 CWE 及び SANS が中心となり、世界各国のセキュリティに関する組織や団体に所属す る有識者の協力を得て、脆弱性の原因となる危険度の高いプログラミングエラー上位 25 個を選んだものである。SANS は、政府や企業・団体間における研究、及びそれらに所属 する人々の IT セキュリティ教育を目的として 1989 年に設立された組織である。 87 (5) DISA（Defense Information Systems Agency） 国防情報システム局。米国国防総省の機関。軍事通信、電波監理や通信システムの開発 など情報システム全般を管轄する。 (6) DISA STIG（Security Technical Implementation Guide） DISA によって策定されたセキュリティ技術導入ガイド。コンピュータソフトウエア及 びハードウエアの安全な導入と保守を実現するために標準化された方法である。 (7) DO-178B 航空機のシステムに組み込まれるソフトウエアに対する要求事項をまとめたものであ る。FAA（米国連邦航空局）から認証を取得する際のデファクトスタンダードとなってい る。米国 RTCA（航空無線技術委員会）より DO-178（1982 年）、DO-178A（1985 年） に続いて 1992 年に発行された。 (8) FDA（Food and Drug Administration of the United States Department of Health and Human Service） 米国食品医薬品局。米国の政府機関で｢保健・福祉省｣に属する。食品・薬品を中心に化 粧品や玩具、タバコなど、消費者が接する機会の多い製品の認可や違反取り締まりを行 う。 (9) FISMA（Federal Information Security Management Act） 米国の連邦情報セキュリティマネジメント法。連邦政府機関が情報セキュリティを強化 することを義務付けており、NIST に対して規格やガイドラインの開発を義務付けてい る。 (10) HIS（Hersteller Initiative Software） ドイツの自動車メーカー5 社(Audi、BMW、Porsche、DimlerChrysler、Volkswagen) によって、2001 年に設立された業界団体である。 (11) IETF（The Internet Engineering Task Force） インターネット技術タスクフォース。インターネットに関する技術についての標準化を 議論する任意の団体である。 コンピュータの相互接続網における共通の技術仕様を策定 する少人数のグループが発端となっている。参加は個人ベースである。参加者は会合やメ ーリングリストでの議論に自由に参加することができる。 88 (12) ISA（The International Society of Automation） 国際計測制御学会。オートメーション分野の世界標準となることを目指して 1945 年に 設立された。本部は米国ノースキャロライナ州である。世界 120 カ国で 5 万人以上の会員 を擁する計測・計装・制御の国際学会である。展示会や国際会議の主催、S88 や S95 な どの国際標準化活動、雑誌 InTech を始めとする技術書の出版や CCST 認定トレーニング コースの開催などの事業を行っている。 (13) ISCI（ISA Security Compliance Institute） ISA セキュリティ適合性協会。制御機器のセキュリティに関する国際認証である EDSA （Embedded Device Security Assurance）認証を策定している。 (14) JSF（Joint Strike Fighter Program） 統合打撃戦闘機計画。米国、英国、カナダ、及びそれらの同盟国の広範囲に及ぶ既存の 戦闘機・戦闘攻撃機・対地攻撃機を置き換える開発・取得計画である。 (15) MC/DC（Modified Condition/Decision Coverage） 航空機に搭載されるソフトウエアをテストする際に使用するテスト網羅度である。米国 の航空機産業の業界団体である RTCA（Radio Technical Commission for Aeronautics） が策定した DO-178B の中で開発された。 (16) NIST（National Institute of Standards and Technology） アメリカ国立標準技術研究所。米国の国立の計量標準研究所である。米国商務省管轄の 技術部門である。 4.3. ツールの活用事例の調査 セキュリティ及びセーフティの検証ツール自体の調査に加えて、それらの検証ツールを 実際の製品である情報システムに活用して不具合や障害の発見、さらに不具合を改修する ことによって製品の品質を向上させた事例についても調査した。情報システムの開発現場 の技術者や検証部門の品質担当者が実際に検証ツールを使用した事例を調査することによ って、検証ツールの以下の特徴を調べた。調査した内容はツールのデータベースに掲載し た。 ・ ツールの操作性（見やすさ、マウスやキーボードによる動作のしやすさ、等） 89 ・ ・ ・ ・ ツールの利便性（検証環境の構築のしやすさ、検証データ及び結果の可読性、等） 使用にあたっての留意点や工夫（検出できない不具合、検証結果の見方、等） ユーザから見たツールのメリット／デメリット（使用者の判断、所感、等） カタログには記載されない性能（検証データの処理時間、操作の反応時間、等） また、開発現場の技術者がツールを活用した事例には、自社の製品の機能や性能を効率 よく的確に検証できるよう、ツールを使いこなすためのノウハウや留意点が数多く盛り込 まれている。そこで、本調査では、スマートメーター・システムのセキュリティ検証を支 援するツール環境のデータベース化を効果的・効率的に実施するための創意工夫として、 それらのノウハウや留意点を参考にして、当該ツールの利用が初めての技術者でもうまく 使いこなせるようにツールの利用シナリオを作成した。シナリオは、ツールをどの段階で どのような手順で使うか、得られる結果はどのようなものか、をまとめたものであり、検 証ツールのデータベースに盛り込むことで、機能や仕様だけのカタログ情報をまとめただ けの従来のデータベースにはない利便性の向上が期待できる。 なお、検証ツールの利用シナリオの作成にあたっては、ツールの活用事例から得られる 情報を参考にしながら、検証対象であるスマートメーター・システムの開発段階から運用 段階までの作業フェーズをまとめたプロセスを定義した上で、さらに、セキュリティ基準 及び評価手順を考慮しながら検討を行った。詳細は、本書「4.5. 検証ツールの利用シナ リオの作成」で報告する。 調査した活用事例の一覧を表 7 に示す。 検証ツールの活用事例は表 7 に示すように、前述した 3 つの分類に従って調査を行っ た。 表 7 調査した活用事例の一覧 NO ツール分類 1 2 3 4 5 6 7 8 9 10 11 12 解析型 ツール 疑似攻撃型 ツール 証拠保全型 ツール 事例 株式会社 ACCESS の事例 住友電工ネットワークス株式会社の事 例 日本光電株式会社の事例 日本電気株式会社の事例 富士ゼロックス株式会社の事例 三菱電機株式会社の事例 仕様書の検証事例 ソフトバンクモバイル株式会社の事例 脆弱性が発見された事例 株式会社 Kaspersky の事例 株式会社サニクリーン九州の事例 株式会社ガスターの事例 90 ツール名称 Coverity QA ※ Coverity QA Coverity QA Coverity QA Klocwork Insight QAC ClearDoc FFR Raven FFR Raven beSTORM NetEvidence NetEvidence 13 14 15 タカラスタンダード株式会社の事例 神甲会 隈病院の事例 JA あいち中央の事例 NetRAPTOR NetRAPTOR NetRAPTOR ※ Coverity QA：Coverity Quality Advisor スマートメーター検証は、ベンダが開発・構築したスマートメーター・システムに対す るセキュリティ検証を行うことを目的としているため、表 7 に挙げられたツールでは、 「疑似攻撃型ツール」が活用可能である。ただし、表 7 に挙げたツールは 1 例であり、同 様のファジングツールやペネトレーションツールは世の中に数多く存在し、それらの機 能・品質は様々である。例えば、EDSA 認証の CRT テスト（通信の堅牢性テスト）で は、表 7 の Raven の他に、Defensics(Codenomicon 社)及び Achilles Satellite(Wurldtech 社)を認定ツールとしている。 スマートメーター検証は、上述したファジングツールやペネトレーションツールに加え て、基本的なポートスキャンや脆弱性スキャンを含めた総合的な検証が必要である。検証 ツールが備えるべき機能要件・非機能要件（品質等）を定め、その要件に必要十分なツー ルを整備し、均質なスマートメーター検証を行える環境を整える必要がある。 以下、事例を紹介する。 4.3.1 解析型ツールの活用事例 解析型ツールは主として、ソフトウエアを実行することなく解析を行うことで、開発段 階の早期に不具合やプログラム上の欠陥を自動検出するツールである。 ここでは、解析型ツールを用いて品質向上、工期短縮を行った事例を紹介する。 (1) 株式会社 ACCESS の事例（Coverity QA） 会社概要 携帯端末及び情報家電向け組込型インターネットソフトウエア等の技術開発。ア メリカ、アジア、ヨーロッパで全 29 の子会社を運営。 課題 開発工程の効率化を図り、顧客へより高品質な製品を提供するため大規模で、納 期までの期間が短い開発プロジェクトを数多く抱えている同社では、組織及び製品 品質の向上、開発作業に影響することなく、いくつものプロジェクトに配備できる ソリューションが必要であった。 2012 年形成された社内品質改善プロジェクトチームは、開発作業の軽減・コスト 削減・製品の品質向上といった開発作業工程の効率化を狙った解析ツールを採用し た。 91 導入効果 以下の効果により同社は投資以上のコスト削減が可能となった。 ・不具合の誤検知率が 10％以下に軽減（図 48 参照）。 ・不具合検出が開発の初期段階で可能。 ・テストケースを用いた検出より効率的。 ・レポーティング機能により解析結果の精査時間が軽減。 ・不具合調査の作業時間が約 5 分の 1 に短縮。 ・テストフェ−ズで使用しても効果は高い。 図 48 Coverity Quality Advisor での検出結果 展望 ソフトウエアの品質向上のため、別プロジェクトにおいても本ツールの利用を 検討。 (2) 住友電工ネットワークス株式会社の事例（Coverity QA） 会社概要 インターネットアクセス系のバックボーンと家庭内機器を中心としたネットワ ーク関連機器の開発・販売。 課題 ソースコードを自社開発するだけでなく外部からミドルウェアなどを購入する 機会が増えた結果、ソースコード全体のボリュームが増加し、品質の管理強化が一 層求められた。 92 開発の効率化とソフトウエア開発者の負担軽減を目的に、同社の品質保証本 部では、ネットワーク機器のソフトウエアの開発工程に静的解析ツールを導入 した。 導入効果 同社の効果は以下の通りである。 ・テストで検出が難しい潜在不具合の検出が可能 異常系処理部やタイミング依存処理部に潜在する不具合はコードレビューやテ ストでは検出が難しかったが、ツールによりメモリ周りの潜在不具合を効率的に検 出・修正できるようになった。 ・高速で精度の良い解析 誤指摘が少ないことによって、指摘箇所の人手による確認の手間を、必要最小限 に留めることができた。 ・開発者へのトレーニング・教育効果 不具合の指摘箇所とその内容がわかりやすく表示されるため、開発者がより良い コードを書くための指針となり、開発者の技術力が向上した。 展望 より一層の品質向上と開発工程の効率化を図るべく、新規プロジェクトにも導入 予定。今後は、導入成果を正確に査定し、より効果的にツールを使用していくとと もに、開発者からのフィードバックを取り入れながら、教育的観点からも積極的に ツールを使用予定。 (3) 日本光電株式会社の事例（Coverity QA） 会社概要 AED（自動体外式除細動器：Automated External Defibrillator）を製造してい る国内唯一のメーカー。医療従事者向けの除細動器、検査用の脳波計、手術室等で 使用される生体情報モニターも製造。 課題 医療機器に組み込まれるソフトウエアは、機器の高度化・複雑化とともに、ソー スコードが肥大化している。プログラムエラーによる重大なトラブルは許されず、 開発におけるヒューマンエラーを減らし、気づきにくい不具合のチェックを効率的 に発見するため、静的解析ツールを導入し、作成したコードを登録するだけで自動 的に解析できる仕組みを構築した。 93 導入効果 ツール導入前は、開発の各フェーズの最後にまとめて解析を実施していたため、 開発フェーズの最後にミスが発見されることもあったが、導入後は、開発を進めな がら並行して自動解析を行い、問題が発見され次第随時修正しているので、常にミ スのない状態を維持することが可能となった。 展望 医療機器の高度化・複雑化を背景としたソフトウエア規模の拡大に伴い、バック グラウンドでコードを解析し続けるツールの貢献は大きくなると想定。 (4) 日本電気株式会社の事例（Coverity QA） 会社概要 国内大手通信・情報機器の総合メーカー。IT サービス、IT プロダクツ、ネット ワークシステム、社会インフラ、パーソナルソリューション、エレクトロンデバイ ス等の多岐にわたる分野をカバー。 課題 ネットワーク製品を開発・製造するネットワークプラットフォーム開発本部では、 製品需要の増加で開発量が増えたことで以下のような課題があった。 ・開発工程中での検証 第三者による静的検査サービスではなく、自社内で開発工程中に適時ソースコー ドを解析することにより、より製品の品質を上げたい。 ・早期の不具合の発見 バッファオーバーフローや、カウンターオーバーフローなどの重大かつ深刻な不 具合を開発工程の早期段階でつぶし、生産性を上げたい。 2008 年 11 月、マルチサービストランスポートスイッチ製品の既存開発とフロー コントローラ製品の新規開発向けに、ツールを導入、2009 年 5 月から全ての新規 開発製品に対してツールの採用を決定した。 導入効果 同社では、2009 年度上期に評価対象 24 プロジェクトにおいて、1,700 件の不具 合を修正したが、ツールなしで修正した場合の工数の差と不具合数によるコストと を比較し、約 8,500 万円の投資対効果（ROI）があった。 同社の効果は以下の通りである。 94 ・修正の必要な不具合を確実に検出 開発の早期段階で不具合を検出、修正できる点が開発の生産性向上につながった。 解析の精度が高く、特に購入部分のソースコードの品質を格段に上げた。 ・不具合レポーティング機能をフル活用し開発者の生産性の向上を促進 不具合修正の進捗をシステム内で管理し、1 週間に 2 度、製造完了の度に静的解 析を実行した。ツールで不具合の軌跡をトレースできるため作業が効率化した。 ・マニュアルチェック結果の透明性、信頼性の向上 従来の開発工程に採用することで、マニュアルチェックの結果に透明性、信頼性 を与えた。 展望 同社内の別部門においても製品の採用を検討する。また、製品を使用者のフィー ドバックも考慮し、より効果的な使用方法を社内で模索していく方針である。 (5) 富士ゼロックス株式会社の事例（Klocwork Insight） 会社概要 オフィス用複写機、プリンタ事業を展開。コントローラ開発本部は、複合機の多 彩な機能を実現するソフトウエアの開発を行っている。 課題 ソフトウエアのプログラムは大規模かつ複雑になり、追加や改良が繰り返される うちに全体を理解しているエンジニアも少なくなり、また、新しい技術者は大きな プログラムのメンテナンスの仕事が多くなっている。 機能追加や改良などの業務が多い中で、技術者のモチベーションを高め、スキル アップを図り、いかに開発効率や品質の向上を実現していくか取り組んでいる同本 部には以下のような課題があった。 ・コードの段階ではプログラムの動作を目で見てチェックすることはできない。 ・コードが正しいのか間違っているのかはレビューで判断するしかないが、コー ドを書き終えた後のレビューでは手戻りが発生する。 ・ 品質を追求するならレビューは数回繰り返す必要もある。チームによるレビュ ーの均質化は難しい。 そこで、上流工程でバグを自動検出できるツールを導入した。 導入効果 95 人手に頼らず自動的に不具合を検出できることで、安定した品質の維持と開発作 業の効率化を実現できた。 また、技術者のプログラム作成時、第三者がきめ細かくチェックすることは時間 的にも困難であったが、不具合の自動検出結果のデータに基づき、開発者自身はも とより第三者も客観的に判断ができるようになった。開発者自身が、不具合の発生 理由に関する気づきを得ることで自身の改善（教育効果）につながった。 展望 ツールの活用は同本部全体に広がっている。同本部では、ソフトウエアメトリッ クス（品質評価基準）やアーキテクチャの視覚化などの指標を使いながら、安定し た品質の維持と合わせてソフトウエア全体の最適化を図るリファクタリングを進 めている。ソフトウエアの見える化により若い技術者の育成にも本ツールを役立て ている。 (6) 三菱電機株式会社の事例（QA C / QA C++） 会社概要 日本の総合電機メーカー。家電から重電、人工衛星まであらゆる製品を販売。設 計システム技術センターは、 全社及び関係会社のハードウエア／ソフトウエアの 設計、生産性向上技術に関する業務を担う。ソフトウエアエンジニアリング部はエ ンジニアリング系／組込み系ソフトウエア、設計プロセス／システムの開発・実用 化、及び製品設計を行う。 課題 製品ソフトの開発は、以前のソフトウエアを流用した開発の割合が高く、流用元 ソフトウエアの品質レベルを確認・確保する必要がある。 また、製品の差別化として、高機能を要求する新規開発ソフトの規模は増加して いるが、低価格化の要求により開発コストの圧縮が求められている。迅速な市場投 入のため開発期間の短縮も要求されている。 設計が良くても最終的なソフトウエア品質はコードで決まるため、実装品質の向 上による開発コスト及び期間の圧縮を図り、不具合につながる危険コードの早期検 出及び修正、潜在ロス及び手戻り工数の削減をする必要があった。 この課題解決のために静的分析ツール、構造解析ツールの導入を検討した。 導入効果 検出できる問題の異なるツールと合わせて使用（補間）し，問題検出・品質のフ ロントローディングを強化した（図 49）。 手戻り抑制により生産コストを低減し、保守性、可読性の高いコードの生産性向 上に寄与した。 96 97 ソース コード メトリックス QA C QA C++ 潜む問題 危険なコード，分りにくいコード メトリックス Imagix4D リアルタイム性に関わる問題 図 49 静的解析ツールの活用 なお、実施した内容は以下の通りである。 ・解析及び結果分析支援によるソフトウエア品質の把握、誤り検出作業の効率化 開発部門は、指摘内容の確認と問題性有無の判断、対応が必要となる箇所の修正 に専念することで効率的な品質向上を促進する。同センターでは品質、生産性向上 施策へのフィードバックを行うための解析レポートを作成し開発部門に提示し、品 質改善のための処方箋では問題点の指摘だけでなく、どこの・何を・どうやって改 善すべきかを示す（図 50 及び図 51） 。 98 改善すべき 機能ユニット 複雑な関数が多い 問題の発生する 可能性の高い関数 問題点の指摘だけでなく， 効率的な品質改善には， どこの，何を，どうやって 改善すべきかを示す 図 50 処方箋（例） 図 51 解析レポート（例） 99 ・マルチタスクプログラムの解析 マルチタスクプログラムにおいて複数タスクに書き込まれる変数や、書き込み前 に読み込まれる変数における危険な項目を検出し問題点として抽出した。また、タ スク間で共有変数はないかなども解析した（図 52）。 図 52 マルチタスクプログラムでの問題点の抽出（例） ・誤り検出作業の効率化のための解析環境の整備と社内への提供 誤り検出作業において GUI による操作性を確保し、解析結果の集計及び分析機 能を強化する Excel の VBA を使用したフロントエンドを開発し社内に展開した。 また、ビューアの機能について整備した（図 53） 。 設定シート 警告一覧シート 警告別合計シート ファイル別シート 複雑度シート 100 図 53 Excel の機能を利用した解析結果の集計及び分析（例） ・誤り検出率の向上のための警告の危険度による分類とピックアップ 危険度により、全警告を 5 段階に分類し検出されると確実にシステムに重大な影 響を及ぼす可能性のある警告をピックアップし、効率良く警告をチェックできる目 安を作成し展開した。 ・誤り検出作業の効率化、誤り混入の未然防止のための MISRA-C 2へ対応 ツールに対応したルール違反チェックを行える、MISRA-C チェッカパッケージ が販売されていたが、電子化された手頃なルールの一覧（表）がないため、MISRAC のルール一覧表を作成した。 ・誤り混入の未然防止のためのコーディング規約との連携 従来のプログラムの保守性を向上させ、問題となる 作りこみを抑制するための命 名規約、スタイル規約、コメント規約、実装規約を持つコーディング規約を策定し、 静的解析ツールで違反をチェックした（図 54 及び図 55） 。 図 54 実装規約の一覧と例 2 MISRA C は MISRA (Motor Industry Software Reliability Association)が開発した安全性と可搬性(移 植性)と信頼性を確保することを目的とした C 言語のためのソフトウエア設計標準規格。 101 図 55 規約記述（例） 展望 これまで実施した内容をブラッシュアップし、ツールのさらなる活用とともに新 しい技術を導入・活用し、グループを含む全社へ静的解析技術を展開・定着させる。 (7) 仕様書の検証事例（ClearDoc） ClearDoc は日本語の文章の曖昧さを検出するツールである。 (a) 活用事例 1（パッケージベンダ企業の事例） 課題 ・運用の順番や内容を間違えてしまう箇所がないか不安がある。 ・過去に運用誤りがあり、事前に予防したい。 ・ユーザへの対応マニュアルの日本語を明確にして運用誤りを防止したい。 解決策 ・ツールを利用して、マニュアル中の曖昧な記述や複雑な文を抽出・改善する。 ・スタッフ間での認識ズレを防止し、運営ルールの浸透を図る。 102 (b) 活用事例 2（オフショア開発企業の事例） 課題 ・仕様に書かれている文章の不具合に困っている。 ・オフショア先送付前に、仕様書の日本語文をわかりやすくしたい。 ・海外のエンジニアにとって、係り受けが複雑な文はそもそも理解しがたい。 解決策 ・ツールを利用して、仕様書の曖昧な記述をチェックして修正。 ・認識ズレが生じにくい、わかりやすく端的なドキュメントを作成。 (c) 活用事例 3（グローバル展開企業の事例） 課題 ・外国語に翻訳するのに、翻訳者が日本文を理解させるところで時間がかかる。 ・正しい翻訳文にするのが難しい文が多い。 ・多言語翻訳前にマニュアルの日本語を端的な文にしたい。 解決策 ・ツールを利用して、仕様書の曖昧な記述をチェックして修正。 ・翻訳時に認識のズレが生まれにくい端的なドキュメントを作成。 4.3.2 疑似攻撃型ツールの活用事例 通信事業やセキュリティソフトウエアの開発を行っている企業では、疑似攻撃型 ツール等を用いてセキュリティの向上を図っている。疑似攻撃型ツールの活用事例 と、実際の製品で脆弱性が発見された事例を紹介する。 (1) ソフトバンクモバイル株式会社の事例（FFR Raven） 会社概要 大手移動体通信事業者。同社の技術管理本部ネットワークセキュリティ推進部監 査課はソフトバンク通信 3 社が展開する商用サービスのネットワーク、機器に対す るビジネスリスクを事前に解消する部門。 課題 これまでは、独自に開発したネットワーク機器に内在する脆弱性を自ら発見する ことが困難であった。脆弱性の診断には、数時間から数日間の時間を要するため、 効率化と精度を維持するバランスが重要との認識があり、同部門では、ネットワー ク利用の多様化による機器の検証コストの負担低減と検査精度の向上の両立が求 103 められていた。このため、検査時間を短時間で終わらせ、脆弱性の発見を確実に行 うツールの導入が検討されていた。 導入効果 検証に必要な時間が大幅に削減され、新しい脆弱性の発見が行えた。 展望 現場で脆弱性検査を実施することにより、現場の脆弱性への理解、品質向上、 意識向上へもつながると考えられている。また、監査課によるチェック時の差し 戻しによって生じる開発部門の手戻り作業などの削減も狙いとしている。 (2) 脆弱性が発見された事例 疑似攻撃型ツールによって発見された脆弱性の事例を紹介する。 脆弱性の報告により、各社の製品のファームウェアが更新されるなどの対応が行 われ、エンドユーザに対応方法などの情報が公開されている。 (a) ヤマハルーターシリーズにおける DoS 脆弱性 ヤマハルーターシリーズの IP パケット処理の脆弱性（細工された特殊な IP パケ ットの送信により、対象ルーターが再起動される）が発見された。 ・報告日： 2009 年 11 月 13 日 ・公開日： 2011 年 04 月 11 日 ・深刻度： 中度（3 段階中） 概要 IP パケットの処理に問題があるため、サービス運用妨害 （DoS） 状態となるセ キュリティ上の脆弱性が存在する。 この弱点が悪用されると、当該製品を停止または再起動される可能性がある。 影響 遠隔の第三者により、サービス運用妨害（DoS）攻撃を受ける可能性がある。 対応と対策 不特定の相手との通信が必要な場合には回避策がなかったため、対策済みファー ムウェアへの更新が必要となった。 (b) Cisco Linksys WRT54GC バッファオーバーフローの脆弱性 Cisco Linksys WRT54GC ブロードバンドルーターの組込み Web サーバ部分に、 バッファオーバーフローの脆弱性が発見された（図 56） 。 ・報告日： 2009 年 08 月 14 日 ・公開日： 2011 年 01 月 28 日 104 ・深刻度： 中度（3 段階中） 概要 細工された HTTP リクエストの処理に問題があり、バッファオーバーフローとい うセキュリティ上の脆弱性が存在する。 この弱点が悪用されると、当該製品を応答不能状態にされる可能性がある。 図 56 脆弱性発見のイメージ図 影響 ブロードバンドルーターが応答不能状態にされる可能性がある。 対応と対策 対策済みファームウェアに更新する。 (c) Windows 7/Vista/2008R2 IPv6 Memory Corruption Vulnerability Windows に標準で搭載されている IPv6 スタックに DoS の脆弱性が発見された。 ・報告日： 2010 年 03 月 24 日 ・公開日： 2011 年 08 月 11 日 ・深刻度： 中度（3 段階中） 概要 細工した IPv6 パケットを送信することでリモートから安定的に対象をクラッシ ュ（BSOD）させることが可能。この脆弱性は、対象が Windows Firewall を有効 にしていた場合でも攻撃が成立する可能性がある。 影響 不正な IPv6 パケットを受信することで、対象がクラッシュする可能性がある。 対応と対策 対策済みの修正版に更新する。 105 (3) 株式会社 Kaspersky の事例（beSTORM） 会社概要 セキュリティソフトウエアの開発・販売、コンピュータウイルスの研究・分析を 行っている。コーポレート・プロダクト開発部門において脆弱性テストを実施。 課題 開発者が予想していなかった脆弱性を見つける手段が求められていた。 特に、マルチプロトコル対応（同社では SSL、SOAP、binary を使用）、製品の使 い勝手、テクニカルサポートが受けられるツールの選定を行う必要があった。 導入効果 テスト対象プロトコルなどの基本的事項の設定により、全てのジョブが生成され るため、テストを容易に行うことが可能となり、開発者の予想していなかった脆弱 性を見つけることができた。 4.3.3 証拠保全型ツールの活用事例 証拠保全型ツールとは、全ネットワーク情報を取得し、ログを記録するためのツ ールである。数多くの顧客情報を取り扱う企業では、このようなツールを導入し危 機 管 理 を 図 っ て い る 。 こ こ で は 、 証 拠 保 全 型 ツ ー ル で あ る NetEvidence と NetRAPTOR の活用事例を紹介する。 (1) 株式会社サニクリーン九州の事例（NetEvidence） 会社概要 九州地区を中心に下関から沖縄までをテリトリーとし、清潔・快適環境作り事業 を展開しており、27 万件の企業及び一般家庭の顧客を持つ。 課題 保護の対象となる主なものは、顧客情報を含む営業管理資料であり、ルール （ポリシー）上、Web メールの使用は禁止しているが、人的教育だけでは防ぎき れないため、監査証跡を残すことのできるツールが必要との判断に至った（図 57）。 106 図 57 NetEvidence Web 検索画面 導入効果 導入後は、定期的な監査・検査に必要な検索・分析を実施することで、ネットワ ーク通信状況を正確に把握でき、漏えい防止対策効果は高まった。監査ができる施 策を社内外に知らしめ、社員に対しセキュリティ対策の必要性についての周知に努 め、社内コンセンサスと物理的なシステム対応策とがうまくマッチした。 (2) 株式会社ガスターの事例（NetEvidence） 会社概要 関東地区を主な事業拠点としてガス機器を専門に給湯事業、床暖房事業、住設 事業、空調事業などを手がける。主要株主であり取引先でもある、東京ガス／ INAX／リンナイなどに向けたサービスを実施する上で、所持する顧客情報及び従 業員情報は慎重に管理運営されている。 課題 東京ガスのグループ企業として整備しておくべき課題や、一般的なコンプライア ンスの問題としての個人情報保護を目的とした対応等がセキュリティ対策のトリ ガーとなっている。情報セキュリティマネジメント体制の下、目指すべき監査体制 を固めるには、セキュリティツールの導入も必要と考え、様々な機能チェックを実 施し、満足なレベルが確保できていることを確認した上で導入に至った（図 58） 。 107 図 58 システム構成例 導入効果 ツールはユーザ部門が使うことから、導入後の運用面での配慮を最も重要なポイ ントとし、ユーザインターフェースが一番のポイントであるツールを評価した（図 59） 。ツールは家電製品レベルでの完成度を持ち、導入即本番稼働が可能であった。 図 59 電子メール検索結果画面 展望 今後さらに運用管理上での使いやすさの向上を期待している。 108 (3) タカラスタンダード株式会社の事例（NetRAPTOR） 会社概要 高品位ホーローという素材を強みに住宅設備の専業メーカーとして事業展開を 行っている。 課題 業務を邪魔することなく抑止力を効かせることが可能な監視系の仕組みを検討 した結果、ネットワーク上に設置することで必要な通信キャプチャを抽出できるツ ールを候補に挙げた。 同時にクライアント PC の不正操作を監視する PC ログ監視ツールも導入し、ク ライアント PC の操作ログとネットワークを流れるパケットから通信パケットを取 得する、全方位的な監視環境を構築した。 導入効果 メールの検索速度はおよそ 70[GB]のデータがわずか 5 秒程度、条件に合致した 通信データのチェックはおよそ 10 分程度であり、 検索性能の高さを評価している。 通信データの取得を従業員に周知徹底できたことで、特別なインシデントが発生 したことは一度もない。導入前は 1 万件ほどの業務外と思われる Web アクセスが あったが、導入直後は 1000 件程度に激減した。 また、モバイル PC などへの対応については、通信事業者の閉域網を活用して外 部へのアクセスを一ヶ所に集約し、社内の端末と同等の監視体制を敷設した。利用 者への牽制作業とロギング作業による追跡環境の整備により、利便性とセキュリテ ィを両立した（図 60） 。 109 図 60 システム構成図 展望 これまでは守りの意味合いが強かったネットワークフォレンジックだが、蓄積さ れたメールや Web アクセスのログ情報をうまく活用し、メールのテンプレート化 や必要な情報に迅速に辿りつくための導線設計に利用するなど、業務の効率化に寄 与できるような仕組みも検討する。また、ストレージそのものが安価になってきて おり、テープの運用から別のストレージデバイスでの運用も検討したい。 (4) 神甲会 隈病院の事例（NetRAPTOR） 会社概要 2 床のアイソトープ病床を含む合計 58 床を保有する、甲状腺疾患を中心とした 専門病院である。 課題 医療情報課が新設され、電子カルテを中核とした、様々なシステムの企画や構築、 運用管理の検討を始め、院内の情報システム全体が見直されることとなった際、セ キュリティへの配慮が一層必要であると考えた。 「外からの侵入」に対してはハード面を整備し、 「中から漏れる」ことへの対応は、 インターネット接続はウイルス感染の危険性が低い Mac のみとし、USB 型データ 端末の利用を制限した。 ウイルス感染の恐れがあるサイトを閲覧した時の対応として、ウェブサイト閲覧 の履歴が取れその内容全てが把握できる機能を持ち、問題があればいつでも遡って 確認でき、さらに設定後は即稼動し、導入しやすいという大きなメリットも持つツ ールを選定した。 導入効果 導入により、同院のスタッフは「安心感」を実感している。業務上必要なサイト は堂々と見ればよく、医療従事者にとっては確かな仕事をしている証明にもなる。 展望 今後は、パケット量の跳ね上がりといったウイルス感染が疑われる様な異常を通 知する機能が追加されると、よりリスク管理に役立つと考えている。 (5) JA あいち中央の事例（NetRAPTOR） 会社概要 JA あいち中央は、愛知県の碧海五市（刈谷市・安城市・高浜市・碧南市・知立市） を管内とする農業協同組合であり、約 4 万人の会員を保有する。 110 課題 情報管理の課題や情報漏えいのリスクについて、 「何らかの対策をしなければ」と いった危機感を漠然と感じていた。 「メール監視」 「添付ファイルを含む全文保存」 「保存情報の高速検索」等の特徴 は所望のシステムに合致していた。 PC1 台あたりに換算した費用対効果が「情報漏えいリスクへの保険」として想定 できる範囲内だったため、早期導入が実現した。 導入効果 リアルタイムで外部とのやり取りがチェックできるため、フリーメールの使用者 にその都度確認を始めた結果、導入直後の 4 月に 23 件あったフリーメール使用が 11 月ではわずか 1 件のみになり、抑止効果があった。導入に際し、他のシステムに 全く影響なく、PC のスペックがまちまちでも、職員の PC 使用に負担をかけず、ネ ットワークの設定変更が不要であるメリットも大きい。 展望 今後は WEB 利用についてのマニュアルや規定整備と合わせ、セキュリティに対 する教育・啓蒙をさらに推進する予定である。 111 4.4. ツール提供企業へのインタビューによる調査 社会の情報システムの大規模化、複雑化に伴って、情報システムを検証するツールも並行 して大規模化、複雑化（ツールの場合は多機能化）の方向に進化している。特に多機能化し た検証ツールの中には、別の機能や拡張機能を本体にオプションとして追加したり、同一の ツール名称でシリーズ化したりしているため、複数の製品を連続的に使用して初めて一連 の検証作業を行うことができるツールも存在する。 一方で、情報システムの開発企業で検証ツールを購入して使用する企業の側では、ツール の使用者（＝現場の技術者）と、購入者（＝購入部門や資材部門など）や導入推進者（＝品 質保証部門など）とが異なる場合が多く、別途費用を払って追加した拡張機能や、シリーズ 内の全ての機能を利用しきれていないことが散見されている。 従って、本調査では検証ツールの利用企業と共に、ツール提供企業に対してもインタビュ ーを行うことで、検証ツールの全体像や最大限発揮できる機能や性能についても調査した。 ツール提供企業は当該ツールを開発あるいは販売している企業であり、特徴や機能の詳細 を熟知しているだけでなく、利用者から寄せられた改善要望などについても把握している。 インタビューでは営業用のカタログや活用事例では得られない情報を収集して調査に活用 することができた。 拡張機能付きやシリーズ化されたツール ツール提供企業へのインタビュー ・ツールの全体像 ・特徴や機能の詳細 ・何が標準で何がオプションか？ ・一連の検証には何が必要か？ ・最大限発揮できる機能 ・ユーザからの改善要望 などの情報を調査 図 61 ツールと提供企業インタビューの概要 インタビューを実施したツール提供企業を表 8 に示す。 表 8 インタビューを実施したツール提供企業 NO 1 2 3 ツール提供企業 インタビュー実施日 平成 26 年 12 月 12 日 平成 26 年 12 月 15 日 平成 27 年 1 月 16 日 日本シノプシス合同会社 株式会社東陽テクニカ 株式会社シーイーシー 112 4 株式会社 FFRI 平成 27 年 1 月 28 日 また、インタビューを実施した際にツール提供企業には図 62 に示す調査シートへの記入 を依頼し、後日、回答を入手した。 図 62 ツール提供企業への調査シート 4.5. 検証ツールの利用シナリオの作成 検証ツールの利用シナリオの作成にあたっては、本書「4.3. ツールの活用事例の調査」 から得られた情報を参考にしながら、検証対象であるスマートメーター・システムの開発段 階から運用段階までの作業フェーズをまとめたプロセスを定義した上で、さらに、セキュリ ティ基準及び評価手順を考慮しながら検討を行った。 113 4.5.1 スマートメーター・システムの開発・運用プロセス ここでは、スマートメーター・システムの開発ベンダと利用企業のそれぞれの立場が、セ キュリティ基準及び評価手順に則ってスマートメーター・システムの開発あるいは選定を 行う場合に、システムの検証という視点から参照すべき開発・運用プロセスを定義する。 図 63 にスマートメーター・システムの開発・運用プロセスを示す。プロセスは設計&実 装フェーズとテストフェーズ、運用フェーズで構成される。システムの開発あるいは選定を 行う際のシステム検証という視点からプロセスを定義した。 図 63 スマートメーター・システムの開発・運用プロセス 114 本プロセスはスマートメーター・システムの開発と選定、さらには選定後の実稼働の段階 についても全て含めた上で、検証という視点に重点を置いて定義したものであるため、一般 的に V 字プロセスと呼ばれているソフトウエア開発プロセスとは異なる体系となっている。 図 64 に本プロセスと V 字プロセスとの対応を示す。 図 64 本プロセスと V 字プロセスとの対応 115 スマートメーター・システムの開発・運用プロセスの「設計&実装」フェーズは V 字プロ セスの詳細設計とコーディング及び単体テストに対応する。開発ベンダ内でシステムが実 現すべき機能や処理の詳細な設計やソースコードのコーディングを行い、コーディングを 担当した技術者が自身のソフトウエアの単体テストを行うフェーズである。 「テスト」フェーズは V 字プロセスの結合テストとシステムテストに対応する。本フェ ーズも主として開発ベンダ内での作業フェーズである。単体テストが完了したソースコー ドと他のソフトウエアとを組み合わせての結合テストから、メーター本体や周辺機器を全 て含めたスマートメーター・システム全体のシステムテストまでをまとめたフェーズであ る。なお、利用企業の既存システムと結合して、実地テストを行う場合には、利用企業も本 フェーズの関係者となる。 スマートメーター・システムの開発・運用プロセスの「運用」フェーズは、V 字プロセス の受入テストに加えて、一般的なソフトウエア開発プロセスの範囲外である実稼働時のテ ストも含めた上で 1 つのフェーズとして定義した。受入テストと実稼働テストはスマート メーター・システムの開発ベンダと利用企業が互いに協力しながら検証を進める作業段階 であり、セキュリティ基準及び評価手順に則ったシステムの開発→選定→運用の一連の業 務における最終フェーズとなる。 なお、V 字プロセスの要求分析、基本設計、機能設計の作業については、スマートメータ ー・システムの開発・運用プロセスにおける前提条件の位置付けとし、それらの作業は開発 ベンダ社内で十分に検討されていることとする。 4.5.2 開発・運用プロセスと検証ツールの利用シナリオ 前節では、スマートメーター・システムのセキュリティ基準及び評価手順に則って、シス テムのセキュリティ及びセーフティの検証を円滑に行うための開発・運用プロセスを定義 した。 ここでは、上記で定義した開発・運用プロセスに沿って、スマートメーター・システムの 開発ベンダが基準に従って開発をする際や、利用企業が自らのセキュリティレベル（基準） に合わせた製品を選択する際、また機器が正常に動作していることを定期的かつ継続的に 検証するために、検証ツールをどの段階で、どのように利用すれば良いかを検討して利用シ ナリオを作成した。 スマートメーター・システムの開発・運用プロセスに沿った検証ツールの利用シナリオの 凡例を図 65 に、利用シナリオを図 66 に示す。 116 図 65 利用シナリオの凡例 図では 3 つの角丸ボックスを示している。図の左側ボックスは、スマートメーター・シス テムの開発・運用プロセスにおける当該フェーズで利用する検証ツールの分類を示してお り、真ん中のボックスに記載された「利用者」はそのツールを主として利用する立場（開発 ベンダ or 利用企業）であり、 「対象」は検証の対象物、 「TASK」は当該フェーズで実施すべ き検証作業を示している。右側のボックスは、全ての TASK を実施した場合に得られる成 果物を示している。 117 118 スマートメーター・システムの開発・運用プロセスに沿った 検証ツールの利用シナリオ 119 図 66 開発・運用プロセスに沿った検証ツールの利用シナリオ 設計&実装フェーズ スマートメーター・システムの開発・運用プロセスの設計&実装フェーズでは、 解析型ツールを用いて検証を行う。ツールの利用者は主として、仕様書や設計書、 ソースコードを所有している開発ベンダである。この段階での検証対象はドキュメ ントとソフトウエアである。仕様書及び設計書検証の TASK では、ソフトウエアの 開発ドキュメントである仕様書や設計書に対して矛盾や曖昧さの有無の検証を行 う。コーディング検証の TASK では、ソースコードに対して静的あるいは動的な検 証を行う。ソースコードが各種の規格や標準、ガイドのルールに違反していないか を検証するのが一般的である。ソースコード解析ツールの中には、ソフトウエアの 処理内容や変数の値の変化を解析できるツールもあるため、単体テストの TASK で は、それらを用いてバッファオーバーフローや Null 値の参照等の事象の有無を検 証する。全ての TASK は、不具合がゼロとなるまで、あるいは、所定の基準を満た すまで実行すべきである。基準を満たして次のフェーズに移行する際には、本フェ ーズの成果物として検証済ソースコードを得ることができる。さらに、情報システ ムの開発ベンダにとって重要な資産である、検証済の仕様書や設計書等の開発資産 を得ることができる。 テストフェーズ テストフェーズでは、疑似攻撃型ツールを用いて検証を行う。ツールの利用者は スマートメーター・システムの開発ベンダが基準に従って開発をする際には開発ベ ンダであり、利用企業が自らのセキュリティレベル（基準）に合わせた製品を選択 する際には利用企業自身となる。また、開発ベンダから利用企業へメーター製品を 納入する際の実地での受入テストで用いる場合は、両者で協力してテストを実施す ることも考えられる。検証対象はその目的に応じて多岐にわたる。ソフトウエアの 組合せテストの TASK を行う場合には、検証対象は、全てのソフトウエアを組合せ た後（リンク後）のソフトウエアシステム全体となる。ハードウエアとソフトウエ アを組合せた、いわゆる対向テストを行う場合にはメーター本体を対象として検証 を行う。検証対象は徐々に拡大していき、最終的には周辺機器も含めたシステムテ ストの TASK を行う必要がある。 全ての TASK は並行して実施するのではなく、順次実施していき、当該 TASK で 不具合がゼロとなる、あるいは、所定の基準を満たした場合に初めて次の TASK へ と移行することが望ましい。全ての TASK を完了して、次のフェーズに移行する際 には、本フェーズの成果物として検証済の完成品を得ることができる。 運用フェーズ 運用フェーズでは、証拠保全型ツールであるフォレンジックツールを用いて有事 の際の証拠確保と、ツール導入による情報漏えいの抑止を図る。シナリオ図の本フ ェーズにおいても、上位であるテストフェーズの疑似攻撃型ツールからの入力があ 120 るのは、スマートメーター・システムの利用企業が、機器が正常に動作しているこ とを定期的かつ継続的に検証する場合を考慮したものである。情報システムに対す る攻撃や情報漏えいの手法や種類は日々変化するため、運用中であっても疑似攻撃 型ツールや、必要に応じて解析型ツールも適用して検証することが望ましい。 本フェーズでは主として証拠保全型ツールを適用する場合のシナリオを説明す る。検証対象はスマートメーター・システム全体である。TASK は順次実施する。 情報収集・保全の TASK ではネットワークフォレンジックツールを用いて、サイバ ー攻撃あるいは情報漏えいの有無を確認し、その痕跡があった場合には怪しいと考 えられる装置や PC を特定する。次に、コンピュータフォレンジックツールを用い て怪しいと考えられる装置や PC の検証を行う。収集したデータは企業内で厳重に 保管する。当該データ自体が利用企業にとって重大なセキュリティ情報となる場合 もあるからである。データ解析 TASK では、両ツールで収集したネットワークデー タと装置や PC のデータを解析する。最後に、全ての TASK で得られたデータを、 法的な証拠能力を持つ情報としてとりまとめ、必要に応じて関係機関等に提出する。 なお、サイバー攻撃や情報漏えい等の事案が発生して検証を行う場合には、スマ ートメーター・システムの内部の仕組みや、ネットワーク上を流れるデータ形式等 を熟知している開発ベンダが協力することが望ましい。 121 4.6. 検証ツールのデータベース（DB）化 本書「4.2. ツールの調査」 「4.3. ツールの活用事例の調査」 「4.4. ツール提供企業への インタビューによる調査」で得た情報を統合、整理した上で、開発ベンダや利用企業が汎用 的に検討できる項目を列挙し、比較検討ができるようなスマートメーター・システムのセキ ュリティ及びセーフティの検証ツールのデータベースを作成した。 4.6.1 検証ツールの一覧 検証ツールのデータベースに収録したツールの一覧を、ツールの分類毎に表 9 に示す。 なお、解析型ツールについては、セーフティの分野で先行している自動車分野や社会イン フラ分野、エンタープライズシステムの開発等で利用されている検証ツールについても、そ の概要を調査して「その他のツール」としてデータベースに収録した。また、疑似攻撃型ツ ールについても、従来から利用されている、既知の攻撃を模擬するツールや、直接的な攻撃 はしないが何らかの手法によって既知の脆弱性を発見することができる脆弱性検査ツール についても、概要を調査して「その他のツール」としてデータベースに収録した。 表 9 検証ツールの一覧（アルファベット順） NO 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 ツール名称 解析型 C++ test Cantana ClearDoc Coverity Quality Advisor Fortify Static Code Analyzer Klocwork Insight PGRelief C/C++ QAC VectorCast その他のツール 疑似攻撃型 証拠保全型 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ Achilles Test Platform Avalanche NEXT(含 Spirent※) beSTORM BreakingPoint Defensics FFR Raven Metasploit その他のツール ○ ○ ○ ○ ○ ○ ○ ○ NetRAPTOR 500 NetEvidence Ax Ver.3.1 1200 Solera DS ○ ○ ○ 122 NO 22 ツール名称 X-Ways Forensics 解析型 疑似攻撃型 証拠保全型 ○ ※Spiren t Stu di o Secu ri tyは Avalanche NEXT に統合される予定である。 4.6.2 データベースの見方 データベースでは、最初にスマートメーターの開発・運用プロセスに沿った検証ツールの 利用シナリオを記載した。以降はシート見出しの色をツールの分類に従って配色した。図 67 にデータベースの構成を示す。 図 67 データベースの構成 黄色のシート見出しは解析型ツールである。緑色のシート見出しは疑似攻撃型ツールで ある。水色のシート見出しは証拠保全型ツールである。 また、ツールの分類毎のデータベースの記載情報を以下に示す。 123 解析型ツール 疑似攻撃型ツール 証拠保全型ツール スマートメーター・システムの開発ベンダや利用企業が汎用的に検討できる項目を列挙 し、比較検討ができるように、ツールの基本事項や機能と特徴～諸元・性能やその他の情報 を、極力統一的に記載した。 124