令和元年度 秋期 情報処理安全確保支援士試験 午後Ⅱ 問2｜工場のランサムウェア感染はなぜ「生産停止」一歩手前で止まったのか——情報処理安全確保支援士で学ぶOTセキュリティの実例

この記事で扱うセキュリティ事例

• 試験区分: 情報処理安全確保支援士
• 出典: 令和元年度 秋期 情報処理安全確保支援士試験 午後Ⅱ 問2
• 主なテーマ: 工場のOT/IT混在ネットワーク、ランサムウェア感染、APT（高度標的型攻撃）、ネットワーク分離、データダイオード、無線LAN認証（MACアドレス認証とWPA2エンタープライズ）、脆弱性管理、セキュリティ規程の整備

この記事は「情報処理安全確保支援士 午後問題 全70問」シリーズの1本です。→ 全70問の一覧・テーマ別索引はこちら

導入: なぜこの事例が重要なのか

オフィスのパソコンがウイルスに感染した——それだけなら、被害は「業務が数時間止まる」「ファイルが一部壊れる」で収まることも多いでしょう。ところが、同じ感染が「工場の生産ライン」に届いた瞬間、話はまったく別の次元になります。製品が作れない。納期に間に合わない。最悪の場合、人や設備が危険にさらされる。情報処理安全確保支援士の午後Ⅱで出題されたこの事例は、まさに「オフィスのセキュリティ問題が、工場の生産設備にまで波及しかねない」という、現代の製造業が抱える最大級のリスクを正面から扱っています。

この問題のキーワードは、OT（Operational Technology＝制御技術。工場の機械や生産設備を動かすための技術領域）とIT（Information Technology＝情報技術。オフィスの事務処理や情報システムの領域）の混在です。長らく別世界だったこの二つが、業務効率化のために一つのネットワークでつながった結果、IT側の弱点がOT側の生産設備を脅かす経路になってしまう。実際に、ある金属部品メーカーの工場で起きたランサムウェア（データを暗号化し、復旧と引き換えに身代金を要求するマルウェア）感染は、もう一歩のところで生産設備を巻き込む寸前まで進んでいました。

この記事を読むと、なぜ工場のパソコンがマルウェアに感染し、それがどうやって生産設備の制御端末にまで広がろうとしたのか、そして「ネットワークを分ける」という一見地味な対策が、なぜ攻撃を封じ込める決定打になるのかが見えてきます。受験者にとってはネットワーク分離・APT・無線認証・脆弱性管理という頻出論点が一気に押さえられ、経営者にとっては「工場のIT化はどこまで安全に進められるのか」を考える教材になるはずです。

インシデントの概要

舞台は、車両や産業用機械に使われる金属部品を製造するA社です。本社オフィスに加え、α・β・γの3か所の工場を持つ、それなりの規模の製造業です。A社は各事業所と工場を結ぶ基幹ネットワーク「A-NET」を整備しており、社内の機器の多くがここに接続されていました。A-NETはシステム部が管理し、各事業所のあいだの直接通信はファイアウォール（FW。通信を許可・遮断する関所のような装置）で制限されています。

A社には全社共通のセキュリティ規程がありました。従業員に貸与する「標準PC」はシステム部が管理し、脆弱性修正プログラム（パッチ。ソフトウェアの欠陥を直す修正プログラム）の適用やマルウェア対策ソフトの導入といった「セキュリティを維持するための措置」を定めている。一方で、各部門が独自に調達して使う「部門機器」や「部門ネットワーク（部門NET）」については、A-NETに接続する前にシステム部へ申請して許可を得るルールになっていました。

仕組みとしては整っているように見えます。しかし、ある日、同業のB社で「生産設備が数日停止する」セキュリティ事故が発生し、業界紙に載りました。A社ではまだ同様の被害は起きていない。けれども、「セキュリティ面を深く考慮せずに拡張してきたA-NETと部門NETには、抜本的な改善が必要ではないか」という声が、現場の技術者から上がり始めていたのです。その不安が現実になる出来事が、α工場で起きました。

何が起きたのか

ある日、α工場の設計部に所属する社員Sさんが使う標準PC——以下「PC-S」と呼びます——の動作が、突然ひどく遅くなりました。それだけでなく、一部のファイルが開けなくなる。Sさんから連絡を受けたシステム部は、α工場で部門機器や業務用ソフトを管理するD主任とともに、調査と対処に乗り出します。

