2014年 - VECサロン

計装制御システムセキュリティ
インシデント対応での復旧作業について

1．はじめに

マルウェアが侵入しないようにする防衛も重要な対策であるが、それだけを行っているだけでは、実際に侵入された時には、パニックとなるのが知見少ない現場の実情であろう。しかし、情報セキュリティに知見だけでは汚染した制御システムや制御装置を復旧されせることは難しい。また、制御システムの知見はあっても、マルウェアに関する知見を持っていないと復旧作業も失敗するリスクは高い。
情報セキュリティの世界では、汚染した部分を削除してエラーとなった情報を元にアップデートソフトをダウンロードしてインストールして再起動することで復旧できる。しかし、インターネットに接続していない制御システムや制御装置のPCやServerは、制御システム独特の事情によりウイルスチェックソフトを常時動かすことができないものが多い。しかも、汚染したソフト部分がどの範囲でそれを交換する為に汚染部分を削除したら、人の手を介して削除した部分をマスターソフトからインストールすることになる。その後、システムを再起動して制御上データ取り合いをしているデバイスとのI/Oチェックを行うことが求められる。それと制御システムが正常に制御動作することを確認しなければならないことがほとんどである。
生産プロセスのログを必ず記録しなければならない法規制がある業界では、そのデータを取り出して、そのデータが汚染していないか、改竄されていないかを確認しなければならない。改竄されている場合は、どう復旧したのかを記録して報告できなければならない。生産ロット単位の品質データを残さなければならない生産現場においても同じである。もし、それらの品質データや生産プロセスデータの健全なデータ確保ができない場合は、生産した製品ごと廃棄しなければならない業界もある。
生産した製品を出荷する時の条件に、その製品を生産している間に、マルウェア侵入されていないことを証明しなければならない義務を持つ業界もある。 そこで、今回は、復旧作業にフォーカスを充てて述べていく。

2．インシデント対応

PDF資料(P2)トラブル発生時、納品した制御システムは、その専門性が高ければ高いほど、供給側の専門的なサポートを必要とされる。だが、重要プラントであればあるほど、非常時の対応レスポンスが高いものについては、エンドユーザー自身でもある程度の対応能力が必要となってくる。インシデント発生時は、現場対応の範囲として考えるならば、緊急対処判断能力を求められる。しかし、全ての事象について、現場で対応ができるかと言うと必ずしもそうだと言いきれないのが現状であろう。ただ、想定範囲については現場対応の道筋はできていなければならないと考えるのが妥当かもしれない。
そこへ、制御システムセキュリティにおけるインシデント対応を実現するとなると、まずは、その内容を理解することから始まる。

インシデント対応には、以下に挙げる項目を考慮していくことになる。

（ア）即時判断

1. このままでは操業継続できない、もしくはこのままでは爆発事故や大事故に至る場合はトリップ停止処理を選択
2. 操業上／制御上の即時対応の必要は無いが、油断ならないので警戒態勢を敷く
3. 即時対応するべきかどうかの判断がつかない　⇒　判断できる者への即時連絡

（イ）検知・分析

1. マルウェアの制御システム侵入検知：
   
   A) インシデント対応システム（IDS／IPSやログ）を設置してあればその分析
   ・情報システムネットワークと生産システム（制御情報系／制御系システム）の間に設置するDMSに設置するIDS／IPS
   ・制御情報系（MES）ネットワークに設置するIDS
   ・制御システムネットワークに設置するIDS
   ・制御製品の中でタスク通信を監視する目的で設置するソフトIDS
   ・フィールドネットワーク（センサーネットワークや無線通信を含む）に設置するIDS
   ＜注1＞設置場所によって求められるIDS仕様は異なる。すでに製品化されているものとまだ製品化していないものがある。
   
   B) インシデント対応システム（IDS／IPSやログ）の設置が無いものについては、起きている現象や警報やコントローラの個別警報などの情報で判断することになる。
