2013年 - VECサロン

サイバー攻撃に強い制御システムを構築するには　その7
攻撃側のスキルと高セキュアコーディングについて

1．はじめに

制御システムセキュリティは、情報システムと同じくウイルス対策／マルウェア対策で医療と同じようなものと言う人がいる。
図1にあるように、自己認識（気づき）、自己治療、予防強化対策、定期健診、専門治療、感染症警戒、人材育成、検査装置、治療薬、医療器具、基礎研究、医療技術開発、研究装置供給などといった構造連携が存在する。
これに対して、制御システムセキュリティを同じようにまとめていくと、図2のようになってくる。


PDF資料(P2)どこが変わってくるかと言うと、予防強化対策が、「制御システムセキュリティ5S運動」、「DMZ導入」、「認証製品導入」、「ゾーン設計」、などになり、感染症警戒が、「IPA、JPCERT/CCのパートナーシップ」、「ICS-CERT」、「各国のCERT機関連携」などになり、基礎研究が、「高セキュア研究開発」となり、セキュリティベンダのツールなどが開発され、高セキュア技術研究されたものを制御ベンダが製品に織り込み、エンジニアリング設計の技術として導入されることになる訳である。
更に、これらの構造連携から、どのような課題が存在しているかを浮かび上がらせたのが、図3である。


PDF資料(P3)現場での制御システムセキュリティ対応5Sがあり、制御システムセキュリティ・ゾーン設計があり、脆弱性指摘と情報公開ハンドリングがあり、制御システムセキュリティアセッサを含む人材育成があり、制御製品取扱いガイドラインがあり、インシデント対応フローチャート作成があり、エンジニアリングガイドラインがあり、出荷装置のリモートサービスセキュリティ対応があり、オンラインパッチ処理を可能としたコントローラ製品開発があり、国際認証取得・ISA Secure認証・WIB認証（Achilles認証）があり、評価ツール開発と運用アップデートなどがある。
こうして見てみると、
医学では、接触⇒侵入⇒感染⇒潜伏⇒発症⇒検査⇒治療（症状緩和治療／病名判断・治療方針決定・本質治療）⇒病状回復⇒リハビリ（復帰療法）⇒再発防止（生活指導、食事管理など）⇒定期健康診断（再発検知）／予防というプロセスがあるが、
制御システムセキュリティでは、接触⇒侵入⇒感染⇒潜伏⇒インシデント⇒対処（緊急対処）⇒状況調査・原因追求・対策方針決定⇒再発防止（ルール改善・パッチ充て・改造など）⇒定期点検／予防対策改善などのプロセスがある。
医学での予防対策としては、体質改善や予防接種（ワクチン）などがあるが、制御システムセキュリティでは、制御システムセキュリティ・ゾーン設計を行い、攻撃され難い／感染が広がり難い／パッチ充てができる制御システムに改造することと、原因追求を的確に行うために、異常発生時のログ収集機能を制御システムに装備することと、オペレーションする人やメンテナンスする人のスキルをアップすることなどが重要なこととして挙げられる。それらを支えるものとして、医学では、検査装置や治療医薬品やリハビリ療法設備、治療薬開発、各種装置開発、基礎研究などがあるのに対して、制御システムセキュリティにおいても、侵入検知技術、防御対処技術、強化判定としての認証を行うための技術などがある。感染症の場合は、医者は、保険所に届けることになり、厚生労働省やWHOに通知して警戒警報や防疫研究や各国連携の警戒体制や防疫対処を国単位で実施している。
日本国内の制御システムセキュリティでは、IPAやJPCERT/CCと米国ICS-CERTや各国CERT機関がこれにあたる。しかし、警戒警報をWebにアップしてパートナーシップ登録者へ通知するところまではJPCERT/CCが実施しているが、防疫研究や各国連携の警戒体制や防疫対処指導を実施できる実力までは持っていないのが現状である。もう一つ、重要なことがある。それは、脆弱性情報が公開されたことで制御製品ユーザーの現場対策が遅くなり、実際に事故が発生して、損害が出た時に、損害賠償問題が出てくる。国の機関が脆弱性情報を公開したのであれば国が損害賠償支払いの責務を負わされるかもしれない。これが一般社団法人であれば、その機関は存続が難しくなる。これをどのようにしておくべきかの課題がある。まだまだ、体制構築は始まったばかりで未熟である。しかし、ハッカーは待ってはくれないし、既にマルウェアはばら撒かれている。

