2012年 - VECサロン

サイバー攻撃に強い制御システムを構築するには　その3
インシデントフローチャート作成と脆弱性情報

1．はじめに

サイバー攻撃に対する対策としてサイバー攻撃に強い制御システムにするには、ユーザーとベンダとエンジニアリングの連携が基本で、制御システムセキュリティ・ゾーン設計をベースにした制御システムや制御装置の改善を予め実施しておくことが重要であることを＜その1＞と＜その2＞で取りあげてきたが、実際にインシデントから事故につながらないようにするには、インシデントが発生した時の前後のログ情報収集と原因追求と改善対策が適正かつスピーディーにできるかに関わることを皆さんご理解いただけると思う。では、そのインシデント発生時の作業フローではどのようなことを押さえていなければならないかについて述べてみたい。また、この対応に関連して、制御製品の脆弱性情報と制御ベンダの対応能力と情報公開については、ハンドリングを間違えると制御現場を危険に陥れることになることにも触れておく。

2．防衛対策の本質

サイバー攻撃は攻撃する側と制御システムを守る防御側との攻防戦であることは、関係者であれば、理解できる範囲と思う。ここに、防衛対策の本質があると言っても良いと思う。攻める方のテクニックが上がることを想定して、防衛能力が向上できるように制御システムを設計し、人的対応能力も成長できる体制を組んでおく必要があると言える。それに、いくら制御システムを頑丈に作っても、技術的検知能力や防衛能力を超える攻撃技術の進歩によっては、現場の作業者の気づきが遅れれば遅れるだけ汚染範囲は広がっていく。汚染範囲が広がればそれだけ復旧作業に人員や時間を要してしまうので、企業損失は大きくなってくる。＜図1＞
さらに、原因追求においても、集めた情報だけで原因追求するのだか、その作業の中でも、新しい攻撃パターンに対しては、気づきも重要な活躍を引き出すことは外せない。＜図2＞
セカンドオピニオンの役割もそのセカンドオピニオンが持つ制御システムや制御装置に関する制御ベンダレベルの知見とサイバー攻撃マルウェアに関する過去と最新の知見と現場経験知で、原因発見までの時間と適正な現場対策を見出すまでの時間は変わってくる。

3．インシデントフローチャートを作るにあたって

インシデント対応について言うと、普段、現場において、不具合が発生したり、何かおかしい現象だと思って、現場調査したりする時には、セキュリティ問題が存在していることを前提に行動していない。通常、よく起きている不良が出ているのか、それ以外かという仕分けから始まる。
それに対して、制御システムセキュリティ・ゾーン設計を施していると、IDS（侵入検知システム ：Intrusion Detection System)やIPS（侵入防止システム: Intrusion Prevention System)機能が検知してくれることで明らかにサイバー攻撃を受けたという判断から始まるインシデント対応と、ゾーン設計がある無しに関係なく警報警告や人による気づきで見つけた異常検出でセキュリティ問題を含んでいるかどうか判らない場合と考えられる。このどちらのケースであっても現場で対応できるインシデンフローチャートを作成しておくことで、作業漏れをしないようにすることができる。但し、攻撃側の巧妙さによって気づきにも引っかからない場合も想定しておく必要がある。では、そのフローチャートを作成するにあたっての注意事項をいくつか挙げてみる。
参考図は、完成度は高くないが、フローサンプル＜図3-1／-2＞を見ていただきたい。

1. インシデントフローチャートの中の異常発見から調査、確認、判定、記録などの登場人物は、
   ①確認できる作業者：Whoever identified the vulnerability
   ②現場部門の管理者：BU/Lob Quality/Support Manager
   ③社内部門CERTメンバー：BU/Lob CERT（制御システムやセイフティ、セキュリティの知見者／専門技術者）
   ④社内CERT責任者：Corporate CERT（品質保証から生産全体を受け持っている責任者）
   ⑤企業広報担当：Corporate Communications
   ⑥制御ベンダ専門家もしくはセカンドオピニオン：Specialist for CERT of Vender or Second opinion
   を考えたい。