2. マルウェア分析：目的は、操業上／制御上、有害か無害かを判断する。
   
   A) マルウェアの種類
   ・トロイの木馬：Trojan horse
   　バックドア型
   　パスワード搾取型
   　クリッカー型
   　ダウンローダー型
   　ドロッパー型
   　プロキシ型
   ・スケアウェア：scare ware：詐欺恐喝行為ソフト
   ・スパイウェア：Spyware：情報搾取
   ・ミスリーディングアプリケーション
   ・ワーム：破壊やトラブル発生を目的につくられた感染力を持つマルウェア
   ・ボットネット：Botnet：ゾンビコンピュータネットワーク
   ・Stuxnet
   ・Shamoon
   
   B) マルウェアに利用されているもの
   ・ウイルス：他のPCに感染・増殖するもの
   ・バックドア：ソフトウェア製品開発で使用する機能
   ・キーロガー：キー入力を搾取
   ・WordやExcelのマクロウイルス
   ・アドウェア：関連があると追加されるソフト
   ・ブートセクタウイルス：ブートセクタに取りつくウイルス
   ・スクリプトウイルス (BAT、Windowsシェル、JavaScriptなど)
   ・バッドウェア：知らせないダウンロードソフト
3. 汚染域の特定
   
   A) ゾーン設計されている制御システムはゾーン単位で確認していく必要がある
   
   B) ゾーン設計していない制御システムは、つながっているものすべてを確認していくことになる

（ウ）判定

1. 洗浄・復旧作業の必要性判断
   
   A) 操業上／制御上、支障がある場合は、即操業停止するかどうかの判断をすることになる。
   
   B) 操業上／制御上、今は支障が出ないが、いつ活動を活発化して支障を来すであろうと予測する場合は、できるだけ早い時間での洗浄化／復旧化を実施することになる。
   
   C) 操業上／制御上、全く問題ない場合は、定期点検時の作業に洗浄及び復旧作業を実施する。
   
   ＜注2＞マルウェアの種類によっては、完全に取り除けない場合もあるので、いきなり現場の制御装置で洗浄作業をするのではなく、オフラインで同党の制御製品を用いた試験環境で洗浄作業及び復旧作業を行ってみて、問題なく復旧して制御できることを確認すること。

（エ）復旧作業

1. 作業計画を立てる。
2. 洗浄・復旧作業道具準備
   
   A) 作業手順を作成：想定される作業流れに従って作成する。
   
   B) 作業手順書に従って作業の流れを追いながら、必要となる道具をリストアップする。
   
   C) 道具を揃える
3. オフラインでの手順確認
   実機と同じ条件で確認することで、想定していない問題点を見つけ出す。
   
   A) オフラインで、制御システムで構成している主要な制御製品を別途揃えて、それを実機からコピーしてきたマルウェアで感染させて、作成した手順書と道具でそれを洗浄する。
   
   B) 浄化・復旧後の確認ポイントを確認する。
   
   C) タクトタイムを測定して作業に必要な時間を確認する。実機で作業するに必要な時間が操業上で確保できるかを確認する。
   
   D) 万が一の時の緊急処置の確認をする。
   
   E) 実施作業に必要となる人数と作業担当の確認をする。
4. 実施条件確認：
   
   A) 万一作業ミスが起きてもプラント事故に至らない最小限の被害対策が可能な実施条件を確認する。
   
   B) 作業全てが、制御上問題にならない時間内で完了することを確認する。
5. 実機作業実施
   
   A) 復旧作業を実施するに、万が一のリスクを考慮するに、作業時間を確保できる操業上もっともリスクが低い運転状況での作業タイミングをつくって行う。

（オ）防衛対策へのフィードバック

1. マルウェア侵入原因や被害内容を検証して、防衛対策を見直しする。
2. 検討された防衛対策内容で、制御システム設計や制御製品や運用、保守・保全に反映するべき項目に分類して各関係者へ通達
3. 防衛対策の改善実施計画を取りまとめ
4. 改善実施
5. 運用動作試験：操業できることを確認する。
6. セキュア評価試験：但し、制御システムを壊しては意味がないので攻撃試験はできない。
7. 運用

などが挙げられる。
注２にも記載したが、洗浄作業をしたからといって、マルウェアを除去できても完全に復旧できるかどうかは、侵入したマルウェアがどのような種類でどのような悪さを仕掛けて、その一時的被害と二次的、三次的に広がった被害全てを復旧できるのかどうかは、確認が必要である。その為にも、復旧作業後の制御製品のI/Oチェックや基本動作及び制御動作や性能に関する確認作業は怠ってはならないところである。
今後、このようなインシデント作業の実施事例などで得られた知見情報は、インシデント・エンジニアリング・ノウハウとして、専門的財産となるであろう。

