CISAがCheck Point複数製品の重大脆弱性2件をKEVに追加—現行悪用中、境界と管理の“両面突破”に備えるべきです

今日の深掘りポイント

• 既知の悪用脆弱性（KEV）に入った時点で「攻撃に使われている前提」で運用判断を切り替えるべきです。3日という短い修正期限の設定は、実運用のスピード感を象徴しています。
• 対象はセキュリティ・ゲートウェイと集中管理の両系統です。境界機器（外縁）とポリシー統制点（中枢）の“同時狙い”は、攻撃者にとって展開速度と支配範囲を最大化します。
• 事実確認が進むまでの暫定措置でも効果は出ます。管理面APIの外部閉塞、信頼できる管理網への限定、監査ログの保全と即時ハンティングを先に打つべきです。
• MITRE ATT&CKでみると、Public-Facing Applicationの悪用（T1190）とExternal Remote Services（T1133）から始まり、管理層での防御無効化（T1562）やポリシー改変（T1098）に接続する典型パスが想定されます。
• 「パッチを当てる」で終わらせないでください。管理層への侵入が示唆される以上、ポリシー・オブジェクトの改変痕跡とログ完全性の検証、機器上の認証情報ローテーションまで含めて一連で設計する必要があります。

はじめに

米CISAがCheck Point製品に関する2件の重大脆弱性（CVE-2026-85102、CVE-2026-93616）をKEVカタログに追加し、現行悪用（in the wild）を明言しています。KEVは「既に攻撃で使われている又は合理的にその見込みが高い」脆弱性の集合で、連邦機関に対してはCISAの拘束力ある指令（BOD 22-01）に基づく期限内対処が義務化されています。今回は追加からわずか3日での期限設定で、攻撃速度に運用を合わせる苦渋の現実がにじみます。

日本の組織にとってもKEVは優先度付けの事実上の基準です。特に境界装置と管理サーバーの両面が対象になるとき、侵入→横展開→統制乗っ取りまでの距離が一気に縮まります。初報段階ではありますが、攻撃仮説に沿った即応の準備をしておくのが賢明です。

• CISA Known Exploited Vulnerabilities Catalog（KEV）: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• CISA Binding Operational Directive 22-01（KEV運用の根拠指令）: https://www.cisa.gov/news-events/directives/bod-22-01-reducing-significant-risk-known-exploited-vulnerabilities

深掘り詳細

事実整理（一次情報と初報の突き合わせ）

• CISAはCheck Point製品に影響する2件の重大脆弱性をKEVに追加し、現行悪用を明示しています。連邦機関に対しては修正期限が設定され、今回の対処期限は9月25日と報じられています（9月22日追加）です。
• 対象CVE（CVE-2026-85102、CVE-2026-93616）は、Check Pointのセキュリティ・ゲートウェイ系および集中管理系に影響するとされています。未認証状態から高影響のアクセス獲得に至る性質が強調されています。
• 参考（速報ベースの報道リンク。一次確認前提での参照にとどめます）:
  • GBHackersによるCISA KEV追加の報道: https://gbhackers.com/cisa-adds-multiple-check-point-product-flaws/
• KEVへの追加は、CISAのBOD 22-01に基づき「対処の優先度が最上位」であることを意味します。KEV自体は常時更新され、各CVEに対処期限（Due Date）が個別に付されます（一次情報）です。
  • KEVカタログ（一次情報）: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
  • BOD 22-01（一次情報）: https://www.cisa.gov/news-events/directives/bod-22-01-reducing-significant-risk-known-exploited-vulnerabilities

注：本稿執筆時点で各CVEの個別エントリURLやベンダー個別アドバイザリの公開有無は確認中です。脆弱性の詳細技術要件（例：VPN証明書検証の不備、管理サーバーのパス・トラバーサル等）については、初報ベースの仮説として取り扱います。確定情報はCISAのKEV個別エントリとCheck Point公式アドバイザリの公開後に精査してください。

インサイト（運用・攻撃両面の視点）