2．攻撃側のスキル

PDF資料(P4)

PDF資料(P5)

PDF資料(P6)攻撃側の状況を少し推察してみよう。攻撃者の武器は、年々高度化している。これは、20世紀末頃から、市販のOSやネットワークの基本的技術情報をベースに攻撃ツールを作成してサイバー攻撃を実施することから始まった。そのうちに、それらをブラックマーケットで販売したり、パスワードを忘れた人の為にとパスワードを解くアプリツールを販売したりしているものを攻撃ツールとして利用することへと広がった。

近年では、制御システム製品の脆弱性情報を基に攻撃ツールを開発しブラックマーケットで販売するという事態を招いている。攻撃者は、ネットワークの基本解析ツールやセキュリティホール解析ツールや制御システム製品攻撃ツールを組み合わせて攻撃できるまでに進歩し、C言語やC++言語などを使えるスキルがあれば容易に攻撃できるまでになっている。

米国国土安全保障機関の一環で活動しているICS-CERTが2011年の一年間においてインシデント対応した件数の中で上下水道業界が40％以上を占めていたのも、その業界で使用されていた制御製品の脆弱性情報の公開されたことが大きな要因であった。これに対し、2012年では、図にあるようにエネルギー業界のインシデント対応が多くを占めている。また、インターネット上からPLCのWeb機能が見えるアドレスを探し出すツールが売られたこともあり、ネット上で遠隔操作やサービスを受けることができるようにした再生可能エネルギーの制御システムで使用されていた制御製品の脆弱性情報が公開されたことも重なって、攻撃件数が増えたようだ。

つまり、脆弱性情報の公開やその攻撃ツールの販売が、制御システムを攻撃するハッカーの一助になっていると言っても過言ではない状況である。

3．IEC62443の動向

制御システムセキュリティ対策の国際規格は、業界別にまちまちであったところがあるが、最近の傾向としてはIEC62443にまとまってきている傾向にある。このIEC62443の内容をまとめている機関が実際はISAのWGで行われていることとこの活動に欧州の制御ベンダも参画していることから、一致したまとまりを示してきているようである。IEC62443-1から-4に至る規格すべてが決まるのも2013年末を予定して進められている。

4．セキュアコーディング形成の為に

制御ベンダがサイバー攻撃に強い制御製品を継続的に出していけるように取り組むことになるが、それは制御ベンダが高セキュアコーディングを継続できる製品開発体制整備と人材育成にかかってくる。
では、その高セキュアコーディングとは、何をすれば良いかについていくつか述べてみよう。
製品設計をするエンジニアは、プログラム仕様から考えることに慣れている。それは、製品設計の仕様を満たすことから始まるからである。しかし、サイバー攻撃する側からすると、飛び交うデータから入り込む術を考えるというパターンになることが多い。

• Command injection
  データの入力や操作を受け付けるようなWebサイトで、プログラムに与えるパラメータにOSに対する命令文を紛れ込ませて不正に操作する攻撃。また、そのような攻撃を許してしまうプログラムの脆弱性のこと。
• SQL Injection
  アプリケーションのセキュリティ上の不備を意図的に利用し、アプリケーションが想定しないSQL文を実行させることにより、データベースシステムを不正に操作する攻撃方法のこと。また、その攻撃を可能とする脆弱性のこと。
• Cross site scripting
  動的にWebページを生成するアプリケーションのセキュリティ上の不備を意図的に利用し、狭義にはサイト間を横断して悪意のあるスクリプトを混入させること。また、それを許す脆弱性のこと。広義にはスクリプトを混入させなくても、任意の要素を混入させられる脆弱性を言う。