3．実際にあった除染作業失敗例

マルウェアの除染作業で失敗した例は、なかなか公表されない。企業としては、企業不安を掻き立てることになるので知られたくないことである。

（1）復旧作業手順抜け

• 現象／経緯：
  汚染した制御システムのPCのマルウェアをウィールスチェッカーソフトで除去したが、ドライバレベルまで除去したにも関わらず、それに気づかず、復旧作業を完了。操業中に制御システムエラーにより、システムダウン。
• 調査：
  ベンダの現場サポート調査で原因が見つかり、復旧。
• 原因：
  PCの製品動作チェックの不備
• 対策：
  PCに搭載のソフト製品の動作チェック機能にドライバなどの構成チェックとI/O通信チェックを追加

（2）制御システムに作業用のPCが接続しているのを見逃す

• 現象／経緯：
  制御システムネットワークにつながるPCやServerを制御システムネットワーク接続図及びネット接続リストをベースにチェックしながら、各PC及びServerを洗浄したが、復旧作業後、操業再開してしばらくして再度汚染。
• 調査：
  制御システムネットワークの接続リストに従って、ハブに繋がっているケーブルを手繰る。保全課が持ち込んだPCを接続していたネットワークケーブルを発見。
• 原因：
  保全課から連絡を受けていながら、接続リストに反映していなかった。
• 対策：
  構成図や配線図で現場調査確認する前に、図面に乗っていない接続があるのかどうかを関連部署にも確認する。

（3）PCのHDDの予備領域の洗浄忘れ

• 現象／経緯：
  洗浄作業を行って復旧作業完了後、操業再開したが、しばらくして再度汚染したことが判明した。
• 調査：
  PCに制御上見えていない予備HDDエリアが存在していることが分かった。しかも、その部分が洗浄作業領域に入っていなかった。
• 原因：
  予備HDDエリアが未洗浄で、そのエリアとのデータファイルアクセスで感染。
• 対策：
  PCやServerの予備HDDエリアが制御システム内に存在しているかどうかを洗浄作業前に確認する。

（4）冗長化制御システムの復旧作業の準備不足

• 現象／経緯：
  冗長化制御システムのSCADAが汚染していることが判明して、すぐに同じ制御システムを注文しても納品までに最短で3か月かかる為、これを除染して復旧することになった。ところが、未経験な為、どこから手をつけたら良いのか分からない。そこで、まず、バックアップ側にFW（Firewall）を設置してみたら、冗長化制御システムのエラーが発生した。
• 調査：
  現象から、FWの設定に問題があったのではないかと考え、FWを調査
• 原因：
  FWの設定がデフォルト設定であったため、冗長化で使用しているファイルコピーで引っかかってしまった。
• 対策：
  オフラインで冗長化制御システムを別途用意して、FW設定のチューニングをして、実機作業手順を書き直して、実機作業に入った。

＜注3＞冗長化制御システムは、冗長化の仕組みがDCSやSCADAの製品構造によって異なる為、手順を一概に決められない。制御ベンダと相談の上で相互協力し合って対処することをお勧めする。
＜注4＞除染の場合、侵入したマルウェアによっては、汚染された部分が広範囲に及んで除染するとOSが緊要しない場合もあったり、ステルス性を持つマルウェアの場合は、起動するまで判らないと言う場合があったりと、完全に除去できない場合がある。その場合は、新しいハードウェアに再構築した制御製品と交換することが賢明の場合もある。
＜注5＞制御製品を復旧させるに必要な条件に制御ベンダが持つ、製品の部品環境がある。ほとんどの場合、制御ベンダはここまで考慮していないことが多い。予め、制御ベンダとユーザーとの間でこの復旧環境について話し合って合意の体制をつくっておくことをお勧めする。

（5）汚染システムからのデータ取り出し作業失敗

• 現象／経緯：
  汚染したシステムから、生産履歴や品質管理履歴や保全記録などのデータを取り出して、復旧作業を試みたが、復旧作業後、再度、システムが汚染してしまった。
