公開日： ｜更新日：
SCADAセキュリティ対策はどこまで必要？
今まで、企業が受ける「サイバー攻撃」の対象は、情報の収集・蓄積・活用のために用いられる業務システムやウェブサイトが主であり、「知的財産」や「個人情報」を奪うための攻撃に限られていました。
しかし、近年ではプラントやインフラ制御のために用いられている「制御システム」もターゲットに含まれるようになり、工場の設備・安全維持のシステムにサイバー攻撃の魔の手が忍び寄りつつあると懸念されています。
制御システムセキュリティの現状
以前のプロセス制御システムは、特注して企業独自のシステムを作るのが一般的でした。工場やインフラの制御システムが、オープンな環境に接続されることはなかったのです。
アメリカ、中国、ロシアなどの制御システムはインターネット接続が基本でしたが、日本の制御システムがインターネットに接続することは滅多にありませんでした。そのため、日本の制御システムのセキュリティリスクは「小さい」とみなされてきました。
IT技術の成熟と「2つ」の懸念
近年では、TCP/IP、ワイヤレス通信などの技術が発展し、IT技術が成熟するにつれてプロセス制御システムも市販品に依存できる環境が整いつつあります。
このような技術の進展は多くの利点を企業にもたらす一方で、2つの大きな懸念も生みました。
- 今まで考えられなかった脅威にさらされる機会が増えた
今まで隔離されていたプラントが、大規模なオープンネットワークへ接続されるようになりました。
その結果として、工場・プラントはこれまでに想定していなかった脅威（ウイルス・ハッカーによる攻撃）にさらされるようになったのです。 - 制御環境サイドのセキュリティ保護対策が甘い
今までは、企業独自のプロセス制御システムを使うのが一般的でした。
しかし、オープン化が進んだ近年では、商用市販ソフトウェア・汎用ハードウェアが使われるようになってきました。
ただし、これらの技術を使う上で必須の「標準ITセキュリティ保護対策」は、プロセス制御環境で採用されていないケースが多いのが現状です。
その結果、制御システムにとって安全な環境を保てておらず、十分なセキュリティ対策が講じられていない可能性があります。
長らく閉鎖的なシステムを採用してきた日本の工場・プラントでは、IoTを受け入れる土壌が十分とはいえません。制御システムのオープン化が遅れた日本では、いまだにセキュリティリスクの認識が低いのです。
情報セキュリティの事故は「情報漏洩」が中心だと思われがちですが、工場・プラントがサイバー攻撃を受けてしまうと、機械設備の誤動作・破壊や、それによる人的／環境破壊という、スケールの大きい事故に繋がってしまうという点を理解しておかなくてはなりません。
オープン化は危険だと忌避するのではなく、オープン化を急くのでもなく、「どうすれば工場の制御を安全に保てるか」に焦点を当てていかなくてはならず、そのためのセキュリティ知識は必須です。
SCADAのセキュリティに必要な条件
『グッド・プラクティス・ガイド プロセス・制御とSCADAセキュリティ』は、SCADAをはじめとする産業制御システムのセキュリティを確保するための「優れた取り組み（グッド・プラクティス）」を普及するために作成された文書です。
この文書には、制御システムをサイバー攻撃から守るための有用なアドバイスが多く記載されており、 SCADAを使用するにあたってセキュリティに必要な条件・仕様のガイドにもなります。
作成したのは、保護セキュリティのアドバイスを提供する英国政府機関・国家インフラ保護センター（CPNI）。邦訳した文書は、一般社団法人JPCERT コーディネーションセンターが公開しています。
こちらでは、『グッド・プラクティス・ガイド プロセス・制御とSCADAセキュリティ』の内容をかいつまんで解説します。
No.1：事業リスクの理解 ※1
セキュリティを改善するための第一歩は、「事業リスク」を正しく理解することです。
事業リスクは、脅威・影響・脆弱性と相関関係にあります。企業が「事業リスク」を理解することで、初めて適切なセキュリティ保護に必要なものが判別できるようになるのです。
また、事業リスクの理解は、1回で終わらせていいものではありません。
セキュリティ上の改善は、適切なレベルの保護を確実するため、「現在直面している」リスクを基準に行われる必要があります。
しかし、セキュリティ上の脅威は絶えず変化しています。1度リスク評価を行い、結果に基づくセキュリティの改善策を講じたとしても、時間が経てば更なる脆弱性が特定されるでしょう。
だからこそ、「事業リスク」がどのように推移するのか見守り続けることが重要です。
このガイドの想定読者
- プロセス制御/オートメーション/SCADAテレメトリ技術者
- 情報セキュリティ専門家
- 物理セキュリティ専門家
- 事業リーダー
- リスク管理者
- 健康・安全管理者
- オペレーション技術者
- 監査人
No.2：セキュア・アーキテクチャの実装 ※2
セキュア・アーキテクチャとは、脅威に対抗する「セキュリティ保護機能」を安全に実装するための設計方針やしくみのことです。
ここでいう「アーキテクチャ」は、技術だけではなく、システムの人的要素も含む広い意味で使っています。
システムの安全を確保する必要に迫られた場合、簡単かつすぐ実施される方法は、「ファイアウォールのインストール」や「ウイルス対策ソフトウェアの導入」といった、明確なセキュリティ手段の実装でしょう。
しかし、それだけでは最適ではない可能性もあります。制御系システムは多様であり、多くの解決策があるため、安全な保護システムをデザインするのは容易ではありません。
セキュア・アーキテクチャは、プロセス・手順・管理などさまざまな対策で構成されるものであり、技術的な解決策だけで事足りるようなものではないのです。プロセス制御のセキュリティに「万能」はなく、計算づくめで組めばすべてに対応できるシステムが出来上がるほど単純なものでもありません。
したがって、グット・プラクティスとして考えられるのは、制御システムが「直面している」リスクを十分に理解した上で、保護対策を選び取って実装すること。「事業リスク」を十分に理解しなければ、制御システムのための総合的なセキュア・アーキテクチャを構築することができません。
詳しいリスク評価については、No.1「事業リスクの理解※1」で詳細に解説していますが、これによって取り組むべき最重要領域が決定され、もっともリスク低減効果が生まれる領域にリソースを分配するための情報も手に入ります。
セキュリティ・アーキテクチャを選択したら、あとはそれを実装するだけです。
簡単そうに聞こえるかもしれませんが、実装プロセスも注意深く管理しなければなりません。さもなければ、危険な場合があったり、システムの機能停止を招いたりすることもあります。
このガイドの想定読者
- プロセス制御/SCADA/産業オートメーション技術者
- テレメトリ技術者
- 情報セキュリティ専門家
- 物理セキュリティ専門家
- 事業リーダー
- リスク管理者
- 健康・安全管理者
- オペレーション技術者
No.3：対応能力の確立 ※3
プロセス制御環境を採用している組織はディザスタ・リカバリと事業継続性計画をすでに備えています。しかし、情報セキュリティでシステムを完全に保護できるわけではありません。脆弱性は常に存在します。情報セキュリティ戦略では脅威のあらゆる変化に対応しつつ、リスクは常に存在しているとの認識が大切になります。
セキュリティ自体の事故の発生はまれだと言われます。しかし、情報セキュリティの観点からは事故に備えた計画が必要になります。オフィス環境に適用される標準的情報セキュリティがプロセス制御システムと適応しない場合などに細かい注意と配慮が必要です。
これを防ぐためには情報セキュリティ要求の策定とインシデント対応計画の準備が不可欠になります。1982年～2000年の間に発生したセキュリティ関係の事故で外的要因によるものは31％にとどまっていました。しかし、2001年から2003年には、これが70％にのぼります。
セキュリティ対策の一つの方法として侵入者を検出したシステムが攻撃者をシステム内に残したまま隔離するという手段を執る場合があります。その場合は対策自体がリスクを生み出してることを認識しなくてはいけません。
グッド・プラクティス・フレームワークでは3つの原則を大切にしています。それは「保護」「検出」「対応」の3点になります。ここで現れる指針の多くは、さまざまなセキュリティ手段の導入によるプロセス制御システム保護に関係するものです。
このガイドの想定読者
- プロセス制御とオートメーション、SCADA テレメトリ技術者
- 情報セキュリティ専門家
- 物理セキュリティ専門家
- 事業リーダー
- リスク管理者
- 健康・安全管理者
- オペレーション技術者
No.4：意識とスキルの改善※4
セキュリティフレームワークを成功に導くには、最終的には人的要素が想定どおりに機能することが前提になります。しかしセキュリティフレームワークに関わりながら動く人的要素そのものがセキュリティの脅威となるリスクも同時に存在しているのを忘れてはなりません。
従来セキュリティは企業のＩＴ環境の問題とされてきました。この論点からプロセス制御環境の問題とする考え方は排除されてきました。しかし両者は表裏一体のものでありプロセス制御担当とＩＴセキュリティ担当者の密接な関係の構築がセキュリティ全体の安全性を向上させることになります。
プロセス制御セキュリティに問題が生じた場合、組織内の多くの人的要素が発生した問題との関連性を疑われなくてはなりません。サイバー・セキュリティ攻撃を防ぐためには意識的プログラムで検証を行うことが求められます。
これを解決していくにはプロセス制御セキュリティに関わるすべての人的要素に対してのトレーニングが必要になります。その内容はＩＴスキルからプロセス制御まで幅広いものになっていくでしょう。
これを効果ある実質的なものとするには目標を定めてトレーニングの効果を測定する作業が必要になります。プロセス制御部門とＩＴ部門を別個に動くものではなく、密接な連携によって動くよう社内システムづくりを行っていく。そこには訓練を重ねることによる意識の向上が不可欠であり、この過程を経てプロセス制御とＩＴセキュリティ双方を向上させる理想的な方向性が得られることになります。
このガイドの想定読者
- プロセス制御とオートメーション、SCADA テレメトリ技術者
- 情報セキュリティ専門家
- 物理セキュリティ専門家
- 事業リーダー
- リスク管理者
- 健康・安全管理者
- オペレーション技術者
No.5：サード・パーティ・リスクの管理 ※5
プロセス制御システムのセキュリティ・リスクはもとの組織だけに限らずにベンダー、サポート組織、サプライチェーン内の他の関係者などのサード・パーティ(社外の組織)によってもたらされる場合もあります。
特に接続が容易なインターネットやダイアルアップ接続の場合は、組織外からの脅威にさらされているため、サード・パーティも含めたリスク減少手段の追究が成されなくてはいけません。
多くの場合プロセス制御システムは社内において記述されていてそこには社外の存在＝サード・パーティが視野に含まれていませんでした。この点がセキュリティ・ホールの原因にもなっていたといえます。このリスクを可視化し管理することによりセキュリティ問題を解決に向けて一歩進める鍵になります。
プロセス制御システムにおけるサード・パーティ・リスクは回線などで結ばれたリモート・アクセス接続を原因にするものと考えられてきました。しかし、本来の問題は社内と社外の連絡体制・協力関係におけるセキュリティに関する基本的な思想が存在しない事実にあるといえます。
このために制御システム・ベンダー、サポート・プロバイダ、サプライチェーン内のさまざまな要素などが社内とどのような思想によって結びついているかが再検討される必要があります。
一見、危険性のないシステムも無秩序に結びつくことでリスクを生み出すことを考えて対応していくことが必要です。
このガイドの想定読者
- プロセス制御とオートメーション、SCADA テレメトリ技術者
- 情報セキュリティ専門家
- 物理セキュリティ専門家
- 事業リーダー
- リスク管理者
- 健康・安全管理者
- オペレーション技術者
No.6：プロジェクトへの参画 ※6
プロセス制御システムは通例として耐用年数が長くなります。その間、システム変更はほぼ行われないことがセキュリティ上理想的であることは議論の余地がありません。
一方で企業組織とは動的なものであり、耐用年数の間にプロセス制御システムに関する新たなプロジェクトが導入されるのも珍しくはありません。ここにもセキュリティ上の問題を生み出す余地があります。
制御システムの新設、制御システムの変更、ＩＴシステムの変更、管理システム情報の更新と実装、新接続の導入･･･など、新たなプロジェクトの導入は新たなリスクの原因を生むものでありリスク評価の対象にされるべき要件といえます。
当初システムを「更地」と認識した場合、プロジェクトは「増築」的な意味合いを持つもので「更地」状態のリスク評価のままの状態で「増築」が行われたプロセス制御システムのセキュリティを考えることはリスク拡大に結びつきます。
いったん構築され使用状態になったシステムのセキュリティに対するリスク評価を再度行うことは費用面で大きな負担となるものです。このために当初のプロセス制御システム開発の段階で、将来的なプロジェクト開発プロセスを視野に収め、新たなプロジェクトが組み込まれることを前提としたセキュリティ保護対策を組み込むことが大局的なコスト戦略を有利に導きます。
このガイドの想定読者
- プロセス制御とオートメーション、SCADA テレメトリ技術者
- 情報セキュリティ専門家
- 物理セキュリティ専門家
- 事業リーダー
- リスク管理者
- 健康・安全管理者
- オペレーション技術者
- プロジェクト・マネージャ
- 調達マネージャ
No.7：継続した統制の確立 ※7
プロセス制御システムのセキュリティ管理は正式な統制により首尾一貫した適切な手法が組織全体で行われることを求めます。この統制が継続的に行われない限り、組織自体の意思疎通の祖語自体がセキュリティ管理のリスクに結びついていくことになります。
このような統制フレームワークにより、立場の異なる組織構成者それぞれに明確や役割と責任、プロセス制御セキュリティのリスク管理に関するポリシーと標準を明確にすることが重要な意味を持ちます。
統制グループは、フレームワークにおける各要素のそれぞれを統制することによりプロセス制御セキュリティ・フレームワークの全テーマに関わることになります。
プロセス制御セキュリティのポリシーおよび標準を経営者レベルで行うことにより、事業リスクと組織のリスク許容度が測られ、外部規制や法律を考慮する基準も示されます。
ポリシーおよび標準の遵守および外部規制当局への報告が成されることにより、ポリシーおよび標準が内包する困難を発見するためにも非常に重要なフィード・バック・ループを提供します。
またポリシーおよび標準を更新していくことは、プロセス制御セキュリティ・フレームワークの他の要素がきっかけになることもあり、この出来事を起点として組織がリスクに対するスタンスを変更する場合もあります。ここで標準を実践することが過剰な負担になり標準を緩める方向性での変更を加えることは、セキュリティプロセス全体を見直した上で更新が求められることになります。
このガイドの想定読者
- プロセス制御とオートメーション、SCADA テレメトリ技術者
- 情報セキュリティ専門家
- 物理セキュリティ専門家
- 事業リーダー
- リスク管理者
- 健康・安全管理者
- オペレーション技術者