• Directory traversal
  ネットワークを通じたソフトウェアへの攻撃手法の一種で、ファイル名を扱うようなプログラムに対して特殊な文字列を送信することにより、通常はアクセスできないファイルやフォルダ(ディレクトリ)の内容を取得する手法。

PDF資料(P7)と、ここに挙げる攻撃手法を取り上げても、データを送りつけて、脆弱性を探り当て、仕組みを解析して、攻撃コードを作成し、突破口を作り出す。

では、どのような現象と対策が必要となってくるかであるが、代表的なものを三つあげてみる。

（1）Input Validation：不適切な入力値検査

入力値の検査が行われていないか行っていても不充分であるため、ソフトウェアが想定していない入力値を許して侵入される。
対策としては、ブラックリスト方式／ホワイトリスト方式の二つを使い分けてプログラミングすることになる。

（2）Buffer Overflow：バッファオーバーフロー

確保されたバッファ領域にデータの書き込みが行われることを許して侵入される。
対策としては、割り当てられたメモリ領域外への書き込みが発生しないよう、範囲チェックを行うことになる。

（3）不適切な整数利用

値がある整数型の最大値を超えるもしくは最小値を超えてしまうことを許してしまうエラー 。
対策としては、整数値のチェックを行うしかない。

ここで挙げた方法は、一部である。ここは、専門家のセミナーを受講したり、専門書を読んだりして、技術的な部分を補っていただきたい。


PDF資料(P8)

PDF資料(P9)重要なことは、これらのコーディング作業をした後に、脆弱性を作り出していないかをチェックすることである。チェックシートを作成して、開発者に確認することも一つの方法である。別のプログラマ―にチェックさせることも方法の一つである。コーディングツールで自動チェックさせることも可能であれば実施することを推奨する。

次に、製品開発したソフトウェアを品質検査する部門の確認環境を整備することである。この場合、製品開発者とは異なる方法で、攻撃側の視点で実施することになるが、なかなか容易なことではない。経済産業省の予算で設置された技術研究組合制御システムセキュリティセンターCSSCの機関機能の一つに、脆弱性研究と検証活動がある。これに参加して脆弱性検出のツールを借りて、テスティングしていくのも方法の一つである。

5．セキュアな通信プロトコルにするために

ネットワーク上の通信スタックを守るには、どうしたら良いであろう。この課題に対処できる技術としてIEC62541のOPC UAが挙げられる。
OPC UAが求めているのは、

• Authentication(認証)
• Authorization (認可)
• Confidentiality(機密)
• Integrity(完全性)
• Auditability(監査能力)
• Availability（可用性)

を保つことである。
では、どのような脅威に対処できることを目的としているかについて述べてみよう。

（1）Message Flooding(メッセージ氾濫)

攻撃者は、OPC サーバー、またはOPC サーバーがCPU, TCP/IP スタック、オペレーティングシステムやファイルシステムなどの信頼できるオペレーションに依存するコンポーネントに過剰な負荷をあたえるために、大量のメッセージ、または膨大な数の要求を含んだ一つのメッセージを送信する。メッセージ氾濫攻撃は、OPC-UA、SOAP、[HTTP]、またはTCP の複数のレイヤーで実行される。メッセージ氾濫攻撃は、正しい形式や間違った形式の両方のメッセージが使われる。最初のシナリオでは、攻撃者は正しいクライアントを悪意的に使い、サーバーに大量の要求を送りつけるかもしれない。クライアントがサーバーのセッションを確立していないケースと、クライアントがサーバーのセッションを確立している二つのケースが存在する。
メッセージ氾濫は、OPC-UA セッションを確立できないようにするか、すでにあるセッションを終了させるかもしれない。 より一般なメッセージ氾濫は、OPC-UA エンティティと通信できなくするようにし、結果としてサービスを実行できないようにする。メッセージ氾濫はavailability に影響を与える。

（2）Eavesdropping(盗聴)