• 調査：
  データを取り出した作業の中に問題が潜んでいるのではないかと思われるので、手順を確認。
• 原因：
  データ取り出しのUSBの作業前後に、ウイルスチェック検査を怠っていたので不明。
• 対策：
  USB使用前後に、ウイルスチェックをすることを作業原則にする。ユーザーは、制御製品の中にあるデータは残したいと考え、制御ベンダは、汚染した制御製品からデータだけを取り出して、復旧を試みた訳だが、取り出したそのデータファイルにマルウェアが潜んでいるのか、データ取り出しに使用した電子媒体にマルウェアが転移したのか判らない。また、使用するウイルスチェックのソフトがそれを検出できるのかも確認が必要である。さらに、取り出したデータがマルウェアによって書き換えられている可能性もあるので、これも確認が必要となる。

＜注6＞生産履歴や品質管理履歴や保全記録などのデータファイルは、ロット単位で取り出して保管することを勧める。特に、生産履歴や品質管理データが改竄された場合、生産している製品によっては、そのロット製品の出荷停止もしくは回収といった事態になりかねない重要データである。

4．マルウェア侵入の原因

日本国内での制御システムを標的にしたサイバー攻撃では、イランのウラン濃縮施設と同じ制御システム構成であるSCADAにStuxnetの発見された事例はある。ただ、遠心分離機の制御システムでなかったのが、Stuxnetが攻撃そのものをしなかったという結果が残っている。もし、制御対象が遠心分離機であって、同じ制御システム構成であったら、Stuxnetが攻撃に転じる可能性は高くなる。それは制御対象の遠心分離機がウラン濃縮であろうがなかろうが同じである。 Shamoonは、どうであろうか？Shamoonの場合、感染したらオートブートを書き換えられて再起動すると二度と起動しないガラクタになってしまう。この現象の報告は、私の方には入っていない。
現在、制御システムを標的にしたサイバー攻撃で多いのは、スパイウェア、スケアウェア、トロイの木馬とワームのようである。
侵入する経緯であるが、

• 作業員が通勤時に使用しているマルチメディアの充電を目的に、業務用PCのUSB口に接続
• 一般キャリア通信機能付き情報端末の充電に業務用PCを使用。情報端末のセキュリティ設定がされていなくて外部からマルウェアが侵入。
• 充電目的で業務用PCに接続していた個人のスマートフォンやiPadでメールを受け取り、添付ファイルを開けたことでマルウェアが侵入し、PCまで感染。
• 業務で使用している情報端末で、メールを受け取ってそれに添付のファイルを開いてマルウェアが侵入。それが使用していたイントラネットを通じて、制御システムに感染。

などが多い。つまり、情報システムのようにサイバー攻撃されることは、制御システムには起きないと言う違った認識が制御システムセキュリティ対策を必要とする認識につながらないことで、現場のセキュリティ認識が育たないままに放置されていることが問題ではないだろうか。
事業用プラント系では、セキュリティ５Sの導入でこのような事件は少ないが、地方自治体や中小企業ではセキュリティ５Sの導入が遅いこともあり、制御システムセキュリティに対する防衛認識の低さから、防衛できる事件が起きていると言えるのではないか。
キャリア通信を使用するモノは、現場持ち込みを制限するべきであり、業務用に使用している情報端末は、ポータルServerを置いて、DMZを設置したServerから情報をポータルServerへ取り出すようにして、一般キャリア通信を使用する場合はキャリア通信のセキュリティを設定するべきであり、情報端末のセキュリティ設定も行って使用するべきと考える。
制御システム製品でWindows XPを使用しているところは多いところに、サポートが無い。サイバー攻撃側の新手の攻撃が出てきているに、防衛は取り残されている。そのWindows XPを抱えている制御システムを一般キャリア通信を使用してクラウドを使用した情報端末を使用する場合は、リスクが高くなっていることに気付いてほしい。手軽さや利便性を言う前に機密性や安全性を確保してから使用するのが企業活動の基本だと思う。

5．インシデント対応に関する考察

