2012年 - VECサロン

サイバー攻撃に強い制御システムを構築するには　その4
ベンダ対応とエンジニアリング受注に向けて何をするべきか

1．はじめに

制御ベンダや装置ベンダが制御システムセキュリティ対策を実施しようとした時、何から始めたら良いか判らないという問いかけと、エンジニアリング会社や商社がプロジェクト受注に向けてどのような対応が必要となるのか分からないという声が多いので、それらを一緒に考えてみたいと思う。

2．プロジェクト受注で要求されること

PDF資料(P2)海外のプロジェクトでは、国際規格に対応した第三者認証機関による制御システムセキュリティ認証合格製品を使用することを提示して見積り入札条件にしているプロジェクトが増えてきている。欧州においてはＷＩＢ認証を指定するところも多く、米国や中近東、南米でのプロジェクトではISA99／ISA Secure認証を指定するプロジェクトが多い。

また、欧州の医薬品／医療品製造企業ではWIB認証指定がほとんどであり、FDA圏内ではISA99を指定するところがほとんどである。これらの対象となる国際標準化規格は業界によって異なってくるが、IEC62443に集約されていく傾向がある。
セキュアな制御システムや制御装置を構築するには、セキュア技術を導入して対策を施した制御製品が必要であり、開発した制御製品の品質検査項目にセキュア項目が入っていなければならないし、セキュアな制御システム設計ができるエンジニアリングスキルも必要であり、その評価審査をする環境も必要となってくる。それと、サイバー攻撃侵入口を想定した製品開発環境対策やエンジニアリング環境も重要な実施項目である。

3．制御ベンダの役割

PDF資料(P3)サイバー攻撃対策として大きな役割を担うのが、制御ベンダのコントローラやDCS、SCADA、HMI、各種Server、インテリジェントなバルブやデバイスなどの製品についての防衛能力アップ対策である。ユーザーが指定する認証に、第三者認証機関の認証を受けることになるが、制御ベンダが抱える制御製品全てを第三者認証取得するには、かなりの費用と時間がかかる。試験期間は、試験レベルやコースで異なるが、1週間から長くて3週間を要する。
認証試験としては、Achilles認証のようなFuzzingツールとISA　Secure認証のようなAchilles＋CRT（Communication Robustness Test）を組み合わせた認証を受けることが求められる。

制御ベンダで制御システムセキュリティに深い知識と実力を持っている制御ベンダにおいては、制御システムセキュリティセンターを設置して、第三者認証機関と同等の自己認証に必要な環境を整え、人材も育成して、ユーザーのオーディットを受けて了承を得たのであれば、自己認証の制御製品を採用することで対応するということもあって良いのではないだろうかと考えられる。
第三者認証機関の認証を受けるにあたり、いきなり認証機関の試験を受けるというのは、かなりハードルが高すぎると考えられる。まずは、第三者認証機関が使用している認証試験環境と同じツールを使用して自社内で行う。
但し、認証製品で制御システムを構成したからと言って、全てのサイバー攻撃から守られているという訳ではない。制御システムや制御製品の城の城壁の高さと厚みを決めただけで、不落の城になった訳ではない。

（1）ISA Secure対象製品の区分けと事業戦略

まず、最初に始めることは、自社内試験環境をどうするかの方針決めであろう。
自社内試験環境に使用するツールは、国際的にも認められ、第三者認証機関も使用しているAchilles-toolが選択順位の筆頭に検討されるだろう。それとも、技術研究組合制御システムセキュリティセンターCSSCのメンバーになってISA Secure認証で使用しているツールを使って、自社内試験環境で試して、問題部分を洗い出し、その対処を行ってから、第三者認証機関の認証を得ることが望ましい。
また、第三者認証機関の認証試験も日本適合性認定協会JABに申請して、国内CSSCの認証試験環境で、認証試験ができる環境を整備しているので、それを利用するのも良いであろう。
次に制御ベンダ自社で販売している制御製品の仕分けである。グループ分けとして、
　①自主的に認証を受ける製品グループ
　②顧客の要望で認証を受ける製品グループ
　③脆弱性指摘があったら対応する製品グループ
　④脆弱性指摘があったら捨てる（販売中止・廃棄）製品グループ
　⑤自主的に販売中止・廃棄する製品グループ
が考えられる。
どの製品がどの対象になるかは、マーケティングの仕事になるであろうが、販売する先のユーザーの業界常識と個別のプロジェクトのユーザーの考え方で決まる。
これについても、制御ベンダが構成する団体とユーザーが構成する工業会団体が話し合ってガイドラインを出していくのも重要な仕事となってくるであろう。
次に行うのが、各グループ別の処理シナリオである。これは個別の製品の事情を抱えていることから、制御ベンダが個別に決めていくことになる。