盗聴は、重大なセキュリティホールにつながる、または、追加攻撃に利用される機密情報の不正な漏洩である。
攻撃者は、基礎となるオペレーティングシステム、またはネットワークインフラストラクチャーを侵害して、メッセージを記録し、捕まえるであろう。オペレーティングシステムが侵害された状態から回復させるのは、クライアントやサーバーではどうにもできない。
盗聴は、直接的にはconfidentiality に影響を与え、間接的には他のすべてのセキュリティの目標を脅かす。

（3）Message Spoofing(メッセージなりすまし)

攻撃者は、クライアントまたはサーバーからのメッセージを偽造する。なりすましは、プロトコルスタック の複数のレイヤーで起こる。 この脅威がセッションを越える場合は、セッションハイジャック」となる。
攻撃者は、クライアントまたはサーバーからのメッセージを偽造して、未認可の操作をおこない、攻撃者の活動を気づかれないようにする。
メッセージなりすましは、integrity とauthorization に影響を与える。

（4）Message Alteration(メッセージ改ざん)

ネットワークトラフィックとアプリケーションレイヤーのメッセージを捕まえ、変更する。そして、変更されたメッセージをOPC クライアントとサーバーへ送る。メッセージ改ざんによって、システムへの不法なアクセスが行われてしまう。
メッセージ改ざんはintegrity と authorization に影響を与える。

（5）Message Replay(メッセージリプレイ)

ネットワークトラフィックと有効なアプリケーションレイヤーのメッセージを捕まえ、変更することなく、あとでOPC クライアントとサーバーに再び送る。 攻撃者は、ユーザーに間違った情報を送ったり、不適切な時間にバルブを開いたりするような不適切なコマンドを送りだす。
メッセージリプレイは、integrity と authorization に影響を与える。

（6）Malformed Messages(マルフォームメッセージ)

攻撃者は、無効なメッセージ構造(不正な構造のXML、SOAP、悪意に満ちたバイナリのエンコーディングなど)を持つさまざまなメッセージ、またはデータ値を巧妙に作り、OPC-UA クライアントやサーバーへそれらを送りつける。OPC クライアントやサーバーは、未認可の操作を実行することによって、または、必要もない情報を漏洩することによってマルフォームメッセージを誤って処理する。そのことによって、サービスを拒否したり、略奪したりする。これにより、アプリケーションの停止、または、組み込みデバイスにおいては、完全なクラッシュが発生することがある。
マルフォームメッセージはintegrity と availability に影響を与える。

（7）Server Profiling(サーバープロファイリング)

攻撃者は、侵入、または、有害な攻撃を仕掛けるために、その製品の具体的な弱点を見つけようとしてサーバーまたはクライアントの識別子、タイプ、ソフトウェアバージョン、またはベンダを類推しようとする。 攻撃者は、有効な、または無効なフォーマットのメッセージをターゲットに送信し、ターゲットをプロファイルし、ターゲットの正常応答やエラー応答のパターンでターゲットのタイプを認識しようとする。
サーバープロファイリングは、すべての目標に影響を与える。

（8）Session Hijacking(セッションハイジャック)

攻撃者は、セッションを越えて有効な書式のOPC-UA メッセージを、既存のセッションに送り込む。
攻撃者は、データの未認可なアクセスを行い、または、無許可な操作を実行することがでる。
セッションハイジャックは、すべての目標に影響を与える。

（9）Rogue Server(詐称するサーバー)

攻撃者は、悪意のあるOPC-UA サーバーを構築し、または正式なOPC-UA サーバーの未認可なインスタンスをインストールする。OPC クライアントは、必要もない情報を漏洩するようになる。
詐称するサーバーは、すべてのセキュリティの目標に影響を与える。

（10）Compromising User Credentials(ユーザー証明書の改ざん)

攻撃者は、文書や画面、電子的な通信を観察したり、推測したりするか、またはパスワードクラッカーなどの自動化されたツールを使用して、ユーザネーム、パスワード、証明書、キーなどのユーザー証明書を得る。これにより、未認可のユーザーにあるにもかかわらず、すべての情報手に入れるためにシステムを起動とアクセスすることができ、プラントの操作や情報に害を与える制御とデータの変更ができる。一度危険にさらされた証明書が使われると、その後のアクティビティはすべて合法とみなされる。
ユーザー証明書の改ざんは、authorization に影響を与える。

