制御システムセキュリティに関する深刻な事件発生

2017年12月14日に中近東のSchneider Electricの安全計装コントローラ「Triconex」を標的にしたサイバー攻撃があり、プラントが停止したことをFireEyeが公開報告した。ハッカーは、「Triconex」のエンジニアリングツールにアクセスして、非公開の専用通信プロトコルを利用してコントローラの設定を変更しようとしたところ、手違いで「Triconex」を動作させてしまい、プラント停止に至らせたとのこと。

FireEyeの報告では、ハッカーは物理的損害を与えるつもりで工作してきたとあるが、今回のように非公開の専用通信プロトコルを利用してプラントを停止させることができれば、事業を止められることが実証されてしまった。

今回の事例からわかる問題として、
・悪意を持って安全計装コントローラをリモート操作されるリスクを許していること
・エンジニアリングツールが常時安全計装コントローラにつながっていることで起きるリスクを考慮していないこと
・安全計装コントローラにプログラム書き換えのインシデント検知機能がないこと
・システム設計の構造上のサイバーリスクを考慮していないこと
などがあげられる。

＜考察＞
安全計装システムを監視する為に安全計装システムのEWSを計装制御システムのEWSと同じネットワークに配置したり、一つのEWSで見ることができるようにしたりするソリューションを提案している制御ベンダがある。また、安全計装システムの面倒を制御ベンダに任せるサービスを受けるためにEWSにインターネットを利用したリモートサービスシステムにつなげるソリューションサービスを提供している制御ベンダがある。
IoT時代に対応して、安全計装のEWS作業をリモートで監視できるソリューションをビジネスにしているソリューションベンダがいる。
そこにセイフティ＆サイバーリスクアセスメントが実施されていれば、可用性より安全性が優先することが解る。欧米のソリューションが正しいという観念でソリューションを丸呑みしている未熟な技術者はいないと思うが、セイフティ＆サイバーセキュリティリスクアセスメントを正しく学ぶことが日本の重要インフラ業界での技術伝承として大切なことだと思います。

昨年末より、インテルやAMDなどのCPU・MPUハードウェアに深刻な脆弱性が三つ発見されたことで、インターネットにつながるICT機器やServerやシステムが新たなサイバー脅威に置かれています。この対策としてOSメーカーやデバイスメーカーが対策を講じるべく動いております。

Vulnerability Note VU#584653
CPU hardware vulnerable to side-channel attacks
Original Release date: 03 Jan 2018 | Last revised: 05 Jan 2018

詳細は、こちらをご覧ください。（正確な解釈は英語Webサイトで確認してください。）
https://www.kb.cert.org/vuls/id/584653

複数のCPUの処理は、アプリケーションの動きを良くするためにプロセスを順次複数のCPUを管理して先行処理する分岐予測機能を持っています。その分岐予測機能のプロセス管理機能が、スペクター（Specter）やメルトダウン（Meltdown）と呼ばれる横からの攻撃に対して脆弱であることが発見されました。

スペクターとメルトダウンは、CPU キャッシュで実行されている命令情報を横から抽出したり注入したりする機能を有しています。
•Variant 1 (CVE-2017-5753, Specter): Bounds check bypass
•Variant 2 (CVE-2017-5715, also Specter): Branch target injection
•Variant 3 (CVE-2017-5754, Meltdown): Rogue data cache load, memory access permission check performed after kernel memory read

SpecterとMeltdownの詳細説明は、以下の通りです。

スペクター（Specter）
スペクター攻撃は、CPU の分岐予測機能を利用しています。最新の CPU にはブランチ予測と呼ばれる機能が含まれており、予測先行処理（注1）で CPU が分岐すると考えている場所で命令を実行します。このような予測先行処理実行により、個々のCPUを効率的に活用し、CPUの待機時間を最小化し、パフォーマンスを向上させることができます。分岐が正常に予測されると、命令は役目を終え、レジスタやメモリ書き込みなどの命令の結果がコミットされます。この分岐が誤って予測された場合、予測先行処理によって実行される命令は破棄され、指示の直接的な影響は元に戻されます。元に戻されないものは、CPU キャッシュの変更などの間接的な副作用が出たりします。
スペクターバリアント 1 (CVE-2017-5753) では、条件分岐の後の命令は、予測の結果として予測先行処理実行されます。スペクターバリアント 2 (CVE-2017-5715) では、誤って予測される分岐ターゲットによって決定されたところでの命令実行となります。
スペクター攻撃の両方の亜種では、プロセスがシステム上の他のプロセスに機密データをリークすることがあります。また、アプリケーションの一部が、異なるところで許可されない同じプロセスメモリ領域の他の部分にアクセスさせることもできます。

