機能セキュリティ、パート5/7。情報と機能セキュリティのライフサイクル

出所



IoTアナリティクスによると、2016年には、モノのインターネットの使用に関連するほとんどのプロジェクト（全体の22％）が産業施設に導入されました。 これにより、 インダストリー4.0の原則で宣言された技術の開発と普及が確認されます。



したがって、目の前に、産業用インターネット制御システム（IICS）または産業用モノのインターネット（IIoT）と呼ばれる新しいクラスのサイバー物理システムが生まれました。



名前から、そのようなシステムは、産業用制御システムおよびモノのインターネットに基づくシステムで使用されるテクノロジーのハイブリッドであることは明らかです。 したがって、このようなシステムでは、情報の特性（セキュリティ）および機能安全（安全性）の侵害に関連するすべてのリスクを考慮する必要があります。



この記事は、 機能安全に関する一連の出版物の続きです。 制御システム（ACS TP、組み込みシステム、モノのインターネット）のライフサイクルの組織に対する要件を考慮します。 情報セキュリティと機能セキュリティの両方の要件の充足をサポートするプロセスの単一構造が提案されています。



産業用制御システムの情報セキュリティの要件を検討する際、情報セキュリティ（IS）と機能セキュリティ（FB）の要件を調和させることができました（図1を参照）。 図からわかるように、情報セキュリティと財務セキュリティを確保するプロセスは、単一のライフサイクル内で実装する必要があります。







図1. ISおよびFBの要件の構造

「大きな」ライフサイクル

私たちは主に自動化されたプロセス制御システムについて話しているため、それらのライフサイクルは通常、産業用制御オブジェクトに関連して考慮されます。 したがって、ACSがコンポーネントの1つである工業施設の設計、建設、運用、廃棄に関連する、いわゆる「大」ライフサイクルが考慮されます。 もちろん、既存のICS機器の近代化は実行できますが、これは「大規模な」ライフサイクルにも適合します。



IEC 61508の「電気、電子、プログラマブル電子安全関連システムの機能安全」（IEC 61508）を見てみましょう。 この規格の最初の部分には、産業施設のライフサイクルに関連する「壮大な」図が含まれています。 ステージの名前はそれ自体を物語っています。 次の手順は、自動プロセス制御システムに直接関連しています（図2の緑色の星印）。



-1コンセプト;

-9電気/電子/プログラマブル電子（E / E / PE）システム安全要件仕様。

-10 E / E / PEシステムの実装。

-12全体の設置と試運転。

-14全体的な運用、保守、修理。

-15全体的な修正と改造。

-16廃止措置または廃棄。







図2. IEC 61508-1、図2-全体的な安全ライフサイクル

（「*」はICSに適用可能な手順を示します）

V字型（「小さな」）ライフサイクル

概念、要件の仕様、および実装は、いわゆるV字型または「小さな」ライフサイクルによって記述されます。 概念は「小さな」ライフサイクルを超えて移動することもありますが、要件の仕様を形成するための開始点を含める必要があるため、概念を含めます。



さらに、IEC 61508は、「10 E / E / PEシステムの実装」フェーズの構造を開示しています（図3を参照）。 実装プロセスの構造は、ソフトウェアとハ​​ードウェアの両方に対して提案されており、後者はプログラマブルコンポーネント（FPGA、プログラマブル集積回路など）と非プログラマブルコンポーネントを区別します。







図3. IEC 61508-2、図4-IEC 61508-2とIEC 61508-3の関係と範囲



IEC 61508には、システムのライフサイクルの構造に関連するいくつかの不正確さとギャップが含まれています。 これは、ソフトウェアとハ​​ードウェアの要件を分離し、「大」ライフサイクルでシステムレベルを表すために、「小」ライフサイクルで試行が行われたという事実によるものです。



したがって、IEC 61508の問題の1つは、自動プロセス制御システム、組み込みシステム、モノのインターネットデバイスのレベルなど、コンピューター制御システムに直接適用できるライフサイクルを明示的に持たないことです。



通常、ソフトウェアおよびシステムエンジニアリングの実践では、サプライヤに転送されるまでシステムを開発することが問題になります。 このようなV字型のライフサイクルについて詳細に検討します。 ライフサイクル構造は、IEC 61508などの機能安全規格によって定義されています（図4を参照）。 ライフサイクルの下降分岐では、トップダウン開発が実行されます。 ライフサイクルの上昇分岐では、統合が「下から上」に実行され、1つまたは別のプロジェクトドキュメントへの準拠のテストが伴います。







図4. IEC 61508-3、図6-ソフトウェアの体系的な機能と開発ライフサイクル（Vモデル）