6．サイトセキュリティとIEC62541 OPC UA の関係

OPC UA セキュリティは、サイトのcyber security management system (CSMS)のあらゆるところで動作することを前提にしている。 サイトはたいていCSMS(アドレスセキュリティポリシー、手続き、人、責任、監査、物理的なセキュリティ)がある。CSMS は一般に、4.で挙げた脅威を取り扱う。セキュリティの危険を分析し、サイトがどのようなコントロールを必要なのかも決めることになる。
一般的に、セキュリティコントロールの成果として、各レイヤーで防御する方策を提供することになる。但し、一つのレイヤーではすべての攻撃から保護することは困難であり、OPC UAでもできないことを認めておく。
バウンダリプロテクションは、ファイアウォール、侵入検出システム、ダイヤル・イン接続におけるコントロール、およびシステムにつながったメディアやコンピュータのコントロールのことである。システムのコンポーネントの保護範囲は、オペレーティングシステムの強固な設定、セキュリティパッチ管理、アンチウィルスプログラム、制御ネットワークにEメールを送らないことまで含まれている。但し、サイトは、North-American Electric Reliability CouncilのCIP002-1 からCIP009-1 までとIEC 62351 を含んだ標準に従うこととする。
サイトCSMS のセキュリティ要件は、そのOPC UA インタフェースにも適用される。すなわち、サイト上のOPC UA インタフェースのセキュリティ要件は、OPC UA 仕様によってではなく、サイトによって仕様が決まる。OPC UA の仕様に適合したクライアントとサーバー製品が、サイトで求められているセキュリティ要件と合致するようにOPC UA の機能は想定している。サイトのセキュリティ責任者は、OPC UA に 適合した製品がどのようにしてサイトの要件を満足するか決めることとなる。
OPC UA クライアントまたはサーバーをインストールするシステムの所有者は、そのセキュリティ上の危険を分析しなければならず、セキュリティの許容レベルを達成するためにそれらのリスクを軽減するために適切なメカニズムを提供しなければならない。
OPC UA は、そのような個々の分析から導き出された多種多様なセキュリティニーズに対応しなければならない。OPC UA クライアントとサーバーは、一定のセキュリティ機能を実装しなければならない。その機能は、システムの所有者がオプションで使用できる。それぞれのシステムの使用者は、OPC UA 仕様の内外の有効なメカニズムを組み合わせて、そのセキュリティと経済的要件に合うセキュリティソリューションを作らなければならない。
サイト上に配置されたOPC UA クライアントとサーバーに課せられたセキュリティ要件は、OPC UA 仕様によってではなくサイトCSMS で規定されている。しかし、OPC UA セキュリティ仕様は、OPC UA クライアントとサーバー製品に基づく要件である。そして、その仕様は、サイトで仕様となるセキュリティ要件に合うために、OPC UA がどのようにサイトに配置されるべきかを推奨することになる。
OPC UA は、セクション4.で説明したようにいくつかの脅威を取り扱う。それらの脅威はクライアントとサーバーのオペレーティングシステムの妥協に帰結するものである。
インフラストラクチャの構成要素への脅威についてはOPC UA では扱っていない。

7．実装上の問題

情報システムセキュリティでは、ソフトウェアのコーディングルールで多くの脅威に対応することが可能であるが、制御システムセキュリティにおいては、ハードウェアとのアーキテクチャー上のチューニング課題や実装上の調整で対処するべき課題がある。

（1）アプリケーションインスタンス証明書