2. フローチャート作成の時には、制御システムセキュリティ・ゾーン設計でインシデント発生を検知する機能を有している場合といない場合を考慮する必要があるが、検知機能があるからと言って、全てのインシデントを発見できるということは言い切れないこと。また、IDSやIPSに頼り切っているのもどうかと思う。理由は、サイバー攻撃は攻撃側と防衛側の攻防戦であるのでIDSやIPSの機能レベルを超えるマルウェアが作られることも脳裏から除外してはならない。
3. 現場のログ情報収集機能を制御システムや制御装置に持っている場合と持っていない場合で原因分析能力に限界が出てくる。
4. セキュリティ問題を抱えている可能性を含む現場の現象を予め想定しておく必要がある。
   例えば、
   ①制御動作が時々遅くなる。
   ②通信エラーが出るようになった。
   ③制御データが抜けている。
   ④制御動作変化しているべき制御データが変化していない。
   ⑤制御信号が突然変化する。（突変現象）
   ⑥壊れるはずの無い部分が壊れている。おかしなストレスがかかったと思われる。
   ⑦制御機器のメンテナンスチェックが終了しない。
   ⑧閉まっていなければならない操作端が開いている。また、その逆。
   ⑨再起動してしばらくは正常動作していたが、また、同じ異常になった。
   ⑩ソフトウェア更新をしたら、異常になった。
   ⑪USBで作業をしたら、異常が出るようになった。
   ⑫外部サポートを受けた後に、異常が出るようになった。
   ⑬制御異常現象は出ていないがインシデント発生
   などである。
5. 現場で不具合現象の問題仕訳をする作業で使用できる道具やツールなどの確認を行っておく必要がある。
   現場には、制御コントローラのハードウェアモジュールの機能をチェックするモジュールチェッカーは存在している。そのモジュールチェッカーの検査機能の内容と範囲を確認しておく必要がある。また、コントローラの自己診断機能の内容と範囲も知っておかないとどこに漏れがあるかが見えてこない。バグ情報もしかり。＜図4＞
6. 現場作業者には、セキュリティ問題解決に必要な情報源に限界がある。そこでリモートで支援できる環境を整備することを考えておく必要がある。情報は見られれば良いというものではない。どの現象にはどの情報が関係していて、どの程度の関わりであるかなどの重み情報も含めてナビゲーションしてくれることを現場は望む。
7. インシデントサポートでオフサイトサポートやオンサイトサポートができる場合とできない場合で現場の作業フローは変わる。＜図5＞
   この場合のテストベッドとは、現場の異常状態の原因追求を支援する環境を指す。現場サポート用の通信でキャリア通信の環境で、災害時の対応を考えると衛星通信をバックアップに持っておくことは考えられる範囲である。通信機械設備も通信費用もさほど高いものではない。非常時だけ衛星通信を使用するより、通常時から衛星通信を利用して、その運用環境を利用しておく方が、災害時に慌てて通信機材を出して「ああでもないこうでもない」と手間取るよりは良いと考える。
8. 制御ベンダやエンジニアリング会社の協力を得られる場合と得られない場合の対処を考えておく必要がある。現場の制御装置や制御製品を扱う問題であるので、制御ベンダやエンジニアリング会社のインシデント対応認識を持って適切な情報を提供してくれるCERT部門が制御ベンダや装置ベンダ、エンジニアリング会社にあることは非常に助かることであり、それに対応した体制を組むことを予め契約しておくことは、フローチャート作成時の大きな条件にもなってくる。だから、保険契約をするつもりで制御ベンダや装置ベンダやエンジニアリング会社と話し合っておく必要がある。＜図6＞
9. インシデント対応フローチャートを作成する最大の目的は、真の原因追求とその対策をフィードバックすることだが、もう一つ、現場における重要課題として、「制御システムを復旧して操業できるようにする」がある。それには、
   
   ①制御システム構成品リストを確認
   - 構成部品リストが現場と一致していること
   
   ②ソフトウェアのマスタ管理の最新バージョン確認
   - 制御コントローラのコンフィギュレーションファイルのマスタ管理
   - DCSのエンジニアリングツールの復旧に必要なソフトウェアのマスタ管理
   - 操作表示器の作画ツールソフトウェアのマスタ管理
   
   ③リフレッシュ作業のマニュアルを確認
   - マニュアルが無ければ作成
   - マニュアルが有れば実際にリフレッシュ作業実績があるか
   - 実績が無ければ、オフライン作業して確認する
   
   ④作業ができる人員確保
   - トレーニング
   - トレーニング環境整備
   - 机上でのイメージトレーニング
   - シミュレーショントレーニング
   - 実トレーニング
   - 現場でのリフレッシュ作業時間の試算
   - リフレッシュ作業能力の確認
   - インシデント時に、リフレッシュ作業できる能力で、生産停止時間を計算
   - リフレッシュ作業時間中、制御一時停止となるが、それが制御上問題ないか確認
   
   などを実施しておく必要がある。

