Sky Breaker

Hacking Celestial Wisdom with Skill and Technique.

NIST SP 800-82を読んだメモ書き(6) Appendix C. Threat Sources, Vulnerabilities, and Incidents

NIST OT

Appendix Cには、OTシステムに対する脅威、脆弱性、インシデント事例が紹介されている。
個人的には最も面白い章である。

C.1 Threat Sources

ここでは、脅威源として大きく分けて4種類が挙げられている。

  • 悪意を持つもの(ADVERSARIAL)：意図的に損害を与えようとする個人、組織、国など
  • 偶然発生したもの(ACCIDENTAL)：操作ミス、連絡不足など
  • 設備・システムの欠陥(STRUCTURAL)：ハードウェア・ソフトウェア故障、環境制御の不備、通信の劣化など
  • 外部環境によるもの(ENVIRONMENTAL)：自然災害、人為的災害、通信や電気といった重要インフラの障害など

1つ目の悪意を持つもの(ADVERSARIAL)は最も分かりやすい。悪意を持って損害を与える存在。分かりやすく言えば、ハッカー、犯罪グループ、ハクティビストといった外部の脅威や内部犯も考えられる。ところで、OTシステムに対する外部の脅威というのが居るというのは分かるが実際どれくらいの攻撃者がいるのだろうか。
ITシステムに対する攻撃、不正アクセスによるインシデント事例は毎日のように多くのニュースが出回っている。ランサムウェア被害、Web改ざんなど様々。
対して、OTシステムや産業システムに対する攻撃のニュースは全く聞かない。国家間の戦争時に工場や発電所などの重要インフラが、サイバー攻撃によって被害を受けた話は出てくるが平時だと殆ど聞かない。ShodanのICS関連のページを見ると分かるが、OT系システムは割とインターネット上に公開されている。なので、OT系システムが全く外部から攻撃を受けないということではなく、不特定多数の第三者から攻撃を受ける可能性はITシステムと変わらない。OTシステムが被害を受けると、ITシステムとは比にならない目に見えた被害が発生するため間違いなく話題になるように思える。それでも、話題にならない1つの原因としてはOTセキュリティの意識にあるかもしれない。以前にも挙げた話だが、まだまだOTシステムがハッキングされるという想定がされておらず、何かしらのOTのシステム障害や障害とまでもいかない不具合が原因不明のまま終わっている例が多いという現状の可能性を考えている。
一方で、人によってはOTシステムは攻撃が難しいために目に見えるインシデントといえる被害を引き起こせる攻撃者が少ないという意見もある。確かに、インターネット上に公開されているといっても、OTシステムごとに役割や目的が全く異なり、被害を起こせる手段も異なる。公開されているものに侵入しても、操作できるのが一見すると意味不明な何らかの数値だけのこともある。自身が今どのようなシステムを攻撃していて、何をすれば次の行動に移れるかというのはITシステムよりも圧倒的に困難なのではないかと考えている。

2つ目の偶然発生したもの(ACCIDENTAL)というのは、意図的ではない出来事というのが全て。技術的なミスや人同士の関わり合いで起こるもの。人的ミスでシステム障害というのは稀に聞くが、OTシステムの場合には人的ミスで復旧できないレベルの被害を受けて倒産というのが想像しやすいのでシャレにならない。

3つ目の設備・システムの欠陥(STRUCTURAL)というのは、先の通り故障、環境制御の不備、通信の劣化など。初期不良や老朽化でハードウェアで異常が発生するかもしれないし、開発者が予想していなかったり意図していないようなことが原因でソフトウェア異常が発生する可能性もあり得る。発生原因というのが、開発者のうっかりミスの可能性というところまでフォーカスするとACCIDENTAL、もしくは場合によってはADVERSARIALに該当することもあるかもしれない。
環境制御の不備というのは、機器自体の発熱や冷却機構に不備がある、または機器が稼働している空間の温度、湿度、ほこり、振動、電力供給などの環境整備がされていないようなことを指すと考えている。
通信の劣化は、単純に有線・無線の通信経路で電波的な障害やハードウェア的な問題を原因として悪影響が生じること。