• 攻撃者の「時間的優位性」は強いです。KEV追加から72時間という短い対処期限は、野放図に露出した境界装置が数日でボットネットやAPTのラダーに組み込まれる現実に即しています。パッチ適用だけを唯一解にせず、露出低減（外部到達経路の閉塞、管理面の分離）と証跡保全を同時進行させる体制が要ります。
• 境界と管理の“二点同時”は、現代のネットワークで最も差し込みやすい刃です。ゲートウェイ側で初期アクセス、管理側でポリシー・構成の上書きというフローが成立すると、EDRやSIEMの可視性をも貫通し得ます。特に集中管理は複数拠点・多数ゲートウェイの“隘路”であり、ここを抑えられると企業全体のセキュリティ・ガバナンスが瞬時に反転します。
• 実装上の弱点が「未認証」条件で突かれる場合、防御は“設計段階の最終線”に依存します。露出面の最小化（不要サービス停止、不要インターフェイス撤去、グローバル到達性の剥離）は、脆弱性出現サイクルとは独立に効く普遍解です。これは脆弱性対応の“買い時間”として機能します。

脅威シナリオと影響

以下は初報段階の仮説に基づく想定シナリオです。MITRE ATT&CKのテクニック参照を併記します。

• シナリオ1：ゲートウェイ経由の未認証RCEからの横展開

  • 侵入仮説: 公開インターフェイスで未認証の入力処理欠陥を突かれ、任意コード実行（RCE）に至る。
  • 可能なTTP:
    • Public-Facing Applicationの悪用（T1190）: https://attack.mitre.org/techniques/T1190/
    • External Remote Services（T1133、VPN・管理用リモート経路の悪用）: https://attack.mitre.org/techniques/T1133/
    • Command and Scripting Interpreter（T1059）: https://attack.mitre.org/techniques/T1059/
    • Ingress Tool Transfer（T1105）: https://attack.mitre.org/techniques/T1105/
  • 影響: ゲートウェイ上の資格情報・セッション・設定情報が窃取され、内部資産への踏み台として利用されます。ログ改ざんが入ると検知窓が狭まります。

• シナリオ2：集中管理サーバーへの未認証アップロード→ポリシー改変

  • 侵入仮説: パス・トラバーサルや認可不備により、スクリプトやモジュールを未認証でアップロード・実行可能。
  • 可能なTTP:
    • Exploit Public-Facing Application（T1190）/Valid Accounts（T1078, 侵入後の恒久化）
    • Impair Defenses（T1562、ログ無効化/IPS無効化）: https://attack.mitre.org/techniques/T1562/
    • Account Manipulation（T1098、管理者権限付与・APIキー生成）: https://attack.mitre.org/techniques/T1098/
  • 影響: セキュリティポリシーの改変、ログ出力の抑止、マルウェア通信の許可など、統制そのものの乗っ取りに直結します。複数拠点へ一斉波及のリスクが高いです。

• シナリオ3：両者連携の“段階展開”

  • 侵入仮説: まずゲートウェイで足場確保→管理サーバーへの信頼関係や認証情報を横取り→管理層で永続化。
  • 可能なTTP:
    • Lateral Movement via Remote Services（T1021）
    • Discovery（T1087, アカウント列挙／T1046, ネットワークサービス列挙）
    • Exfiltration Over C2 Channel（T1041）
  • 影響: 境界防御の信頼モデルが崩壊し、インシデント解消には“再設計＋全域再デプロイ”に近い負担がかかります。

定量面の総合評価として、緊急度と行動可能性が高く、悪用の確度も高い事案と見ます。現場では「適用可否の判断とダウntime確保」という運用制約が最大のボトルネックになります。対処難度の高い装置群こそ、仮想パッチや露出低減を先に入れて時間を稼ぐ作戦が実効的です。

セキュリティ担当者のアクション

初報段階で実装できる“被害限制策”と、確定情報入手後の“復旧策”を併走させる計画が要です。