（2）制御製品を支える高セキュア技術研究

それらの動きに並行して、高セキュア技術の研究がある。
サイバー攻撃の対応としては、侵入防止、侵入検知、感染を広げない、機能起動させない、消去という五つの切り口があるが、制御システムの場合はそれだけではない。

1. オペレーションプロテクト技術研究
   HMI（Human Machine Interface）のパスワードやID確認技術の研究
2. 高セキュアプログラム研究
   プログラムやファームウェアのサイバー攻撃されやすいコードを使用しないとか、攻撃されにくいプログラムの組み方を使用しているチップやハードウェア仕様依存部分を含めて研究しておく必要がある。
3. 通信スタックのセキュア化技術研究
   通信ドライバのプログラムだけでは限界があり、通信スタックそのものにセキュア対策が必要となる。
4. 侵入検知技術研究
   ネットワークがビジー状態にならないで、検知する技術
5. 感染が広がらない技術研究
   感染した制御製品がネットワークを離脱し、マニュアル操作できる範囲でオペレーションできて、他の制御製品に広がらない技術を確立できたら、評価が高い。
6. マルウェアの機能封じ込め防御研究
   マルウェアが侵入しても操業中は機能しないようにすれば、それを監視しながら次の点検時まで現状維持という選択肢もある。トリップが多大な損害を受けるプラントについては有効な技術でもある。
7. オンラインパッチ処理研究
   脆弱性を発見してバージョンアップする時に、自動運転を継続したままコントローラのバージョンアップができる技術研究。DCSのコントローラ製品では実現しているものもある。これをPLCにも採用していくことで、計装PLCの採用範囲にも要求が広がってくる。
8. メンテナンス時のクリーンアップ作業研究
   汚染した制御製品のクリーンアップ作業を短時間で処理したい。
9. 遠隔サービスのセキュア確保技術研究
   セキュリティを確保して、出荷した製品の遠隔サービスを実現する技術。今まで、VPNやSSLが大丈夫と言われたが、ICS-CERTの脆弱性レポートに、VPNであっても、SSLであっても、それだけではガードにならないという。それに、ブラックマーケットに攻撃ツールが乗って売買されると、それを利用して容易にVPNやSSLを破って攻撃されていることから、セキュリティの強化は遠隔サービスにも必要になっている。
10. 脆弱性確認ツールやその確認をするための環境整備に関するツール研究
    脆弱性確認をするのに、Fuzzingツールだけでなく、その制御性を確認するRobust-testツールも必要となり、制御製品にどこに脆弱性があるのかの調査を行っていくのに、セキュリティホールを追いかけていく時に使用するScanningツールが必要となり、FuzzingやRobustの影響度合いを診ていくのにEffectツールが必要となってくる。それらのツールを使用する際、開発していないインターフェースを製品に持っている場合は、そのツールも購入するか開発する必要がある。
11. インシデント対応時の製品仕様に関する研究
    ユーザーの現場でインシデントが発生した時の対応で重要なことは、現場ではセキュリティ問題であるかどうかの判断がとっさにできないということにある。異常警報が出るのが日常茶飯事の現場では、特に区別をつけるのに時間がかかる。この時のログデータ収集や取り出し、複数のログデータを突き合わせした時の時間経過における追跡調査作業などを考慮した時に、制御製品にどのような機能を搭載したら良いか？　また、どこまでの機能を搭載することが可能か？　という問題を抱える。

以上の強化項目に対して、既に存在しているモノや知見の範囲であるモノは、購入したり採用したりすれば良い。
ただ、これらの対応を施していくには、制御ベンダとして腹をくくった年度計画での投資を継続的にしていかなければならない。その範囲は、製品開発だけでなく、マーケティング、品質保証、生産環境、品質管理、部品調達など部門間の連携が必要な取り組みとなることから、経営オーナーレベルに制御製品に関するセキュリティ問題担当オーナーがいる方がスムースに実行できると思われる。

（3）（2）の解説と補足説明

