以下の内容はhttps://error-daizenn.hatenablog.com/entry/2025/12/06/110314より取得しました。


NCSCの新サービス「Proactive Notifications」とは?公開サーバーの脆弱性を自動で教えてくれる仕組みと注意点


英国の国家サイバーセキュリティセンター(NCSC:National Cyber Security Centre)が、インターネットに露出した機器やサービスに潜む脆弱性を自動で見つけて、組織にメールで知らせる新サービス「Proactive Notifications(プロアクティブ・ノーティフィケーション:能動的通知)」のパイロット運用を開始しました。(
BleepingComputer)
これは、特に英国国内の組織向けのサービスですが、「外から見える情報だけを使って、国家機関が脆弱性を教えてくれる」というコンセプトは、他国の企業や自治体にとってもかなり参考になります。
最近はロンドンの複数の区(council)のシステム障害や、Cox EnterprisesのOracle E-Business Suite関連の情報流出など、公開システムまわりの事故が続いています。(BleepingComputer)
「うちもどこかのポートが開きっぱなしになっていないか…?」と不安な情シス・セキュリティ担当者に向けて、今回はこの新サービスの中身と意味、そしてもし同様のメールを受け取ったらどう動くべきかを、ニュース+考察という形で整理していきます。

1. いつ、何が起きたのか:NCSC「Proactive Notifications」の概要

2025年12月4日(現地時間)、セキュリティメディアのBleepingComputerが「NCSC’s ‘Proactive Notifications’ warns orgs of flaws in exposed devices(NCSCの『Proactive Notifications』が露出デバイスの欠陥を組織に警告)」という記事を公開し、この新サービスの詳細が明らかになりました。(BleepingComputer)

サービス自体は、NCSCが推進する「Active Cyber Defence(アクティブ・サイバー防御)」プログラムの一部として、すでに公式サイトの情報ページ「NCSC Proactive Notifications Service」として告知されています。(NCSC)

このパイロット版がカバーするのは、
・英国に紐づくドメイン(.ukなど)
・英国の自律システム番号(ASN:Autonomous System Number)に属するIPアドレス
とされています。(BleepingComputer)

つまり最初の対象は「英国のインターネット空間」ですが、考え方そのものはどの国の組織にも当てはまります。
「インターネットから見える情報だけをもとに、外側から“危ないよ”と教えてくれるセーフティネットを、国が用意し始めた」というのが、このニュースの一番重要なポイントです。

ニュースとしての「発生日時」をまとめると、
・2025年11月17日:NCSCのニュースページにProactive Notifications Serviceの情報が掲載(NCSC)
・2025年12月4日:BleepingComputerがパイロットの詳細を報道(BleepingComputer)
という流れになります。

2. NCSCとActive Cyber Defence(ACD)ってそもそも何?

NCSCは英国政府傘下のサイバーセキュリティ機関で、ガイドラインの発行からインシデント対応、重要インフラの防御までを担う「日本でいう内閣サイバーセキュリティセンター+JPCERT/CC」を足したような存在です。

そのNCSCが数年前から進めているのが「Active Cyber Defence(能動的サイバー防御)」というアプローチです。これは「攻撃を受けてから対処」ではなく、DNSフィルタリングやフィッシングサイトの一括ブロック、メールセキュリティ改善サービスなどを“国家レベルで”先回りして提供し、被害の芽を摘もうとする取り組みです。(NCSC)

従来のACDサービスとしては、
・Web Check(ウェブサイト診断)
・Mail Check(メールセキュリティ診断)
・Early Warning(アラート通知サービス)
などがありましたが、Web Check/Mail Checkは2025年11月に「役割を終え、順次終了していく」との公式ブログも出ています。(NCSC)

Proactive Notificationsは、この“ACDの新世代サービス”として、早期にリスクを伝える役割を担う位置づけになっています。
古いサービスを畳みつつ、より“スケールできる仕組み”に集中していく流れと考えると、全体像が見やすくなります。

3. Proactive Notificationsの仕組み:どうやって脆弱性を見つけるのか

このサービスの技術的な肝は、「Netcraft(ネットクラフト)」というセキュリティ企業との連携です。Netcraftは昔からフィッシング対策やホスティング調査で有名な会社で、インターネット全体をスキャンして統計を取るのが得意なプレイヤーです。(Rankiteo Blog)