4つ目の外部環境によるもの(ENVIRONMENTAL)というのは、自然災害やOTシステムを管理する組織ではどうにもならないような重要インフラの障害。どうにもならない。

C.2 Vulnerabilities and Predisposing Conditions

ここでは、脆弱性と潜在的な原因(Predisposing Conditions)？という言い方をしている。「the source of vulnerabilities」や「that(vulnerabilities) causes」という表現があるので、おそらく潜在的な原因はより根本的なもの。
大きく分けて2種類の脆弱性に関して解説されている。

  • ポリシーや手続きの脆弱性(Policy and Procedure Vulnerabilities)
  • システムの脆弱性(System Vulnerabilities)

C.2.1. Policy and Procedure Vulnerabilities and Predisposing Conditions

セキュリティポリシーが不十分なことが潜在的な原因であり、脆弱性となり得るという話。
例として以下の13個が挙げられている。

  • リスク評価に対する組織的な責任の欠如
  • OT向けセキュリティポリシーの不備
  • OTセキュリティトレーニングおよび意識向上プログラムの不備
  • 資産管理ポリシーの欠如
  • 構成管理ポリシーの欠如
  • OT機器導入ガイドラインの不備
  • セキュリティポリシー実施のための管理規程の欠如
  • OTセキュリティ管理策の有効性レビューの不備
  • OT専用のインシデント対応計画の欠如
  • 適切なアクセス制御ポリシーの欠如
  • 適切な認証ポリシーの欠如
  • インシデント検出および対応計画・手順の不備
  • 重要コンポーネントの冗長性の欠如

C.2.2. System Vulnerabilities and Predisposing Conditions

システムに関わるものを大きく分けて6種類、45の例が挙げられている。

脆弱性と記載されているが、セキュリティの考慮事項であったり、攻撃

アーキテクチャおよび設計上の脆弱性

ここで挙げられている6つの例は、システム全体やネットワーク利用における脆弱性。

  • システムやネットワークを構築する際にセキュリティ対策が十分に考慮されていない
  • 不適切な変更管理による脆弱な範囲の拡大
  • セキュリティ境界が定義されていない
  • OT系ネットワークをそれ以外のIT系ネットワークなどと共用している
  • OT系システムがそれ以外のIT系システムなどに依存している
  • システム内で発生した重要なイベント（例：ログイン履歴、エラー、設定変更など）のログが十分に収集・保存されていない
設定およびメンテナンス上の脆弱性

ここでは管理に関する脆弱性の例が19個挙げられている。

  • 資産管理に含まれないハードウェア、ファームウェア、ソフトウェア
  • 構成管理されていないハードウェア、ファームウェア、ソフトウェア
  • ベンダーのセキュリティアップデートは、脆弱性が発見されてからかなり遅れて開発される場合がある(脆弱性？)
  • ベンダーが脆弱性に対するパッチ開発を拒否する場合がある
  • 脆弱性管理体制が無い
  • セキュリティ関連の修正や設定変更のテストが不十分
  • リモートアクセス制御が不十分
  • 不適切な設定（例：不要な情報の公開、不要なサービスの有効化）が使用されている
  • システム運用に不可欠な設定情報が適切に保管またはバックアップされていない
  • 持ち運び可能なデバイスに保存されたデータが保護されていない
  • ベンダーのデフォルトパスワードが使用されている
  • ポリシーに準拠していないパスワードの運用
  • 不適切なアクセス制御
  • 不適切なデータ連携
  • マルウェア対策の機能がインストールされていない、または最新ではない
  • マルウェア対策の機能が十分なテストなしで実装されている
  • Denial of service (DoS)
  • IDS/IPSが導入されていない
  • ログが管理されていない
物理的な脆弱性