ライフサイクルの詳細な研究のために、著者の解釈が提案され、いくつかの成功した認証プロジェクトでの自身の経験でテストされています。 提案されたライフサイクル構造は、一方ではIEC 61508の要件と矛盾せず、他方では要件のいくつかのギャップを埋めて、システム、ソフトウェア、およびハードウェアの開発、検証、検証を単一のモデル内に統合する方法を示しています。







図5.情報のライフサイクルと機能セキュリティ



ライフサイクルモデルには、次の順番に実行される手順が含まれます（図5では、手順は結果のドキュメントの名前で示されています）。



-コンセプトの開発（コンセプト）;

-安全要件仕様（SRS）の開発。これは、システムを「ブラックボックス」、つまり「どのように行われているのか」ではなく「何が行われているのか」と記述しています。

-安全要件仕様（SRSレビュー）の概要は、検証および検証プロセスのステップです。

-システムアーキテクチャプロジェクト（System Architecture Design、SAD）の開発。これは、システムを「ホワイトボックス」、つまり「何が行われるか」ではなく「何が行われるか」の形で記述します。

-システムアーキテクチャプロジェクトのレビュー（SADレビュー）は、検証および検証プロセスの段階です。

-ロシア語ではハードウェアプロジェクト（ハードウェアデザイン）の開発。このコンポーネントは設計文書（CD）と呼ばれ、ケーブルを含む電子回路設計と機械構造と電気部品（いわゆる「ストラッピング」）の図面の両方が含まれます。電源およびフィールド機器とのインターフェースコンポーネント（センサーおよびアクチュエータ;

-ハードウェア設計レビュー（ハードウェア設計レビュー）は、検証と検証のプロセスのステップです。

-障害の種類、結果、および重大度の分析（障害モード、影響および重大度分析、FMECA）は、検証および検証プロセスの段階です。 FMECAの実行時には、ハードウェア構造が主に考慮されますが、ソフトウェアに実装された診断およびフォールトトレランスメカニズムも考慮されます。

-ソフトウェア設計（ソフトウェア設計）;

-ソフトウェアプロジェクトのレビュー（ソフトウェアデザインレビュー）は、検証および検証プロセスの段階です。

-ソフトウェアコード開発（ソフトウェアコーディング）;

-プログラムコードの静的分析（静的コード分析）;

-プロジェクトの要件に準拠するソフトウェアテスト（ソフトウェアテスト）には、単体テストと統合テストの両方、機能テストと構造テストの両方が含まれます。 テストの前に、ソフトウェアテスト計画と仕様（TP＆S）が開発され、テスト結果がソフトウェアテストレポート（TR）に文書化されます。

-ハードウェアおよびソフトウェアの欠陥をシードする方法によるテスト（障害挿入テスト）。その入力は、自己診断の実装の分析に関するFMEDAの結果です。 テストを開始する前に、欠陥シード（Fault Insertion TP＆S）によるテストのテスト計画と仕様が開発され、テスト結果が欠陥シード（Fault Insertion TR）によるテストに関するレポートに記録されます。

-アーキテクチャの要件に準拠するための統合ソフトウェアおよびハードウェアコンポーネントの統合テスト（統合テスト）。 テストの前に、統合テストの計画と仕様（統合TP＆S）が開発され、テスト結果は統合テストのレポート（統合TR）に記録されます。

-安全要件の仕様に準拠するための統合システムの検証テスト（検証テスト）; テストを開始する前に、検証テスト（検証TP＆S）の計画と仕様が作成され、検証結果に関するレポート（検証TR）にテスト結果が記録されます。 ライフサイクルのこの最終段階の重要性を考慮して、IEC 61508では、安全要件仕様（SRS）の開発直後に検証テスト計画を作成することを要求しています。 検証には、機能テストに加えて、極端な環境の影響（温度-湿度、機械的、電磁的、放射など）に対する耐性のテストも含まれます。

ライフサイクルフェーズ

ライフサイクルのフェーズの詳細な説明は、一連の表の形式で提示されます。 テーブルは、機能と情報の両方のセキュリティを確保するためにアクティビティを同期しました。 一部のアクションは、FBとIBに同時に起因する場合があります。 コンピューター制御システムの場合、主なリスクはFBプロパティの違反に関連しています。 したがって、テーブルでは、FBに優先順位が与えられます。 FBとIBの両方を提供するアクションは、FBに関連する列に含まれています。 したがって、ISに関連する列では、SEを確保するためのアクティビティと重複しないアクションが考慮されます。 これはすべて退屈に見えますが、提案された資料は参考として使用できます。



表1.フェーズの概念







表2.安全要件仕様フェーズ







表3.安全要件の仕様レビューフェーズ







表4.システムアーキテクチャ設計、システムアーキテクチャ設計レビューのフェーズ







表5.フェーズハードウェア設計、ハードウェア設計レビュー







