機能安全とサイバーセキュリティについて

はじめに

安全な装置を設計するには、“機能安全“の理解は今や必要不可欠となっています。IEC 61508規格の初版が発行されてから既に20年が経過し、EUではその技術導入や理解が浸透していますが、残念ながら日本ではまだ一部の企業に限られているのが現状です。必要に迫られ弊社に相談いただく企業は多いのですが、機能安全の予備知識が十分でないまま打ち合わせを行うと、議論が噛み合わないことも多々あります。なぜなら大抵の場合、規格適合のための明確な数値を知りたくて相談に来られるのですが、明確な数値要求はほんの一部であり、規格で要求されていることは、「設計者は規格の要求事項に沿って技術的解決方法を自ら考え、その方法の合理性を理論的に立証すること」だからです。当然そこには設計責任も伴い、これが現在の国際安全規格、機能安全規格が意図することです。この規格を良く理解し、積極的に使いこなせれば、安全性証明のための非常に合理的な手段になるでしょう。

また一般的には機能安全との関連が無いように認識されているサイバーセキュリティですが、ネットワークで安全機能を実現する装置が増えるにしたがって、セキュリティの脅威がクローズアップされています。IEC 61508のみならず、複数の機能安全規格がサイバーセキュリティの考慮を要求として取り込みつつある中で、サイバーセキュリティへの理解も必要不可欠となってきています。

 規格の要求を分かりやすく図で表現すると以下のようになります。

 

要求の主要4要素

■ハードウェアへの要求

これは、目標としている安全度水準SIL実現のために必要なハードウェアアーキテクチャおよび診断機能に関する考え方を示しています。たとえば安全機能をシングルチャンネルで設計した場合、目標SILを達成するためには高性能で高頻度の診断が必要となります。それに対し多重チャンネルでは、診断への要求レベルは比較的低くなりますが、部品コスト、実装面積の増大が問題になるかも知れません。

 

ソフトウェアへの要求は、ソフトウェア開発プロセス中で導入されてしまうかもしれないフォールトを可能な限り排除するという考え方で、定性的なものであり、数値指標による定量的なものは示されていません。その一つとして要求しているのが、明確な開発プロセスの定義とそれらのマネジメントです。規格書ではVモデル開発を示していますが、アジャイル型設計でも問題なく、重要なことはソフトウェア安全要求仕様への正確なトレースとなります。特にソフトウェアによる診断機能を十分に考慮する必要があり、診断機能のほとんどはハードウェアとソフトウェアのコンビネーションで実現されることから、ハードウェアの限界性能を良く理解したソフトウェア開発が必要となります。

 

基本的にはフォールトの導入回避が目的です。設計プロセスにおける人的・組織的な要因によるフォールト導入を極力排除するための取り組みです。つまりこれは品質マネジメントシステムISO 9001とほぼ同様な考え方であり、ISO 9001の仕組みをそのまま使えます。しかし品質の管理と安全性の確保という概念の違いがあるため、例えば設計変更によって安全側面で影響を受けないかどうか、つまり影響解析などが必須となります。

 

PFD、PFH、SFFなど設計によって達成すべき具体的な数値の要求があり、目標SILが達成できたかが計算結果などによって明確に分かるようになっています。しかしながら、安全は数値のみで判定できるほど単純なものではなく、これらパラメータの数値だけでSILが確定できたと考えてはなりません。

 

 

２．フォールトの分類と対処方策について

安全機能を喪失させる可能性のあるフォールト（起因）をSystematic（決定論的）要因とRandom（偶発的）要因とに分類して考えます。それらに対し以下のような対処方策があります。

■Fault avoidance（フォールト回避の方策）

Systematic要因とは 、故障に至る因果関係が明確な現象のことで、原因となるフォールトの発生をできる限り減少させることが有効です。つまりフォールトの導入を可能な限り回避するための方策・技法を用いることを意味します。例えば、設計プロセスのマネジメント、有効なテストプランの作成や独立性が確保された者によるレビューなどがあります。

■Fault control（フォールト制御）

上記のようなフォールト回避方策だけでは故障を完全に防ぐのは現実的には不可能で、特にRandom要因の回避は不可能と考えるべきです。よって、何らかのフォールトが発生しても冗長構成もしくは診断機能により安全機能が喪失しない仕組みが求められます。これらの方策はSystematic要因とRandom要因双方に対して有効な手段となります。

原因と対処法策の関係を図で表すと以下のようになります。

 

 

３．認証プロジェクトのプロセス例

標準的な認証プロセスを表したものです。

B.　サイバーセキュリティについて

１．サイバーセキュリティの規格構成
一般的にセキュリティというとIT（Information Technology）が対象ですが、機能安全と組み合わされて使われるのはOT（Operational Technology）、つまり制御技術に対するセキュリティです。これに関してはIEC 62443シリーズとして規格化されています。

これらの規格の中では機能安全同様、セキュリティレベル（Security level = SL）というものが定義されており、1～4で示されています。この水準はどういったレベルからの攻撃を防ぐことを目的としているか、という観点から設定されています。よく用いられる例では、SL 4であれば国家機関レベルの必要十分な能力と資源、モチベーションを持った攻撃者からの攻撃を防ぐことを目的とし、SL 1であればふとした思い付きでの攻撃や、意図せず発生してしまった攻撃しか防げないレベルとなります。

２.　OT (Operationsl Technology) のセキュリティの保護対象
ITセキュリティでは保護する対象は個人情報や開発情報等の機密情報ですが、OTセキュリティでは多くの場合、制御機能の動作そのもの、つまりセキュリティ上の問題が発生したとしても可用性（Availability）を保つことが第一目的となります。この点を誤ると全く見当違いのセキュリティ対策を施しかねないため、注意が必要です。

３.　IEC 62443-4の要求事項
機能安全と組み合わせるのは機器を対象としたIEC 62443-4-1, -4-2です。-4-1では機器の開発プロセスやその後の維持プロセスに対する要求がまとめられていて、-4-2では技術的な要求がまとめられています。IEC 62443-4の適合を宣言するためには、この両方を満たす必要があります。
特に-4-1の要求事項については、機能安全規格のプロセスの要求と同一の考え方で構成されていて、機能安全開発プロセスとの親和性が高く、機能安全とサイバーセキュリティを同時に対応させると効率的です。ただし、特に製品リリース後の脆弱性管理やセキュリティアップデート管理は、サイバーセキュリティに独特の要求事項となるので、その点は注意が必要です。

～おわりに～
機能安全とサイバーセキュリティについて、要求事項や概要について簡単に説明しました。ただしこれらについては正しい理解の元で取り組まないと多くの手戻りや開発のやり直しを招くこととなります。その理解の一助になればとWebinarを実施予定ですので、ぜひご参加ください。

◆◆◆　【終了しました】ライブ　オンラインセミナー　『機能安全とサイバーセキュリティ ～入門～』2020年 10月 23日（金）13時～15時　◆◆

また、機能安全エンジニア資格トレーニングなどさなざまなセミナーやトレーニングを多数実施してまいりました。詳しくはこちらをご覧ください。