ここでは、ハードウェアに対する直接的な脅威やその対策の不足といった5つの例が挙げられている。

  • 許可されていない担当者が機器に物理的にアクセス可能
  • 無線周波数、電磁パルス (EMP)、静電気放電、電圧低下、電圧スパイクによる機器への干渉
  • バックアップ電源がない
  • 環境条件が管理できない状態になる
  • 物理ポートが保護されていない
ソフトウェア開発における脆弱性

以下は開発側が考える必要があるような脆弱性の3つの例。

  • 入力されたデータの検証不備
  • インストールされたセキュリティ機能が有効になっていない
  • 認証機構、権限管理、アクセス制御が不十分
通信およびネットワーク設定の脆弱性
  • データフロー制御がされていない
  • ファイアウォールが存在しないか、設定が不適切
  • ファイアウォールおよびルーターのログが不十分
  • 標準的に利用され、十分に文書化された通信プロトコルが暗号化なしで使用されている
  • ユーザ、データ、またはデバイスの認証が不十分
  • セキュアでないOTプロトコルが使用されている
  • 通信における整合性チェックがない
  • 無線クライアントとアクセスポイント間の認証が不十分
  • 無線クライアントとアクセスポイント間のデータ保護が不十分
センサ、フィールドデバイス、資産管理における脆弱性

C.3 Threat Events and Incidents

ここでは、実際に発生したOTシステムに関わるインシデントが紹介されている。
C.2では、脅威源として悪意を持つもの(ADVERSARIAL)、偶然発生したもの(ACCIDENTAL)、設備・システムの欠陥(STRUCTURAL)、外部環境によるもの(ENVIRONMENTAL)の4つに分類した。ここでも、4種類の脅威源に分けて例が挙げられている。紹介されているインシデント事例では、さらに以下の4種類の情報により原因をより明確にしている。

  • [M]=悪意のある行為(Malicious)ー＞OTシステムや関連したシステムに対して何者かが悪意を持って行った
  • [N]=悪意は不明(Non-malicious)ー＞インシデントを引き起こす意図が確認されていない
  • [D]=直接的な影響(Direct)ー＞OTシステムが直接被害を受けた事例
  • [I]=間接的な影響(Indirect)ー＞OTシステムが直接狙われた訳ではなく、被害を受けた関連システムやインフラから影響を受けた事例

C.3.1. Adversarial Events

以下は、悪意を持つものによる事例

[M][D] Marconi wireless hack

1903年6月4日にイギリスで発生した事件。
無線技術の発明者Guglielmo Marconi氏が、長距離の安全な無線技術のデモンストレーションを行おうとしていた。デモでは、Marconi氏がイギリスのコーンウォールからロンドンの王立研究所までメッセージを送信することが予定されていた。しかしながら、Marconi氏ではない何者によって、Marconi氏を侮辱するものや意図しないメッセージが王立研究所で出力されてしまった。
このときの犯人は、Marconi氏のライバルであるNevil Maskelyne氏であった。Maskelyne氏はMarconi氏のシステムが安全ではないと考え、その欠陥を暴露しようとしていた。
この事件が起こってしまった原因の一つは、Marconi氏がデモで使用していた受信機が非同調式受信機(non-syntonic receiver)であったこととされている。Marconi氏は、実際に提供する無線通信のサービスにおいて、特定の周波数のみで通信する同調式受信機(syntonic receiver)を利用するとしていたが、デモでは周波数がフィルタリングされない非同調式が利用されていた。そのため、Maskelyne氏が行ったことはデモの会場から遠くない場所に送信機を設置し、Marconi氏の信号よりも強力な信号を送信することで、出力されるメッセージの改ざんを成功させた。
この出来事によって、各国機関が無線技術にセキュリティをより意識するようになったとされている。

参考:

[M][I] Worcester air traffic communications