メルトダウン（Meltdown）
メルトダウンは、予定されていない別のデータにアクセスするためにキャッシュ側のチャネルを使用しているということでスペクター攻撃とは違って、CPUのアウトオブオーダーの実行機能を利用しています。
CPU のアウトオブオーダー実行は、分岐予測による予測先行処理の実行と同様にCPU を最大限に活用するための技術です。
通常、CPUの命令は機械語で順次実行されますが、順序外実行をサポートする CPU は命令を非シーケンシャルに実行することがあり、CPU がアイドル状態になる時間を最小限に抑えることができます。
メルトダウンは、Intel の CPU で実行された安全でない動作の影響で、バスやネットワークでつながった他のベンダの CPU に影響を与える可能性があります。メルトダウン攻撃はカーネルメモリ値を読み取り、ユーザー空間特権で実行されているコードはカーネルメモリを直接読み取ることができないため、例外を発生させることができます。ただし、競合状態になることで、障害が発生した命令に続く順序外命令も実行されることがあります。
一つの命令実行後に別の命令が実行されたとしても、順序外の実行では、例外を発生する命令から取得したデータを使用して実行することがあります。例外が発生するまでに、いくつかの注文命令が実行されます。すると、発生した例外によって、CPU は順序外命令をロールバックしますが、キャッシュの状態は元に戻りません。これにより、例外が発生したときに、アウトオブオーダー命令のデータがポイントを超えて保持されるようになります。（この状態は異常です。）
メルトダウンの影響は、ユーザー空間で実行されているプロセスがカーネルメモリの内容を表示できることです。メルトダウンによって、ユーザー/カーネル特権の境界を越えることのないスペクターのようなメモリコンテンツが漏洩する可能性もあります。
メルトダウンのための Linux カーネルの緩和策は、カイザーと呼ばれ、その後 KPTI、カーネルとユーザーのメモリページの分離を改善する方法があります。スペクター攻撃はユーザー/カーネルの境界を越えないので、カイザー/KPTI で導入された保護は、それらに対して一切の防御効果はありません。

影響（Impact）
・メルトダウン攻撃により、ユーザーのペースからカーネルメモリを読み取ることができます。これにより、特権のエスカレーション、機密情報の漏えい、または KASLR などのカーネルレベルの保護を弱めることができます。
・スペクター攻撃は、プロセス間またはプロセス内のデータ漏洩を可能にします。
コードをローカルで実行するには、攻撃者がターゲットの有効なアカウントまたは独立した侵害を可能にします。
・Web ブラウザ(インターネット接続は全て)で JavaScript を使用する攻撃が可能です。
・マルチユーザおよびマルチテナントシステムは、最大のリスクに直面する可能性があります。つながるそれぞれのCPUベンダ製品の脆弱性におけるリスクを合わせ持つことになります。
・ハードウェアの脆弱性ですから、どのシステムやデバイスであっても、任意の Web サイトを参照する時、危険にさらされていることになります。
・攻撃者がコードを容易に実行できない閉域網つながりのシステムは、リスクを大幅に軽減できます。
・MicrosoftなどOSを販売しているベンダはアップデート対応をしなければ市場を失うことになるでしょうが、オープンOSであるLinuxについては、Linuxを製品と一緒に提供している各ベンダが対応しなければ誰も対応責任を持たないで放置されると思われます。
・ICT機器で、複数のプロセッサを抱えたCPUで処理の予測先行処理のスケジュールを採用しているものについては、同じ脆弱性を持っている可能性があります。
・制御製品で該当するCPUを採用しているもの、もしくは該当するハードウェアに制御製品を搭載して使用しているものについては対策が必要であることを確認して対処方法を顧客へ提示する必要があると思います。

＜ソリューション＞
根本的対策はセキュア改善されたハードウェアへの交換ですが、ハードウェアの交換を一度に実施することは難しいので、更新プログラムの適用で対応することになります。
オペレーティングシステムと一部のアプリケーションの更新により、これらの攻撃が軽減されます。

対象ベンダ：AMD、Apple、Arm、Google、Intel、Linux Kernel、Microsoft、Mozila
（対象ベンダは、今後も増えると思われます。）

注1：speculatively executes通常の和訳では「投機的実行」と訳しますが、ここではCPUの動作特徴を捉えて「予測先行処理」と訳しております。

＜考察＞
サイバー攻撃によって起き得る現象は、情報の搾取だけでなく、プログラムの準備条件成立を遅らせたり、不成立にさせたりして新たな脆弱性を創り出すことも可能となります。また、予測先行処理のスケジュールを削除することで機能停止させることも可能となります。予測先行処理のスケジュールを書き換えることで別のアプリケーションを起動させることも可能となります。
対策済みのハードウェアがリリースされて現場に配置できるのは時間を要するし、大きな投資になってしまいます。その為、制御システム設備での対応は、OSのアップデートで対処するサイバーセキュリティ対策や制御システムセキュリティ対策技術でカバーしていくことが今まで以上に重要となっている。装置や機械やロボットなどにおいては、今まで以上に脆弱性対策が重要となってきます。（対策技術はICS研究所のeICS講座で解説）
IoT新時代にインターネット接続でリモートサービスシステムや遠隔監視システムなどは設備側やシステムネットワークに繋がるデバイスの対処が急務と思われる。プライベートクラウドを利用した閉域網のシステムでは、そのリスクは軽減できます。（Industry4.1Jソリューション）
会社業務で使用している機器のOSのアップデートもそうですが、設備機器のメンテナンス用に管理しているPCやデバイスのアップデート管理の徹底をお忘れなく。また、その為の機器管理リストにOSやアプリケーションのアップデート情報や脆弱性情報の管理項目を追加することもお忘れなく。