すべてのUA アプリケーションは、アプリケーションの新しいインスタンスがインストールされるApplication Instance Certificateの時は、いつもユニークで自己署名されたルート証明書を作成することを推奨する。この自動作成される証明書のためのpublic key は管理者がアクセスできる所に保存されるべきである。これで、管理者は新しいUA Application Instance と通信する必要がある他のUA アプリケーションをコンフィギュレーションすることができるようになる。また、UA アプリケーションは、管理者が自動生成されている証明書を管理者が選択したCA によって発行された証明書に置き換えることができる。信頼できる証明書リストは、サイトにおいて許可されない改ざんから守られるようにすべきである。
また、UA アプリケーションが新しい自己署名入りの証明書を信頼できる証明書のリストに追加するプロセスを簡素化することが推奨される。可能であれば、UA アプリケーションが初めてUA サービスを利用する証明書を交換するときはいつも、UA アプリケーションは数種類の通知を行うべきである。最も良い手順はアプリケーションに依存するのでそこは設計考慮願いたい。しかしながら、それは、ユーザーにダイアログを表示して、証明書を受け入れるかの確認をユーザーに問い合わせることも含まれる。サーバー・アプリケーションまたはユーザーインタフェースのないアプリケーションは条件付きで証明書を受け入れて、セキュリティログまたはメールを使って管理者に報告する。UA アプリケーションは、当然のことであるが、知らない証明書機関が自己署名したり、または、証明したりした証明書を決して黙って受け入れるべきではない。

（2）適切なタイムアウト

通常メッセージ到着などのイベントのために、待たなければならないタイムアウト時間は、セキュリティの実装で重要な役割を果たす。 考えられる結果は以下のとおりである。

• サービス拒否:
  タイムアウト時間が非常に長い場合、クライアントがセッションをリセットしない時はサービス拒否の条件が存在するかもしれない。
• リソース消費:
  クライアントが長期間活動していないときに、サーバーはその期間、クライアント情報を保持していなければならない。しかし、これはリソースを食い尽くすので要注意である。

実装者はそれぞれの接続段階に妥当なタイムアウト設定するべきである。

（3）Strict Message Processing(厳密なメッセージ処理)

仕様は、しばしば正しいメッセージの形式を規定するが、仕様から逸脱するメッセージに対し、何を実装するべきか規定していない。 典型的なケースでは、実装はそのようなパケットを解釈し続け、それが脆弱性につながっていくので要注意である。

• 実装者は、メッセージ・フォーマットの厳密な検査をするべきであり、パケットを捨てるか、以下で示されるエラーメッセージを返すべきである。
• エラー処理は、最も条件に適合したエラーコードを使用する。エラーコードはUA パート4 で定義されている。

（4）強固なエラーリカバリー

プロトコル上のエラー(ハングや、間違ったプロトコル状態に陥るなど)は、不適切なプロトコル仕様やクライアントが送付したメッセージが仕様範囲外だったというような様々な理由で発生する。そのようなエラーから回復するために、洗練されたエラーリカバリー処理を実装すべきである。正しい形のエラーメッセージを送信することやメモリを回復することは、そのような処理の一例である。

（5）乱数生成

セキュリティ要求を満たす乱数は暗号ライブラリによって提供される適切な関数によって生成することが可能である。CRT rand()関数のような他の手段は脆弱すぎるので要注意である。

（6）スペシャルとして予約されたパケット

実装時には、(IP 仕様のブロードキャストとマルチキャストアドレスなどの)スペシャルなものとして予約されたメッセージタイプを正しく理解し、解釈しなければならない。それらのスペシャルなパケットを理解せず、解釈できないと脆弱性につながるので要注意である。

（7）レート制限とフロー制御

OPC-UA はレート制御機構を提供しない。しかし、実装ではレート制御を取り入れることができる。

8．まとめ

PDF資料(P10)せっかく高セキュアコーディングしたのに、コーディング後のチェックやチューニング作業や品質検査、実装上の課題調整を手抜きしたのでは、意味がない。また、顧客からの問い合わせで脆弱性に関係する情報を軽視してもならない。製品紹介のセミナーや扱い方のセミナーを実施するだけでなく、今後は、実装した時のチューニング方法や制御システムセキュリティ対策のトレーニングもアフターサービスに加えることを推奨する。

つまり、供給ベンダとしてリリースする製品のライフサイクルとして制御システム製品におけるセキュリティ対策を考えて、進めていく必要があると考える。
これらの活動は、これからの時代を企業が生き残っていくために必要なことであると考えていただきたい。