1997年3月10日にアメリカのマサチューセッツ州ウースターで発生した事件。
この町で音声・データ通信などの電話回線サービスを統合管理している「ループキャリアシステム」というシステムが存在していた。このシステムに対して、マサチューセッツ州ウースターの十代の少年が自宅のコンピュータからシステムを無効化するコマンドを送信し、ウースター空港の航空交通管制システムを混乱させた重大な事件が発生した。
このシステムは、電話会社がリモートでメンテナンスを行うために遠隔から操作可能であった。 犯人は、ループキャリアシステムに接続されたモデムの電話番号を特定し、ループキャリアシステムにアクセス、システムを停止させるようなコマンドを送信したとされている。 ループキャリアシステムの停止により、音声・データ通信などの電話回線サービスが利用不可能になった。これにより、サービスを利用していた個人や企業が電話回線を利用できなくなってしまった。 ウースター空港の関連施設も電話回線サービスを利用しており、連邦航空局タワー、空港消防署、空港警備、気象サービス、民間航空貨物会社などの連携が途絶えた。そのほか、タワーで利用されていた無線機や航空機の滑走路灯を操作するシステムなどが動作不能となってしまった。
このときの犯人は10代の少年であったが、経済的損害を引き起こしただけでなく、公衆衛生や人々の安全を脅かした。こういったことから、連邦裁判所にて起訴された。

参考:

[M][D] Maroochy Shire sewage spill

2000年にオーストラリアのマルーチー・シャイアで発生した事件。
元従業員が下水処理の制御システムにリモートで侵入し、近隣の河川や公園に下水が流出した。
犯人のVitek Bodenは、マルーチー・シャイア議会からの依頼で無線制御の下水処理システムを設置したHunter Watertech社の従業員であった。しかしながら、Bodenは会社や上司との関係が悪化し退職。その後、マルーチー・シャイア議会の職に応募したが不採用となった。このため、議会とHunter Watertech社に対しての復讐を企てた。
Bodenは盗んだ無線機、SCADAコントローラー、Hunter Watertech社製の制御ソフトウェアを使用し、確認されている限りで2000年2月28日から4月23日まで少なくとも46回に渡って下水ポンプ施設に不正なコマンドを送信したとされている。下水ポンプ場を車で回り、無線通信の届く範囲でシステムを停止させたり、警報が報告されないようにしたり、通信を途絶させた。これにより、80万~100万リットルの未処理の下水が公園、河川、ホテルの敷地などに放出された。この影響は、経済的損失だけでなく、悪臭、生物の死滅など環境への大きな影響を与えた。
対象のシステムは、システムへのアクセスの難しさで守られていたのみであり、真にセキュリティ的な意味合いで守られてはいなかったらしい。アクセスするためには、周波数とプロトコル(推定ではDNP3)、ノード番号、ユニット番号などを知らなければいけないが、内部犯であれば仕様さえ分かるといつでもアクセスできる状態であった。
この事件は、内部犯による重要インフラに対するサイバー攻撃として最初に広く知られた事例の一つとされている。

参考:

[M][I] Night Dragon

McAfeeによって2009年に活動が確認された脅威アクター「Night Dragon」に関する話。
世界中の石油、エネルギー、石油化学製品企業を標的としたサイバー攻撃が確認された。侵入方法はスピアフィッシングやWindowsOSやVPNの脆弱性の悪用といったよくあるITシステムへの攻撃方法となっている。ただ、この脅威アクターが収集していたファイルは稼働中の石油•ガス田の生産システムに関するもの、SCADAシステムのデータ、油田の探査および入札に関連する財務文書に集中していた。MacAfeeのレポートでは、OTシステムに重大な影響を及ぼした報告は無いが、OTシステムを含む重要インフラに対する脅威を示した事例である。

参考:

[M][D] Iranian centrifuge, Stuxnet

