本記事は工業技術社月刊「計装」2017年10月号「制御セキュリティ特集（8月号）への補足」に寄稿した記事に一部追記し、編集部と共著者のご了解のもと掲載しています。掲載記事は本誌をご覧ください。8月号では紙面スペースの都合で割愛した IEC 62433の発行状況やセキュリティレベルについて補足しています。
はじめに
８月号に寄稿した制御セキュリティについての記事において、紙面制限の都合で割愛したSecurity Levelについて、現在発行されているIEC 62443の体系とあわせて補足解説する。
IEC 62443の体系と発行状況
IEC 62443として体系化および発行を予定している規格は（図１）のとおり、Part1からPart4までの4区分13編であるが、発行されているのはそのうちの7編(※）である。工場や設備の制御ネットワークに携わる組織によって参照するべきPartが異なる。8月号の記事はPart1～3の6編について解説した。JSAのサイトで日本語版も販売されている。※本記事執筆時点 6編。2018年2月4-1発行予定。
IEC/TS 62443-1-1[1]
関係者全員が読むべき用語解説や、全体を通して重要な概念であるZone、Conduit、さらに制御システムの参照モデルや、本紙後段に示すセキュリティレベルの考え方、Defense In Depthの重要性も述べられている（IEC 62443-1-1 5.Concept）。8月号の解説記事は、本篇に基づく。また記事に引用した参照モデルは本編のFigure 12である。
IEC 62443-2-1[2], TR 2-3[3], 2-4[4]
これは工場や設備のオーナに求められる要件である。マネージメントやセキュリティポリシーの作成、運用など、設備を長期にわたってセキュアに維持するためのライフサイクルと、その中で必要な活動（たとえばSecurity Levelを設定し維持する活動など）を定義している（図２）。8月号の解説記事は本篇に基づく。
Part 3-1[5]、3-3[6]
3-1は、一般的なセキュリティ技術の解説と、それらの技術や製品が、制御システムのネットワークにおいての向き・不向きともに、どのように活用すべきか解説されている。緊急操作の必要なゾーンの端末には、長いパスワードなど高いセキュリティ機能を要求することは難しい点などの指摘は、8月号の解説記事は、本篇に基づく。(IEC 62443-3-1 5.3.5)
3-3では、1-1に示されているSecurity Levelの考え方が、より具体的に示されている。また、脅威や脆弱性を洗い出し特定するための、7つの観点が示されている。本件は後述する。3-2で予定されている「Security Risk Assessment」は、発行の最終段階にあるため、近日公開される予定である。3-2に基づくセキュリティリスクアセスメントに基づき、制御ネットワークのゾーンにセキュリティレベルが与えられ、その結果に基づき3-3に掲載されているセキュリティ機能が必要となる。
Part 4-1,4-2（未発行）※4ｰ1は2018年2月23日発行
これらは、デバイス単体の機能をSecurity Levelと対比し、達成するための製品開発者の活動を規定するものであるが、現在のところ未発行である。本篇は後述するSL-C（Capability）の単体評価について触れられる予定であるが、未発行であり、計装制御エンジニアの範囲ではないため、8月の特集では触れていない。なお4ｰ1（開発ライフサイクル）は現在PRV (Pre-release version)が発行されており、2018年2月23日に正式に発行される予定である。
IEC 62443におけるSecurity Levelの考え方
IEC-62443（前述の6編）には、Security Level（SL）という指標が登場する。システムにおけるネットワークのエリア（ZoneおよびConduit：後述する）の評価に使用する。SLは使用目的によって3つの表記方法を用いる(IEC 62443-1-1 5.11.2)。 SL-T（Target）とは、設備オーナや事業者がリスク分析に基づき、そのネットワークゾーンに求めるレベルを示す際に使う。同じSL=2でも、SL-T=2というのは、設定値である。
適切な分離や階層化したネットワーク設計によって、そのゾーンが達成した（と評価できる）セキュリティレベルが、SL-A（Achieved）である。もちろんSL-Aの達成目標はSL-Tである。特集記事で用いたSLという表現は、この-Tと-Aに関係する計装エンジニアの用途でのSLである。
SL-C（Capability）は、ネットワーク機器の持つセキュリティ機能の評価方法について、機材開発者への指標となるが、前述のとおり未発行のPart4の範囲である。発行されたのち、機会あれば解説する。
このようにSLは人の立場によって、目標なのか達成度なのか分かれるが、指標としては０および１～４で表現される。その定義はIEC 62443-3-3にあるが、後述するSLの7つのベクトル表記の要素ごとに個別に解釈がなされるものである。
SL=0とは、装置としてはセンサーやデバイスなど、特別なセキュリティ機能を持ちえないレベルとされる。もしくはセキュリティレベルを設定する必要のないゾーンともいえる。
SL=1は、偶発的なセキュリティトラブルを考慮するレベルである。SL=1から上はセキュリティインシデントを発生させる脅威に備えるレベル、即ち何らかのセキュリティ対策がもとめられるレベルとなる。（装置の機能である必要はない。物理的な分離も対策となりうる）
SLの数値が大きいゾーンは、より強い動機やネットワークに対する知識、使用する機材が大掛かりになる。SL=4は、オフィスなど制御システムの現場から見て、緊急操作などの実際の運転に無関係な人々がアクセスするようなゾーンとなる。IEC 62443-3-3には、各レベルで必要になるセキュリティ機能が整理されている。
これらのレベル付けと制御システムのモデルとの関連付けの例は、IEC 62443-3-3 Annex Aにある。8月の制御システムの参照モデル（IEC 62443-1-1 Figure 12）とSLとの関連付けは本編に基づき、制御装置の中核に近いほど高いセキュリティレベルの機能を付与できない点を解説した。実際のSL-Tは特集記事に記載のとおり、設備のリスク分析に基づき決定してゆく（IEC 62443-2-1）。なおSL-AはDefense in Depthによるネットワークの分離や階層化に基づいた、脆弱性分析や脅威分析の結果によって評価されるべきものである。
Security Levelのベクトル表現
SLは、機能安全のSILのようなイメージではあるが、大きく異なる点が、レベルをベクトルで表すことである。つまり前述のようにSL=１という書き方は便宜的なもので、IEC-62443としての要件に沿えば、SL=(4,1,2,1,3,2,0)のように、7つの成分を持つベクトル表記となる（図３）。
これは一口に制御システムのネットワークといっても、リアルタイム性の必要な運転ゾーンから監視や操業データを編集するゾーンなど様々な運用実態があり、運用と置かれる環境によって脅威や脆弱性への分析観点が異なるためである。
このため「SL-Cが高いものが、より信頼性が高くて安心である」と一概にはいえない。たとえば、現場に近く極めて限定された運転員しか操作しないゾーンで、かつ緊急時の設備操作に必要な端末では、前述のとおり、運転員に長くて複雑なパスワードはかえって緊急操作の障害になる可能性がある。そのような局面が想定されるゾーンは、おそらくSL-A (IAC) =1や0となるだろう。そのゾーンにSL-C（IAC）=4の機能（二要素認証）を持つデバイスは不必要（不向き・過剰）だと考えるべきである。
裏を返せば、そのような操作端末（緊急操作をするための端末）を設置するゾーンは、SL=0または１とできるように、ネットワークの分離や階層化を行うべきである、という表現が正しい。すなわちDefense in Depthの思想でネットワークを設計することが肝要である。（IEC 62443-1-1 5.Concept）
実際のTUV-SUDドイツによるアセスメントでは、SL-T=3や4となる「ゾーンの存在自体」が問題視されるケースがあった。つまり制御システムに影響を与えるようなデバイス（および機能や通信）を、そもそもそんなところに設置するなよ、という話である。
おわりに
特集記事では紙面の制約で解説できなかったSecurity Levelの詳細を解説した。末尾の発行年を見てもらえればわかる通り、基本となるIEC 62443-1-1は2009年の発行である。筆者は2000年前後から発電所の制御ネットワークのセキュリティ設計、制御システムのネットワーク処理機構の開発を経験してきたが、IoTなどと騒がれる現代も当時も、制御システムとネットワークの本質的な問題に変わりない。つまりセキュリティインシデント（事件）を事故（災害）に結び付かせないという視点である。IEC 62443は計装制御エンジニアが古くから試行錯誤してきた課題を整理しており、実際の計装制御インテグレーションの関係者ならば、特別なことが書かれていないことが判る。
IEC 62443-1-1にも記載があるが、実際の設備制御の現場では、古いデバイスや、テキスト文字むき出しのパスワードを伝送する装置も現役で動作していることであろう。IoTやIndustrie4.0で付帯ネットワークを構築する際は、そのような現場の現状を踏まえ、計装制御エンジニアがリスク分析、脆弱性分析、脅威分析を行いながら、ネットワーク設計をしてゆく大切さが伝わればと願い特集記事を寄稿した。
引用文献
[1] IEC/TS 62443-1-1 Ed 1.0, “Industrial communication networks – Network and system security –Part 1-1: Terminology, concepts and models”, 2009-07.
[2] IEC 62443-2-1 Ed 1.0, “Industrial communication networks – Network and system security –Part 2-1: Establishing an industrial automation and control system security program”, 2010-11.
[3] IEC TR 62443-2-3 Ed 1.0, “Security for industrial automation and control systems –Part 2-3: Patch management in the IACS environment”, 2015-06.
[4] IEC 62443-2-4 Ed 1.0, “Security for industrial automation and control systems –Part 2-4: Security program requirements for IACS service providers”, 2015-06.
[5] IEC/TR 62443-3-1 Ed 1.0, “Industrial communication networks – Network and system security –Part 3-1: Security technologies for industrial automation and control systems”, 2009-07.
[6] IEC 62443-3-3 Ed 1.0, “Industrial communication networks – Network and system security –Part 3-3: System security requirements and security levels”, 2013-08.