PDF資料(P3)制御システムゾーン設計は、インシデント対応を考慮して設計するとインシデント対応時間を短縮できる。インシデントアラームが出て、マルウェアが存在している場所を特定したり、マルウェアの種類を分析したり、洗浄作業に必要な道具を揃えたり、洗浄する手順の確認を行ったり、洗浄後の動作確認をしたりと、インシデント対応には時間がかかる。操業者にしてみると、運用が止まっている時間をできるだけ短縮することが良い。

（1）工場の制御システム

1. 
   PDF資料(P4)プラントの制御システムの場合、制御システムとMESの間をGATE Wayでつないでいる場合、生産管理システムや品質管理システムや設備管理システム、環境管理システムなどがつながっているMESネットワークは、汎用OS（WindowsやLinux）を使用しているものが多いのに対して、プラント制御そのものを携わる制御システムは、専用コントローラを使用していることもあり、汎用OSをターゲットにしたマルウェアはなかなか侵入しないと考えがちであるが、汎用OSのPCやServerからデマンドを差し替えて制御システムに違った制御をさせることが起き得る。また、制御システムのエンジニアリングツールを搭載しているPCから、違ったデマンドを制御システムのコントローラへ送るという妨害が考えられる。この場合、MESネットワークにハニーポット式検知製品を設置しておくと効果的であろう。（こぼれ話：計装制御エンジニアの感覚では、ハニーポットという名前が良くない。上司に「ハニーポット」と言うとくまのプーさんのイメージで伝わってしまう。）
2. 
   PDF資料(P5)生産の素材加工の前工程をPAで行い、製品成型やパッキングをFAで行っている生産現場では、汎用OSを使用したSCADAやHistorianなどが多く使われているところが多いことから、制御システムのゾーン設計をして各ゾーンにIDSを設置することになる。
3. アセンブリ生産のシステムでは、制御システムゾーン区分が生産プロセス単位に分けることが多い。生産プロセスで区分しているので、どこかでマルウェアに汚染すると、その上流は中間ストックが溜り、下流では欠乏する。生産している製品によっては、生産全体を停止することを選択する場合もある。

（2）交通管制システム

PDF資料(P7)交通管制システムの場合、インシデント対応が考慮されていないケースが多く、マルウェアが侵入して感染していても判らないのが実状。システムからデータを取り出して業務用PCでデータを利用した報告処理をしているが、その業務用PCの定期ウイルスチェックでマルウェアに感染していることが判明することが多い。
また、Windows XPを使用しているところも多く、XPのサポートが切れているで、サイバー攻撃側の新手攻撃に防衛が更新できていないことなどから、急速にリスクが高まっている。現在、実際に発生しているサイバーインシデントは、Windows XPが多い。
制御システムセキュリティのインシデント対応の必要性を感じているところが多い。

（3）ごみ焼却場や上下水処理場など

自治体で管理している施設の多くは、サイバー攻撃対策を行っているものの、情報セキュリティ対策強化までで、制御システムセキュリティ対策はこれからと言うところが多い。
実際にインシデントが発生して対応するにも、冗長化している制御システムも多い。インシデント対応での復旧作業の手順書作成および見直しを行っておくことをお勧めする。

（4）ビルオートメーション

PDF資料(P6)今まで、サイバー攻撃の標的になるのは、ほとんどない業界であったが、月を追うごとに増えてきている傾向がある。
中堅規模のビルは、警備員に管理を任せているところも多く、リモートサービスで管理されているところが多い。現場の制御システムには、マルウェア侵入検知機能を設置して、インシデントが発生したら専門チームが現場へ急行するオンサイトサポート体制作りが必要と思われる。
防衛面強化では、現場には、PCを置かないようにして、USBインターフェースのあるパッチパネル表示器も置かないようにするなどのリスクを減らすこととセキュリティ５Sの徹底が望ましい。リモートサービスのHMIも、セキュリティ強化仕様にして、パスワード入力回数制限があるHMIブラウザによる操作端末にすることをお勧めする。また、オペレーションゾーン設計も効果的なのでお勧めする。

（5）工場ユーティリティ

PDF資料(P8)工場の共通インフラとしての自家発電や水の供給、エアコンプレッサなどの管理から、大気汚染対策や排水処理や産業廃棄物処理もあるが、最近は、発電施設の見直しで2015年から始まるエネルギー売買を目的にした太陽光発電や風力発電、バイマス発電などエネルギーに関する制御システムが増えてきている。