Proactive Notificationsでは、このNetcraftが実施するスキャン結果をもとに、
・公開サーバーや機器がどんなソフトウェアを動かしているか
・そのバージョンが既知の脆弱性(CVE:Common Vulnerabilities and Exposures)を含んでいないか
・暗号化(encryption)の設定が明らかに弱くなっていないか
などをチェックし、「これは危ない」と判断されたケースについて、該当組織にメールで知らせます。(BleepingComputer)

NCSCは、スキャンの根拠として「外部から観測できる情報、たとえばサーバーが公開しているバージョン番号などに依拠する」と説明しており、「Computer Misuse Act(英国のコンピュータ不正使用法)」に準拠した活動だと強調しています。(BleepingComputer)

通知メールについても、いくつかの特徴がはっきり示されています。
・送信元はnetcraft.comドメインのアドレス
・添付ファイルは付けない
・支払い情報やログイン情報などを要求しない
つまり「怪しい添付や金銭要求があれば、それは偽物」と見分けやすくしているわけですね。(BleepingComputer)

要するにProactive Notificationsは、“外から見えるバナー情報など”だけを使って、危険な古いバージョンや弱い暗号設定を見つけ、所有者にだけそっと教えてくれるサービスです。

4. 対象ユーザー層:誰がこのサービスの恩恵を受けるのか

パイロットフェーズで対象となるのは、
・英国のドメインやIP空間を持つ組織(企業、自治体、大学、病院など)
・その中でも、NCSCが「必須のセキュリティサービスを導入していない」と判断した組織
とされています。(BleepingComputer)

ここでいう「必須のセキュリティサービス」とは、たとえばDDoS対策やWebアプリケーションファイアウォール(WAF:Web Application Firewall)、堅牢なメールゲートウェイなど、「今の時代なら最低限ほしいよね」というレイヤを指していると考えられます。

逆に言うと、すでに高度なマネージドセキュリティサービスを入れている大企業よりも、予算や人員が限られていて「セキュリティが後回しになりがちな中堅・中小組織」に、より大きなメリットが出る設計になっているとも言えます。

NCSC自身も「このサービスだけに頼ってはいけない」と明言しており、対象は“英国の一般〜中堅組織を中心とした広い層”だが、セキュリティ運用の代わりになるものではない、というスタンスです。(BleepingComputer)

日本を含む他国の組織から見ると、「自国でも類似の仕組みを作れないか」「自社で似たアプローチ(外形監査)を取り入れられないか」と考えるヒントになります。

5. Early Warning(早期警告サービス)との違いと“二段構え”の守り

NCSCはすでに「Early Warning(アーリー・ワーニング:早期警告)」という無料サービスを提供しています。これは、各種脅威インテリジェンス(threat intelligence)や政府・民間の情報源を集約し、登録された組織のドメイン・IPアドレスと突き合わせて、
・マルウェア感染の兆候
・ボットネットへの参加
・スキャンや攻撃の標的になっている形跡
などを検出すると、メールでアラートを出す仕組みです。(BleepingComputer)

一方で、Proactive Notificationsは「攻撃や侵害の“兆候”が出る前」の段階で発動します。
・公開サーバーが古いバージョンのまま放置されている
・VPN機器に既知の脆弱性が残っている
・暗号スイートが危険な状態のまま
といった“潜在リスク”を見つけて知らせるわけです。

NCSCやLinkedIn上の関係者の説明では、「Proactive Notificationsで“守りを固め”、それでも抜けたものをEarly Warningが拾う」という“二段構えのレイヤードディフェンス(layered defence:多層防御)”のイメージで語られています。(LinkedIn)

まとめると、Proactive Notificationsが『事前の予防整備』、Early Warningが『異常が出た後の早期検知』という役割分担になっており、両方を組み合わせることで、国家スケールでの守りを分厚くしようとしているのです。

6. どんな「露出機器の欠陥」が狙われるのか:具体例イメージ

BleepingComputerの記事やNCSCの説明からは、Proactive Notificationsが想定している「欠陥(flaws)」として、以下のようなイメージが読み取れます。(BleepingComputer)

たとえば、
・インターネットに直接公開されているVPN装置が、既知の重大CVEを含む古いファームウェアのまま
・Webサーバーが古いTLSバージョンや弱い暗号スイートを使い続けている
・リモートデスクトップ(RDP:Remote Desktop Protocol)が、インターネットに丸見えの状態で晒されている
・IoTデバイスや管理インターフェースがデフォルト設定のまま公開されている
といったケースです。