PDF資料(P4)通信スタックにセキュア技術を盛り込んで、デバイスやコントローラのデータ取り合いレベルのSALレベルからMESのSALレベル、ERPのSALレベル、Cloud Server環境のSALレベルまで、異なるSALレベルをクリアする為に、しかもモデリング仕様対応で、オブジェクト思考での通信プロトコル対応仕様となると、OPC UAがOPC Foundationから出ている。OPC UAはIEC62541に登録されており、セキュリティ機能が無いリアルタイム制御で使用されるOPC Classic（-DA、-E&A、-HAD、-XML）に対して、リアルタイム制御からMESからERPからCloud Serverの環境まで使用できる高セキュア環境まで実現できる通信プロトコル仕様である。しかも、オブジェクト思考の情報連携環境に対応できる情報モデル仕様を採用していることから、通信プロトコルで扱う情報モデル構造の塊から新たなオブジェクト・アプリケーション用に情報データをピックアップして、情報モデルを再編成することが可能となっている。OPC UAでは通信データをリアルタイム制御で使用する最小単位のデータから、情報系で使用できる大型の情報モデルまで形成できる。それらを通信スタックからセキュリティガード技術を織り込んで、使用したいアプリケーションで欲しいKPIを出すことも可能にしてくれる通信プロトコルの仕様である。OPC UAを採用することで②の項目は、クリアできる可能性がある。


PDF資料(P5)通信スタックにセキュア技術を盛り込んで、デバイスやコントローラのデータ取り合いレベルのSALレベルからMESのSALレベル、ERPのSALレベル、Cloud Server環境のSALレベルまで、異なるSALレベルをクリアする為に、しかもモデリング仕様対応で、オブジェクト思考での通信プロトコル対応仕様となると、OPC UAがOPC Foundationから出ている。OPC UAはIEC62541に登録されており、セキュリティ機能が無いリアルタイム制御で使用されるOPC Classic（-DA、-E&A、-HAD、-XML）に対して、リアルタイム制御からMESからERPからCloud Serverの環境まで使用できる高セキュア環境まで実現できる通信プロトコル仕様である。しかも、オブジェクト思考の情報連携環境に対応できる情報モデル仕様を採用していることから、通信プロトコルで扱う情報モデル構造の塊から新たなオブジェクト・アプリケーション用に情報データをピックアップして、情報モデルを再編成することが可能となっている。OPC UAでは通信データをリアルタイム制御で使用する最小単位のデータから、情報系で使用できる大型の情報モデルまで形成できる。それらを通信スタックからセキュリティガード技術を織り込んで、使用したいアプリケーションで欲しいKPIを出すことも可能にしてくれる通信プロトコルの仕様である。OPC UAを採用することで②の項目は、クリアできる可能性がある。

また、高セキュアプログラム研究については、言語ベースで脆弱性を作り出してしまうプログラムコードやプログラム構成に気を付けることも大切であるが、OSやファームウェアベンダとの関係も重要になってくる。ICS-CERTから脆弱性のポイントとして指摘されることに、OSとのチューニング部分の脆弱性をつかれることがある。制御ベンダとしては「それはOSの問題です。」と言いたいであろうが、「製品として販売しているのはOS込みでしょう。」ということで、制御ベンダ製品の脆弱性として扱われる。つまり、制御ベンダとしてOSベンダに対して要求するべき問題であって修正して供給するべきであるという考えである。OSベンダに対して要求したが対応してくれないという問題については、「そのOSベンダ製品を採用したのは制御ベンダの責任でしょう。」ということになる。
侵入検知技術については、IDS（侵入検知システム）やIPS（防衛システム）を採用することも考えられるが、IDSやIPSと同じネットワークにつながったServerやOS製品は、ネットワークビジーか、フラグ処理の不完全処理などの要因で止まることがある。実際に制御システムや装置システムの構成で実証試験しながら結論を出していく必要がある。
マルウェア機能封じ込めについては、ホワイトリストを採用することで可能となってくるが、それだけで十分かどうかの確認が必要となる。Windowsに関するホワイトリスト機能は、マカフィーMacAfee社でツール販売しているが、Microsoft社の最新OSではホワイトリスト機能を使えるようにしたものも対応している。Windows以外のOSベンダにも、ホワイトリスト機能を要求するべきところには要求しなければならないだろうし、対応してくれないOSベンダ製品は、自社で改良しなければならなくなるであろう。 オンラインパッチ機能は、冗長化仕様を加工することで可能になる。


PDF資料(P6)PDF資料（P6）にあるように、通常の冗長化機能は、Ⅰのパターンとして、異常になったコントローラを外し、新しいコントローラのIPだけ合わせて異常になったコントローラの場所に挿入する。演算周期が一周すると、演算プログラム含めコピーする。同一性を確認したら、ホットスタンバイモードになって冗長化完了で異常警報を消す。この新しいコントローラにパッチを充てたプログラムもしくはハードウェアの状態で同じ操作をして冗長化完了プロセスが可能になるように、チェック内容を変えた仕様にする。そこまでお話すれば制御製品設計者であれば理解できるでしょう。

