CCoP 2.0 におけるファイル流入の見え方

この地域のあらゆる制御セットは深層防御を求めており、シンガポールの重要情報インフラに関する Cybersecurity Code of Practice も例外ではありません。これは、誰も反対できないためにレビュー会議を生き残る、そうした言い回しの一つです。

また、文字どおりに読めば、これは制御の数ではなく、連鎖の中にある制御の種類に関する主張でもあります。この違いは、セキュリティの大半ではほとんど意味を持ちません。そこでは層が実際に異なるからです。ファイアウォール、ID 制御、エンドポイントエージェントは、同じ考え方の変種ではありません。これがファイル流入では大きな意味を持ちます。なぜなら、組織は同じ方法で同じ問いに答える3つか4つの制御を、日常的に積み重ねているからです。

対象範囲と変更点

Cybersecurity Act 2018 により、シンガポールの Cyber Security Agency は、エネルギー、情報通信、水、医療、銀行・金融、警備・緊急サービス、航空、陸上交通、海事、政府、メディアの11分野にわたって重要情報インフラを指定する権限を持ちます。指定されることで、Code of Practice は指針から法的義務へと変わります。

Cybersecurity (Amendment) Act 2024 により、適用範囲は大幅に広がりました。2025年10月31日から、新たな Part 3A は、依存しているインフラを所有していない重要サービス提供者に加え、クラウドサービスプロバイダーとデータセンター運用者にも及びます。もし貴組織が数年前に、所有ではなく賃借しているのだからこの制度は自分たちには関係ないと結論づけていたなら、その結論は再確認する価値があります。

CSA は2026年7月22日、Code が再度更新され、Advanced Persistent Threats と AI を活用した攻撃に対応すること、また同じ時期に Cloud Services 向けの別個の Code が用意されることを発表しました。発表では、更新された Code に関連して Cyber Trust Mark Level 5 certification も言及されました。ここで注目すべきシグナルはそこです。拘束力のある文書と並んで任意のマークが名指しされると、指定の有無にかかわらず、その分野に販売するすべての事業者にとって調達上のフィルターになりがちです。

ファイルは実際にどこから入るのか

「ファイル流入」は一つのことのように聞こえます。しかし CII 環境では通常7つあり、それらを同じチームが所有していることはほとんどありません。

1. Email attachments。誰もが考えたことがあり、ほとんどの制御図で示される唯一の経路です。
2. Supplier and customer portals。アップロードフォーム、請求申請、入札回答、オンボーディング文書です。多くの場合、アプリケーションチームが構築し、その日にアプリケーションフレームワークが提供していたものだけで保護されています。
3. Managed file transfer and scheduled exchanges。取引先とのやり取りで、制御は内容よりも可用性と照合を中心に設計されています。
4. OT vendor material。ファームウェアイメージ、設定ファイル、PLC プロジェクトファイル、試運転文書です。この経路は最も重大な結果をもたらし、検査は最も少なくなります。形式が独自仕様であり、保守時間が短いためです。
5. IT と OT の境界にある removable media。正式な policy では通常禁止されていますが、実務では通常受け入れられます。ベンダーの技術者がノートパソコンと締切を持って到着するからです。
6. Cloud storage and collaboration surfaces。第三者と共有され、ファイルは運用者が境界として認識するものを一切通らずに到着します。
7. Backup and restore paths。以前のある時点で受け入れられたファイルを、その時点で存在していた制御の下で再導入します。

エンジンについて議論する前に、これら7つを自社環境に照らして書き出してください。この作業は、製品比較よりも多くのリスクを解消する傾向があります。よくある発見は、制御が弱いことではないからです。7つの経路のうち3つが、そもそもどの制御の対象にも入っていなかったということです。

類似した制御を積み重ねても深さにはならない理由

防御されている経路を取り上げ、何がそれを防御しているのかを見てください。

典型的な受信チェーンでは、まずゲートウェイエンジンがあり、次に別ベンダーのシグネチャを使う第2のエンジンがあり、さらにサンドボックスが続くこともあります。3つの製品、3つの請求書、3つのダッシュボードです。それぞれが何に答えているのかを尋ねると、答えは同じです。このファイルは悪意のあるものか。どのように判断しているのかを尋ねると、方法も似通っています。既知の悪性に対するパターンマッチング、構造に対するヒューリスティック、そしてファイルが自らを明かすかもしれない環境で観測される挙動です。

2つの制御が同じ方法を共有していれば、その方法の盲点も共有します。シグネチャベースの検知は、新しいサンプルが収集され、分析され、配布されるまでの時間だけ、新規サンプルに遅れます。第2のシグネチャセットを追加すると、その時間差は短くなりますが、なくなりはしません。サンドボックスは設計次第です。サンドボックスを確認するファイル、待機するファイル、あるいはサンドボックスが実行しないクリックを必要とするファイルは、完全に正常に振る舞います。それを2回実行しても、同じ良好な挙動が2回得られるだけです。

同じ問いを3つの制御でサンプリングするのは、一貫性テストです。エンジン同士が一致していることは分かります。しかし、そのファイルが安全だとは分かりません。そして深さを求める Code の下では、それは3層ではなく、1層を3回報告しているだけです。

Depth, という表現が主張する意味での深さには、チェーン内に少なくとも1つ、まったく別の経路で判定に至る制御が必要です。これは製品ではなくカテゴリであり、いくつかあります。ファイルタイプと送信元による allowlisting により、予期しない形式がそもそも parser に到達しないようにすること。コンテンツを転送ではなく再作成することを強制する protocol break。文書をその format specification に従って deterministic に rebuild し、誰も見たことのないファイルでも、誰もが見たことのあるファイルでも同じ結果を生み出すこと。rendering step を isolation し、parsing がどこで起きても問題にならない場所で行われるようにすること。

それぞれに実際のコストがあり、そうでないふりをするよりも、それを明確に挙げる価値があります。 Allowlistingは例外を生み、例外は蓄積していき、やがてリストは装飾的なものになります。 Protocolの破断は遅延を追加し、OTのメンテナンスウィンドウでは許容できない場合があります。Rebuildingは ファイルを変更します。これは、相手方がバイト単位で同一の文書や、署名が保持されることを期待している場合に重要です。Isolationはリスクを取り除くのではなく、移動させます。これらのコストを率直に見積もって選んだcontrol setは、病院と港では異なるものになるでしょう。

評価を通過する読み方

CCoPは、継続的な監視、ITとOTの両方にわたる行動異常の検知、そして必要に応じて調査と監査の検証を支えられる十分な保持を求めています。これらの義務は、見て証明することに関するものです。上記の深さの議論は、判断することに関するものです。そして両者は実務上の一点で交わります。ある経路がどのように防御されているかを尋ねる評価者は、同種のエンジンが連なる構成を受け入れるでしょう。しかし、その連鎖の説明は1文に収まり、その文は、この経路上のすべてが同じ方法で判断される、というものになります。

金融機関に対しては、MAS Technology Risk Management Guidelinesが別の言い方で同様の期待を示しています。メール、アップロードポータル、または第三者との交換で到着する信頼できないファイルは、判断を下してから後で確認するのではなく、境界で処理されます。

どちらの文書も技術を名指ししておらず、そうすべきでもありません。最終的に両者が求めているのは、運用者がファイルの通る経路と、その各段階で適用される判断を説明できるかどうかです。7つの経路、各段階ごとの方法、そして方法が繰り返される段階への率直な注記。この文書は半日分の作業ですが、残りの会話を意味のあるものにするのは、まさにそれです。

より詳細な制御マッピングと文書の詳細は、当社の Singapore compliance pageにあります。