それぞれに教育カリキュラムが必要で、マニュアル管理の社内ルールに基づいてマニュアルが必要となってくる。 インシデント対応のフローチャートを作成するということは、これらの環境を整備することになり、必要経費を企業として投資することになる。その投資金額は、実際にサイバー攻撃を受けてインシデントで済まなくて事故になったことを想定すると、企業経営にとってリアルなリスク軽減の一助になっていることが明らかとなる。よって、試算するのが大変であることや社内手続きをすることは大変であるが企業が生き残っていくには必要な投資だと理解していくことが大切である。

4．脆弱性情報と実際の製品更新

インシデント対応から事故につながることを考えると制御ベンダや制御装置ベンダの脆弱性発見と対応が重要であることも理解できると思う。そして、制御ベンダや装置ベンダの脆弱性情報はインシデント対策をしていく時の重要な情報の一つになっている。
その脆弱性情報のハンドリングであるが、ICS-CERTは、Control Systems Security Program (CSSP)　／ICS-CERT Vulnerability Disclosure Policyを2012年9月に以下の追記をしてアップデートした。＜図7＞

UPDATE! In cases where a vendor is unresponsive, or will not establish a reasonable timeframe for remediation, ICS-CERT may disclose vulnerabilities 45 days after the initial contact is made, regardless of the existence or availability of patches or workarounds from affected vendors.

「【今回更新】ベンダの対応が鈍い場合、または、ベンダが提示するパッチの準備に必要なタイムスケジュールが妥当ではないと思われる場合、ICS-CERTはベンダに脆弱性発見の通知をした日から45日後以降に、パッチや回避策の在る無しに関わらず、脆弱性情報を公開することがあります。」

ICS-CERTの公開サイトはこちら
http://www.us-cert.gov/control_systems/ics-cert/disclosure.html