DCSやDDCのコントローラには、

• ビット（１ビット／２ビット）エラー修正機能
• I/O／通信チェック、各部分のパリティチェック
• プログラムチェック
• 演算データチェック
• （自動）バックアップ機能
• 冗長化機能
• コンフィギュレーションツールとのデータ認証機能
• 性能試験のやり方

PDF資料(P7)

PDF資料(P8)などがあるが、オンラインパッチ充てる機能を加えるとこれらの内容を見直して変わってくる部分が出てくる。また、PLCなどのコントローラにオンラインパッチ充て機能を加える場合もここに挙げた機能が揃っていないにしても、見直すことが出てくる。
SCADAの場合は、シンプル仕様のSCADA製品と冗長化仕様のSCADA製品に分かれる。冗長化仕様のSCADAにもHMI機能＋Server＋アプリケーション開発という構造で冗長化を実現しているSCADAと機能別にモジュール化した構造でモジュール単位での冗長化を実現しているSCADAがある。このSCADAでオンラインパッチ充て作業を実現するとなると、モジュール単位で冗長化したSCADAが実現可能に近い。

遠隔サービスのセキュア化については、装置や設備のリモートサービスでVPNやSSLを利用しているからセキュリティは大丈夫という考えは、今は通用しない。ICS-CERTの報告でもVPNやSSLだけの利用でなく、通信スタックや通信プロトコル、アプリケーションなどもセキュリティ対策を実施することを推奨している。通信で使用するIDにもIPv4ではなくIPv6を採用することでセキュリティレベルは上がる。通信スタックのセキュリティ対応を可能にしたIEC62541（OPC UA）を採用することでかなり高度なセキュリティレベルを確保することができる。
メンテナンス時のクリーンアップについては、制御ベンダに相談して制御製品そのもののクリーンアップ作業を実施していくことをお勧めする。制御ベンダも現場の制御製品にセットされたコンフィギュレーションやセイフティインターロックの設定内容を変えることなく制御製品のクリーンアップが可能になる制御製品の開発を推進していくべきである。また、制御ベンダは、制御製品のセキュリティメンテナンスのトレーニングやチュートリアルツールを作成し、ユーザーやシステムインテグレータや装置ベンダへの教育推進も重要なサービスビジネスと考えていくべき時代ではないだろうか。
脆弱性確認ツールとその環境については、制御製品のインターフェースやOSやミドルウェアの条件で、揃えていくしかない。制御製品の脆弱性確認ツールは、日本国内のセキュリティベンダが制御システムについての知識や認識が乏しく、調達そのものが不充分であることから、世界から調達することが必要となってくる。欧州のWIB認証機関やISA　Secure認証機関でも使用しているAchillesが有名であるが、それだけでは不十分であることから、シーメンスやシュナイダー、ABB、GE、エマーソン、ハネウェル、ロックウェルなどでは、セキュリティベンダに脆弱性確認ツールのドライバを発注して対応している。現在わかっているだけでも、

• Achilles：ネットワークスタックテストツール
• Nmpa：ポートスキャンニングツール
• Nessus：脆弱性スキャンニングツール
• Backtrack：ハッキングツール、ネットワークの通信プロトコルテストツール ＜取扱い要注意＞
• Metasploit：ハッキングツール、Unix／Linuxを対象とした専用ツール ＜取扱い要注意＞
• Sniffers ：ハッキングツール、ネットワークアナライザーツール ＜取扱い要注意＞
• MUSIC： MuDynamic社の Secure Industrial Control　ネットワークプロトコルを対象にしたツール

＜取扱い要注意＞：米国では、ハッキングツールやマルウェアを持っていることは、法に触れず、これを使用して犯罪を行うことが法に触れる。日本国内では、研究目的以外で、ハッキングツールやマルウェアを持っているだけで処罰対象になる。これは、銃刀所持と同じ扱いとみなされているので管理面の責任が発生すると考えておく方が良い。

インシデント発生時の対応については、オンコールで現場の情報をもとに、サポートセンター内で再現テストを実施して現場をサポートするオフサイト対応から、現場へ急行するオンサイト対応など、ユーザーとベンダとの基本契約をベースにして考えていく必要がある。しかし、その場合でも現場の異常時の制御システム製品やネットワークなどの情報が手元になければ、原因の追及のやりようが無い。そこで、異常発生時前後の各種ログデータは重要な情報となる。これらを取り込んでデータ凍結させる仕組みは不可欠である。現場の制御システムのどこにどのようなログ機能を、どの制御製品のどこにどのようなログ機能をと、インシデント対応作業を想定したログ機能の仕掛けそのものの設計も、制御ベンダにとってもエンジニアリングにとっても重要なことである。