2010年にマルウェアの正体が確認された皆さんご存じ「Stuxnet」。
2010年の6月にイランの不可解な動作をするPCを調査した際にマルウェアが発見された。このマルウェアは、イランの原子力に関連する施設で利用される遠心分離機という機器を標的としていた。
「Stuxnet」は、国家が背後にいるような高度なサイバー攻撃に利用されたマルウェアの事例として話に挙がることが多いが、OTシステムに対する脅威ということでOTセキュリティを語る中では必ず触れられる。インターネットに繋がっていないエアギャップネットワークの端末に対して、USBに感染することで侵入し、Windowsの複数のゼロデイ脆弱性を活用していた。拡散は無差別であったが、攻撃コードの実行はPLCを制御するためのSiemensのソフトが実行されているPC上でのみ行われ、対象としていたPLCは特定のCPU、特定の通信モジュール、特定の範囲の周波数で動作する周波数変換器を利用していたものであった。
これぞ、国家的な活動の可能性がみられるサイバーウェポン。

参考:

[M][D] German steel mill attack

2014年に発生したらしいドイツの製鉄所での事件。
詳細は公表されていないが、攻撃者が製鉄所の高炉を制御不能にしたことで甚大な被害をもたらしたらしい。
侵入は、スピアフィッシングと高度なソーシャルエンジニアリングから始まり、オフィスネットワークに接続した。そして、制御システムのネットワークに接続し、様々な操作を行った。らしい。詳細不明。

参考:

[M][I] Shamoon

2012年にサウジアラビアの企業で確認されたマルウェア。
サウジアラビアの国営石油会社サウジアラムコがサイバー攻撃を受けた。このマルウェアは、ハードドライブにアクセスしMBRやパーティションテーブルの書き換え、削除ファイルの上書きなどを行うワイパー系のマルウェアであったらしい。
このマルウェアの活動により、石油関連ネットワークには影響がなかったものの、業務ネットワークではデジタルな活動できずアナログな手段に頼らざるを得なかった模様。

参考:

[M][D] New York dam

2013年にアメリカのニューヨーク州ライブルック近郊にあるダムで起こった事件。
インターネット上に公開されていたダムを制御するSCADAシステムに侵入された。これによって、ダムの状態や水位と水温に関する情報、水位と流量を制御する水門の状態等などを取得した。水門を制御することが可能であったため、周辺地域に甚大な影響を及ぼす可能性があった。が、定期メンテナンスのためにオフラインであったために大きな影響は無かったらしい。
この攻撃はイランのイスラム革命防衛隊に所属するハッカーによるものであったと判明したことから、「新しい戦争の形態」として警鐘を鳴らす事件として認識された。

参考:

[M][D] Dragonfly campaign, Havex

2013年に確認されたマルウェア。
「Dragonfly」と呼ばれたグループがRATとしての機能を持つ「Havex」と呼ばれるマルウェアを使用して、制御システムでのネットワークに接続している端末やOPCサーバの情報収集を行った。直接的な影響は情報収集の他には確認されていないが、大規模なスパイ活動とされている。
攻撃者は、正規のベンダーのWebサイトを改ざんし、Havexマルウェアを含む正規のソフトウェアを様々な企業にインストールさせた。「Havex」はインストール後にTCPポート44818、105、502で動作する端末をスキャンした。

参考:

[M][D] Ukrainian power grid, BlackEnergy3

2015年12月23日にウクライナで発生したマルウェアによるインシデント。
攻撃者は、電力を管理するシステムに侵入し、複数の変電所でブレーカーを操作したとされている。これにより、約22万5000人以上の顧客が影響を受けた。
この攻撃に関連して、スピアフィッシングなどでRATの機能を持つ「BlackEnergy3」というマルウェアが展開され、情報収集や横展開に使用されたとみられる。次に「KillDisk」というワイパー系のマルウェアがHMIのファイル削除、攻撃者によるシリアルイーサネットデバイスのファームウェア書き換え等によって復旧を遅らせた。
このインシデントは、大規模な電力網に対する最初のサイバー攻撃として知られている。

参考:

[M][D] Ukrainian power grid, Industroyer

