経済産業省
文字サイズ変更

制御システムセキュリティ検討タスクフォース(第2回)‐議事要旨

日時:平成24年1月27日(金曜日)10時~12時
場所:経済産業省本館2階 東6共用会議室

出席者

新誠一座長、尼崎新一委員代理(長島氏)、大津秀伸委員、岡庭文彦委員(遠藤氏)、斧江章一委員(原氏)、北川卓志委員、木元正孝委員、久保智委員、小西信彰委員、小林偉昭委員、庄司慎吉委員、高宗直人委員、竹田浩伸委員、谷岡雄一委員、土屋徹委員、土井良彦委員、中野利彦委員、松井俊浩委員、村上正志委員、吉田雅美委員、米田尚登委員、渡部宗一委員、岩本佐利オブザーバ、越島一郎オブザーバ、佐川浩二オブザーバ、芹澤善積オブザーバ代理(木内氏)、高野一志オブザーバ代理(西間木氏)、高野正利オブザーバ、瀧田誠治オブザーバ、橋本芳宏オブザーバ、宮地利雄オブザーバ

議題

  1. サイバーセキュリティテストベッド構想
  2. 各WGの進捗報告
  3. その他

議事概要

冒頭、新座長より挨拶が述べられた。その後、事務局からサイバーセキュリティテストベッド構想について説明(資料3)。続いて越島オブザーバよりテストベッド検討WG中間報告について、小林委員より標準化、評価・認証制度WG中間報告について、宮地オブザーバよりインシデントハンドリングWG中間報告について、橋本オブザーバより人材育成WG中間報告について、村上委員より普及啓発WG中間報告について説明が行われた(資料4、5、6、7、8)。
これらを受けた自由討議の概要は以下のとおり。

  • テストベッド構想について伺いたい。ユーザとしては海外製品も利用しているので海外製品の認証を行うのか、あるいは一定の指針があるのか確認したい。
  • テストベッドではユーザ環境とほぼ同じ環境を検証する予定。認証に必要な技術をテストベッドに準備し対応する。運用については今後の検討事項となる。
  • 認証についてはグローバルに認証できるものを想定している。ISAセキュアにおけるチャータードラボでは2名の人間がユーザの現場に行きセキュリティ機能や開発経緯を確認し認証を行っており、こうした認証方法を検討している。テストベッド施設の利用と認証のやり方については今後検討予定。海外製品も評価認証できるようにする予定。
  • 二つ確認したい。(1)認証制度を欲している。ISMSのようなユーザ側の認証あるいはコンサルの計画はあるか。(2)インシデントハンドリングで脆弱性情報の共有は開示によるリスクがあるのではないか。
  • 研究を通じた検証となるので、ある意味のコンサルティングになると思う。
  • 設計ベースと現場ベースのコンサルティングがある。設計ベースについてはテストベッドで研究の一環として行うのが望ましい。現場については、インシデント対応のレベルをいかにして上げるか、また現場負担とならない仕組みやツールが必要になるので、仕組みやツールの研究をテストベッドで行うという考えもあるのではないか。
  • ISMSのような使う側の環境に対するコンサルはあるのか。
  • テストベッドは個別の機密確保が必要であり、テストベッド施設の保安機能を設ける必要があると考えている。
  • 先ほどの評価・認証WG報告でCSMSといったのはIEC62443-2にISMSに準拠した制御システムの標準ISMSがあるので、それをCSMSとして日本語にまとめる予定。普及啓発WGと協力し、CSMSを普及啓発していき、これをコンサルしてくれる人が出るといいと思っている。
  • 脆弱性情報の取り扱いについては、議論百出状態である。「脆弱性があるという連絡が来るか?」「連絡が来たら攻撃者に情報を渡らないようにするには?」「利用者がそもそも情報を公表しない」といった考えがあるが、例えば脆弱性情報の報告後、一年は公表せず、個別の連絡チャネル(ユーザ、ベンダー、ICS-CERT間)で対策を行い、一定期間後に脆弱性情報を公開するというような案がある。
  • インシデントハンドリングとは、どこをターゲットにサポートするのか?トラブルシューティングから製造業は入ると思う。その際、制御システムセキュリティかもしれないと気づくようにするにはどうすればいいか。
  • インシデントだと気づかないことが多い。不具合が起きたときの判定は、業界や事業者によって固有の事象があるので、業界や事業者内で判定基準を作ることになるのではないかと思っている。それにあわせインシデントハンドリング・ガイドラインを考えていく必要がある。
  • トラブルシューティングの段階からインシデントハンドリングするのは難しいが、テストベッドにオンサイトで繋がっていれば検証できる環境を構築すること可能かもしれない。オフサイトで持ち込んでいただき検証することは可能。どのタイミングで脆弱性情報を出すかは、対象となる制御製品のベンダー側で考える問題になると思う。やっかいなのはマルチベンダー環境であり、この際の責任者はユーザ自身になるのではないかと思う。
  • システム連携からデバイスまで、全体をどうセキュリティするかの検討が必要。
  • タスクフォースが設置された発端はスタックスネットの登場である。スタックスネットが入っているかどうかが分からなかったというのが当時の状況である。よって、インシデントが起こってからの対応を考えることは重要である。
  • パッチ情報の公開についても問題があり、課題は(1)重要インフラをはじめとした止められないシステムへのパッチ、(2)共通系の制御システムへのパッチなど、仕様環境下によりパッチ対応が困難なケースがある。
  • テストベッドでは高セキュア化研究開発のテーマとして、今動いている機器をどう守るかの技術開発や、多重化対応の有効性検証などがある。テストベッドではこうした環境化にも対応できる構成を持つ予定である。
  • 事象が分かっている前提ならCERTとして機能する。現状では、現場としてセキュリティかセイフティかを判断する仕組みがないので、高セキュア化の研究課題になると思う。
  • 議論に詰めてないが、攻撃されていると認知できなければ対応できないのは当然。よって事後、予防的な検知のやり方(資料4ではサーベランスと表現)を考える必要がある。事故か故障か攻撃なのかを検知できるテストベッドとしていくべき。
  • ユーザがどこまでやるかをガイドラインが必要。不具合との切り分けの整理が重要である。初めてのインシデントに対し解析機能と結びつかないとうまくいかない。日本版ICS-CERTではユーザ、ベンダーと協力しながら対処する必要がある。
  • 従来の事故・故障とサイバー攻撃は分ける必要があり、そのための人材育成、普及啓発が必要となる。
  • 先ほどの人材育成WG及び普及啓発WGの報告資料で“制御システムサービス”と文言を修正したが、これはサービスとしての故障のモデル化や対応をいったものが必要ということで、これについては各WGで検討していただきたい。
  • 新設、既存施設、改修時など時系列的での対応をどうするか。セキュリティのゾーニングをどう考えればいいか。
  • IEC62443-3でシステム認証を検討していることが分かっている。ここでは、ユーザがゾーンを決め認証を取ると定義されている。物理的なゾーンに加え、インテグレーションへのアセスメントという考え方も出てきている。6月頃に詳しい情報が分かる予定。
  • 時系列における改修問題については、現場と同じようにセキュリティ技術も時系列で変化してくる。医薬品業界などでは改定対応を常に行っており、改修対応についても常にやり続けなければならないという課題がある。そのためには、ユーザとベンダー、テストベッドの協働が必要である。
  • 物理的なゾーニングと情報的なゾーニングを分けて考えていかなければならない。
  • テストベッドにおける高セキュア研究とは何か。
  • 今ある製品を高セキュア化するには現状に技術を+αする対応が必要と考えている。障害切り分けの検証では、現場におけるセキュリティ問題への対応としては、セキュリティ問題を判断できるようになるための訓練が必要で、そのためにテストベッドでは演習用テストベッドを持つこととした。人間面の向上を期待している。
  • 制御システムセキュリティでは、情報セキュリティと比べアベイラビリティを高める必要があるとなっている。特に広域連携などを考えると大きな研究課題になると考えている。
  • (事務局)4月に第3回タスクフォースを予定している。詳細連絡は後刻事務局より行う。
  • 本日は色々なご意見により方向性の確認と課題が分かってきたので、引き続きのWG活動をよろしくお願いする。

問い合わせ先

経済産業省商務情報政策局情報セキュリティ政策室
電話:03-3501-1253
FAX:03-3580-6073

関連リンク

 
 
最終更新日:2012年2月20日
経済産業省 〒100-8901 東京都千代田区霞が関1-3-1 代表電話 03-3501-1511
Copyright Ministry of Economy, Trade and Industry. All Rights Reserved.