（4）制御製品開発環境の見直し

セキュアな制御製品を開発するには、その開発環境も健全性を確保しなければならない。
次に、制御製品開発環境の健全性確保について、検討する対象項目をあげておくので、是非、検討していただきたい。

制御製品開発用ネットワークの隔離

• ファイヤーウォール設置
  注：ファイヤーウォールにも機能レベルがあるのとその設置場所で効果が出るものと出ないものがある。
• ネットワーク・ケーブルの仕分け
  - インターネット接続可能なネットワーク・ケーブル
  - インターネット接続不可能なネットワーク・ケーブル
  注：ケーブルの色分けをして管理がし易いようにすることと、ケーブルリストを作って管理することを当たり前にして、社員への躾も定期的に行うことが大切である。

セキュリティ確保、情報漏洩防止できる開発環境

注：入退出管理は当然であるが、アクセスできるServerの権限管理も重要である。また、パスワードは定期的に変更して、不審なアクセスを防ぐことも当たり前にしていくことが求められる。

サーバーとPCネットワークのセキュリティチェック管理責任者をおく

• ファイヤーウォールのDMZ ( De-Militarized Zone )
  - IDS：侵入検知システム (Intrusion Detection System)
  - IPS：侵入防止システム(IPS: Intrusion Prevention System)
  注：DMZのネットワーク内にあるServerなどに処理時間が長いアプリケーションが存在するとIDSやIPSの割り込みなどで停止することがある。DMZネットワーク内のServerはデータや情報の出入り処理の処理時間が短いプログラムだけにして、ホワイトリスト起動を基本にしておくと良い。

チェックできる環境整備

• 
  PDF資料(P9)環境整備計画
  - 対象製品の選定
  - 製品の重要性と事業性との確認
  - 規模計画
  - 投資金額設定
  - 費用回収計画
  - 運営方法
• 環境整備
  - 自社製品以外の環境構築
  - ３Dシミュレーションの活用認
  - エミュレータ
  - 必要とされるツール類
  　・Fuzz（評価）ツール
  　・Robustness（評価）ツール
  　・Scanning（追跡・監視）ツール
  　・Exploit（影響確認）ツール

（5）製品開発の基礎知見の構築

PDF資料(P10)製品開発していくステップで、評価ツールを使用して得た情報をデータベース化して、知見内容の向上を図っていくことは、企業力を考える際、基礎開発力及び人材育成の上で重要な企業活動となってくる。特に、セキュア技術の知見情報構築は、企業の生命線になる技術といっても過言ではないと考える。その重要性を考えて、自己認証も視野に入れ、ユーザーへの人材教育サービスとして取り扱いトレーニングに反映させるなどして、自社の制御システムセキュリティセンターを創設する企業も出てきている。

（6）制御ベンダの品質保証環境について

セキュリティ対策強化の対象は、制御製品の開発だけではない。当然、開発した製品を出荷するのであるから、品質保証も制御システムセキュリティ対応レベルを一定に維持することが必要となる。

製品開発の品質管理に求めること

• セキュア知識を持って製品開発における品質保証管理を行う
  - ISO／IEC6１508と同等の位置付け
  - IEC62443を熟読　⇒　認識を高める

品質保証全般のテストにセキュリティ問題を加える

• デザインレビュー項目に制御システムセキュリティ対策を加える
  - セキュア知識を持ったソースコード解析や脆弱性の洗い出し
  - 脆弱性情報・対策の履歴管理

サイバー攻撃を想定した品質検査

• バリデーション
  - 適合性確認
  - 妥当性確認
  - 外注のセキュリティ対策管理

ユーザーに対しての責任

• ユーザーへの脆弱性情報と対策情報の公開
• 取り扱いガイドラインに、制御システムセキュリティ対策を加える

PDF資料(P11)　 PDF資料(P12)

PDF資料(P13)

4．まとめ

ここでは、制御ベンダの取り組みについて書いているが、装置ベンダや設備ベンダにとっても、これを参考にして取り組んでいってもらいたい。また、装置ベンダや機械ベンダにとっては機械安全と制御システムセキュリティとの関係、システムエンジニアにとっては機能安全と制御システムセキュリティとの関係を安全本質の考え方で検討し、方針を決め、対応していく必要が考えられる。それについては、次回の号で述べてみたい。