経済産業省は、この内容をそのまま国内適用にすることでガイドラインを出すことを進めている。
ここで問題となってくるのが、この適用範囲と運用である。
制御システム製品のソフトウェアは、情報系と異なって、電源ON/OFFでソフトウェアの起動や再起動をすぐに行えるようにソフトウェアの一部や全部をASICチップ化して制御コントローラのハードウェアに搭載していることが多い。インテリジェントなバルブ製品は、現場の環境にも対応できるようにフィードバック制御のプログラムをROM化して使用している。PLCにおいても操作表示器製品においても制御プログラムや操作表示処理プログラムはハードウェア部分の一部になっている。これらの製品開発期間は、1年から2年かけて次の新製品をリリースするというものである。そのスケジュールの中で大きな時間ファクターを占めているのが環境品質性能試験と機能性能試験（ロバストテスト）である。
2012年2月にK社のPLCの脆弱性情報を公開するという通知をICS-CERTからもらったK社では、脆弱性対象となったプログラムはほとんどのプログラム領域にわたっており、ほとんどのプログラムが書き換えということであった。しかし、情報公開までの期日が1週間前に迫ったことでの判断は、PLCそのものをネットワークアクセスできないようにするディップスイッチを設けるというものであった。急遽、PLCの基盤のディップスイッチの空スイッチにその設定を行えるようにするということは、基盤回路印刷パターンの一部を切って、ジャンパー線を這わせる作業を行うことになる訳だが、この対処はプログラム変更して様々な試験を合格して新しい製品が出てくるまでの応急処置となる。それまで納品したユーザーの工場の製品を取り換えする作業に数か月を要したであろう。もし、この作業を行わず、脆弱性をついたサイバー攻撃がネットワーク経由で行われ、現場ロボットが暴走したりして現場作業者を傷つけたり死なせたりしたら、PL法などの責任もついて、大変な損害賠償や保障賠償をしなければならない事態になっていたと思われる。
制御ベンダが納品先を把握している場合は訪問して対処となるが、商社経由で一般販売している場合は、制御ベンダがその納品先全てを把握している訳ではない。また、ネットワークアクセス許可をディップスイッチで対処となると、生産する製品が変わる度に自動でレシピを書き換えていた生産ラインそのものを止めてレシピを書き換えてその書き換えたものが正常であるかの確認を人海戦術で行って生産再開しなければならなくなる。つまり、生産する製品のタグを見て製品化するレシピを生産管理のMES Serverからデマンドを自動で取り込んでコントローラのレシピを変えて生産することができなくなる訳である。その代わりを人の手で行うことになるが、その間、製品を生産できなくなる。その他、プラントなどではハードウェアを交換する為に生産操業を止めるのに、生産計画の変更と準備のための時間も要するところもある。など、その影響は広範囲に及ぶ。海外プラントにおいてもインターネットが普及している現代では同じである。そのすべてを45日間で終わらせることは不可能に近い。よって、脆弱性発見の通知をICS-CERTからもらった場合、すぐにどれだけの作業が必要となってどれだけの時間が必要となってくるかをはじき出す必要があり、対応していく要所々々でICS-CERTへ報告していくことで、連携した対処を作り出すことも可能となる。
ICS-CERTは、アメリカ国土安全保障省の制御システムを熟知している国家公務員メンバーが従事していることから、アメリカ国民の生命と財産を守ることを基本としている。制御ベンダをつぶす目的でやっている訳でもなくパンデミックを引き起こすことを目的としていないことは立場的に理解できると思うが、制御システムの仕組みを理解していないメンバーで構成している機関がハンドリングする場合は、ICS-CERTと同じハンドリングはできないと思うのが道理である。そう考えると米国ICS-CERTと同じ機関を持たずに脆弱性情報を一方的に公開するルールを作るのはどうかと言わざるを得ない。
しかし、ICS-CERTがベンダに通知をしようと連絡をしても反応しないベンダもいる。売りっぱなしで責任を持たないベンダもいる。セキュリティ問題に関する認識を持たないベンダもいる。それが明らかとなっていくことで、市場からなくなっていく企業もこれから出てくるであろう。それは、市場での信用の問題であり、社会的責任を持つことが求められる時代になっていると理解するしかないとも言える。
制御ベンダや装置ベンダが、ICS-CERTなどの機関から脆弱性情報の通知をもらってから対策クローズするまでの責任者とマニュアル（手順書）は、予め作成しておき、責任者の引き継ぎの都度、手順確認を行っておくことをお勧めする。

ICS-CERTから、通知をもらった時の一対応例

• 受け取ったことをICS-CERTに返信：
  弊社の責任窓口を通知するが、できればディレクター（本部長）クラスかサブディレクター（担当部長）クラスが直接対応し、自己責任範囲を伝えるとICS-CERTの担当官の感触も良い。
• 2,3日以内に、ICS-CERTへ方針を伝える。：
  対象製品の出荷数量や販売地域範囲と対処方法を施していくのに特殊事情があるのであればそれも含め、関連する特徴を伝えるとともに、どのような対処方法をとるかをICS-CERT側から見て理解できるように伝えることになる。

注1：
ソフトウェアならパッチをいつどこにアップして、顧客にどのように伝えてサポートするのかを具体的に知らせる。それまでのユーザーに依頼する対処についてもガイドラインを示すことを欠かさないように。

注2：
ハードウェアなら応急処置と恒久対策を示すことになる。

注3：
ホームページなどで情報公開する内容も知らせる。対策の段階によって顧客に依頼する防御方法もガイドラインとして明示することが重要である。「セキュリティ対策環境で使用してください。」とか「ネットワークにつながない運用をしてください。」など、脆弱性をついて攻撃してくるサイバー攻撃の標的になっても防御できる方法を公開しておくことや顧客への直接通知が重要となる。