（6）冗長化制御システムのSCADAの場合

PDF資料(P9)汚染した冗長化制御システムを除染して復旧させるのは、かなり熟練度を要求する。
SCADA製品の構造は、製品開発時点の発想によって異なった構造をしている。

1. 通信ドライバでPLCからデータをHMIソフトに取り込んで表示操作できるようにした初期のSCADA
   I/O点数は数十点から数百点規模
2. PLCとの通信ドライバとHMIソフトとSQL Serverを組み合わせて、製品化したSCADA
   I/O点数は、SQL Serverの処理能力による
3. DCSコントロールの監視制御システム装置の構造思想を継承して開発されたSCADA
   PLCとの通信は50msec毎に行い、数百点ほどのI/O点数を扱う規模
4. モジュール構造の冗長化制御システム仕様のSCADA
   通信ドライバの周期も任意に設定でき、数万点から数十万点のデータを扱える大規模監視制御システム

《余談であるが、これらのSCADA製品の成長の中で、TAG（データに関連の定義情報を持った小サイズのデータ構造単位）という概念やOPCという標準通信ドライバとそれを支える標準化団体OPC Foundationが誕生した。これらを考え出したのが、今は無いIntellution Inc.のAlchizum氏（CTO）である。》

SCADAを復旧させるには、

1. 汚染した部分を除去して取り除いた部分を補完して再起動すると言うWindowsの構造を継承している製品
2. リアルタイムOS構造を持っているので専用の復旧ソフトが必要な製品
3. 復旧するには同じSCADA製品にデータや情報を与えて置き換える製品

の種類に分かれる。


PDF資料(P10)前準備

1. SCADAを通信上マルウェアから隔離するためのFWもしくはルータを確保
2. SCADAを復旧させるソフト環境を確認
3. 必要となる道具が揃っているかを確認
4. 手順書を作成／見直し
5. オフサイトにて手順書に従って作業者が作業を行う
6. 操業上、最も安全な作業タイミング条件を待つ

などの２．に記載の基本的なことを行って作業に入る。

6．復旧作業ができるための体制づくり

PDF資料(P11)

PDF資料(P12)

PDF資料(P13)

PDF資料(P14)

PDF資料(P15)
制御システムを守るにも、サイバー攻撃からは、これで充分と言うことは無い。制御システムは、製品を生産供給する為に使用している。となれば、サイバー攻撃に汚染された制御システムは、復旧しながらも、安全に操業そのものを継続できるように体制をつくっておく必要があると考える。

制御システムを復旧できるようにするには、

1. 制御システム構成品リストを確認
   ・構成部品リストが現場と一致していること
2. ソフトウェアのマスタ管理の最新バージョン確認
   ・制御コントローラのコンフィギュレーションファイルのマスタ管理
   ・DCSのエンジニアリングツールの復旧に必要なソフトウェアのマスタ管理
   ・操作表示器の作画ツールソフトウェアのマスタ管理
3. リフレッシュ作業のマニュアルを確認
   ・マニュアルが無ければ作成
   ・マニュアルが有れば実際にリフレッシュ作業実績があるか
   ・実績が無ければ、オフライン作業して確認する
4. 作業ができる人員確保
5. トレーニング
   ・トレーニング環境整備
   ・インシデントフローチャートを作成
   ・インシデントフローチャートに従った実トレーニング
6. リフレッシュ
   ・現場でのリフレッシュ作業時間の試算
   ・リフレッシュ作業能力の確認
   ・インシデント時に、リフレッシュ作業できる能力で、生産停止時間を計算
   ・リフレッシュ作業時間中、制御一時停止となるが、それが制御上問題ないか確認
7. インシデント（マルウェア侵入）を検出できる制御システム設計
   ・制御システムの構造に適したIDS設置
   ・制御システムの構造に適したログ機能設置
8. オフサイト／オンサイトの体制づくり
   ・制御ベンダやエンジニアリング会社との連携体制づくり
9. 重要インフラの制御システムとしては、サーベランスシステム体制づくり

などの体制をできる範囲から考えていっていただきたい。