- 4.1 Managing OT Security Risk
- 4.2 Special Areas for Consideration
- 4.3 Applying the Risk Management Framework to OT Systems
4.1 Managing OT Security Risk
ここでは、リスク管理プロセスが
- リスク枠組み設定(framing risk)
リスクに基づく意思決定のための状況を確立すること - リスク評価(assessing risk)
- リスク対応(responding to risk)
- リスク監視(monitoring risk)
の4つで構成されるとしている。
組織全体のリスク管理は、
- 組織レベル(organization level)
- ミッションおよび業務プロセスレベル(mission and business process level)
- システムレベル(system level)
の3つのレベルで適用されるとある。
4.1.1 Framing OT Risk
ここでは、リスク枠組み設定、リスクフレーミングについて記載されている。
Safety can be defined as “freedom from conditions that can cause death, injury, occupational illness, damage to or loss of equipment or property, or damage to the environment.”
安全とは、「死亡、けが、職業病、機器や財産の損傷・喪失、または環境への損害を引き起こす可能性のある状況ではないこと」と定義されている。
Based on this, human safety impacts are typically evaluated based on the degree of injury, disease, or death that could result from the OT system malfunctioning after a cyber incident, taking into consideration any previously performed safety impact assessments.
これに基づいて、OTシステムへのサイバー攻撃による人間に対する安全性への影響評価を行っていくと。”人間に対する”というところが大事だと思います。ここでいう”人間に対する”というのは、組織外だけではなく組織内も含むところ。
当たり前のことではあるが、実際のサイバーインシデントの際には「組織外には影響が起きていないから問題ナシ的」な経営側の判断も稀にみられることがあるので強調していきたい。サイバーセキュリティインシデントの情報漏洩にて、「社員の情報しか漏れていない、お客様の情報の漏洩は無いから個人情報漏洩ナシ」とかあり得るので。
ところで、実際にOTシステムへのサイバー攻撃によってどれほど危険な状況になり得るのだろうか。そもそも、危険な状況に成り得る産業の現場では何かしらの安全システムが存在するハズ。それらによって、機器の異常、災害などによって危険な状況になるのが防がれることが想定されているハズ。サイバー攻撃が原因であっても危険な状態という物理的影響として現れる事象は同じであって、最終的な結果が同様であれば防げるのでは？
なので、そういった環境でのサイバー攻撃による安全性への影響というのを明確にイメージできていない。
ある程度整っている環境であってもやられるというのは、例えば安全システムがカバーし切れていないとか、安全システムをサイバー攻撃で止められてしまうというようなことが想定されているのだろうか。Webセキュリティでいうような認証機能の回避とか、入力値の検証が不十分とか、人の悪意によって及ぼされる影響が想定されていない安全システムがあるということ？こう考えると、危険な状況に成り得る産業と考えられていなかったものが、サイバーセキュリティ脅威、つまり人の悪意を想定することで危険な状況に成り得る産業/環境といえるものも現れそうな気がする。
それとも、安全システムがITの現場でいうEDR、SOC的な立ち位置で実際には浸透しきっていない面もあるのだろうか。それはそれでヤバそうだ。
組織は、人間に対する安全性へ影響を与えるサイバーセキュリティの脅威分析を行い、緩和策の導入を検討すべきと。ITシステムならば、リスク軽減策としてセキュリティ対策製品を導入し、それによって情報セキュリティのCIAのような部分がある程度守られる。OTシステムだと安全性も考えなければならないので、どうやって危険な状態に陥らないようにするか、危険な状態になったらどうするかの対策も考えがえなければならない。OTシステムは殊更に大変そうだ。ただ、一方でOTシステムはセキュリティ対策を導入しようがない、もしくはどうしてもできない面もある気がするので、そういう点は大きな括りで見るとITシステムよりもセキュリティ対策にお金がかからなかったりするのだろうか。
Additionally, the nature of OT systems requires organizations to consider additional factors that may not exist when conducting risk assessment for a traditional IT system. For example, OT will have different threat sources, vulnerabilities, and compensating controls than IT.
OTセキュリティではITのセキュリティと異なる脅威、脆弱性、対策が存在する。
脅威という部分では、可用性が最も重視されるOTシステムなので、ITシステムとは問題なり得るような事象も全くことなることは想像に難くない。また、最近知ったがOTシステム特有のマルウェアや脅威アクターが存在する。この辺の話は、別のブログポストで扱いたい。
脆弱性という部分では、OTシステム全体からして異なるものはあるだろうが、機器のレベル、技術的なレベルとしては特に変わらないのではと考えている。
対策という部分で、ここまでのNIST SP 800‑82r3の説明からITシステムとは異なる考え方が必要というのは既に分かっていること。
OTシステムを持つ組織がサイバーインシデントによる潜在的な物理的被害を評価する際に考慮すべきこととして、以下の3つが挙げられている。
- サイバーインシデントがどのように運用に変化をもたらして物理環境に影響を与える可能性があるか
- OTシステムに影響を防止または軽減するための設計上の機能がどのように存在しているか
- これらの条件に基づいてどのように物理的なインシデントが発生する可能性があるか
先ほども同じような話をしたが、OTシステムを構築する際にサイバーセキュリティ以外の何らかの脅威によるシステムへの影響はある程度考慮されているのでは？
であれば、2や3はある程度既に存在すると考えている。危険な状態になるのを防止・軽減する仕組みがあり、サイバーセキュリティ的脅威が原因であることに関わらず、システムの異常によってどのような物理的なインシデントが起きるかは想定されていると。
なので、もしかすると場合によってはサイバーセキュリティの考えを加えるだけで直ぐに評価が終わってしまうような環境も多い可能性があるのでは？
ただ、繰り返しになるがサイバーセキュリティ的脅威を考えることで危険な状態になりやすい、なり得る状況が発生するような環境もあるような気がする。
ところで、OTシステムのセキュリティ評価はどれほど難しいのだろうか。
ITシステムであれば、サイバーセキュリティのCIAを基にどのように影響が出るのか評価する。評価の方法はある程度広まっているし、形作られた、固まったものがある。一般的に多くある脆弱性というものが知られており、それらが悪用される手法や脅威も知られている。システムの構成としても同じようなものが多く、それらに対する脅威や脆弱性も似たようなものになることが多い。
対してOTシステムであればどうだろうか。サイバーセキュリティのCIAの中で、特に可用性について考慮する必要があり、さらに安全性というITシステムではあまり考えられなかったものが入ってくる。可用性もそうだが、安全性というのがどのように脅かさせれるのか。CIAと安全性が関わってくることもあれば、安全性のみへの影響を考えるかもしれない。OTシステムでも構成によって、可用性や安全性にどのような事象が影響を与えるのか全く異なる可能性がある。
そのような中で、評価の方法は広まっておらず、しっかり形作られ固まったものは無いように思える。
脆弱性は技術的には、ITシステムと同じものもあるが異なるものもある。それらを悪用する手法や脅威は、あまり知られていないと思われる。そもそも、攻撃されるという意識が無いからこそセキュリティの意識が広まっていないとも言える。
他の話だが、個人的には悪用手法が広まっていないからこそ、インターネット上に公開されている無防備なOTシステムが不正アクセスによる影響をあまり受けていない印象がある。
システムを構成する機器は、OTシステムで同じようなことが多い印象があるが、目的や用途はシステムごとに全く異なると考えている。そのような環境ごとに全く脅威が異なるものに対してのセキュリティ評価は、ワクワクする。
OTシステムは、その特性？特徴？構成上？、セキュリティ的に対策すべきところがいくつ見つかったとしても、受け入れざるを得ないセキュリティ的欠陥は必ず存在すると考えている。セキュリティ評価の結果、どのようなレベルでの脅威・危険性であっても、組織にとっての許容度、優先順位、トレードオフという言葉がITシステムよりも多く飛び交いそうだ。
4.1.2 Assessing Risk in an OT Environment
ここらからは、リスク評価の話に入る。
組織としてのリスク評価では、脅威と脆弱性、それらが引き起こす可能性のある損害、脅威と脆弱性によって悪影響が発生する可能性を特定する。
リスク評価には、やはりITシステムでは考えもしなかったことを考える必要があったりする。例えば、サイバーセキュリティ的脅威がサイバー的/デジタル的影響だけでなく、物理的影響としてどのように現れるか等。
このような点に関しては、OTシステムのセキュリティ評価はITシステムよりもさらに評価の信頼性であったり、経験や知識が重要になってくると思わせる部分だと感じている。ITシステムでは、セキュリティ評価、脆弱性評価が網羅できていなくとも何かあった際に人命に直結するなど重大になりすぎることが無かったり、そもそも不正アクセスが起きてもシステム上の問題であり現実には影響が無いことが多い。であれば、気づかれない内に影響が出ており、攻撃者が目的を達してもなお気づかれずに収束している可能性がある。このような状況だからか、セキュリティ評価を外部に委託し、後の問題によってセキュリティ評価を行った企業が責任を問われるような事例は聞いたことが無い。
しかし、OTシステムでは、サイバーセキュリティ的脅威により現実に影響が出る。なおさら、評価の信頼性が重要になり、中途半端な評価は重大な事故を引き起こしかねない。ITシステムに対する脆弱性評価を行うサービスは、費用もレベル感も、とんでもなくまちまち。費用が高いから良いサービスというわけではなく、安くてとても悪いサービスも普通に多い。そんなサービスの状況がOTシステムの評価に入ってきたらヤバそうだ。OTシステムの知識がなく、ITシステムの経験を基にOTシステムのセキュリティ評価なんてやってしまったら、後々に大事故が起こるに決まっている。
ここでは、OTの一般的な脆弱性の例として、いくつかが示されている。
- 不適切なコーディング手法(Poor coding practices)
ここでいうコーディングは、主にPLCなどの機器管理・制御におけるプログラミング可能な箇所における脆弱なコーディングという話だと考えている。もしくは、OTシステムに利用される機器自体が動作するためのOSやプログラム自体の脆弱性に関わる部分も含まれる？ - 不適切なネットワーク設計(Poor network designs)
おそらく、しっかりネットワークセグメンテーションをしましょうというお話。産業環境のネットワークは、平坦なものが多いと聞く。FWやデータダイオードを挟みましょう。 - 不適切なデバイス設定(Poor device configurations)
デバイスをデフォルトで使う、セキュリティ機能を有効活用していない場合にはリスクが伴う。サイバーセキュリティ的脅威を考えた際には、有効にしなければいけない項目があるハズ。 - 脆弱なネットワークサービスやプロトコル(Vulnerable network services and protocols)
ITシステムでいうならば、暗号化されていないTelnetやHTTPは危ないというようなお話かと。OT系通信プロトコルとしてよく出てくるModbusやDNP3など、暗号化が想定されていないものが多い。なので、サイバーセキュリティ的脅威を考えた際には、それらをどのように扱っていくか、どのように監視していくかを考えるということ？ - 脆弱な認証 (Weak authentication)
ここでいう認証(authentication)が認証機構(ログイン機能、認証情報の検証方法など)なのか、認証情報(パスワード桁数、パスワード文字種)なのかは明確に分からない。が、どちらにしても認証機構や認証情報が脆弱なものにならないようにしようという話だと考えている。 - 過剰な権限(Excessive privileges)
ユーザ、アカウントには不必要に過剰な権限を与えない。面倒だからといって、全て管理者権限ユーザで運用、パスワードなんか要らないというようなことにすると、どこか一点が不正アクセスで侵害された際に一気に被害範囲が広がる。そういったことを防ぐ、そもそも侵入されにくくするために重要となる。 - 不適切な情報公開(Information disclosure)
特に考えずにデフォルト設定で利用していると公開不要な情報を不特定多数に大っぴらにし続けていることがある。そのようなところから、大きな被害に繋がる不正アクセスが始まることも多い。もしくは、業務効率などということから、公開しっぱなしなことも。セキュリティ評価で、ネットワークに繋がる機器が、どこから、どのように見えているのかを確認すべき。
先にも述べたが、OTシステムは目的や用途によって、セキュリティ評価内容、評価結果が大きく異なる。もしかすると、運用される自然環境といった要素も関わってくるかもしれない。OTシステムには、様々な条件があるハズなので、例えば以下のようなことを考える必要がある。
- OTシステムの安全性、人命、および運用継続に直接関係する物理資産とセキュリティ対策
- OTシステムの機能を脅かす可能性のある物理資産に関連するサイバーセキュリティリスク
- 物理的なセキュリティ担当者が、自身が守るOTシステム環境に関わる相対的なリスクと物理的セキュリティ対策を理解しているか
こういったOTシステムごとの特徴を洗い出したうえで、セキュリティ評価に臨む必要がある。そうでなければ、中途半端な評価となってしまい、後々の重大な事故に繋がりかねない。
上記の3点のような話を聞くほど、OTシステムのセキュリティ評価は、「OTシステム(技術)の評価」ではなく「OTシステム(技術、管理、組織)の評価」という意味合いが強いのではと考える。OTシステムを構成する機器の評価でもセキュリティ評価といえるだろうが、「サイバーセキュリティ的脅威の存在」、「脅威の発生可能性」、「脅威による物理的影響度」を考えるには機器だけを見ても分からない。実際の現場環境、運用体制、組織的な管理状況など、セキュリティ評価の対象としても物理的環境を考える必要がありそうだ。
リスク評価の際に考慮する既存の対策という点について触れられている。既存の対策としては、OTシステムと接続されているものもあるが、システムから独立しておりその場にいないと確認できない・動かせないようなものがある。確かにそういったものがあった方が、サイバーセキュリティインシデントの際には絶対に活躍できる。まぁ、それらはサイバーセキュリティインシデントを想定したものでは無く、緊急の際の最後の手段として手動で操作するために用意されたものだろうが。
- アナログ表示またはアラーム(Analog displays or alarms )
非デジタル表示（温度計、圧力計など）やアラーム(音での警報)を通じて、デジタルでの情報取得機構が利用できない場合でもオペレータが情報取得できるようにする。 - 手動での制御機構(Manual control mechanisms)
OTシステムが使用不能な場合でも、手動で操作可能なバルブや物理スイッチを用意しておく。 - アナログな制御システム(Analog control systems)
デジタルな環境と接続されていないような制御システムもOTシステムのデジタルな部分が機能しないときに有効となる。レギュレータ、ガバナ、電磁リレー、圧力逃し弁、真空逃し弁など。
しかしながら、アナログな機構は現地に赴かなければ操作できないなど、インシデント際が実際に起こった際に考慮しなければ物理的な壁が存在していることも考えなければならない。そう考えると、対策は存在しているだけではダメで、実際にどのように運用されるか、どれほど効果があるかもOTシステムの評価においては重要になってくる訳だ。
4.1.3 Responding to Risk in an OT Environment
少し異なる話だが、OTシステムで何らかの事故が発生した場合には、それがサイバーセキュリティ脅威によって引き起こされたとどうやって分かるのだろうか。
サイバーセキュリティ脅威によって、物理的環境に影響が出ることは分かるが、それがサイバーセキュリティ脅威起因だということに通常気づくのだろうか。ニュースとしては、ある工場で機械の故障があって在庫が枯渇している製品があるとか、ある工場で爆発が起きたという話がある。それらが、サイバーセキュリティ脅威が原因だということに、サイバーセキュリティ脅威を想定していない組織が気づけるのだろうか。
何らかのネットワーク監視や機器のリソース監視はあるハズで、その監視機構の中でこれまでの想定でありえないような数値を示したとする。サイバーセキュリティ的脅威のための監視機構がある、サイバーセキュリティ的視点の監視を行っていれば気づけるかもしれない。しかし、そういった想定がされていない組織では、実はこれまでに実際に不正アクセスが原因で起こっていた障害も原因不明で終わっているのではないだろうか。
話は変わって、リスク対応の一部としてOTシステムのインシデント対応について考えてみる。
ITシステムでは、セキュリティインシデントが発生した際に作業機器を準備して対応する。それらは、インシデント対象機器を保全するための機材であったり、調査用PCなど。
ここで、OTシステムでは何か特別な準備が必要なのかと気になった。簡単に調べたところ、以下のような記事を発見した。
www.dragos.com
この記事の「Essentials for Industrial Cyber Incident Response Toolkits」に注目すると、以下のようなITシステムでの対応では現れないようなものが含まれている。
- ヘルメット(Hard hat)
- 安全ゴーグルまたはメガネ(Safety goggles or glasses)
- 先芯入り安全靴(Composite toe safety shoes)
- 耳栓などの聴覚保護具(Hearing protection)
- 上着、ズボンの耐火作業服(Fire-resistant clothing (including undergarments and outerwear))
OTシステムは、どのような環境で稼働しているか分からない、インシデントでどのような物理的影響が出ているか分からない所にインシデント対応者が向かう可能性があるため、このような準備が必要なのだろうか......?
4.1.4 Monitoring Risk in an OT Environment
異常によって危険な状態になり得るOTシステムは、常に監視しなければならず、組織はそれらに対する様々なモニタリングを行っているハズ。その監視の機能や視点にサイバーセキュリティ的考えが入っているのかどうか。現状は入っていない組織が多そうなので、サイバーセキュリティ的観点を取り入れた監視を行っていかなければならない。技術レベル、規模的、リソース的に組織で対応できないならば外部のサービスや人員に頼ることになりそうだ。ここで、気になることが1点。OTシステムに対するSOCサービスは、一体どこまで対応するのだろうか。
ITシステムに対するSOCサービスは、どこまで対応するかサービス形態によって異なるだろう。個人的な一般的イメージとして、対象機器から取得するログを監視、不審な動きがあれば対象組織に通知するとこまでのものが多いか。その後、初動対応をするのか、簡易的な調査をするのかはサービス次第で、詳細な調査は都度別見積もりになるハズ。
では、OTシステムに対するSOCサービスはどうだろうか。何らかのログを監視して、不正アクセスを検知すれば通知するようなサービスではあるはず。検知した時点で物理的影響が起きていないのであれば、ITシステムに対するサービスと同じようになりそうだ。が、検知時点で物理的影響が出ている場合には、その影響に対するサポートもあるのだろうか。SOCサービスの体制によっては、現地で何が起こっているかを把握しているかもしれない。そうなると、現地の危険な状態を通知する、場合によっては消防車など緊急車両の手配も入ってくる？？？初動対応の話を考えると、状況把握や現地での作業に肉体労働も入ったり？？？OTシステムのSOCサービスというのをITシステムのSOCサービス基準で考えると、ログの監視だけで十分とは思う反面、検知まで・検知後に起こったことをどこまでサポートできるかも含めてサービスの質に関わってくるかもしれない。と考えてしまう。
4.2 Special Areas for Consideration
4.2.1 Supply Chain Risk Management
ここでいうサプライチェーンは、他のところでもよく言われる話と同様のこと。OTシステムで利用する機材、生産するもの、取引先などに関連するものの中の様々な箇所にサイバーセキュリティリスクは潜んでいる。そういった部分もセキュリティ評価に組み込んでいきたい。
サプライチェーンのセキュリティ体制を確認・評価することが推奨されるとよくよく言われるようになってきている訳だが、最近は「自社のサプライチェーンに連なる取引先のサプライチェーンも評価すべきでは」なんて声もあったりする。
サプライチェーンのサプライチェーンのサプライチェーンのサプライチェーンの......。
4.2.2 Safety Systems
危険な状況になる可能性があるOTシステムは、危険な状態を防止・軽減するような機能が存在する。しかし、その安全システムにはサイバーセキュリティ観点が含まれていない。
サイバーセキュリティ脅威に対して、安全システムはカバーできていない、回避されてしまう、停止されてしまうといった環境であることから機能しないことがあるかもしれない。サイバーセキュリティ的脅威を踏まえて、安全システムを考え直すべき。
4.3 Applying the Risk Management Framework to OT Systems
基本的には、NIST Risk Management Framework (RMF) を適用するとのこと。書いてある通りなので、特になし。OTセキュリティを考える際に重要なIEC 62443の2-1も踏まえて考えましょうとのこと。