注4：
顧客の顔が見えているところと見えていないところへの対処方法も予め決めておく必要がある。
- 毎週一回は、ICS-CERTに進行状況を報告する。

注5：
脆弱性情報はできるだけ早く公開することを基本に、起きた問題点や起き得るであろう問題点を早めにICS-CERTへ通知していくことで、対処方法についてアドバイスも得ることができるし、ICS-CERT側の配慮も期待できる。但し、ICS-CERTの担当官によっては配慮してくれない場合もあり得ることは想定しておく必要がある。
- ソフトウェアのパッチができた時やハードウェアの対策が決定した時には、ICS-CERTへ、その旨を通知する。
- ベンダとしての対処すべきことが終了したと判断する前に、ICS-CERTに今までの対処内容を整理して報告し、クローズ判断基準を明確に伝え、最終確認をICS-CERTへ通知する。

注6：
脆弱性情報を公開されても事故が起こさないために必要な顧客への情報提供や対処サポートを実施して、ベンダ責任を果たしているという第三者判断が可能な状況を作っている証拠を残しておくことが重要である。

5．事故につなげない体制づくり

今、企業に求められることは、ユーザー企業はインシデント対応の体制づくりであり、制御ベンダや装置ベンダには脆弱性情報に対する対応体制づくりである。

1. インシデント対応について
   大事故や事故につながる前所謂インシデントの段階で、予兆や前兆をとらえて、不具合の本当の原因を見つけて、根本的対策を施せば、大事故や事故は発生しないと普通考えられる。それは、標的型サイバー攻撃を受けていないケースで、巻沿いを受けた時などに発生したインシデントの場合である。標的とされて狙われた場合は、Serverを乗っ取られて操作端を直接操作された場合やコントローラから出る指令値やコマンドを差し替えられた場合などは、いきなり、事故となるケースが考えられる。だから、制御システムにおけるセキュリティ対策は、制御上のセイフティ対応と一緒に制御システム設計を考えていく必要がある。しかし、セイフティ対応は固定的な対策とルールを守る教育が重要であるが、セキュリティ問題は攻撃する側の存在がある為、攻防戦の要素が大きい。このため、セキュリティ問題の情報を集中して扱う専門CERT担当を組織機能としておくことが必要となる。それから、インシデントフローチャートを作成して、そのトレーニングをしながら、従事する人達のスキルアップをはかっていく必要がある。＜対象は、本原稿の3．の1）に記載の登場人物にあたる組織と人材＞
   また、新マルウェアの情報があって、その対策方法をまだ自社が手を付けていないことであったり、現在の対策に追加対策を施さなければならなかったりする場合も出てくる。
2. 脆弱性対応について
   ICS-CERTからの脆弱性発見通知を受けて対処する責任者を決めておくことと、定常業務としてセキュリティ問題に関する情報を入手して自社との関連を判断し、関連部署に通知していく担当部門も決めておく必要がある。
   例えば、製造ラインで使用しているであろうと思われる制御製品の脆弱性情報があれば、製造現場や生産技術の部門、設備保全の部門には通知しておく必要があるだろう。また、他社の脆弱性情報から、自社のセキュリティ試験で抜けている試験項目の見直しもあるだろう。

6．あとがき

サイバー攻撃に対する対策は、今までの制御製品のバグ対応を行ってきたところに、新たにサイバー攻撃というカテゴリが追加となった訳であるが、未知で未経験であることから、対応体制も見直しできていないのが実情である。どのような被害が出るのか、どのような被害が出ているのかを把握していく必要があるが、日本国内の企業は風潮被害を避けるために現場で起きているインシデント情報をひた隠しにしている傾向があるようだ。中には、「海外で出ている話は聞いているが日本では出ているという話はほとんど聞かないからまだいいよ。」と言って対応しないインターネットを理解できない経営者も少なくない。自社のインターネットServerや他社のServerを借りて、リモートサービスの画面をツリー構造で作って、Webでアクセスできるようにして、「クラウドでリモートサービスしています。」と言っている日本のベンダ会社もある。その認識の低さを嘆いている場合ではない。