• 露出評価（今すぐできること）

  • インターネットに到達可能なCheck Point機器（ゲートウェイ／管理）の一覧化と、管理面（WebUI/API/SSH）の外部露出有無の棚卸しを行います。
  • 管理サーバー接続元を管理セグメントに限定し、ゼロトラスト・プロキシや踏み台経由の多要素認証（MFA）を強制します。
  • 監査ログ（管理操作、ポリシー変更、ユーザー/オブジェクト作成・削除）の即時保全と転送先の改ざん耐性（WORM化、外部保管）を確保します。

• 暫定の技術的コントロール

  • 影響面のサービス（リモートアクセス、管理API、未使用プラグイン）の一時停止・外部遮断を検討します。不可の場合は到達元IPの厳格制限とレート制御を入れます。
  • IPS/WAF/ゲートウェイの仮想パッチ（シグネチャ／振る舞いベース）をベンダから入手できる場合は即時適用します。
  • 証明書関連の不備が疑われる場合（仮説段階）、強制的なサーバー証明書検証とピンニング設定を見直します。

• パッチ／アップグレードと検証

  • Check Pointの公式アドバイザリ／ホットフィックスを入手次第、HA構成の片系から適用→フェイルオーバー→反対系適用の手順でダウンタイム最小化を図ります。
  • 適用後に“意図しないポリシー差分”“ログ出力停止”“不明な管理者アカウント・APIキー”がないか、監査ダイフを必ず比較します。

• ハンティング・検知（IoC未確定でも回せる観点）

  • 短時間に連続するポリシーインストール、通常外の管理者端末・ASNからの管理アクセス、ゲートウェイから未知FQDN/ASNへのアウトバウンドがあれば要精査です。
  • ゲートウェイ／管理サーバー上の新規SUID/SGIDファイル、新規常駐スクリプト、rc.localやcronの変更痕跡を点検します。
  • 大容量の設定バックアップ／ログの外部送信があれば、機密情報の二次被害（資格情報・トポロジ漏えい）を前提に対応します。

• 侵害疑い時の対応方針

  • まず“管理サーバーの論理隔離”を優先し、既知クリーンなバックアップからの再構築を検討します。ログは隔離前にスナップショットを取得し、整合性を保って保存します。
  • ゲートウェイ／管理サーバーに保存された認証情報（ローカル管理者、APIキー、デバイス間信頼、ディレクトリ連携）のローテーションを行います。
  • 影響範囲が広い場合は、ポリシー・オブジェクトの“最小許可原則”へ暫定収束（通信許可を厳格に絞る）して再展開します。

• ガバナンス・連携

  • CISO/IT運用と合意の“KEV優先パス”を事前に整備し、パッチ承認・ダウンタイム確保・暫定遮断の意思決定を加速します。
  • ベンダTAC／国内代理店と連絡線を開き、公式IoC・緩和策・サポート手順の入手を優先します。
  • 重要拠点・OT/ICS接続のあるネットワークでは、業務継続計画（BCP）と併せた段階的ロールバック計画を作成します。

最後に、メトリクスからにじむ“即応性・実効性の高さ”は、現場がいま求められている判断の難しさを物語ります。完璧な情報が揃う前に、損害を最小化するための暫定策を打てる組織が強いです。境界と管理、二つの急所を同時に守るために、技術と運用の両輪でスピードを出していきたいところです。

参考情報

• CISA Known Exploited Vulnerabilities Catalog（一次情報）: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• CISA Binding Operational Directive 22-01（一次情報）: https://www.cisa.gov/news-events/directives/bod-22-01-reducing-significant-risk-known-exploited-vulnerabilities
• MITRE ATT&CK T1190（Public-Facing Applicationの悪用）: https://attack.mitre.org/techniques/T1190/
• MITRE ATT&CK T1562（Impair Defenses）: https://attack.mitre.org/techniques/T1562/
• 報道（速報ベース）: https://gbhackers.com/cisa-adds-multiple-check-point-product-flaws/