表6.フェーズ障害モード、影響および重大度の分析







表7.ソフトウェア設計、ソフトウェア設計レビュー、ソフトウェアコーディング、静的コード分析のフェーズ







表8.フェーズソフトウェアテスト







表9.障害挿入テストフェーズ







表10.統合テストフェーズ







表11.検証テストフェーズ

トレース要件

要件エンジニアリングは、要件エンジニアリングと呼ばれる幅広い知識分野のプロセスの1つです。



要件は、契約、標準、仕様、またはその他の正式な文書を満たすためにシステムまたはシステムコンポーネントが満たさなければならない条件またはプロパティの文書化された表現です。



要件トレースは、要件の変更と関連する成果物を管理する方法です。 トレース要件は、3つの主なタスクを解決します。



-上位レベルのすべての要件の下位レベルでの実装を保証します。

-文書化されていない機能の下位レベルでの出現を防ぎます。

-すべての要件のテストを提供します。



トレースの実行方法の例を見てみましょう（図6を参照）。 例は、 RadICSコントローラー認証プロジェクトから取得されます 。 要件をトレースするには、要件の定式化の境界を定義する要件識別子とタグを配置して、このプロセスのドキュメントを準備する必要があります。







図6.トレース要件の例



左側は、安全要件仕様の断片です。 ドキュメントは表形式で作成されます。 各要件（この場合はEIR.01、電源インターフェースの要件）ごとに識別子が入力されます。 トレースのためにドキュメントをスキャンすることは、exidaのDEUSツールによって実行されます。 DEUSはMS Officeマクロです。 リクエストの開始は識別子によって決定され、リクエストの終了は記号[/]によって決定されます。 割り当てフィールドは、仕様要件がトレースされる下位レベルのドキュメントを示します。 この場合、それはシステムアーキテクチャ設計です。 システムアーキテクチャ設計では、タグ付け要件も実行する必要があります。 さらに、各要件について、そのソースをトップレベルのドキュメント、いわゆる親要件に示す必要があります。 要件については、1対多の関係が得られました。つまり、電力要件は、製品の基本概念、シャーシ、およびすべてのモジュールの要件に反映されました。 次に、SAD要件のそれぞれが、ハードウェア設計とソフトウェア設計でトレースされます。 最終的なトレース結果は、ドキュメントの要件間の関係を反映する一連のマトリックスの形式で表示できます。 要件のリバーストレーサビリティは、下位レベルのドキュメントから上位レベルのドキュメントまで実行され、製品に不要なドキュメント化された機能がないことを確認します。



テスト時には、プロジェクトドキュメントから要件を抽出することでトレースが行われます。 複雑なプロジェクトの場合、テストドキュメントの開発は2段階で行われます。 最初に、テストされた要件のリストを含むテスト計画が作成され、次にテスト仕様の要件ごとにテストケースが作成されます。 テスト中、要件の直接的なトレーサビリティは、プロジェクトドキュメントから計画とテスト仕様、そしてテストレポートまで実行されます。 欠陥シーディングによるテストでは、診断された障害を分析することにより、テストのリストがFMECAレポートから抽出されます。 妥当な一連の失敗については、診断機能がチェックされる一連のテストがコンパイルされます。 ここでバックトラッキングは重要ではありません。設計ドキュメントが原因ではない追加のテストが実行される場合、これはセキュリティに影響しないためです。

結論

第4次産業革命（Industry 4.0）は、新しいタイプのシステムである産業用インターネット制御システム（IICS）または産業用モノのインターネット（IIoT）に情報と機能セキュリティを提供することに関連する課題を提起します。 この点で、複合施設のISおよびFBの要件を考慮することが重要と思われます。 ISおよびFB要件を実装するための戦略の一環として、この記事では、安全性とセキュリティのライフサイクルの手順の構造と内容について説明します。



別の課題は、新しいクラスのシステム（IICS、IIoT）を開発、評価、および運用できる専門家のトレーニングです。 明らかに、そのような専門家は、ICSとモノのインターネットという2つの領域でテクノロジーを所有する必要があります。 私たちの大学はそのような専門家をまだ大量に訓練していませんが、産業制御システムとモノのインターネットの市場では、技術の単一スタックとして、彼らはまだ「友人」ではありません。



PS機能安全の主な側面を説明するために、次の一連の記事が開発されています。

- 機能安全のトピックの紹介 。

-IEC 61508規格：用語 。

-IEC 61508規格：要件構造 。

- 情報と産業用制御システムの機能安全との関係 。

- 機能安全の管理と評価のプロセス ;

- 情報と機能セキュリティのライフサイクル 。

- 信頼性と機能安全の理論：基本的な用語と指標 。

- 機能安全を確保する方法 。



ここでは、出版のトピックに関するビデオ講義を見ることができます。