2016年の12月17日にウクライナで発生した電力網への攻撃。
後に、このサイバー攻撃に利用されたマルウェアがESETによって「Industroyer」と名付けられた。 このマルウェアは、IEC101 , IEC104, IEC61850, OPC DAで通信を行う機器を探し、機能を停止。それらを管理するWindowsの端末のデータを削除するような機能を備えているらしい。 ちなみに、Dragosが「CRASHOVERRIDE」と名付けたものは殆ど同じものとされている。
電力網を攻撃するために特別に設計された最初のマルウェアとして知られているらしい。

参考:

[M][I] Maersk, NotPetya

2017年に起きたランサムウェアグループ「NotPetya」によって、世界的な海運物流企業のMaersk社が被害を受けた。
「NotPetya」は初めはウクライナの企業を標的にしていたが、後に世界中の企業を標的にするようになり 、Maersk, FedEx, Merck, Saint-Gobainといった企業が被害にあったらしい。(個人的にはFedExしか知らない)。Maersk社の場合は、世界各地で積み荷が停滞したことで農産物の腐敗や荷物の行方不明など壮絶だったらしい。
「NotPetya」は暗号化を行ったと見せかけて、ファイルが元に戻ることのない改ざんを行っていた。

参考:

[M][D] Saudi Petrochem, TRITON

2017年にペトロ・ラービグ社で発生した予期せぬ自動シャットダウンを発端として発見されたマルウェアの話。
当時のFireEyeによって「TRITON」と名付けられたマルウェアは、SISコントローラを改ざんする機能を持っていたとのこと。しかしながら、おそらく攻撃者のミスによって冗長化されたSISコントローラでコードの検証に失敗し、OTのプロセスがセーフシャットダウンを開始してしまった。セーフシャットダウンの異常は6月と8月の2度発生し、二度目のインシデント調査にて外部からの攻撃の可能性を考え、調査した結果マルウェアが発見されたらしい。
これは、OTシステムにおいて事故が起こった際に被害を軽減する安全システム(SIS)を改ざんし、被害拡大を狙った事例といえる。このときに調査を行った当時のFireEyeの専門家は、「この活動は、国家が攻撃を準備しているものと一致すると我々は考えている」と述べたらしい。

参考:

[M][I] Norsk Hydro, LockerGoga

2019年3月18日にノルウェーのアルミニウム製造大手 Norsk Hydro社で発生したランサムウェア被害。
「LockerGoga」ランサムウェア被害を受けたNorsk Hydro社は、世界40か国の拠点に影響が及んだ。製造所にも影響が及んだようだが、注文や製造工程をどうにか手作業で行ったことで業務を継続させたらしい。
このインシデントの対応は覚知から、復旧までの対応の透明性という点で評価されている。

参考:

[M][I] Colonial Pipeline

2021年の5月7日にアメリカ最大級のパイプライン運営会社の一つ、Colonial Pipeline社がランサムウェア被害を受けた。
Colonial Pipeline社はアメリカの東海岸の地域の燃料輸送を担っていた。この企業がランサムウェア被害を受けたことで、燃料価格の上昇や一時的な買い付け騒ぎが発生したらしい。インシデントでFBIが動いたり、国家安全保障会議に持ち上がったりと、とんでもない重大インシデントとなった。
Colonial Pipeline社は75BTCを払うことで復旧対応を行ったとのこと。基本的には各国の警察機関が「身代金を払うべきではない。」とアナウンスしているが、この件では「FBIは被害者に対し、支払いの必要性を感じれば理解すると非公式に伝えることがある」という話があったらしい。また、支払ったうちの約64BTCは司法省が回収した？という話も。

参考:

[M][I] Ransomware targeting healthcare

医療分野を狙ったランサムウェア被害が増えたことから、2020年秋にCISAよりアラート(AA20-302A)が発表された。

参考:

C.3.2. Structural Events

以下は、設備・システムの欠陥関する事例

