[{"data":1,"prerenderedAt":51},["ShallowReactive",2],{"journal-detail-19":3},{"main":4,"content":12,"author":46},{"id":5,"level":6,"level_name":7,"title":8,"summary":7,"body":9,"author":10,"created_time":11,"edited_time":11},346,0,"","制御システムセキュリティに関する深刻な事件発生","2017年12月14日には安全計装システムの基本設計の考え方に関するサイバー事件が、2018年1月5日にはコンピュータのCPUハードウェアの深刻な脆弱性情報が報告されております。\n\n制御システムを構成する制御製品まで拡がった深刻な問題であるため、今回記事としました。これらの問題の深刻さはサイバーリスクアセスメントを理解している方には、ご理解いただけると思います。また、もっと詳しく理解出来るようになりたいという方は、ICS研究所の研修を受講されることをお勧めします。","murakami","2018-01-17 03:04:00",[13,18,21,26,29,33,38,42],{"id":14,"heading":15,"summary":7,"body":16,"gallery":17},347,"1．安全計装システムを標的にしたサイバー攻撃事件「Triton」","2017年12月14日に中近東のSchneider Electricの安全計装コントローラ「Triconex」を標的にしたサイバー攻撃があり、プラントが停止したことをFireEyeが公開報告した。ハッカーは、「Triconex」のエンジニアリングツールにアクセスして、非公開の専用通信プロトコルを利用してコントローラの設定を変更しようとしたところ、手違いで「Triconex」を動作させてしまい、プラント停止に至らせたとのこと。\n\nFireEyeの報告では、ハッカーは物理的損害を与えるつもりで工作してきたとあるが、今回のように非公開の専用通信プロトコルを利用してプラントを停止させることができれば、事業を止められることが実証されてしまった。\n\n今回の事例からわかる問題として、\n・悪意を持って安全計装コントローラをリモート操作されるリスクを許していること\n・エンジニアリングツールが常時安全計装コントローラにつながっていることで起きるリスクを考慮していないこと\n・安全計装コントローラにプログラム書き換えのインシデント検知機能がないこと\n・システム設計の構造上のサイバーリスクを考慮していないこと\nなどがあげられる。","image1.jpg",{"id":19,"heading":7,"summary":7,"body":20,"gallery":7},348,"\u003Cstrong class=\"tx-orange\">＜考察＞\u003C/strong>\n安全計装システムを監視する為に安全計装システムのEWSを計装制御システムのEWSと同じネットワークに配置したり、一つのEWSで見ることができるようにしたりするソリューションを提案している制御ベンダがある。また、安全計装システムの面倒を制御ベンダに任せるサービスを受けるためにEWSにインターネットを利用したリモートサービスシステムにつなげるソリューションサービスを提供している制御ベンダがある。\nIoT時代に対応して、安全計装のEWS作業をリモートで監視できるソリューションをビジネスにしているソリューションベンダがいる。\nそこにセイフティ＆サイバーリスクアセスメントが実施されていれば、可用性より安全性が優先することが解る。欧米のソリューションが正しいという観念でソリューションを丸呑みしている未熟な技術者はいないと思うが、セイフティ＆サイバーセキュリティリスクアセスメントを正しく学ぶことが日本の重要インフラ業界での技術伝承として大切なことだと思います。",{"id":22,"heading":23,"summary":7,"body":24,"gallery":25},349,"2．CPUハードウェアに関する深刻な脆弱性問題","昨年末より、インテルやAMDなどのCPU・MPUハードウェアに深刻な脆弱性が三つ発見されたことで、インターネットにつながるICT機器やServerやシステムが新たなサイバー脅威に置かれています。この対策としてOSメーカーやデバイスメーカーが対策を講じるべく動いております。\n\nVulnerability Note VU#584653\nCPU hardware vulnerable to side-channel attacks\nOriginal Release date: 03 Jan 2018 | Last revised: 05 Jan 2018\n\n詳細は、こちらをご覧ください。（正確な解釈は英語Webサイトで確認してください。）\n\u003Ca href=\"https://www.kb.cert.org/vuls/id/584653\" target=\"_blank\">https://www.kb.cert.org/vuls/id/584653\u003C/a>\n\n複数のCPUの処理は、アプリケーションの動きを良くするためにプロセスを順次複数のCPUを管理して先行処理する分岐予測機能を持っています。その分岐予測機能のプロセス管理機能が、スペクター（Specter）やメルトダウン（Meltdown）と呼ばれる横からの攻撃に対して脆弱であることが発見されました。\n\nスペクターとメルトダウンは、CPU キャッシュで実行されている命令情報を横から抽出したり注入したりする機能を有しています。\n•Variant 1 (CVE-2017-5753, Specter): Bounds check bypass\n•Variant 2 (CVE-2017-5715, also Specter): Branch target injection\n•Variant 3 (CVE-2017-5754, Meltdown): Rogue data cache load, memory access permission check performed after kernel memory read","image2.jpg",{"id":27,"heading":7,"summary":7,"body":28,"gallery":7},350,"SpecterとMeltdownの詳細説明は、以下の通りです。\n\n\u003Cstrong class=\"tx-blue\">スペクター（Specter）\u003C/strong>\nスペクター攻撃は、CPU の分岐予測機能を利用しています。最新の CPU にはブランチ予測と呼ばれる機能が含まれており、予測先行処理\u003Csup>（注1）\u003C/sup>で CPU が分岐すると考えている場所で命令を実行します。このような予測先行処理実行により、個々のCPUを効率的に活用し、CPUの待機時間を最小化し、パフォーマンスを向上させることができます。分岐が正常に予測されると、命令は役目を終え、レジスタやメモリ書き込みなどの命令の結果がコミットされます。この分岐が誤って予測された場合、予測先行処理によって実行される命令は破棄され、指示の直接的な影響は元に戻されます。元に戻されないものは、CPU キャッシュの変更などの間接的な副作用が出たりします。\n スペクターバリアント 1 (CVE-2017-5753) では、条件分岐の後の命令は、予測の結果として予測先行処理実行されます。スペクターバリアント 2 (CVE-2017-5715) では、誤って予測される分岐ターゲットによって決定されたところでの命令実行となります。\n スペクター攻撃の両方の亜種では、プロセスがシステム上の他のプロセスに機密データをリークすることがあります。また、アプリケーションの一部が、異なるところで許可されない同じプロセスメモリ領域の他の部分にアクセスさせることもできます。\n\n\u003Cstrong class=\"tx-blue\">メルトダウン（Meltdown）\u003C/strong>\nメルトダウンは、予定されていない別のデータにアクセスするためにキャッシュ側のチャネルを使用しているということでスペクター攻撃とは違って、CPUのアウトオブオーダーの実行機能を利用しています。\nCPU のアウトオブオーダー実行は、分岐予測による予測先行処理の実行と同様にCPU を最大限に活用するための技術です。\n通常、CPUの命令は機械語で順次実行されますが、順序外実行をサポートする CPU は命令を非シーケンシャルに実行することがあり、CPU がアイドル状態になる時間を最小限に抑えることができます。\n メルトダウンは、Intel の CPU で実行された安全でない動作の影響で、バスやネットワークでつながった他のベンダの CPU に影響を与える可能性があります。メルトダウン攻撃はカーネルメモリ値を読み取り、ユーザー空間特権で実行されているコードはカーネルメモリを直接読み取ることができないため、例外を発生させることができます。ただし、競合状態になることで、障害が発生した命令に続く順序外命令も実行されることがあります。\n一つの命令実行後に別の命令が実行されたとしても、順序外の実行では、例外を発生する命令から取得したデータを使用して実行することがあります。例外が発生するまでに、いくつかの注文命令が実行されます。すると、発生した例外によって、CPU は順序外命令をロールバックしますが、キャッシュの状態は元に戻りません。これにより、例外が発生したときに、アウトオブオーダー命令のデータがポイントを超えて保持されるようになります。（この状態は異常です。）\n メルトダウンの影響は、ユーザー空間で実行されているプロセスがカーネルメモリの内容を表示できることです。メルトダウンによって、ユーザー/カーネル特権の境界を越えることのないスペクターのようなメモリコンテンツが漏洩する可能性もあります。\n メルトダウンのための Linux カーネルの緩和策は、カイザーと呼ばれ、その後 KPTI、カーネルとユーザーのメモリページの分離を改善する方法があります。スペクター攻撃はユーザー/カーネルの境界を越えないので、カイザー/KPTI で導入された保護は、それらに対して一切の防御効果はありません。\n\n\u003Cstrong class=\"tx-blue\">影響（Impact）\u003C/strong>\n・メルトダウン攻撃により、ユーザーのペースからカーネルメモリを読み取ることができます。これにより、特権のエスカレーション、機密情報の漏えい、または KASLR などのカーネルレベルの保護を弱めることができます。\n・スペクター攻撃は、プロセス間またはプロセス内のデータ漏洩を可能にします。\nコードをローカルで実行するには、攻撃者がターゲットの有効なアカウントまたは独立した侵害を可能にします。\n・Web ブラウザ(インターネット接続は全て)で JavaScript を使用する攻撃が可能です。\n・マルチユーザおよびマルチテナントシステムは、最大のリスクに直面する可能性があります。つながるそれぞれのCPUベンダ製品の脆弱性におけるリスクを合わせ持つことになります。\n・ハードウェアの脆弱性ですから、どのシステムやデバイスであっても、任意の Web サイトを参照する時、危険にさらされていることになります。\n・攻撃者がコードを容易に実行できない閉域網つながりのシステムは、リスクを大幅に軽減できます。\n・MicrosoftなどOSを販売しているベンダはアップデート対応をしなければ市場を失うことになるでしょうが、オープンOSであるLinuxについては、Linuxを製品と一緒に提供している各ベンダが対応しなければ誰も対応責任を持たないで放置されると思われます。\n・ICT機器で、複数のプロセッサを抱えたCPUで処理の予測先行処理のスケジュールを採用しているものについては、同じ脆弱性を持っている可能性があります。\n・制御製品で該当するCPUを採用しているもの、もしくは該当するハードウェアに制御製品を搭載して使用しているものについては対策が必要であることを確認して対処方法を顧客へ提示する必要があると思います。\n\n\u003Cstrong class=\"tx-orange\">＜ソリューション＞\u003C/strong>\n根本的対策はセキュア改善されたハードウェアへの交換ですが、ハードウェアの交換を一度に実施することは難しいので、更新プログラムの適用で対応することになります。\nオペレーティングシステムと一部のアプリケーションの更新により、これらの攻撃が軽減されます。\n\n対象ベンダ：AMD、Apple、Arm、Google、Intel、Linux Kernel、Microsoft、Mozila\n（対象ベンダは、今後も増えると思われます。）\n\n\u003Csmall>注1：speculatively executes通常の和訳では「投機的実行」と訳しますが、ここではCPUの動作特徴を捉えて「予測先行処理」と訳しております。\u003C/small>\n\n\u003Cstrong class=\"tx-orange\">＜考察＞\u003C/strong>\nサイバー攻撃によって起き得る現象は、情報の搾取だけでなく、プログラムの準備条件成立を遅らせたり、不成立にさせたりして新たな脆弱性を創り出すことも可能となります。また、予測先行処理のスケジュールを削除することで機能停止させることも可能となります。予測先行処理のスケジュールを書き換えることで別のアプリケーションを起動させることも可能となります。\n対策済みのハードウェアがリリースされて現場に配置できるのは時間を要するし、大きな投資になってしまいます。その為、制御システム設備での対応は、OSのアップデートで対処するサイバーセキュリティ対策や制御システムセキュリティ対策技術でカバーしていくことが今まで以上に重要となっている。装置や機械やロボットなどにおいては、今まで以上に脆弱性対策が重要となってきます。（対策技術はICS研究所のeICS講座で解説）\nIoT新時代にインターネット接続でリモートサービスシステムや遠隔監視システムなどは設備側やシステムネットワークに繋がるデバイスの対処が急務と思われる。プライベートクラウドを利用した閉域網のシステムでは、そのリスクは軽減できます。（Industry4.1Jソリューション）\n会社業務で使用している機器のOSのアップデートもそうですが、設備機器のメンテナンス用に管理しているPCやデバイスのアップデート管理の徹底をお忘れなく。また、その為の機器管理リストにOSやアプリケーションのアップデート情報や脆弱性情報の管理項目を追加することもお忘れなく。",{"id":30,"heading":31,"summary":7,"body":32,"gallery":7},351,"3．CPUハードウェアに関する深刻な脆弱性問題のICS-CERT及びNIST情報","コンピュータメーカー製品や、制御ベンダの制御製品などコンピュータを使用しているメーカーにとって脆弱性対策と顧客への脆弱性情報（サイバーリスク情報）提供を実施していくべき深刻な問題でありますが、その対応情報がICS-CERTのAlert情報にアップされました。米国におけるNISTのWebサイトにも家電や携帯電話やスマートデバイスの対象製品のメーカーからの情報公開及びアップデート案内情報がまとめてアップされております。制御ベンダからの対応案内もアップされております。使用している制御製品に対処が必要か否かの情報提供は重要になっております。対処が必要であれば計画的な対応を実施していくことになると思われます。\n\nAlert (ICS-ALERT-18-011-01)\nMeltdown and Spectre Vulnerabilities\nOriginal release date: January 11, 2018\n\u003Ca href=\"https://ics-cert.us-cert.gov/alerts/ICS-ALERT-18-011-01\" target=\"_blank\">https://ics-cert.us-cert.gov/alerts/ICS-ALERT-18-011-01\u003C/a>\n\nSpectre1，2、とMeltdownの対象製品のパッチ及びアップデートの情報サイトをNISTがWebに公開されております。\n\nCVE-2017-5753, CVE-2017-5715, and CVE-2017-5754 have been assigned to these vulnerabilities.\nCVE-2017-5753 Spectre1の対象製品のNIST情報サイト\n\u003Ca href=\"https://nvd.nist.gov/vuln/detail/CVE-2017-5753\" target=\"_blank\">https://nvd.nist.gov/vuln/detail/CVE-2017-5753\u003C/a>\n\nCVE-2017-5754 Meltdownの対象製品のNIST情報サイト\n\u003Ca href=\"https://nvd.nist.gov/vuln/detail/CVE-2017-5754\" target=\"_blank\">https://nvd.nist.gov/vuln/detail/CVE-2017-5754\u003C/a>\n\nCVE-2017-5715 Spectre2の対象製品のNIST情報サイト\n\u003Ca href=\"https://nvd.nist.gov/vuln/detail/CVE-2017-5715\" target=\"_blank\">https://nvd.nist.gov/vuln/detail/CVE-2017-5715\u003C/a>\n\n各制御ベンダからも対処の案内が出ています。\n\n\u003Cstrong>情報公開している制御ベンダの情報\u003C/strong>\n\n・ABB:\n\u003Ca href=\"http://search-ext.abb.com/library/Download.aspx?DocumentID=9AKK107045A8219&LanguageCode=en&DocumentPartId=&Action=Launch\" target=\"_blank\">http://search-ext.abb.com/library/Download.aspx?DocumentID=9AKK107045A8219&LanguageCode=en&DocumentPartId=&Action=Launch (link is external)\u003C/a>\n\n・Becton, Dickinson and Company (BD):\n\u003Ca href=\"http://www.BD.com/productsecurity\" target=\"_blank\">http://www.BD.com/productsecurity (link is external)\u003C/a>\n\n・Rockwell Automation (account required for login):\n\u003Ca href=\"https://rockwellautomation.custhelp.com/app/answers/detail/a_id/1070884\" target=\"_blank\">https://rockwellautomation.custhelp.com/app/answers/detail/a_id/1070884 (link is external)\u003C/a>\n\n・Siemens:\n\u003Ca href=\"https://www.siemens.com/cert/pool/cert/siemens_security_bulletin_ssb-068644.pdf\" target=\"_blank\">https://www.siemens.com/cert/pool/cert/siemens_security_bulletin_ssb-068644.pdf\u003C/a>\n\n\u003Cstrong class=\"tx-orange\">＜考察＞\u003C/strong>\n対処が必要な制御製品を持つ制御ベンダに求められることをあげておきます。（あくまでも参考です。）\n対処が必要な制御製品を使用している制御装置ベンダや機械ベンダは同じく顧客への情報公開が必要になってくるのではないでしょうか。\n\n\u003Cstrong>ハードウェアの制御製品ベンダが顧客に提供しなければならない情報としては、\u003C/strong>\n・ハードウェアに採用しているCPUにSpectreやMeltdownと同じ脆弱性があるか否か？\n・想定されるサイバーリスク情報\n・ソフトウェアのアップデートが必要かどうか？\n・メーカーでのアップデート作業が必要かどうか？\n・問い合わせ先情報\n\n\u003Cstrong>ソフトウェアの制御製品を提供しているベンダ\u003C/strong>\n・使用するハードウェアに対してアップデート対応が必要か否か？\n・想定されるサイバーリスク情報\n・使用するハードウェアのOSのアップデート対応でソフト製品でのアップデートが必要かどうかの情報\n・問い合わせ先情報\nなど",{"id":34,"heading":35,"summary":7,"body":36,"gallery":37},352,"4．OPC UAを使っているから大丈夫というものではない","OPCサーバーを利用している制御システムは多いが、OPC DAやOPC E＆A、OPC HADなどのOPC ClassicはD-COMの脆弱性があるために、セキュリティ性能や機能が高いOPC UAへ移行する方針を出しているところがほとんどである。\n確かに、欧米でのIndustry4.0やIICでも通信仕様はOPC UAだけであるし、サプライチェーンのSAPもIBMでも、OPC UAインターフェースを用意しており、接続性が高くなっている。\n\nしかし、OPC UAだから大丈夫という訳ではない。サーバーやクライアントのOSやBIOSやドライバやアプリケーションの脆弱性が無いことが制御システムの安全を確保することになる。さらに、ハードウェアの脆弱性をついたマルウェアにも対策が必要になってくる。\n個々の脆弱性については発見されたら、改善作業を計画的に進めれば良いが、もっとサイバー攻撃に強い制御システム設計や制御製品ができれば、現場の制御システムセキュリティ管理も容易になってくる。","image3.jpg",{"id":39,"heading":40,"summary":7,"body":41,"gallery":7},353,"5．サイバーリスクアセスメントを学ぶには","経済産業省から「サイバーセキュリティ経営ガイドラインV2.0」が出ております。\nサイバーセキュリティリスクに対する経営認識を深めることと扱い方についてまとめております。\n\u003Ca href=\"http://www.meti.go.jp/policy/netsecurity/mng_guide.html\" target=\"_blank\">http://www.meti.go.jp/policy/netsecurity/mng_guide.html\u003C/a>\n\n内閣サイバーセキュリティセンターNISCからも「リスクアセスメントガイドライン」を公示するべく準備しているようです。\n\n特に重要インフラや製造業や公共施設などの制御システムセキュリティ対策技術は、サイバー攻撃に強い制御製品で制御システムを設計していくことが求められる訳ですが、その研究をテーマに対策技術をまとめているICS研究所のeICSの受講をお勧めします。\n特に、eICS受講＋順次開催しているICS研究所の研修をセットにして受講するとさらに良く理解できます。",{"id":43,"heading":44,"summary":7,"body":45,"gallery":7},354,"eICSのWebサイト","\u003Ca href=\"https://www.ics-lab.com/e/\">https://www.ics-lab.com/e/\u003C/a>\n社内手続きで見積書が必要であれば、「見積書請求」からお申し込みください。",[47],{"id":10,"company":48,"name":49,"profile":50},"株式会社ICS研究所","村上 正志","1979～90年まで、日本ベーレーのシステムエンジニアとして電力会社の火力発電プラント監視制御装置などのシステム設計及び高速故障診断装置やDirect Digital Controllerの製品開発に携わる。\n＊関わった火力発電所は、北海道電力（苫東厚真、伊達）、東北電力（新仙台、仙台、東新潟）、東京電力（広野、姉ヶ崎、五井、袖ヶ浦、東扇島）、北陸電力（富山新港）、中部電力（渥美、西名古屋、知多、知多第二）、関西電力（尼崎、御坊、海南、高砂）、中国電力（新小野田、下関、岩国）、四国電力（阿南）、九州電力（港、新小倉、川内）、Jパワー（磯子、松島、高砂）、日本海LNG　など\n\n1990年、画像処理VMEボードメーカーに移籍し、大蔵省印刷局の検査装置や大型印刷機械などのシステム技術コンサルティングに従事。\n\n1995年、デジタルに移籍し、SCADA製品の事業戦略企画推進担当やSE部長を務める。（2004年よりシュナイダーエレクトリックグループ傘下に属す）また、1999年にはコーポレートコーディネーション／VEC（Virtual Engineering Company & Virtual End-User Community）を立ち上げ、事務局長として、「見える化」、「安全対策」、「技術伝承」、「制御システムセキュリティ対策」など製造現場の課題を中心に会員向けセミナーなどを主宰する。協賛会員と正会員のコラボレーション・ビジネスを提案し、ソリューション普及啓発活動を展開。\n2011年には、経済産業省商務情報政策局主催「制御システムセキュリティ検討タスクフォース」を進言、同委員会委員及び普及啓発ワーキング座長を務める。\n2015年、内閣官房 内閣サイバーセキュリティセンターや東京オリンピックパラリンピック大会組織委員会などと交流。\n\n2015年、株式会社ICS研究所を創設。VEC事務局長の任期を継続。世界で初めて制御システムセキュリティ対策e-learning教育ビデオ講座コンテンツを開発。\n\n2017年4月～ 公益財団法人日本適合性認定協会JABの制御システムセキュリティ技術専門家\n\n2017年7月～ 経済産業省の産業サイバーセキュリティセンターCoEの制御システムセキュリティ講座講師担当\n\n現在活動している関連団体及び機関\n・日本OPC協議会 顧問\n・制御システムセキュリティ関連団体合同委員会委員",1779421343253]