ここで重要なのは、「内部ネットワークの詳細」までは見ていないという点です。外から見えるバナーや証明書、オープンポートなど“インターネット側に顔を出している部分”だけから判断されます。

つまりProactive Notificationsが教えてくれるのは、“あなたの家の外壁にヒビが入っていたり窓が開けっ放しだったりする”ことまでであって、“家の中に泥棒がいるかどうか”までは見てくれない、というイメージです。

だからこそ、通知を受けた組織は、そこから先を自分たちで掘り下げる必要があります。

7. 通知メールを受け取ったとき、組織はどう動くべきか(実務ステップ)

「もし自分が英国の組織で、このメールを受け取ったら何をするべきか?」という視点で、実務ステップを整理してみます。これは日本や他国の組織でも、そのまま“演習ネタ”として使える内容です。

通知メールを受け取ったときに一番大事なのは、『本物かどうかを冷静に確認しつつ、内容は“かなり真剣に”受け止めること』です。

(1) メールヘッダ情報を確認し、送信元がnetcraft.comドメインであるか、SPF/DKIMの検証結果に大きな不審点がないかをチェックする。

(2) メール本文の中で、添付ファイルの開封や金銭・ログイン情報の入力を求めていないかどうかを確認する(そうした要求があれば偽物の可能性が高い)。

(3) 通知に記載されているドメイン名・IP・ホスト名が、自組織の管理範囲に含まれるかを確認する。過去に委託先やグループ会社が管理していた資産の可能性も含めて棚卸しする。

(4) 指摘されている脆弱性やソフトウェアバージョンについて、自社のアセット管理台帳や構成管理データベース(CMDB:Configuration Management Database)と突き合わせる。

(5) ベンダーのセキュリティアドバイザリやCVE情報を確認し、パッチ適用、設定変更、サービス停止など、取れる対策パターンを整理する。

(6) 影響範囲・重要度・攻撃容易性を踏まえて優先度を決め、緊急度が高いものからメンテナンス計画に乗せる。

(7) 対応が終わったら、チケットに記録を残し、可能であれば再スキャンや外部の監査サービスを使って「本当に塞がったか」を再確認する。

ここまでを一連の“インシデントではないけれど、インシデント予備軍への対応プロセス”として標準化しておくと、似た通知(国内のCSIRTやクラウドベンダーからのアラートなど)にも再利用できます。

8. フィッシングメールとの違いと、攻撃者が真似してくるリスク

正直なところ、「Netcraftのドメインから、脆弱性を指摘するメールが届く」というだけ聞くと、かなり“それっぽいフィッシング(phishing:なりすましメール)”を連想してしまう人も多いはずです。

NCSCもそこは分かっているようで、
・添付ファイルは付けない
・金銭の要求はしない
・パスワードや個人情報の提供も求めない
というルールを明示しています。(BleepingComputer)

とはいえ、攻撃者が将来的にこのフォーマットを真似てくる可能性は高く、
・本物の通知を装って、不正なリンクに誘導
・NCSCやNetcraftを名乗って、VPNやメールの管理者アカウントを盗む
といったシナリオは容易に想像できます。

したがって各組織としては、「本物のProactive Notificationsメールの特徴」を事前に社内に周知しつつ、「どんなに本物っぽくても、ID・パスワードを打たせるリンクはすべて疑う」という原則を徹底する必要があります。

「セキュリティのためのメール」が、逆にフィッシングの材料に使われる――というのはありがちな話なので、ここは早めに意識合わせをしておきたいところです。

9. なぜ今このサービスなのか:最近のインシデントとのつながり

BleepingComputerの関連記事を見ると、
・新しいOutlookで一部のExcel添付が開けない問題
・ロンドンの複数の区でITシステムがサイバー攻撃により障害
・Cox EnterprisesによるOracle E-Business Suite関連のデータ侵害公表
など、企業・自治体の「公開システムまわり」でのトラブルが続いています。(BleepingComputer)

さらに他メディアを見ると、React/Next.jsの重大な脆弱性やVPN機器のゼロデイ悪用など、「公開しているだけで狙われる」タイプのインシデントもこの1〜2年で増加傾向です。(リスクディスカバリー)