コンピュータメーカー製品や、制御ベンダの制御製品などコンピュータを使用しているメーカーにとって脆弱性対策と顧客への脆弱性情報（サイバーリスク情報）提供を実施していくべき深刻な問題でありますが、その対応情報がICS-CERTのAlert情報にアップされました。米国におけるNISTのWebサイトにも家電や携帯電話やスマートデバイスの対象製品のメーカーからの情報公開及びアップデート案内情報がまとめてアップされております。制御ベンダからの対応案内もアップされております。使用している制御製品に対処が必要か否かの情報提供は重要になっております。対処が必要であれば計画的な対応を実施していくことになると思われます。

Alert (ICS-ALERT-18-011-01)
Meltdown and Spectre Vulnerabilities
Original release date: January 11, 2018
https://ics-cert.us-cert.gov/alerts/ICS-ALERT-18-011-01

Spectre1，2、とMeltdownの対象製品のパッチ及びアップデートの情報サイトをNISTがWebに公開されております。

CVE-2017-5753, CVE-2017-5715, and CVE-2017-5754 have been assigned to these vulnerabilities.
CVE-2017-5753 Spectre1の対象製品のNIST情報サイト
https://nvd.nist.gov/vuln/detail/CVE-2017-5753

CVE-2017-5754 Meltdownの対象製品のNIST情報サイト
https://nvd.nist.gov/vuln/detail/CVE-2017-5754

CVE-2017-5715 Spectre2の対象製品のNIST情報サイト
https://nvd.nist.gov/vuln/detail/CVE-2017-5715

各制御ベンダからも対処の案内が出ています。

情報公開している制御ベンダの情報

・ABB:
http://search-ext.abb.com/library/Download.aspx?DocumentID=9AKK107045A8219&LanguageCode=en&DocumentPartId=&Action=Launch (link is external)

・Becton, Dickinson and Company (BD):
http://www.BD.com/productsecurity (link is external)

・Rockwell Automation (account required for login):
https://rockwellautomation.custhelp.com/app/answers/detail/a_id/1070884 (link is external)

・Siemens:
https://www.siemens.com/cert/pool/cert/siemens_security_bulletin_ssb-068644.pdf

＜考察＞
対処が必要な制御製品を持つ制御ベンダに求められることをあげておきます。（あくまでも参考です。）
対処が必要な制御製品を使用している制御装置ベンダや機械ベンダは同じく顧客への情報公開が必要になってくるのではないでしょうか。

ハードウェアの制御製品ベンダが顧客に提供しなければならない情報としては、
・ハードウェアに採用しているCPUにSpectreやMeltdownと同じ脆弱性があるか否か？
・想定されるサイバーリスク情報
・ソフトウェアのアップデートが必要かどうか？
・メーカーでのアップデート作業が必要かどうか？
・問い合わせ先情報

ソフトウェアの制御製品を提供しているベンダ
・使用するハードウェアに対してアップデート対応が必要か否か？
・想定されるサイバーリスク情報
・使用するハードウェアのOSのアップデート対応でソフト製品でのアップデートが必要かどうかの情報
・問い合わせ先情報
など

OPCサーバーを利用している制御システムは多いが、OPC DAやOPC E＆A、OPC HADなどのOPC ClassicはD-COMの脆弱性があるために、セキュリティ性能や機能が高いOPC UAへ移行する方針を出しているところがほとんどである。
確かに、欧米でのIndustry4.0やIICでも通信仕様はOPC UAだけであるし、サプライチェーンのSAPもIBMでも、OPC UAインターフェースを用意しており、接続性が高くなっている。

しかし、OPC UAだから大丈夫という訳ではない。サーバーやクライアントのOSやBIOSやドライバやアプリケーションの脆弱性が無いことが制御システムの安全を確保することになる。さらに、ハードウェアの脆弱性をついたマルウェアにも対策が必要になってくる。
個々の脆弱性については発見されたら、改善作業を計画的に進めれば良いが、もっとサイバー攻撃に強い制御システム設計や制御製品ができれば、現場の制御システムセキュリティ管理も容易になってくる。

経済産業省から「サイバーセキュリティ経営ガイドラインV2.0」が出ております。
サイバーセキュリティリスクに対する経営認識を深めることと扱い方についてまとめております。
http://www.meti.go.jp/policy/netsecurity/mng_guide.html

内閣サイバーセキュリティセンターNISCからも「リスクアセスメントガイドライン」を公示するべく準備しているようです。

特に重要インフラや製造業や公共施設などの制御システムセキュリティ対策技術は、サイバー攻撃に強い制御製品で制御システムを設計していくことが求められる訳ですが、その研究をテーマに対策技術をまとめているICS研究所のeICSの受講をお勧めします。
特に、eICS受講＋順次開催しているICS研究所の研修をセットにして受講するとさらに良く理解できます。

https://www.ics-lab.com/e/
社内手続きで見積書が必要であれば、「見積書請求」からお申し込みください。