１．OPC UAに17件の脆弱性情報（カスペルスキー社報告）
Industry4.0やIICでは製造システム／制御システムで使用する通信としてセキュリティ仕様が高く評価されているOPC UAのみを指定しています。しかし、セキュリティ評価の高いOPC UAにもOPC FOUNDATIONが公開しているサンプルソースコードに17件の脆弱性情報があることをカスペルスキー社が2018年5月10日に報告しました。
https://ics-cert.kaspersky.com/reports/2018/05/10/opc-ua-security-analysis/
https://ics-cert.kaspersky.com/reports/2018/05/10/opc-ua-security-analysis/
OPC UAのオープンソースが公開されているWebサイトはこちらです。
https://github.com/opcfoundation/
https://github.com/opcfoundation/
２．OPC Foundationからのコメント
OPC UAのオープンソースに脆弱性がある件についてのOPC Foundationからのコメントを以下に記載します。
Review of Kaspersky Labs Report Confirms OPC Foundation’s Transparent, Open Source OPC UA Implementations Strategy Improves Security
（意訳：OPC UAのオープンソースに脆弱性があるというカスペルスキー社の指摘はOPC UAのセキュリティを向上させる戦略上に貢献するものである。）
https://opcfoundation.org/news/press-releases/review-kaspersky-labs-report-confirms-opc-foundations-transparent-open-source-opc-ua-implementations-strategy-improves-security/
以下、上記リンク先のOPC Foundationのコメントの英語と日本語を併記しておきます。
1. Eight issues were associated with an OPC Foundation ANSI-C sample server application that was provided with the ANSI-C stack code in GitHub. These issues did not affect the ANSI C stack itself or products based on commercial SDKs. Nevertheless, all issues have been fixed.
GitHub （公開オープンソースサイト）のANSI-Cスタックコードで提供されていた OPC Foundation ANSI-Cサンプルサーバアプリケーションに関連付けられたオープンソースコードに８つの問題がありました。これらの問題は、ANSI C スタック自体や商用 SDK（ドライバ開発ツール）に基づく製品には影響ありませんでした。それでも、すべての問題が修正されました。
2. Six issues were associated with the OPC Foundation server enumerator (LDS). These were fixed in 2017 and a CVE was published. These issues were not exploitable remotely.
OPC Foundation サーバー列挙子 (LDS) に6つの問題が関連付けられています。これらは2017で修正され、CVE（Common Vulnerabilities and Exposures）が公開されました。これらの問題はリモートでは悪用確認できませんでした。
（注：サイバー攻撃の技術レベルもあるので一概にリモート操作の話はできないですが、OPC Foundationの技術者では確認できなかったと理解しておいた方が良いでしょう。）
3. Three issues affected some products in the field. Specifically:
a.) One issue was specific to a product from a vendor who published a CVE in 2016;
b.) The second issue is specific to a product from a vendor who is working on a fix and will report it to US ICS CERT as soon as possible;
c.) The third issue affected a legacy .NET stack that was promptly fixed by the OPC Foundation in 2017. OPC users were notified of this issue via a CVE in 2017.
3つの問題は、フィールドの一部の製品に影響を与えた。具体的には
a.) 1 番目の問題は、2016で CVE を公開したベンダの製品に固有のものでした。
b.) 2 番目の問題は、修正に取り組んでいるベンダからの製品に固有のものであり、できるだけ早く米国 ICS CERT に報告します。
c.) 3 番目の問題は、2017の OPC Foundation によって速やかに修正されたレガシー .NET スタックに影響を及ぼしました。 OPC ユーザーは、2017の CVE を介してこの問題について通知されました。
In addition, to alleviate potential confusion the Kaspersky Labs report may have created about the strong security the OPC UA standard offers, the OPC Foundation emphasizes that:
• The OPC UA software eco-system is composed of multiple commercial OPC UA SDK/Toolkit vendors that offer well tested and well documented products.
• The vast majority of OPC UA products are based on these commercial OPC UA SDK/Toolkits and are not affected by the issues with the ANSI-C sample server application published on GitHub.
さらに、OPC UA 標準が提供する強力なセキュリティについて、カスペルスキーのレポートが作成した可能性のある混乱を緩和するために、OPC Foundation は次のことを強調しています。
• OPC UA ソフトウェアエコシステムは、よくテストされ、十分に文書化製品を提供する複数の商用 OPC UA SDK/ツールキットベンダーから成っています。
• OPC UA 製品の大半は、これらの商用 OPC UA SDK/ツールキットに基づいており、GitHub で公開されている ANSI C サンプルサーバアプリケーションの問題の影響を受けません。
The OPC Foundation works cooperatively with vendors to have the open source code base tested by external security organizations and have those results incorporated into GitHub.
OPC Foundation は、外部のセキュリティ組織によってテストされたオープンソースコードベースをベンダと協調して実行し、それらの結果を GitHub に組み込んでいます。
Review of Kaspersky Labs Report Confirms OPC Foundation’s Transparent, Open Source OPC UA Implementations Strategy Improves Security
（意訳：OPC UAのオープンソースに脆弱性があるというカスペルスキー社の指摘はOPC UAのセキュリティを向上させる戦略上に貢献するものである。）
https://opcfoundation.org/news/press-releases/review-kaspersky-labs-report-confirms-opc-foundations-transparent-open-source-opc-ua-implementations-strategy-improves-security/
以下、上記リンク先のOPC Foundationのコメントの英語と日本語を併記しておきます。
1. Eight issues were associated with an OPC Foundation ANSI-C sample server application that was provided with the ANSI-C stack code in GitHub. These issues did not affect the ANSI C stack itself or products based on commercial SDKs. Nevertheless, all issues have been fixed.
GitHub （公開オープンソースサイト）のANSI-Cスタックコードで提供されていた OPC Foundation ANSI-Cサンプルサーバアプリケーションに関連付けられたオープンソースコードに８つの問題がありました。これらの問題は、ANSI C スタック自体や商用 SDK（ドライバ開発ツール）に基づく製品には影響ありませんでした。それでも、すべての問題が修正されました。
2. Six issues were associated with the OPC Foundation server enumerator (LDS). These were fixed in 2017 and a CVE was published. These issues were not exploitable remotely.
OPC Foundation サーバー列挙子 (LDS) に6つの問題が関連付けられています。これらは2017で修正され、CVE（Common Vulnerabilities and Exposures）が公開されました。これらの問題はリモートでは悪用確認できませんでした。
（注：サイバー攻撃の技術レベルもあるので一概にリモート操作の話はできないですが、OPC Foundationの技術者では確認できなかったと理解しておいた方が良いでしょう。）
3. Three issues affected some products in the field. Specifically:
a.) One issue was specific to a product from a vendor who published a CVE in 2016;
b.) The second issue is specific to a product from a vendor who is working on a fix and will report it to US ICS CERT as soon as possible;
c.) The third issue affected a legacy .NET stack that was promptly fixed by the OPC Foundation in 2017. OPC users were notified of this issue via a CVE in 2017.
3つの問題は、フィールドの一部の製品に影響を与えた。具体的には
a.) 1 番目の問題は、2016で CVE を公開したベンダの製品に固有のものでした。
b.) 2 番目の問題は、修正に取り組んでいるベンダからの製品に固有のものであり、できるだけ早く米国 ICS CERT に報告します。
c.) 3 番目の問題は、2017の OPC Foundation によって速やかに修正されたレガシー .NET スタックに影響を及ぼしました。 OPC ユーザーは、2017の CVE を介してこの問題について通知されました。
In addition, to alleviate potential confusion the Kaspersky Labs report may have created about the strong security the OPC UA standard offers, the OPC Foundation emphasizes that:
• The OPC UA software eco-system is composed of multiple commercial OPC UA SDK/Toolkit vendors that offer well tested and well documented products.
• The vast majority of OPC UA products are based on these commercial OPC UA SDK/Toolkits and are not affected by the issues with the ANSI-C sample server application published on GitHub.
さらに、OPC UA 標準が提供する強力なセキュリティについて、カスペルスキーのレポートが作成した可能性のある混乱を緩和するために、OPC Foundation は次のことを強調しています。
• OPC UA ソフトウェアエコシステムは、よくテストされ、十分に文書化製品を提供する複数の商用 OPC UA SDK/ツールキットベンダーから成っています。
• OPC UA 製品の大半は、これらの商用 OPC UA SDK/ツールキットに基づいており、GitHub で公開されている ANSI C サンプルサーバアプリケーションの問題の影響を受けません。
The OPC Foundation works cooperatively with vendors to have the open source code base tested by external security organizations and have those results incorporated into GitHub.
OPC Foundation は、外部のセキュリティ組織によってテストされたオープンソースコードベースをベンダと協調して実行し、それらの結果を GitHub に組み込んでいます。
３．今回学ぶべきこと
OPC UAのソースコードに脆弱性があるからと言って、全てのOPC UA製品に脆弱性があるという訳ではありません。以下の対応をしているかどうかが重要です。
●OPC UAドライバを開発するベンダがOPC UAのソースコードを参考にはするが、OPC UAの仕様を理解して搭載しようとする製品仕様に合ったOPC UA通信ドライバをコーディングします。その後、使用している開発ツールで最新のCVEやNVD、JVNなどの脆弱性情報データベースを使ってセキュアコーディングチェックを実施して脆弱性を取り除きます。このやり方はＩＣＳ研究所のeICSの制御製品開発技術「セキュアコーディングにおけるセキュリティ対策」講座と「プログラム開発ツールについて」講座でもご紹介しております。
そして、静的解析ツール、動的解析ツールの検査を行います。さらに、ISA Secure認証のEDSA認証の検証ツールと同等もしくはそれ以上の検査ツールを使用してCRT（Communication Robustness Test）を実施します。
工場の立会試験では装置や機械のサイバーセキュリティ機能及び性能試験を実施します。そういったプロセスを経たOPC UA製品であれば、慌てることはありません。また、ISA Secure認証のEDSA認証を取得しているOPC UA製品については指定のセキュリティレベルを持っていることが証明されております。
以上を簡潔にまとめますとこの3項目です。
①製品開発プロセスのコーディング作業段階でセキュアコーディングチェックを実施し、開発ツールや静的解析ツール、動的解析ツールで最新のCVEやNVD、JVNなどの脆弱性情報データベースによるチェックを実施していること
②製品開発プロセスのサイバーセキュリティ機能試験、性能試験時にISA Secure認証のEDSA認証で使用している検証ツールと同等もしくはそれ以上の検査ツールを使用して確認していること
③ISA Secure認証のEDSA認証を取得しているとなお良い。（但し、ISA Secure認証のEDSA認証の最新バージョンはV2.1です。）
●問題となるケースは、OPC UAの公開ソースコードをそのまま使用して、セキュアコーディングやサイバーセキュリティ品質検査を製品開発プロセスの各チェック段階で実施していない。もしくは、実施しても出てきたwormingの対処をしないまま、製品出荷している場合、これらの脆弱性情報をもとに、OPC UAのソースコードに注目して新しいマルウェアを開発して闇市場で販売開始すると瞬く間にネット上に拡がっていきます。
すでにカスペルスキー社は100以上の「OPC UA製品」に問題があることを確認しています。
●OPC UAドライバを開発するベンダがOPC UAのソースコードを参考にはするが、OPC UAの仕様を理解して搭載しようとする製品仕様に合ったOPC UA通信ドライバをコーディングします。その後、使用している開発ツールで最新のCVEやNVD、JVNなどの脆弱性情報データベースを使ってセキュアコーディングチェックを実施して脆弱性を取り除きます。このやり方はＩＣＳ研究所のeICSの制御製品開発技術「セキュアコーディングにおけるセキュリティ対策」講座と「プログラム開発ツールについて」講座でもご紹介しております。
そして、静的解析ツール、動的解析ツールの検査を行います。さらに、ISA Secure認証のEDSA認証の検証ツールと同等もしくはそれ以上の検査ツールを使用してCRT（Communication Robustness Test）を実施します。
工場の立会試験では装置や機械のサイバーセキュリティ機能及び性能試験を実施します。そういったプロセスを経たOPC UA製品であれば、慌てることはありません。また、ISA Secure認証のEDSA認証を取得しているOPC UA製品については指定のセキュリティレベルを持っていることが証明されております。
以上を簡潔にまとめますとこの3項目です。
①製品開発プロセスのコーディング作業段階でセキュアコーディングチェックを実施し、開発ツールや静的解析ツール、動的解析ツールで最新のCVEやNVD、JVNなどの脆弱性情報データベースによるチェックを実施していること
②製品開発プロセスのサイバーセキュリティ機能試験、性能試験時にISA Secure認証のEDSA認証で使用している検証ツールと同等もしくはそれ以上の検査ツールを使用して確認していること
③ISA Secure認証のEDSA認証を取得しているとなお良い。（但し、ISA Secure認証のEDSA認証の最新バージョンはV2.1です。）
●問題となるケースは、OPC UAの公開ソースコードをそのまま使用して、セキュアコーディングやサイバーセキュリティ品質検査を製品開発プロセスの各チェック段階で実施していない。もしくは、実施しても出てきたwormingの対処をしないまま、製品出荷している場合、これらの脆弱性情報をもとに、OPC UAのソースコードに注目して新しいマルウェアを開発して闇市場で販売開始すると瞬く間にネット上に拡がっていきます。
すでにカスペルスキー社は100以上の「OPC UA製品」に問題があることを確認しています。
まとめ
OPC UAの仕様は、今後もIndustry4.0やIICの通信仕様として位置づけられます。
製品開発ベンダや制御システムインテグレータが開発プロセスで実施するべきセキュアコーディングチェックや静的・動的解析／サイバーセキュリティ品質検査を実施することで安全の要因であるサイバーセキュリティレベルが確保されます。
ISA-99（ISA Secure認証）は、重要インフラや製造業などで制御システムを標的にしたサイバー攻撃に対処する設備オーナーにとって、サプライヤ責任とオーナー責任の間を定義するオーナー指定の認証制度になるべくセキュリティレベルを考慮した認証制度です。
- CSMS認証：サイバーセキュリティマネージメントシステム（IEC62443-2-1）
- SSA認証：制御システム、制御装置、機械（IEC62443-3-1）
- EDSA認証：制御製品、制御コントローラ（IEC62443-4-1）
（欧米をはじめ、インドネシアやオーストラリア、南米での重要インフラやプラント発注プロジェクトではISA-99を基本発注仕様書などで指定しています。）
セキュリティ認証を取得した制御製品を採用し、制御セキュリティ対策と情報セキュリティ対策の両方の技術を対象となる制御システムに施すことでサイバー攻撃に強い制御システムが実現可能となります。
製品開発ベンダや制御システムインテグレータが開発プロセスで実施するべきセキュアコーディングチェックや静的・動的解析／サイバーセキュリティ品質検査を実施することで安全の要因であるサイバーセキュリティレベルが確保されます。
ISA-99（ISA Secure認証）は、重要インフラや製造業などで制御システムを標的にしたサイバー攻撃に対処する設備オーナーにとって、サプライヤ責任とオーナー責任の間を定義するオーナー指定の認証制度になるべくセキュリティレベルを考慮した認証制度です。
- CSMS認証：サイバーセキュリティマネージメントシステム（IEC62443-2-1）
- SSA認証：制御システム、制御装置、機械（IEC62443-3-1）
- EDSA認証：制御製品、制御コントローラ（IEC62443-4-1）
（欧米をはじめ、インドネシアやオーストラリア、南米での重要インフラやプラント発注プロジェクトではISA-99を基本発注仕様書などで指定しています。）
セキュリティ認証を取得した制御製品を採用し、制御セキュリティ対策と情報セキュリティ対策の両方の技術を対象となる制御システムに施すことでサイバー攻撃に強い制御システムが実現可能となります。
