ITエンジニアが仕事に対して思うこと

ITエンジニアとして働く中で感じたことを、現場の温度感そのままに言語化するブログです。設計・実装・運用のリアル、学び続ける負荷、品質とスピードのせめぎ合い、コミュニケーションの難しさなど、きれいごとだけでは語れない「仕事の実態」を整理します。誰かを責めるのではなく、なぜそうなるのかを構造で捉え、明日から少し楽に、少し強く働ける視点を提供します。新人から中堅、マネジメントまで参考に。

情報処理安全確保支援士試験 令和元年秋午後2問2の問題解説

R元秋2-2「工場セキュリティ」問題文の要点と流れ(丁寧解説)

1) 物語の舞台(A社/A‑NET/規程)

  • A社は本社+3工場を持つ製造業。事業所内外をつなぐ基幹ネットワーク「A‑NET」をシステム部が管理しており、社内機器の多くが接続されています。各工場は独立部門として扱われます。

  • 全社共通のセキュリティ規程があり、各部門はこれに従って機器を管理します(図1・図2が参照図)。

  • 図1の注記では「工場間の直接通信はFWで禁止」「各工場に従業員が使えるファイルサーバがある」と明記。

  • 規程の骨子:標準PCはシステム部管理、パッチ適用とマルウェア対策は必須/業務用ソフトの導入は事前許可/A‑NETの管理責任はシステム部/部門機器や部門NETをA‑NETへつなぐには申請が必要――など。

2) 事件の発端(ランサムウェア感染:図3)

  • a工場のSさんが、CADツール「CAD‑V」の“有償オプション広告メール”からリンクを踏み、サンプルファイルTをDL→CAD‑Vで開くと、PC‑Sが外部サイトUへ即通信。約30分後に異常に気付きました。

  • ベンダ解析の結果:

    • CAD‑Vの脆弱性悪用で動作し、利用者権限で一部ファイルを暗号化。動作状況等をサイトUへ登録。

    • 遠隔操作機能はなし。感染拡大機能はあるが「条件V」を満たすときだけ働く(感染力は弱い)。

  • a工場では条件Vを“全部満たす機器”は無いものの、PC‑Sから5台への感染拡大試行が確認。

  • 初動対処として、バックアップからの復元、CAD‑V全台の脆弱性対策、配布サイトやcへの社内アクセス遮断、全従業員への注意喚起などが図3に整理されています。

3) なぜFA端末が危険になったか(規程の“盲点”とベンダ制約)

  • 感染拡大の試行が見つかったのは生産設備を制御する専用PC=FA端末。A‑NET接続は“部門機器”として許可済みでした。

  • D主任の理解では、FA端末は「標準PCではない」ため、規程にある“標準PC向けのパッチ適用・対策ソフト導入”の適用外だと誤解していたことが示されています。

  • さらにFA端末はベンダYの指定方法で運用する必要があり、ベンダ許可なくパッチ適用や他社ソフト導入をすると“動作保証がなくなる”制約も背景にあります。

4) 経営判断とプロジェクトW

  • 実害が生じ、かつ生産設備への影響の可能性や同業他社の事故も踏まえ、経営陣は工場セキュリティの「抜本的見直し」を決定(プロジェクトWを設置)。目的は“サイバー攻撃等による生産設備停止の防止”で、A‑NET障害時でも稼働を維持できる体制を目指します。

  • 進め方:まずa工場を詳細調査→結果を踏まえて他工場へ展開。担当はCさん、外部の登録セキスペF氏(E社)が支援。

5) APT攻撃をどう捉えるか(表1の概念)

  • F氏はB社事故を「APT攻撃により遠隔操作型マルウェアに感染したのが発端」と説明。APTの典型ステップ(偵察→武器化→配送→エクスプロイト→インストール→C2(コマンド&コントロール)→目的実行)を表1に整理して、Cさんへ共有します。

  • 本文の攻撃記述は「メールでマルウェアを送付」「脆弱性を突いて実行」「バックドア設置で長期侵入」「攻撃者サーバと通信し指示に従う」「窃取・破壊・改ざん・横展開」と、表1の流れを具体化した形で示されます。

6) a工場ネットワークの“いま”(図4)とWi‑Fi利用

  • 図4では、a工場のサーバLAN・工場LANがA‑NETの一部である一方、FA端末は“部門機器”扱いである点が強調されます。訪問者の標準PC接続用にAP(無線アクセスポイント)が用意されている構造です。

  • Cさんはこの現状を踏まえ、問題点の洗い出しへ進みます。

7) 見つかった主要な課題(要約)

  • 課題1:FA端末にパッチもマルウェア対策も未実施なのに、複数台がA‑NETへ接続されている。

  • 課題2:APは許可機器をMACアドレス認証だけで制御。

  • 課題3:パスワード/証明書による認証は未導入。AP近傍からg(傍受)してh(MACアドレス)を取得すれば容易に接続可能、という脆弱性。

  • さらに、標準PC・FA端末を含めた“業務用ソフトの脆弱性管理”が不十分。公開情報を確認せず、パッチ未適用の機器が多い。そもそも規程に脆弱性管理の具体がなく、部門任せになっている点が構造的問題。

8) 課題1の背景要件(なぜFA端末をA‑NETに?)

  • D主任いわく、A‑NET接続の主目的は2つ:①生産データを業務サーバ登録や印刷のために取り出す(1時間に1回以上)②メンテや設計データ更新時にA‑NET経由でFA端末へ転送(月数回)。これが接続ニーズの“業務要件”として示されます。

9) この後の展開(見直し案:表2・図5)

  • CさんとF氏は「ネットワーク構成の見直し」で課題1の解決を図る方針を固め、a工場の見直し案を表2/図5に示して次章へ進みます(以降が設計課題)。


まとめ(この問題で読むべき“芯”)

  • 規程遵守の境界(“標準PCだけ”に対策規定が適用され、FA端末が抜け落ちていた)と、ベンダ運用制約が、A‑NET直結のFA端末を無防備にしていた――ここが事件のコア。

  • メール由来の脆弱性悪用→暗号化→外部登録というランサムウェアの典型挙動に対し、初動の封じ込めは実施されたが、構造的な弱点(Wi‑Fi認証/脆弱性管理)が残っている――これをプロジェクトWで**“業務要件を保ちつつ分離・強化”**していくのが後半の設計テーマです。

参考:出題の狙いは「OTとITが混在する現場で、インシデント対応・APT概念・ネットワーク分離・無線認証・規程運用を総合的に組み合わせて、目的(生産停止防止)に適う解を設計できるか」を問う点にあります。