調べ始めてすぐ、不穏な事実が浮かびます。社内から社外への通信を中継するプロキシサーバ（社内PCの代わりに外部と通信を行う中継役のサーバ）のログを見ると、PC-Sが正体不明の宛先——調査チームが「サイトU」と呼んだ場所——に対して、奇妙なHTTPリクエストを繰り返し送っていたのです。そのリクエストのUser-Agentヘッダ（通信を送ってきたソフトの種類を示す情報欄）には「curl/7.64.0」という値が入っていました。curlはコマンドラインでデータを送受信するためのツールであり、人が普段使うWebブラウザの名前ではありません。つまり、PC-Sの中で「人間が操作していない何か」が、勝手に外部と通信していた。

さらにPC-Sでは、アクセスできるファイルサーバ上のファイルの一部が暗号化されていました。実行中のプロセスのいくつかは、エラーメッセージをログに吐き出していた。Sさんへの聞き取りと、PC-Sおよびプロキシサーバのログ解析から、感染の経緯が組み上がっていきます。

きっかけは、一通のメールでした。Sさんは、α工場で使っているCADツール（設計図面を作るソフト。以下CAD-V）の有償オプション機能を宣伝する広告メールを受け取りました。本文に書かれたURLリンクをクリックすると、CAD-V用の「サンプルファイル」（以下ファイルT）がダウンロードできる、という案内です。設計の仕事に役立ちそうなオプションの宣伝——疑う理由は、その場では見当たりませんでした。Sさんはリンクをクリックし、ファイルTをダウンロードし、いつものようにCAD-Vで開きます。すると即座に、PC-SはサイトUへ最初の通信を行いました。Sさんがおかしいと気づいたのは、その30分後でした。

ファイルTの正体は、マルウェア対策ソフトのベンダに解析を依頼して判明します。ファイルTはランサムウェアでした。CAD-Vの脆弱性を悪用して動作し、CAD-Vでファイルが開かれると、それを実行している利用者の権限で書き込み可能なファイルの一部を暗号化する。同時にサイトUにアクセスし、ランサムウェアが動いた機器の環境や暗号化の状況を登録する。幸い、このランサムウェアには「攻撃者が遠隔操作を行う機能」はありませんでした。また、感染を拡大する機能はあるものの、それは「一定の条件（条件V）を満たす場合にだけ機能し、感染力は弱い」という性質でした。

ここで調査チームの背筋が凍る発見がありました。α工場の中で、条件Vをすべて満たす機器は「なかった」。けれども、条件Vを一部満たす機器は存在し、PC-Sから5台の機器へ「感染拡大を試みた痕跡」が見つかったのです。そして、その5台の正体こそが、この事例の核心でした。感染拡大の試行先は、いずれも生産設備を制御するための専用PC——FA端末（Factory Automation端末。工場の機械や生産ラインを自動制御するための端末）だったのです。

FA端末は、α工場が管理する部門機器として、A-NETへの接続が許可されていました。しかしそこには、致命的な空白がありました。FA端末には、パッチの適用もマルウェア対策ソフトの導入も、セキュリティを維持するための措置が一切施されていなかったのです。D主任の説明はこうでした。「FA端末は標準PCではないので、セキュリティ規程で定められた標準PC向けの措置は適用対象外だと理解していた」。さらに、FA端末は汎用OS（一般的な基本ソフト）を使ったPCでありながら、生産設備の製造ベンダであるY社が指定する方法でしか利用できない。Y社の許可を得ずに勝手にパッチを当てたり、他社のソフトを入れたりすれば、FA端末や生産設備の動作が保証されなくなってしまう——。

つまり、もしこのランサムウェアの感染力がもう少し強かったら、あるいは条件Vを完全に満たす経路が存在していたら、無防備なFA端末が次々に感染し、生産設備が止まっていたかもしれない。B社で起きた「生産設備が数日停止する事故」は、A社にとって決して他人事ではなかったのです。今回は生産設備の停止には至らず、実害は限定的でした。しかし「実害があったこと」「生産設備に影響する可能性があったこと」「同業のB社で現に事故があったこと」を重く見たA社の経営陣は、工場のセキュリティを抜本的に見直す方針を決定します。

その見直しプロジェクトを率いることになったのが、システム部のM部長です。プロジェクト名は「プロジェクトW」。目的は明確でした——サイバー攻撃などによる生産設備の停止を防ぐこと。たとえA-NETで障害が起きても、生産設備の稼働だけは維持できるようにする。情報セキュリティの知見が社内に乏しいことを踏まえ、M部長はセキュリティコンサルティングを手がけるE社の支援を受けることにします。担当はシステム部のCさん、E社側は情報処理安全確保支援士（登録セキスペ）のF氏。ここから、α工場を出発点とした守りの再設計が始まりました。