[N][D] Bellingham, Washington, gasoline pipeline failure

1999年6月10日にアメリカのワシントン州べリングハムで発生したパイプライン事故。
Olympic Pipe Line社が管理するパイプラインにて、圧力上昇が検知され漏洩が疑われる状況があった。しかしながら、実際に近隣の川に流出し、通報があるまでガソリン漏洩の事実に気づくことができなかった。ガソリン流出確認後にパイプラインを停止させたが、川沿い約2.5kmで火事が発生した。
この事故の最も大きな要因は、漏洩検知やパイプラインの監視に利用されていたSCADAの機能不全と言われている。オペレータの操作に対してシステムが正常に反応しなかった期間が確認されており、この原因が本番環境でのDB開発作業と言われている。実際には、安全弁の不具合や過去のパイプライン周辺工事によるパイプライン損傷の不適切な調査などもあったらしい。が、運用状態を監視するSCADAシステムの不具合が最終的な事件の要因と言えそうな状況とも考えられる。
ITシステムでも運用環境で行ってしまうことで、業務が停止するという不祥事は聞く。OTシステムでは良かれと思ってやってちょっと失敗してしまったかもというような事象が、エンジニアの意図しないところで重大な事件に発展するという事例とも言える。

参考:

[M][I] CSX train signaling system

2003年8月20日にアメリカの東海岸で発生した鉄道信号システムの障害。
アメリカの大手貨物鉄道会社のCSXの本社のシステムにて、マルウェア「SoBig」の感染が確認された。その影響で、CSXの管理する列車信号システム、運航管理システム等に障害が発生した。関連地域の鉄道に遅延が発生した。
ところで、「SoBig」は簡単に調べて見るとメールを勝手に送るような機能しかないように見えたが、マルウェアに感染したシステムはそれほど大きな影響を受けたのだろうか。「SoBig」は独自のSMTPエンジンを備えているいるとのことなので、その機能か、メール送信の仕組みがシステムに何らかの影響を及ぼしたのか？？？

参考:

[N][D] Browns Ferry-3 PLC failure

2006年8月19日にアメリカテネシー州流域開発公社(TVA)の原子力発電所で発生したインシデント。
TVAの管理するブラウンズフェリー原子力発電所3号機でPLCが応答不能となった。PLCの停止の原因は、過剰なネットワークトラフィックであり、過剰なネットワークトラフィック自体の原因詳細は公表されていなさそう。あるところでは、特定の産業用ネットワーク機器のバグとのこと。
PLCは二重に冗長化されていたらしいが、どちらも原因の同じネットワークに常にオンラインであったため、ダメだった。冗長化とは？？？

参考:

C.3.3. Environmental Events

以下は、避けられない外部環境によるもの

[N][I] Fukushima Daiichi nuclear disaster

2011年3月11日に日本の福島県にて地震による津波の影響を受けて発生した事件。
東北地方太平洋沖地震発生当時、東京電力の管理する福島第一原子力発電所にて1 - 3号機が運転中、4 - 6号機は定期検査中という状態であった。ここを地震の影響による津波が発電所を襲い、非常用の発電機が故障。電源が供給されないため、最終的に水素爆発による原子炉建屋や周辺施設大破、大気中・土壌・海水・地下水へ放射性物質が放出された。
「津波災害を過少評価していた」ことが根本原因とされている。NIST SP 800-82には、「発電所の緊急対応センターには、主要な安全関連機器に関する情報を発電所の他のエリアに提供するための安全な通信回線が不十分であった。」と記載があるが、そのようなシステムが十分であってもこの規模の津波に対しては結果的に同じことになっていたと言われている。

参考:

C.3.4. Accidental Events

以下は、人為的なミスも含め偶然発生したもの。

[N][D] Vulnerability scanner incidents