NCSCがProactive Notificationsを「Active Cyber Defence」の一部として打ち出した背景には、
・すべての組織が高度な脆弱性診断サービスを買えるわけではない
・でもインターネットに繋がっている以上、攻撃者からは“等しく見える”
というギャップへの問題意識があると考えられます。

言い換えると、「国家としてのサイバー衛生(cyber hygiene:サイバー衛生状態)を底上げしないと、重要インフラもサプライチェーンも守れない」という危機感の表れが、今回のサービスローンチのタイミングに出ているのではないでしょうか。

10. 日本や他国の組織が真似できるポイント

「うちは英国じゃないから関係ない」と切り捨てるには、正直もったいない話です。
日本企業・自治体・教育機関などが、今回のニュースからすぐ真似できるポイントをいくつか挙げてみます。

まず一つ目は、「自分たちでもProactive Notifications的な“外形診断”を始めること」です。
・Shodanのようなインターネットスキャン検索サービス
・自前のスキャナやクラウドベンダーの診断機能
などを使い、「自分たちのIPやドメインを外側から見たらどう見えるか」を定期的にチェックする運用を作るだけでも、かなり視界がクリアになります。

二つ目は、「国レベル・業界レベルのCSIRTともっと積極的に連携すること」です。
日本でもJPCERT/CCや各業界ISAC(Information Sharing and Analysis Center:情報共有・分析センター)が、インシデント情報や脆弱性情報を共有していますが、「自社が情報を取りに行く」姿勢がないと、どうしても連携が弱くなりがちです。

三つ目は、「通知を受けた後の社内フロー」をあらかじめ決めておくことです。
どの担当が一次受付をして、どのチームにエスカレーションし、どのくらいの時間で暫定対応まで進めるのか――こういった流れを、今日の記事のステップを参考にしながらホワイトボードに書き出してみると、かなり整理されます。

Proactive Notificationsそのものは英国限定のサービスですが、“外形スキャン+責任ある通知+組織側の素早い対応フロー”という組み合わせは、どの国・どの組織でも今すぐ設計を始められる普遍的なモデルだと言えます。

11. RedditやSNSの反応:現場の声はどう見ているか

セキュリティ系SNSやRedditなどでは、「これは良い施策だ」というポジティブな声と同時に、いくつかの懸念ポイントも議論されています。

たとえば、
・「通知が多すぎてノイズにならないか」
・「このサービスがあるからといって、自前の脆弱性管理をサボる口実にならないか」
・「NetcraftやNCSCをかたるフィッシングが激増しそう」
といったコメントが挙がっています。(Reddit)

LinkedIn上でも、「素晴らしいイニシアティブだが、組織側がこれをダッシュボードやリスク評価と連携させて“行動に落とせるか”が鍵になる」といった実務寄りのコメントが見られます。(LinkedIn)

現場目線で見ると、Proactive Notificationsは“ありがたいお節介”であると同時に、組織側の運用成熟度を如実に映し出す鏡にもなる――そのあたりがこのサービスの面白くも難しいところです。

12. みんなはどう思う?コメント欄で議論したいポイント

最後に、このニュースをきっかけに読者のみなさんと議論してみたい問いを、いくつか投げておきます。

・あなたの組織では、インターネットに公開しているシステムの棚卸しや外形スキャンを、どのくらいの頻度でやっていますか?
・もし自国の政府機関から「あなたのサーバーが危ない」とメールが来たら、社内では歓迎されそうですか?それとも「余計な口出しだ」と反発が出そうでしょうか。
・Proactive Notificationsのようなサービスが日本や他国でも始まった場合、どのような“ルール設計”なら、フィッシングとの混同を最小限にできると思いますか。
・そしてなにより、「自分たちの公開サーバー、本当に今のままで大丈夫?」という問いに、胸を張って「大丈夫」と言えるでしょうか。

このあたりの“生々しい現場の感覚”こそが、Proactive Notificationsのようなサービスを本当に役立てられるかどうかの分かれ目です。

「うちではこうしている」「ここが不安」など、実務で感じていることがあれば、ぜひコメント欄で共有してみてください。
おそらく同じ悩みを抱えている担当者が、思っている以上にたくさんいるはずです。






以上の内容はhttps://error-daizenn.hatenablog.com/entry/2025/12/06/110314より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14