脆弱性診断時の事案として、2つの例が紹介されている。
1つ目は、脆弱性診断時の事前情報収集の際のpingスイープによってロボットアームが急に動き出した事例。アームのコントローラは、スタンバイモードであったとのこと。
2つ目は、ネットワーク内の端末把握のためにpingスイープを行ったところ、集積回路の製造システムが停止した。この結果、約5万ドルのウエハが破損してしまった。
どちらもOTシステムに対して知識が不足していたが故に起きた事案といえる。ITシステムであれば、ネットワーク内の端末把握のためにpingスイープによって把握できるのは通常のこと。しかしながら、OTシステムではTCP/IPの通信ができるといっても、標準化されたプロトコルをそのまま実装していない、通常起こらないパケットに対して対処できない・誤解釈されることがある。こういったことを踏まえて、ネットワークスキャンを行う必要がある。もしくは、そもそもネットワークスキャンを行うべきか、行うことによるリスクを共有したうえで実施していかなければならない。
nmap, nessusといったスキャンツールもこういった影響は、デフォルトでは考慮されていないので注意して利用、もしくはリスクを把握したうえで利用しなければならない。

参考:

[N][D] Penetration testing incident

ペネトレーションテスト時の不手際の事例。
あるコンサルティング会社がITネットワークのペネトレーションテストを行った際に、SCADAシステムと接続されていたネットワークの一部まで侵入してしまった。この影響により、対象のガス事業社は4時間パイプラインの利用が停止してしまったとのこと。
この事例からも、セキュリティ診断の担当者がOTシステムに関する知識不足の場合には重大なインシデントに繋がってしまうことが伺える。
セキュリティ評価側者には「OTシステムの一部の脆弱性も分かったので、セキュリティ評価的にさらに広範囲を診断できて良かったですね(⌒∇⌒)」と言いたい気持ちもあるが、そんなこというと担当者には殴られるだろう。OTシステムも何らかの形で対象に関わるのであれば、ペネトレーションテストの前に詳細なスコープ定義や厳密なテスト計画がより重要になってくる。それでも、実際にはスコープ外もガンガンアクセス試行していくスタイルのペネトレーションテストが主流の企業もあるようだ。(本当に大丈夫？？？)

[N][I] NERC Enforcement Action

北米電力信頼性協議会（NERC）がデューク・エナジー社に1,000万ドルの過去最高額の罰金を課した。
特にインシデントが発生したわけではないが、NERC CIPに違反したために罰金。
どこの国でもどこの業界でも、それくらいの勢いでやった方が良いと思います。

参考:

[N][D] NASA fire

NASAの施設で宇宙船ハードウェアの製造・試験に使用されている大型エンジニアリングオーブンにて重大な火災事故が発生。
ITシステム向けのセキュリティアップデートをOTシステムの一部として利用している端末に適用したことで、オーブンを制御していた端末の再起動が必要になった。そのため、再起動を行ったことでオーブンの制御ができなくなってしまった。オーブンの温度が上昇し、火災が発生、宇宙船に関わるハードウェアが破壊されてしまった。さらに、火災は3時間半もの間検知されなかったらしい。
システム的な区分けとしてITとOTを分けていなかったこと、OTシステムに関する教育が足りなかったことが根本原因。ところで、OTシステムの利用者側は、ITとOTという区別をしているのだろうか。

参考:

[N][D] Hatch Nuclear Power Plant

2008年3月7日にアメリカのジョージア州の原子力発電所にて、ソフトウェア更新が原因で48時間のシステム緊急停止
エンジニアが化学分析データと診断データの監視に使用されていた業務ネットワーク上の端末のWindowsPCにソフトウェア更新を適用した。更新後に再起動したことで、データ同期プログラムが制御システム上のデータをリセットした。これにより監視データが初期化状態となったことで、安全システムはデータの消失を原子炉関連システムの非常事態として誤って解釈し、非常停止処理が開始した。
データ同期プログラム関連の設計問題もあるが、やはりITとOTの区分け、OTシステムという認識の教育が重要な例。

参考: