マクニカでは、セキュリティの企画・導入・文化浸透を担う人たちが集まって互いの知見を共有し、現場の課題に取り組むためのコミュニティ「関西情報セキュリティコミュニティ（通称：KISC）」を運営しています。 

2025年4月に、自社サービスや製品をリリース・運用するためのお悩みや知見を共有する分科会「製品セキュリティ分科会」を発足し、2026年7月31日(金)に第4回目となるMeetupを関西大学梅田キャンパスにて実施しました。

今回は16名の方々に参加いただき、「SBOMは"どこまで・何のために"作るのか」について、たくさんの意見交換が行われました。本記事ではその様子をお届けします。  

　過去の製品セキュリティ分科会のレポートはこちら：
　　Vol.1：製品セキュリティの組織体制や人材の在り方とは？【関西コミュニティ（KISC）活動レポート】 
　　Vol.2：CRAなど法規制や規格対応の実情とは？【関西コミュニティ（KISC）活動レポート】
　　Vol.3：SBOMについてみんなで語ろう -導入のアレコレ交換会-【関西コミュニティ（KISC）活動レポート】

目次 

・テーマ設定の背景 
・当日の様子 
・まとめ 
・参加者の反応 

テーマ設定の背景 

前回の製品セキュリティ分科会Vol.3では「SBOMに関する取り組み」をテーマにMeetupを開催しました。その際に、SBOMに関する取り組みはまだまだ不透明な部分が多く、手探りで進めている企業様が多いと感じたことから、より深ぼりしてSBOMについての情報交換を行うために、第3回に引き続きSBOM（Software Bill of Materials／ソフトウェア部品表）に焦点を当てました。 

イベントアジェンダ 

・オープニング
・初参加企業ライトニングトーク
・グローリー株式会社/パナソニックインダストリー株式会社/古野電気株式会社/オムロン株式会社によるパネルディスカッション
　　①SBOMは"どこまで・何の目的で"作るのか
　　②SBOMを"作った後"、脆弱性トリアージをどのように運用するのか
　　③サプライチェーン／3rdパーティにSBOMをどのように要求し、どのように活用するのか
・テーマ別グループディスカッション
・全体共有
・クロージング

当日の様子 

今回の分科会では、「参加企業4社によるパネルディスカッション」と「テーマ別グループディスカッション」を行いました。 

参加者の属性としては、製造業を中心に、研究開発、ソフトウェア／ハードウェア開発、品質保証、生産技術、情報システム部門など、製品セキュリティに関わる多様な部門の方々に参加いただきました。  

第1回・第2回・第3回から継続してご参加いただいている方も多く、回を重ねることで参加者同士の距離感がより近くなっている様子が印象的でした。 

製品セキュリティという、明確なまだ正解が見えづらく、手探りで取り組む企業が多いテーマだからこそ、社名や立場を越えて本音を共有できる、数少ない場として機能し始めていることを改めて実感する時間となりました。 

「初参加企業のライトニングトーク」では、各社の事業や業務内容に加え、SBOM対応の取り組み状況や課題感が共有されました。
特に印象的だったのは、「SBOM」という同じテーマに向き合っていても、企業ごとに置かれている状況や課題の出発点が異なることです。CRA対応を契機に整備を進めている企業、脆弱性管理ツールを活用しながら運用方法を模索している企業、製品セキュリティの基盤づくりを進めている企業など、それぞれの立場から具体的な悩みが共有されました。
後半のディスカッションが盛り上がった要因の一つとして、事前に参加者それぞれの背景や課題感を共有したことで、お互いの立場を理解しながら議論を進められたことが挙げられています。

「参加企業4社によるパネルディスカッション」では、所属企業で製品セキュリティを主導している方から、自社でのSBOMの取り組み・脆弱性のトリアージ・サプライチェーンへのSBOMの要求状況・活用方法を発表いただきました。  

業界や企業規模を問わず共通のお悩みが多くでる一方で、それぞれの立場ならではの工夫や課題について意見が交わされました。

ディスカッションを進める中で、7月30日に経済産業省が公開した「サイバーセキュリティのためのソフトウェア部品票（SBOM）の最小要素に関する国際ガイダンスへの共同署名」について触れられるなど、最新情報の共有も含まれたディスカッションとなりました。

 「テーマ別グループディスカッション」については、テーマごとに振り返りができればと思います。

テーマ1：SBOMは"どこまで・何の目的で"作るのか

このテーマでは、SBOMを「何のために作るのか」「どこまで管理対象とするのか」について議論しました。

参加者からは、「自社のソフトウェア管理のため」「脆弱性管理のためにSBOMを作成している」といった声がありました。また、「SBOM作成は必要性に迫られている」「不明な項目は"不明"として扱ってよい」といった実務的な気づきも共有されていました。

一方で、運用面ではさまざまな課題が見えてきました。例えば、「SBOMの正しさをどのように担保するのか」「OSSが少なく自社開発が多いため自動生成が難しい」「古くなったSBOMをどう扱うか」「SBOMの一覧が常に最新であり、かつ脆弱性が無いことをどう確認するか」といった議論が交わされました。

こうした課題に対して、今後のアクションとしては、新バージョンのSBOMやOSSの登録を優先し、古いバージョンのSBOMや購入品コンポーネントの優先度を見直すことがあげられました。また、購入品コンポーネントについては契約文書を活用して管理責任を明確化することや、SBOMの内容を確認する手段を整備することも重要な取り組みとして共有されました。

テーマ2：SBOMを"作った後"、脆弱性トリアージをどう回すか

このテーマでは、SBOMを作成した後の脆弱性管理、特にトリアージをどのように運用していくかについて議論しました。

参加者からは、「トリアージのやり方は他社も同じで安心した」「技術部門にトリアージまで任せる企業が多い」「手間がかからない方法で判断する仕組みが必要」といった気づきが共有されました。

一方で、悩みとしては、「対外的に納得してもらえるトリアージ方法は何か」「誰がトリアージするのか」「設計担当者以外がトリアージできるのか」「トリアージ結果を誰がレビュー、承認するのか」といった役割分担や判断基準に関する論点が挙がりました。さらに、NVD登録後に即時チェックすると更新が発生することや、EPSSなど更新される情報によって判断がぶれないかという懸念も示されました。また、「Linuxの脆弱性が多いこと」、「CPEやPURLのないコンポーネントの脆弱性をどう見るか、対象が溜まって放置されないようにするにはどうすればよいか」、といったより具体的な悩みも挙がっていました。

今後のアクションとしては、まずトリアージ基準や規定を策定し、優先度の高いものから段階的に導入することや、AIを活用したトリアージへの挑戦にも高い関心が寄せられていました。

今回の議論を通じて見えてきたのは、SBOM作成後の運用をいかに現実的かつ継続的に回していくかという点です。

最初から完璧な仕組みを目指すのではなく、まずは優先度の高い判断基準から整備し、運用しながら改善を重ねていくことの重要性が感じられる議論となりました。

テーマ3：サプライチェーン/3rdパーティにSBOMを"どう要求し、どう使うか"

このテーマでは、サプライヤや3rdパーティからSBOMをどのように取得し、実際の脆弱性管理に活用していくかについて議論が行われましたが、現時点では3rdパーティにSBOM要求をしていない企業が多いようでした。

また、「SBOMよりもVMP、VDPを確認することが重要ではないか」といった気づきや、「脆弱性管理そのものを3rdパーティに依頼するという考え方」も話題にあがりました。

一方で、悩みとしては、「サプライチェーンでどこまで責任を負うべきか」「サプライヤからのセキュリティ更新をどう社内対応フローにつなげるか」「子会社と自社でSBOM管理を分けるか否か」といった論点が挙げられていました。また、「サプライヤからSBOMをもらった後の管理や更新」「TARA(Threat Analysis and Risk Assessment)のためにサプライヤSBOMが必要か」「SBOMのフォーマットが合意できないこと」「調達をどう巻き込むか」といった悩みも挙がりました。

今後のアクションとしては、3rdベンダーの取り扱いを社内ルール化することや、SBOMを受領した後の運用を検討すること、脆弱性管理についてベンダーと対話してみることなどの意見が出されました。

SBOMはサプライヤから受け取れば終わりではなく、受け取った情報をどう管理し、どう社内の脆弱性対応フローにつなげるかを考える必要があります。今回の議論では、SBOM単体ではなく、VMPやVDP、脆弱性管理プロセス、購買や調達との連携を含めて考える重要性が浮き彫りになりました。

各社の状況や、参加者が担う役割によって抱える課題はさまざまですが、参加者同士が「実務的な目線」で経験や課題を共有しながら学び合い、熱気あふれる時間となりました。

まとめ 

今回の製品セキュリティ分科会 Vol.4では、SBOMを「作る」だけではなく、「何のために作るのか」「作った後にどう運用するのか」「サプライチェーンとどう向き合うのか」といった、より実践的なテーマについて意見交換をしました。

議論としては、SBOMの正しさをどう担保するか、脆弱性トリアージを誰がどの基準で行うか、サプライヤから受け取ったSBOMをどう管理するかなど、現場で直面している具体的な悩みが多く共有されました。

一方で、トリアージ基準の策定、AI活用への挑戦、3rdパーティ取り扱いのルール策定、ベンダーとの脆弱性管理に関する対話の強化など、次につながる具体的なアクションについても多くの意見が交わされました。

SBOMや製品セキュリティへの取り組みは、まだ発展途上の領域です。だからこそ、同じ悩みを持つ実務者同士が集まり、現場のリアルや実践例を共有しながら、一緒に前へ進んでいくことに大きな価値があります。今後も、製品セキュリティに関わる方々が立場や業界を越えて学び合える場として、KISC製品セキュリティ分科会を盛り上げていきたいと思います。

参加者の反応 

今回は、参加者全員から満足度の高いイベントを開催することができ、７割を超える参加者の方が「コミュニティでの情報交換や交流が役に立った」と回答しており、参加者同士の対話や知見共有の価値が改めて確認されました。 

アンケートでも、 
「各社のさまざまな取り組みが参考になった」 
「他社の状況を知ることで、自社の立ち位置を把握できた」 
「具体的な事例やツール、AI活用の話が実践のヒントになった」 
といった声が多く寄せられ、実務に直結する学びの多い場となったことがうかがえます。

最後に 

KISC製品セキュリティ分科会は、ユーザ企業同士の情報交換に加え、製品セキュリティ分野における豊富な経験や知見を持つ有識者にも参加いただき、実務に即した視点でのコメントやアドバイスが得られる点も特長の一つです。 

現場で直面している課題や悩みを共有しながら、専門的な知見も交えて議論できる場として、単なる情報交換にとどまらない、より実践的な学びの機会を提供しています。 

SBOMや製品セキュリティへの取り組みに課題意識をお持ちの方は、ぜひ次回のMeetupにもご参加ください。 

「関西情報セキュリティコミュニティ」に是非参加してみたい、という方は以下HPからコミュニティへの登録を、お待ちしています！
※東京・名古屋にも開催地を拡大中！
※本コミュニティは企業のサイバーセキュリティを担う方限定のコミュニティとなります。

▼Taneva（対象：自社のセキュリティを担う方はどなたでもご参加可能）　参加お申込みはこちら

▼KISC：関西版コミュニティ（対象：マクニカから製品・サービスをご購入いただいているお客様） 参加お申し込みはこちら

▼IST2：東京版コミュニティ（対象：マクニカから製品・サービスをご購入いただいているお客様） 参加お申し込みはこちら

▼Ikomai：東海版コミュニティ（対象：マクニカから製品・サービスをご購入いただいているお客様） 参加お申し込みはこちら

近年、サイバー攻撃が巧妙化し、企業や組織を悩ませる被害が急増しています。なかでもランサムウェアは、ネットワークを介して侵入し、重要なデータを暗号化して身代金を要求するなど、甚大な影響を及ぼす代表的な脅威です。本記事では、ランサムウェア被害の最新動向から、それに対抗するために有効な「マイクロセグメンテーション」と「NDR（Network Detection & Response）」の2つの手法を、3つのセキュリティフレームワークの考え方を軸にわかりやすく解説します。

目次

• ランサムウェア被害の現状
  • 企業に深刻な脅威となる攻撃手法
  • 検知困難な脅威とその進化
• 3つのセキュリティフレームワークとその役割
  • サイバーハイジーン：平時・予防のセキュリティ
  • ゼロトラストネットワーク：防御・制御のセキュリティ
  • サイバーレジリエンス：有事の対応と復旧

ランサムウェア被害の現状

企業に深刻な脅威となる攻撃手法

ランサムウェアは、外部公開機器や脆弱な拠点、サプライチェーンの弱点を起点に、企業の内部ネットワークへ侵入します。ゼロデイ脆弱性を突いた初動から、手動操作によって巧みに横展開（ラテラルムーブメント）されるケースが増加しています。攻撃者は認証情報を奪ってEDRの導入範囲を避けて移動し、バックアップも事前に標的にするなど、従来の防御策を突破する手口が主流になっています。

検知困難な脅威とその進化

攻撃は高速かつ広範囲に拡散し、EDRの検知を意図的に回避、停止、無効化されることも珍しくありません。さらに、攻撃者が暗号化を行う前に機密情報を窃取し、二重脅迫に発展する例も増えています。クラウドの設定不備や、外部公開資産へのアタックサーフェス拡大は、企業ごとに日々深刻化しています。

3つのセキュリティフレームワークとその役割

総合的なセキュリティ体制の構築には、「サイバーハイジーン」「ゼロトラストネットワーク」「サイバーレジリエンス」という3つの視点が重要です。

サイバーハイジーン：平時・予防のセキュリティ

サイバーハイジーンは、脆弱性管理や攻撃対象の可視化・優先順位付けなど、平時からのリスク削減を目的としています。近年は「エクスポージャー管理（CTEM）」として、実際に攻撃に使われる危険なエクスポージャーだけに集中し、対処すべきリソースを最適化する流れが強まっています。

エクスポージャー管理には複数のソリューションを組み合わせます。資産の把握（EAP）、脅威・リスクの検出・優先順位付け（AEV）、攻撃シナリオ検証、パッチ等の自動化対応をワークフロー化し、全社的なセキュリティ体制を整備します。特に多様化したクラウド資産や外部公開資産への対応が不可欠です。 

ゼロトラストネットワーク：防御・制御のセキュリティ

ゼロトラストネットワークは、"信頼しない"ことを大前提にしてあらゆる通信やアクセスを最小限に制御します。多要素認証や端末評価を中心に「縦：ユーザーや拠点からのアクセス」のゼロトラスト化（SASE/IDaaS/EDR）、そして「横：同一ネットワーク内での通信」の分割・抑止（マイクロセグメンテーション）が柱となります。

SASEなどによる「縦」の保護

SASE（Secure Access Service Edge）は、WANの統合やクラウド活用の広がりと共に、企業ネットワークの多地点化・リモート化にも対応。ユーザー認証、端末評価、通信制御の一元管理を実現し、パートナーアクセスや工場拠点への守りも強化します。

マイクロセグメンテーションによる「横」の抑止

従来、内部ネットワークは比較的広範な通信を許容してきました。しかし、侵入後の横展開防止には、サーバー間やワークロード間の通信をきめ細かく分割する「マイクロセグメンテーション」が有効です。API連携やエージェントレスな管理で、危険なワークロードや疑わしい挙動を自動隔離できる先進的なソリューションも登場しています。

サイバーレジリエンス：有事の対応と復旧

巧妙化・検知困難化する攻撃への"最後の綱"となるのがサイバーレジリエンスです。これは、実際に侵害が発生した場合もデータ復旧や事業継続を可能にする方策を指します。

NDRによる網羅的な攻撃検知

NDR（Network Detection & Response）は、意図的にEDRを回避する攻撃者や、EDR／ログ分析だけでは検出困難な侵害活動も、ネットワーク全体を「面」で監視することで早期発見します。端末単位の監視とは異なり、ラテラルムーブメントや認証情報の悪用行動も抽出でき、XDRとの連携で隔離と対応の高度化が図られています。

NDRを活用したセキュリティ運用は、インシデント事例の分析からインシデント対応の自動化・意思決定の迅速化まで幅広く対応しています。

データレジリエンスの重要性

近年は「侵害されることを前提」としたバックアップ、暗号化・鍵管理がより重視されています。クラウド/SaaS環境含め多様なデータ管理基盤が登場し、万が一の漏洩時でもデータ復旧不能、盗まれても暗号化で守れる体制が構築されつつあります。

まとめ

ランサムウェア被害の現状は、攻撃手法の高度化・多様化により、予防～検知～復旧まで一貫した対応が欠かせません。「サイバーハイジーン」で脆弱性管理体制を整え、「ゼロトラストネットワーク」で内部横展開と不正アクセスの抑止を実現、「サイバーレジリエンス」で有事対応力とデータ復元力を備えることがポイントです。とくにマイクロセグメンテーションやNDRなど、最新ソリューションを適切に組み合わせて運用高度化を進めてください。

本記事の詳細は、無料動画ポータル「Macnica Security& DX Stream」で公開中！
１度の登録で、100セッション以上が見放題！今すぐ動画視聴申し込みする↓

こんにちは！マクニカ コミュニティマネージャーの福地です！
企業のサイバーセキュリティを担う立場の人たちが集い、課題や悩みを共有しあうことで日本のセキュリティ対策をより強固にしていきたい――そんな思いから、マクニカではセキュリティコミュニティ「情報セキュリティチーム Tokyo（IST2）」を運営しています。

2026年5月28日に開催したMeetup Vol.4では、「ランサムウェア対策、いま見直すべきポイントは？」をテーマに、27名の方が集まり、各社のランサムウェア対策における見直すべきポイントについて、共有やディスカッションが行われました。

本記事では、当日行われたMeetupの様子をお届けいたします！

目次

• テーマ設定の背景
  
  • イベントアジェンダ
• 当日の様子
  • ①「対策済み」は本当に安心なのか？
  • ②「見えていないリスク」をどう見つけるか
  • ③グループディスカッションで見えてきた共通課題
  • ④技術では解決できない課題
• まとめ

テーマ設定の背景

ランサムウェアは、IPAが公開する「情報セキュリティ10大脅威」でも継続して上位に挙げられるなど、企業にとって最も警戒すべきサイバー脅威の一つです。

昨年も国内外で大きな被害が相次ぎ、多くの企業が改めて自社の対策状況を見直すきっかけとなりました。

多くの企業ではEDRやバックアップ対策などを導入し、ランサムウェア対策を進めています。一方で、新たな攻撃手法の登場や被害事例を目にする中で、「本当に今の対策で十分なのだろうか」「見落としているポイントはないだろうか」「有事の際に想定どおり機能するだろうか」「他社はどのような観点で対策を見直しているのだろうか」といった不安や疑問を感じている方も多いのではないでしょうか。

そこで今回のIST2 Vol.4では、「ランサムウェア対策、いま見直すべきポイントは？」をテーマに、各社の実践事例や課題、見直しのポイントについて共有・議論を行いました。

イベントアジェンダ

今回のMeetupでは、事例共有と参加者同士のディスカッションを通じて、ランサムウェア対策を見直すための観点や考え方を持ち帰っていただくことを目的に、以下のプログラムを実施しました。

• オープニング
• ライトニングトーク
• 事例講演①
• 事例講演②
• グループディスカッション
• クロージング
• 懇親会

事例講演では各社の実践的な取り組みや経験を共有いただき、グループディスカッションでは参加者同士で率直な意見交換を行いました。ランサムウェアを取り巻く脅威が変化する中で、現在の対策をどのような視点で見直すべきか、多くの実践的な学び・考え方が得られる会となりました。

当日の様子

①「対策済み」は本当に安心なのか？

ライトニングトークや事例講演では、各社がランサムウェア対策を見直した背景や、その過程で見つかった課題について共有いただきました。
その中で特に印象的だったのは、「対策があること」と「有事に機能すること」は別物であるという共通認識です。
EDRやバックアップ、認証強化など、多くの企業ではすでにさまざまな対策が導入されています。
しかし、実際に見直しを進める中で、

• バックアップは取得しているが、リストアを検証したことがない
• 管理できていると思っていた資産に抜け漏れがあった
• システム同士のつながりが想定以上のリスクになっていた
• 有事の際の判断基準や連絡体制が明確でなかった

といった課題が見つかったという声が共有されました。
対策を「導入すること」だけでなく、有事に本当に機能するかという視点で見直すことの重要性を改めて考えさせられる内容となりました。

②「見えていないリスク」をどう見つけるか

事例講演では、過去のインシデント経験や対策の棚卸しを通じて見えてきた"盲点"についても紹介されました。

特に印象的だったのは、

• 想定外の侵入経路
• 管理対象外になっていた機器
• グループ会社や海外拠点との運用差

といった、一見すると見落としがちなポイントです。

また、参加者からは「対策済みと思っていたものほど、実際に検証すると不安が残る」という声も聞かれました。
新しい対策を追加するだけではなく、いま実施している対策を改めて検証することこそが、ランサムウェア対策の第一歩なのかもしれません。

③グループディスカッションで見えてきた共通課題

グループディスカッションでは、各テーブルでさまざまな議論が行われましたが、多くのグループで共通して話題になったのが、「初動対応をどう設計するか」というテーマでした。

ランサムウェア攻撃は短時間で被害が拡大するため、

• どのアラートを重要と判断するのか
• 誰が判断するのか
• 誰に報告するのか
• 夜間や休日はどう対応するのか

といった点を平時から整理しておく必要があります。

「実際にインシデントが発生したとき、迷わず動ける状態を作れているだろうか」という問いは、多くの参加者にとって共通のテーマとなっていました。

④技術だけでは解決できない課題

もう一つ印象的だったのは、技術的な対策だけでは解決できない課題が多く挙がったことです。 ディスカッションでは、

• 経営層との認識合わせ
• 海外拠点との連携
• 自社資産の把握
• インシデント対応体制の整備
• 全社員への意識浸透

などのテーマについても活発な意見交換が行われました。

企業規模や業種は異なるものの、「どこまで対策を実施するか」「限られた人員・予算の中で何を優先するか」という悩みは多くの企業で共通していることがわかりました。

まとめ

ランサムウェア対策というと、EDRやバックアップ、脆弱性対策などの技術的な施策に目が向きがちです。しかし今回のMeetupを通じて見えてきたのは、「対策を導入すること」と「有事に機能すること」は必ずしも同じではないということでした。

事例講演やグループディスカッションでは、バックアップのリストア検証、初動対応のルール整備、資産管理、経営層との連携など、企業規模や業種を問わず多くの組織が共通して抱える課題について意見交換が行われました。

また、「本当に今の対策で十分なのか」「有事の際に想定どおり機能するのか」といった問いに対し、他社の実践や考え方を知ることで、自社の対策を見つめ直すヒントを得られた参加者も多かったのではないでしょうか。

IST2は、正解を学ぶ場ではなく、自社を見つめ直すきっかけを得る場です。

チャタムハウスルールのもとで率直な議論を行い、それぞれの組織が抱える悩みや工夫を共有することで、「自社ではどう考えるべきか」「何から取り組むべきか」を考える機会になります。

今後もIST2では、企業のセキュリティ担当者同士が実践的な知見を共有し、ともに学び合えるコミュニティを目指して活動していきます。
※関西・名古屋でも開催中！
※本コミュニティは企業のサイバーセキュリティを担う方限定のコミュニティとなります。

▼Taneva（タネバ）：自社のセキュリティを担う方はどなたでもご参加可能なコミュニティ

▼KISC：関西版コミュニティ（対象：マクニカユーザ）

▼IST2：東京版コミュニティ（対象：マクニカユーザ）

▼Ikomai：東海版コミュニティ（対象：マクニカユーザ）

▼SD-Streamにてコミュニティについての動画公開中、ぜひご視聴ください

• HTTP/2 Bombは、HTTP/2の仕組みを悪用してWebサーバーのメモリを急速に消費させるDoS攻撃です。
  
• 公開情報では、AIコーディングエージェントであるCodexを使って発見された事例として紹介されており、PoCも公開されています。
  
• AI時代には未知・新種のWeb脆弱性がより早く発見・再現される可能性があり、外部公開Webサーバーには防御の見直しが求められます。

はじめに

WebサーバーやWebアプリケーションは、企業のサービス提供や顧客接点を支える重要な基盤です。一方で、インターネットに公開されている以上、世界中の攻撃者から直接アクセスされる可能性があります。
近年、AIの進化により、ソースコードの解析、脆弱性の発見、攻撃手法の組み合わせが以前よりも高速化する可能性が指摘されています。その象徴的な事例の一つとして注目されたのが、HTTP/2 Bombです。
HTTP/2 Bombは、Web通信で広く使われるHTTP/2の仕組みを悪用し、サーバーのメモリを急速に消費させることでサービス停止を引き起こす可能性のある攻撃です。公開情報では、OpenAI Codexを活用して発見されたと説明されており、さらにPoCも公開されています。
本記事では、HTTP/2 Bombの概要、攻撃の仕組み、そして外部公開Webサーバーに求められるフロンティアAI対策について分かりやすく解説します。

目次

1. HTTP/2 Bombの概要
2. HTTP/2 Bombの攻撃の仕組み
3. 外部公開 Web サーバーに求められるフロンティアAI対策
4. 攻撃を到達する前に検知・制御する防御層：WAF
5. Imperva CloudWAFについて
6. まとめ

1．HTTP/2 Bombの概要

HTTP/2 Bombとは、HTTP/2通信の仕組みを悪用して、Webサーバーのメモリを大量に消費させるサービス拒否、つまりDoS攻撃の一種です。
DoS攻撃とは、サーバーに過剰な負荷をかけ、正常な利用者がWebサイトやWebサービスにアクセスできない状態にする攻撃です。情報を盗む攻撃とは異なり、主な被害は「サービス停止」や「応答遅延」です。
HTTP/2 Bombが注目された理由は大きく3つあります。

HTTP/2 Bombが注目された理由

①少量の攻撃通信によって、サーバー側に大きな負荷を与えられること

一般的な大量アクセス型のDDoS攻撃では、攻撃側にも多くの通信量が必要になります。
一方、公開情報によると、HTTP/2 Bombは1台の端末と一般的な回線でも、短時間でサーバーを応答不能にし得ると説明されています。
つまり、大規模な攻撃基盤を持たない攻撃者でも、条件が合えば深刻な影響を与えられる点が危険視されています。

②PoCが公開されていること

PoCとはProof of Conceptの略で、脆弱性が実際に成立することを示す実証コードを指します。
PoCは、防御側が影響確認や対策検証を行ううえで重要な情報です。一方で、攻撃者にとっても攻撃手法を理解し、再現しやすくなる材料になり得るため、早期に影響確認と防御策の見直しを行うことが重要です。

③AIを活用して発見された脆弱性であること

HTTP/2 Bombは、AIコーディングエージェントであるOpenAI Codexを活用して発見された攻撃手法として、公開情報では説明されています。
具体的には、以前から知られていた複数の攻撃手法を組み合わせる形で発見されたとされています。これは、AIが既知の技術情報やコードの差分を分析し、これまで見落とされていた攻撃の組み合わせを見つける可能性を示す事例です。
つまり、HTTP/2 Bombは「AIによる脆弱性発見」が、将来の話ではなく、現実のWebセキュリティ課題として表面化したということです。

2．HTTP/2 Bombの攻撃の仕組み

HTTP/2 Bombの仕組みを、簡単にご紹介します。

悪用されたHTTP/2の仕組み「ヘッダー圧縮」とは

ブラウザがWebサイトにアクセスするとき、ブラウザからサーバーへは「ヘッダー」と呼ばれる付随情報が送られます。
ヘッダーには、たとえば「どのページを見たいのか」「どんなブラウザを使っているのか」「ログイン情報やCookieはあるか」といった情報が含まれます。

HTTP/2は、Webサイトを高速に表示するために使われる通信方式です。HTTP/2では、こうしたヘッダー情報を短い情報でやり取りできるように工夫されています。
たとえるなら、飲食店で「ハンバーグ、ライス、サラダ、スープ、ドリンクのセット」と長く伝える代わりに、「Aセット」とだけ注文するようなものです。
注文する側は短い言葉で済みますが、お店側は「Aセット」が何を含むのかを確認し、実際にハンバーグ、ライス、サラダ、スープ、ドリンクを準備する必要があります。
HTTP/2のヘッダー圧縮もこれに近く、通信する側は短い情報で済みますが、サーバー側ではその情報をもとに実際の内容を確認し、処理する必要があります。
通常であれば、これは通信を効率化し、Webサイトを速く表示するための便利な仕組みです。

HTTP/2 Bombでは、この仕組みが悪用される

「ヘッダー圧縮」は、本来であれば通信を速くするための便利な機能です。
しかし、HTTP/2 Bombでは、この仕組みが悪用されます。

攻撃者は、ネットワーク上では小さく見える情報を繰り返しサーバーに送ります。
サーバー側では、その大量の短い情報を確認し、処理のためにメモリを使います。
その結果、攻撃者が送るデータ量は小さくても、サーバー内部では処理が大きく膨らみ、想定以上のメモリが使われてしまう場合があります。

また、HTTP/2 Bombでは、単に小さな通信を繰り返し送り大きな処理を発生させるだけではありません。
攻撃者は、通信をすぐに終わらせず、サーバーに「まだ処理中」の状態を保たせます。
これにより、サーバーは使ったメモリをすぐに解放できず、メモリ使用量が増え続けます。

先ほどのレストランの例でいえば、料理の完成後、攻撃者は料理の受け取り拒否をします。
そうすると、レストラン側は料理や配膳スペースを片付けられません。
その結果、厨房や店内の余裕がなくなり、ほかのお客さんへの対応が難しくなっていきます。

攻撃の流れまとめ

攻撃の流れを簡単にまとめると、次のようになります。

1. 攻撃者が、サーバー側の処理を膨らませる短い情報を繰り返しサーバーに送る
2. サーバー側では、繰り返し送られる短い情報を処理するために大きなメモリが使われる
3. 攻撃者が通信を終わらせず、サーバーに処理中の状態を保たせる
4. メモリが次第に圧迫され、応答遅延やサービス停止につながる

ポイントは、攻撃者が大量のデータを送りつけなくても、サーバー側に大きな負荷を発生させられることです。
つまりHTTP/2 Bombは、HTTP/2の「少ない通信量で効率よくやり取りする仕組み」を逆手に取り、サーバー内部の処理負荷を大きく膨らませる攻撃だと言えます。

3．外部公開 Web サーバーに求められるフロンティアAI対策

基本的な対策は、セキュリティパッチの適用・アップデート

HTTP/2 BombのようなWeb脆弱性に対して、まず基本となる対策は、影響を受けるソフトウェアを確認し、必要に応じて修正済みバージョンへアップデートすることです。
Webサーバー、リバースプロキシ、APIゲートウェイ、ロードバランサーなど、外部公開されたWeb基盤でHTTP/2を利用している場合は、利用している製品やバージョンが脆弱性の影響を受けるかを確認する必要があります。
そのうえで、ベンダーから提供されるセキュリティパッチの適用・アップデートをすることが重要です。

アップデートだけに頼らない備えが必要

しかし、実際の企業システムでは、すべての脆弱性に対して即座にアップデートを適用できるとは限りません。
Webサービスを停止できる時間は限られており、アップデート前には影響確認、検証、メンテナンス調整、関係者への通知などが必要になります。
特に今後、AIによる脆弱性発見が進むことで、新たなWeb脆弱性がより短い間隔で見つかる可能性があります。
そのたびに本番環境のメンテナンス時間を確保し、すべてのシステムを即座に更新し続けることは、現実的には大きな負担になります。

また、ソフトウェアアップデートは、すでに発見され、修正プログラムが提供された脆弱性に対して有効な対策が、まだ発見されていない未知の脆弱性や、修正プログラムが提供される前の攻撃に対しては、アップデートだけで防ぐことはできません。
つまり、アップデートは非常に重要な対策ですが、それだけで外部公開Webサーバーを十分に守れるとは限らないのです。

4．攻撃を到着する前に検知・防御する防御総：WAF

そこで有効な対策の一つとなるのが、WAF（Web Application Firewall）です。
WAFは、Webアプリケーションとインターネットの間で通信を監視・制御し、不審なリクエストを検知・遮断するセキュリティ製品です。攻撃をWebアプリケーション本体に到達させる前に制御できる点が、大きな特長です。
たとえば、異常なリクエスト、大量アクセス、不自然なヘッダー、通常とは異なる通信パターンなどを検知し、必要に応じてブロックや制限を行うことができます。

修正までの時間を補う「仮想パッチ」

また、WAFは「仮想パッチ」として機能する場合もあります。仮想パッチとは、ソフトウェア自体をすぐに修正できない場合でも、WAF側で攻撃に使われるリクエストの特徴を検知・遮断し、脆弱性を悪用されるリスクを低減する考え方です。
新しいWeb脆弱性が発見されても、本番環境のアップデートには検証やメンテナンス調整が必要です。そのような場面で、WAFに防御ルールやシグネチャを適用することで、修正プログラムを適用するまでの間、攻撃リスクを抑えることが期待できます。

未知・未修正の脆弱性にも備えるWAF

AIによって未知・新種の脆弱性がより早く発見され、PoC公開によって攻撃手法が短期間で広がる可能性がある中、企業側にも迅速な防御対応が求められます。
WAFは、ソフトウェアアップデートだけでは埋めきれない時間的なギャップを補い、外部公開Webサーバーを守るための有力な防御手段となります。
特に、既知の脆弱性に対する防御だけでなく、未知の脆弱性が悪用される場合でも、不審なリクエストや通常とは異なる通信パターンを検知・制御することで、攻撃リスクを低減できる可能性があります。

重要なのは「検知できる」だけでなく「止められる」こと

そのため、AI時代のWebセキュリティにおいては、最新の脆弱性へ迅速に追随できることに加え、未知の攻撃にも備えられる検知精度が重要です。
さらに、実運用では「検知できること」だけでなく、「ブロックモードで運用しやすいこと」も欠かせません。
誤検知が多いWAFでは、正常な利用者への影響を懸念して、実際にはブロック運用に踏み切りづらくなります。
そのため、ブロックモードで運用しやすい誤検知の少なさや、日々の運用を支援する機能を備えたWAFを選定・運用することが重要です。

5．Imperva Cloud WAFについて

弊社で取り扱うThales社「Imperva Cloud WAF」は、最新の脆弱性や攻撃手法に対応するための防御ルールが継続的にアップデートされるクラウド型WAFです。

最新の脆弱性へ迅速に対応

メーカー側では、最新のWeb攻撃や脆弱性情報を継続的に調査する専門チームを有しています。
新たな脆弱性が発見された場合でも、迅速に防御ルールが自動適用されるため、修正プログラムを適用するまでのリスク低減に寄与します。

未知・新種の攻撃にも備える

Imperva Cloud WAFは、既知の攻撃パターンだけでなく、不審なリクエストや通常とは異なる通信挙動を検知・制御することで、未知・新種の攻撃に対しても一定の防御効果が期待できます。
AIによって新たなWeb脆弱性の発見や攻撃手法の拡散が加速する可能性がある中で、こうした未知・新種の攻撃にも備えられる点は大きな価値となります。

ブロックモードで運用しやすい検知精度

また、検知精度の高さにより、正規の通信をできるだけ妨げずに攻撃通信をブロックしやすい点も特長です。
これにより、「誤検知が怖くてブロックモードにできない」「検知モードのまま放置されてしまう」といった状態に陥りにくく、実効性のあるWAF運用を進めやすくなります。

日々の運用負荷を軽減

さらに、運用支援機能が充実している点も重要です。
WAFアラートを集約する機能により、攻撃の全体像を把握しやすくし、管理者の確認負荷を軽減します。
加えて、アラート状況に応じた設定の最適化をサジェストする機能もあり、継続的なチューニングにも対応しやすくなります。

6．まとめ

HTTP/2 Bombは、HTTP/2の効率的な通信の仕組みを悪用し、少ない攻撃通信でもサーバー側に大きな負荷を発生させる可能性があるDoS攻撃です。AIを活用して発見された攻撃手法として紹介され、PoCも公開されていることから、防御側には早期の影響確認と対策の見直しが求められます。

この事例は、AI時代においてWeb脆弱性の発見や攻撃手法の再現が、これまで以上に速く進む可能性を示しています。もちろん、影響を受けるソフトウェアのアップデートは基本対策です。しかし、すべての脆弱性に即座に対応することは難しく、未知の脆弱性や修正プログラム提供前の攻撃には、アップデートだけでは十分に備えられない場合があります。

そのため、今後のWebセキュリティでは、攻撃をWebサーバーやアプリケーション本体に到達させる前に検知・制御する防御層であるWAFの活用が重要です。

Imperva Cloud WAFは、最新脆弱性への迅速な対応、ブロックモードでの運用のしやすさ、アラート集約や設定最適化による運用負荷の軽減を支援するクラウド型WAFです。HTTP/2 Bombのような新たなWeb脆弱性に備えるうえで、外部公開WebサーバーやWebアプリケーションの防御強化を検討する有効な選択肢となります。

関連ソリューション

◇Imperva製品に関する資料はこちら

◇Imperva製品のお問い合わせはこちら

こんにちは！マクニカ コミュニティマネージャーの堀内です。
マクニカでは、セキュリティの企画・導入・文化の浸透を担う方々が集まり、互いの知見を共有しながら課題解決に取り組むことを目的としたコミュニティを運営しています。

その名も「関西情報セキュリティコミュニティ（通称：KISC）」

2026年5月15日（金）に開催したMeetup Vol.8では、14名の方々に参加いただき、各社のランサムウェア対策の取り組み状況や課題について、たくさんの意見交換が行われました。
本記事では、当日の様子や話題となったポイントをご紹介します！

目次

• テーマ設定の背景：なぜ今、ランサムウェア対策なのか
• 当日の様子
• まとめ

イベントアジェンダ

• オープニング『最新ランサムウェア動向』
• 事例セッション
• 初参加企業によるライトニングトーク
• グループディスカッション
• 懇親会

テーマ設定の背景：なぜ今、ランサムウェア対策なのか

ランサムウェアは、もはや「暗号化されるだけ」の攻撃ではありません。
データを窃取したうえで脅迫する「二重恐喝」や、VPNや認証経路を狙った侵入、EDRでも検知が難しい攻撃など、その手口は年々巧妙化しています。
こうした状況の中で企業に求められているのは、「侵入を防ぐ」ことだけでなく、「万が一侵入された場合でも事業を停止させない体制や仕組みをどう構築するか」という視点です。

一方で、企業が実際にどのような対策や運用体制を整備しているのかといった情報は、なかなか公開される機会は多くありません。だからこそ、参加者同士が顔を合わせて実際の取り組み内容や悩みを率直に意見交換できるのは、コミュニティならではの価値だと感じています。

当日の様子

オープニング

オープニングでは、マクニカ セキュリティ研究センターの山﨑より、最新のランサムウェア動向についてコンパクトにご紹介しました。
現在もランサムウェア被害は世界・日本ともに高い水準で推移しており、攻撃者によるリークサイトに公開される被害組織数は増加傾向にあります。

事例セッション

事例セッションでは、長年KISCにご参加いただいているお二人に、自社での取り組みをご紹介いただきました。

① 実際のインシデント対応事例

1社目からは、実際のセキュリティインシデントを題材に、侵入から検知・対応までの流れや、そこから見えてきた課題について共有いただきました。
特に印象的だったのは、「対策済みと思っていた仕組みの隙を突かれるケースが存在すること」や、「個々のアラートだけでなく、一連の挙動を通してリスクを把握する重要性」といった点です。
また、侵入後の横展開や権限昇格をいかに早期に検知するか、ネットワーク内部に侵入された後の対策をどう強化するかなど、"侵入されることを前提とした防御"の必要性についても議論が行われました。
さらに、Q&Aタイムでは「SASEが止まったらどうするか」「その際のバックアップは？」といった質問が飛び交い、逆に登壇者から参加者へ「VPNやリモートアクセス環境をどこまで残すべきか」「EDRで検知しづらい活動をどう補完するか」といったテーマも投げ込みがあり、活発な意見交換が行われました。

②ランサムウェア対策の見直し事例

2社目からは、ランサムウェア被害を想定した事業継続の観点から、対策を抜本的に見直した事例をご紹介いただきました。
従来の「IT部門によるセキュリティ対策」だけでなく、「どのように事業を継続するか」という視点で見直しを進められており、認証基盤の停止やコミュニケーション手段の断絶、バックアップ環境の侵害など、最悪のシナリオを前提に備えを進めている点が非常に印象的でした。
また、「月曜出社時に確認すべきこと」として

• 緊急時にSOCや関係者と連絡を取れる手段は確保できているか
• EDRはすべての端末で正しく稼働しているか
• 法令や当局報告に関する対応手順は明確になっているか

など、実践的な確認ポイントも共有いただきました。
どちらの発表にも共通していたのは、「侵入を防ぐこと」だけではなく、「侵害された場合でも事業を止めないための準備」が重要だということです。
実践的な施策の話はもちろん、「意外と準備できていないポイント」についても共有いただき、参加者の多くが熱心にメモを取る姿が見られました。自らの経験が他の参加者の学びにつながる――そんなコミュニティならではの光景が印象的でした。

＃恒例の大阪スイーツ紹介も♪

初参加企業によるライトニングトーク

初参加企業によるライトニングトークでは、5名の方にご登壇いただき、自己紹介とともに、自社の取り組みや現在抱えている課題について共有いただきました。

各社の発表では、

• サプライチェーン対策において取引先へどこまで求めるべきか
• セキュリティ人材不足への対応
• セキュリティ方針策定時のガイドライン選定

など、それぞれの立場ならではのリアルな悩みが挙げられました。

また、今回はセキュリティ担当になったばかりで右も左も分からない、と助けを求めてコミュニティに参加いただいた方もいらっしゃいました。ルーキーもベテランも組織を超えてお互いの状況を共有し合うことで、「それはうちも同じだ」「その考え方は参考になる」といった共感や新たな発見が生まれる場面も多く見られました。同じミッションや課題感を持つ企業同士だからこそ実現できる、活発な意見交換が印象的でした。

グループディスカッション

最後にグループディスカッションを実施しました。
各社の事例発表から得た学びや気づき、そして自社が抱える課題についてテーブルごとに意見交換を行い、その内容を全体で共有しました。
ディスカッションでは、以下のような実務的なテーマが議論されました。

• 復旧用アカウントの管理方法
• 手順書の安全な保管場所
• 海外拠点やサプライチェーンにおけるリスク管理
• 人材不足への対応（外部委託や自動化の活用）

企業規模や業種を超えてリアルな課題が共有され、多くの気づきや学びが生まれる場となりました。

＃発表タイム

＃みんなのノート

参加者の声

アンケートでは、

• 具体的な事例について役に立った
• 人に関する課題はどの企業にも共通しており、継続的に取り組む必要があると感じた
• 自分とは異なる考え方や、逆に共感できる取り組みに触れることができ、大きな刺激を受けた

といったコメントが寄せられました。
同じ立場で日々セキュリティに取り組む担当者同士だからこそ得られる気づきや学びがある――改めてコミュニティの価値を感じる会となりました。

まとめ

今回のMeetupでは、机上の理論ではなく、「実際に役立つ備え」に焦点が当てられました。各社の事例や参加者同士の意見交換を通じて見えてきたのは、ランサムウェア対策は単にセキュリティ製品を導入するだけでは十分ではないということです。

認証基盤の停止、コミュニケーション手段の断絶、バックアップ環境の侵害など、これまで「あまり起こらないだろう」と考えていた事態も現実のリスクとして捉え、「もし発生したらどうするか」を事前に考えておくことの重要性を改めて議論する場となりました。

ランサムウェア対策見直しの主なポイント

• 全社レベルで事業継続を見据えたセキュリティ設計
• 認証基盤の喪失など、"最悪のシナリオ"を前提とした対策
• 復旧優先順位（MVB）の明確化
• 隔離された復旧環境の整備
• バックアップのイミュータブル化
• 緊急時の連絡手段の確保（紙媒体を含む）
• 緊急アクセス用アカウントの整備

これらはいずれも、単なるセキュリティツールの導入にとどまらず、「組織としてどのように備えるか」が問われる領域です。

「侵入を防ぐ」から「侵害されても事業を継続する」へ。
セキュリティ担当者だけでなく、経営層や事業部門も含めて考えるべきテーマであることを改めて実感するMeetupとなりました。

「関西情報セキュリティコミュニティ（KISC）」では今後も、こうした実践的な事例共有や意見交換を通じて、関西のセキュリティ担当者同士がつながり、学び合える場を提供していきます。是非参加してみたい！という方は以下HPからコミュニティへの登録、お待ちしています！ 　
※東京・名古屋にも開催地を拡大中！
※本コミュニティは企業のサイバーセキュリティを担う方限定のコミュニティとなります。

▼Taneva（タネバ）：自社のセキュリティを担う方はどなたでもご参加可能なコミュニティ

▼KISC：関西版コミュニティ（対象：マクニカユーザ）

▼IST2：東京版コミュニティ（対象：マクニカユーザ）

▼Ikomai：東海版コミュニティ（対象：マクニカユーザ）

▼SD-Streamにてコミュニティについての動画公開中、ぜひご視聴ください

攻撃者がAIを使い始めた、というのはもう遠い未来の話ではありません。
脆弱性の発見からマルウェアの作成、侵入後の横移動まで、攻撃のさまざまな工程がAIによって自動化され、スピードを増しています。

その一方で、守る側の人員は相変わらず限られており、日々増えていく脆弱性やアラートに従来のやり方では追いつけず、加えて経営層への説明も求められる。
そんな板挟みに頭を悩ませている方も多いのではないでしょうか。

この記事では、AIを悪用した攻撃の脅威動向と、従来運用の限界を押さえたうえで、防御側は何ができるのかを具体的に考えていきます。

目次

• フロンティアAIによって変わる脅威
• 増え続ける脆弱性と従来運用の限界
• AIにAIで勝つ！防御の鍵は自社環境の「コンテキスト」

フロンティアAIによって変わる脅威

2026年4月、Anthropic社は「Project Glasswing」と題した取り組みのなかで、自社のAIを使って主要なOSやブラウザから多数のゼロデイ脆弱性を発見したと公表しました。
このモデルは「Claude Mythos」と名付けられており、あまりに高性能であるため一般公開は見送られ、限定パートナー約40社にのみ提供されていました。

Claude Mythos の力を借りることで、Mozilla Firefoxでは脆弱性対応件数が、2025年の月平均 約21件から、2026年4月は約20倍の423件と急増しました。しかも、そのうち271件は、Mythosが発見したものだと報告されています。*¹

ただし、これは一部の特別なモデルに限った話ではありません。
汎用的なモデルでも、人間なら12時間かかるような脆弱性発見を、わずか10分ほど・低コストでこなせる水準に近づいています。
「脆弱性を見つける」という作業は、いまやAI業界全体に共通する一般的な能力になりつつあります。

そして攻撃の高速化は、CrowdStrike社が公開した「2026年版 グローバル脅威レポート」でも数字にはっきり表れています。*²

• AIを活用した攻撃者活動　前年比89%増
• ブレイクアウトタイム　29分（最速27秒）
• AIプラットフォームへの攻撃　90以上の組織

とはいえ、冷静に見ておくべき点もあります。
現時点のAIは、侵入から情報の窃取までを完全に自律でやり遂げる段階には、まだ達していません。
脆弱性の発見はあくまで侵害成立の「必要条件の一つ」であり、実際に攻撃を成立させるには、適切な指示や条件の整備（ハーネスエンジニアリング）が欠かせません。
過度に身構える必要はありませんが、攻撃の「速さ」と「量」が桁違いに増しているという現実には、きちんと備えておく必要があります。

※Mythosに関してより詳しい情報を知りたい方は、Macnica SD-Stream（登録無料）よりご視聴いただけます。

https://sd-stream.macnica.co.jp/home/session/?id=2606Mythos

増え続ける脆弱性と従来運用の限界

では、守る側の状況はどうなっているでしょうか。
米国国立脆弱性データベース（NVD）への登録件数は、2019年の17,305件から2025年には48,185件へと急増しました。
あまりの数に、NISTは全件を分析する従来の方針を見直し、優先度の高いものに絞り込まざるを得なくなっています。
もはや「すべての脆弱性に対応する」こと自体が、現実的ではなくなってきているのです。*³

この問題は、クラウド環境ではいっそう深刻になります。
CSPMやCWPPといった単一のソリューションを導入するだけではアラートが大量に発生するため、本当に危険なものがその中に埋もれてしまいます。
脆弱性や設定ミス、権限、公開状態といった情報も、それぞれ別々に管理されていて全体像が見えにくくなります。
その結果、調査や原因の特定に時間がかかり、修正にたどり着くまでのリードタイムも延びていきます。

こうした状況では、アラートを一つずつ手作業で追いかける運用は、増え続ける脅威に対してどうしても後手に回ります。
いま必要なのは、膨大な情報の中から「本当に重要なリスク」だけを浮かび上がらせ、影響度や緊急度に応じて優先度をつけて対処するリスクベースのアプローチです。

AIにAIで勝つ！防御の鍵は自社環境の「コンテキスト」

AIを駆使する攻撃に対して、防御側に勝ち目はあるのか。
結論から言えば、十分にあります。
その鍵を握るのが、攻撃側には決して手に入らない防御側のみが持つ「コンテキスト」です。

コンテキストとは、どのコードがどのクラウド資産上で動き、どんな権限を持ち、外部にどこまで公開されているのかなど、環境の関係性を表す情報です。
この全体像を把握できるのは、外から探りを入れる攻撃者ではなく、環境を運用している守る側だけです。
コード（Code）・クラウド（Cloud）・ランタイム（Runtime）を横断して資産同士の関係性を可視化できれば、バラバラだったアラートを「意味のあるリスク」として読み解けるようになります。

ここで効いてくるのが、「有害な組み合わせ（Toxic combination）」という考え方です。
例えば「インターネットに公開されている」「重大な脆弱性がある」「過剰な権限を持っている」という条件が重なって初めて本当に危険な攻撃になります。
対処すべきリスクを有害な組み合わせに絞り込むだけで、対象は一気に現実的な数まで減らすことができます。

また、防御側はこれらのコンテキストを学習したAIを用いることで、非常に有利な対策ができます。
攻撃側のAIは、インターネット上に公開されているリソースやデータのみを頼りに攻撃を仕掛けるのに対して、防御側のAIは、自社環境を誰よりも深く理解して攻撃経路となり得る弱点を迅速に特定し、高速かつ効率的な防御を実現できます。
またリスクの修正時も通常ユーザーが調べるべきこと（誰に連絡するか、優先度の判断基準、関連するリソースなど）を自動的に調査して、環境を加味した修正手順やその他のワークアラウンドを自動的に出力できます。

ここで具体的に従来のアラート対応と何が違うのか比較してみます。

この「自社環境を理解したコンテキスト×AI」こそが、AIに対抗するための土台になります。

こうした「コンテキスト × AI」の発想を、実際の製品に落とし込んだ一つが、クラウドセキュリティプラットフォームの「Wiz」です。
Wizは、検出した資産に対して攻撃・防御・修復の役割を担う「Red Agent」「Green Agent」「Blue Agent」の3つのAIエージェントがコンテキストを付与します。

• Red Agent：発見した自社の資産に対して、外部の攻撃者視点で攻撃を行うことで、ペンテスターの役割を行い、リスクの検知精度を向上
• Green Agent：リスクを分析して資産のオーナーを推測し、環境を加味したリスクの修正手順を提示
• Blue Agent：発生した脅威を自動でトリアージし、結論だけでなく確信度とその根拠まで添えて提示することで、Tier1のアナリストの様な役割を行い担当者の調査負荷を軽減

まとめ

攻撃がAIによって高速化していく時代に、いつまでも人手だけで対応し続けるのは、限界があります。
自社環境のコンテキストを学習したAIエージェントを、リスクの検知から修正のプロセスに組み込むことで、対処を自動化・高速化していくことが、フロンティアAIという脅威への現実的な答えだと考えています。

出典
*¹2026/5/7  Behind the Scenes Hardening Firefox with Claude Mythos Preview：https://hacks.mozilla.org/2026/05/behind-the-scenes-hardening-firefox/
 *²2026/2/24  CrowdStrike社2026年版グローバル脅威レポート：AIによって加速する攻撃者と新たに形成される攻撃対象領域：https://www.crowdstrike.com/ja-jp/press-releases/2026-crowdstrike-global-threat-report/
*³2026/4/15 NIST Updates NVD Operations to Address Record CVE Growth：https://www.nist.gov/news-events/news/2026/04/nist-updates-nvd-operations-address-record-cve-growth

関連ソリューション

Wiz ～1つのプラットフォームでクラウド環境を包括的に保護するCNAPP～
◇Wiz製品紹介資料はこちら

◇15分で知る！Wiz製品紹介動画はこちら

◇Wiz製品のお問い合わせはこちら

近年、製品やサービスのセキュリティに対する社会的な要求が高まっています。特にIoT、医療、自動車分野などでは、法令や規制を背景に、SBOM（Software Bill of Materials：ソフトウェア部品表）の作成・管理が求められるようになりました。

本記事では、技術者の視点から、「なぜSBOMを作成する必要があるのか」「作成時にどのような注意点があるのか」「ツール選定で考慮すべきポイント」について、実践的に解説していきます。自社でSBOMを正しく運用するために、基本から応用まで整理していきます。

目次

• SBOMを作成する理由
  
  • 法令・規制への対応
  • 脆弱性管理・製品品質向上
• SBOM作成時の注意ポイント
  • 作成側・受領側の合意形成
  • 主流フォーマットと最小要素
  • 記載項目のミス・抜け漏れ対策
• SBOM作成観点でのツール選定ポイント
  • ツールが必要な理由
  • 選定時に確認すべき機能

SBOMを作成する理由

法令・規制への対応

SBOMの作成が求められる背景として、国内外の厳格なセキュリティ関連の法令・規制が徐々に増えています。日本国内ではIoT製品向けに「セキュリティ適合性評価制度（JC-STAR）」、医療分野では「薬機法」の改正でSBOMの整備が必須項目となっています。海外では、アメリカの大統領令（EO 14028）、EUサイバーレジリエンス法（CRA）、自動車業界のUN R155／UN R156など、多様な分野でSBOMの作成・提出が企業に義務付けられています。

CRAでは、罰金が最大1,500万ユーロ、または前年度全世界売上の2.5%まで課せられる可能性があります。これらの法令・規制は今後さらに拡大・厳格化していく見込みです。

脆弱性管理・製品品質向上

法令対応だけでなく、SBOMが現場で活用される主なユースケースも重要です。SBOMによって出荷後の製品の脆弱性判定が容易になり、ユーザーからの問い合わせ対応や開発部門との連携がスムーズになります。また、新たな脆弱性情報が公開された際にもSBOMと照合して自社製品への影響を効率的に確認できます。

理想的には、サプライチェーン全体の関係者がそれぞれの責任範囲でSBOMを作成し、最終製品の透明性と脆弱性管理力を高めていくことが重要です。

SBOM作成時の注意ポイント

作成側・受領側の合意形成

SBOM作成の際は、作成者（製造業やベンダー）と受領者（利用者やエンドユーザー）で記載内容やフォーマットについて事前に合意しておくことが重要です。例えば、「SPDX」「CycloneDX」といったフォーマットの選定や、記載すべきデータフィールド、品質管理や提出・更新方法などを明確にしておくことで、運用時のトラブルを防げます。

主流フォーマットと最小要素

現在主流となっているSBOMフォーマットはSPDXとCycloneDXで、SPDXは特にライセンスとコンプライアンス管理に強みがあり、CycloneDXはセキュリティに重点を置いています。

また、SBOM作成時は、NTIAが定義する「SBOM最小要素」にも注意しましょう。データフィールドとして、サプライヤー名、コンポーネント名、コンポーネントバージョン、その他の一意な識別子、依存関係、SBOMの作成者、タイムスタンプの7項目が挙げられます。手作業でSPDXを構築する場合も、この7項目は必ず記載しましょう。

記載項目のミス・抜け漏れ対策

タイムスタンプ・作成者の書き方

タイムスタンプは必ずUTC形式で「YYYY-MM-DDThh:mm:ssZ」と記載し、SBOM作成者は組織名、担当者名、ツール名のいずれかを明記します。

識別子（CPE、PURL）の表記ゆれ・複数存在の問題

脆弱性管理やコンポーネント特定に用いる識別子（CPE、PURL）は、開発会社の買収やブランド変更などにより表記ゆれや複数割り当てが生じることがあります。例えば「ThreadX」はMicrosoftやEclipseへの移管により複数のCPEが付与されており、情報収集時に抜け漏れのリスクが高まります。これらを正しく管理するには、複数識別子を重ねて収集・照合する運用が必要です。

コンポーネント名・バージョン・サプライヤー名の表記ゆれ

表記の統一も重要な注意点です。例えば「OpenWrt」と「openwrt」、「18.06.2」と「18.6.2」など、細かな違いがあると脆弱性情報の検索や管理業務に支障が出ます。組織内で書式ルールや管理指針を設定しておくとよいでしょう。

依存関係の記述

SBOMではコンポーネント間の依存関係（relationship）を正確に記載します。SPDXでは「DESCRIBES」「CONTAINS」「DEPENDS_ON」「DYNAMIC_LINK」など多様な関係タイプを用いて構造を表現します。複雑なソフトウェア構成を持つ場合は特に注意が必要です。 

SBOM作成観点でのツール選定ポイント

ツールが必要な理由

IoT機器や複雑な製品では、コンポーネント数が100以上になるのも珍しくありません。手作業でのSBOM作成は人的ミスや工数過多につながりやすく、正確性・効率性を担保するためにも専用ツールの導入が推奨されます。ツールを活用しつつ、エンジニアが最終確認する運用が現実的です。

選定時に確認すべき機能

ツール選定時は、以下の観点で比較検討しましょう。

• 解析能力：対応言語や検出力（誤検出・漏れの頻度も含む）
• データ出力：SPDXやCycloneDXなど、多様なフォーマットへの出力可否
• チェック・精査機能：自動レビュー、品質管理機能
• GUIの有無：直感的な操作性
• 他ツール連携・自動化：CI/CDパイプラインとの連携、ソフトウェアライフサイクル全体の効率化
• サポート体制：問い合わせ対応、OSS管理コンサルティング等

適切なツール選定で、SBOM作成・運用の負担を最小化できます。

SBOM作成は今や企業のセキュリティ・コンプライアンス対応の要となっています。小規模なプロジェクトなら手作業も可能ですが、正確性と効率化を求めるならツール活用が不可欠です。自社製品のセキュリティ品質向上のためにも、SBOM運用体制の整備を検討してみてください。

関連ソリューション

・Black Duck Software
・LeanSeeks

本記事の詳細は、無料動画ポータル「Macnica Security& DX Stream」で公開中！
１度の登録で、100セッション以上が見放題！今すぐ動画視聴申し込みする↓

SBOM管理や脆弱性管理に関するご相談は、マクニカまでお気軽にお問い合わせください。
自社の現場に合った運用支援やソリューション導入にも対応しています。
関連製品や最新情報も動画ポータル内で紹介していますので、ぜひ一度ご覧ください。

サイバー対処能⼒強化法（所謂「能動的サイバー防御」）や、⾼圧ガス保安法などの法規制により、重要インフラや製造業においてもサイバーインシデント発生時の迅速な報告や原因究明が、これまで以上に求められるようになっています。
IT環境ではEDRやSIEMなどのセキュリティ監視基盤の普及により、「サイバー攻撃によるものなのか」「どの端末が影響を受けたのか」といった情報を比較的把握・分析しやすい環境が整いつつあります。

一方、OT環境では現場のPCにEDRを導入できないケースが多く、設備停止や異常発生後も、それが機器故障なのか、設定ミスなのか、あるいはサイバー攻撃によるものなのかを、迅速に判断する手段がない組織も少なくありません。
その結果、法規制で求められる説明責任を十分に果たせないリスクが存在しています。

さらに、重要インフラや製造業をとりまく脅威も年々高度化しています。LOTL（Living Off The Land）やログ消去といった痕跡を残しにくい攻撃⼿法が一般化する中、最近ではフロンティアAIの登場によって、攻撃の自動化や効率化も進んでいます。これにより、攻撃者は従来よりも短時間で大量の攻撃を実行できるようになり、サイバー攻撃の「量」と「速度」が大きく変化し始めています。しかし、ITとOTでは守る対象や運用制約が大きく異なるため、同じ考え方で対策することはできません。

本記事では、昨今の法規制強化と脅威環境の変化を踏まえながら、OT環境が直面する5つの防御課題を整理し、法規制で求められる「説明責任」と「サイバー対処能力の向上」を実現するための考え方と対策のポイントを解説します。

目次

1. 法規制とフロンティアAIがもたらす5つの変化
2. 変化に対応するためのOT防御の考え方
3. まとめ：防御は準備で決まる

1.法規制とフロンティアAIがもたらす5つの変化

前述の通り、OTセキュリティを取り巻く環境は、法規制の強化とフロンティアAIの進展によって大きく変化しています。特にOT環境では、インシデント発生時の説明責任への対応に加え、攻撃の量や速度の変化を前提とした防御が求められるようになりました。その変化を整理すると、主に以下の5つの課題に集約できます。

これらは個別の問題に見えますが、いずれも「攻撃を見つける」「正しく判断する」「迅速に対処する」というOTセキュリティの基本プロセスの課題として整理できます。次章では、それぞれの課題に対して、OT環境ではどのような防御の考え方が求められるのか、以下の5つに分けて解説します。

①サイバー攻撃をどう識別・特定するか
②急増するアラートにどう対応するか
③判断と対処をどう迅速化するか
④増え続ける脆弱性にどう優先順位を付けるか
⑤ゼロデイ攻撃にどう備えるか

2.変化に対応するためのOT防御の考え方

①サイバー攻撃をどう識別・特定するか

サイバーインシデント発生時の報告・情報共有を行うには、「インシデントの原因がサイバー攻撃かどうか」「攻撃状況や影響範囲はどこまでか」を客観的に説明できなければなりません。

OT環境では、現場のPCにEDRを導入できないケースが多く、産業制御機器に至っては攻撃検知ツールが何も入っていません。LOTLを駆使しファイアウォールを通り抜けて侵入してくる現代的な攻撃に気付く方法がないのです。更に、攻撃者は操作ログを消去するため、後から調査することも困難です。このため、事故が起きて初めて問題に気付き、調査してもサイバー攻撃か設備故障かを判断できない、侵害状況が判らないというのが現実です。

このように、IT環境で行えたことがOT環境では行えず、法規制が求める報告要請に応えることが困難な状況にあります。

そこでOT環境では、EDRに代わる有効な手段としてネットワーク検知（ネットワーク型IDS）の採用が進んでいます。中でも、サイバー攻撃の検知・識別・特定機能、侵害調査機能が役に立ちます。OT環境で従来から行われてきた「異常検知」と、法規制に応えるための「攻撃検知」は同じではありません。異常を検知できても、それが設備故障や設定ミスによるものなのか、サイバー攻撃によるものなのかを識別できなければ、説明責任を果たすことはできません。そのためMITRE ATT&CK ICSや脅威インテリジェンスを活用した、説明性の高い「攻撃検知・攻撃識別」が行えることが重要です。また、ログ消去に対抗するには、ネットワーク挙動の記録と、その記録に基づくフォレンジックが必要であり、これも説明責任の観点からネットワーク型IDSに欲しい機能です。

②急増するアラートにどう対応するか

IT・OTを問わず、今後はAIを利用した攻撃の自動化によって、攻撃試⾏回数の増加や、比較的単純な攻撃の大量実行が増えると考えられています。これにより、「セキュリティアラートの爆発的な増加」や「本当に対応すべき事象が埋もれる」「すべてのアラートを人手で精査することの限界」などの課題が出てきます。

OT環境では、侵害対象がWindows PCやサーバだけでなく、PLC、HMI、エンジニアリング端末、センサー、制御ネットワーク機器など多様であり、1件のアラートを調査する負荷が非常に高い特徴があります。このため、過検知ノイズを含む大量のアラートを人手で処理することは、今後現実的ではなくなります。

そのため、「何を優先的に対応すべきかを判断できること」が重要です。すなわち、IDSの能力は、攻撃検知機能単体の優劣ではなく、大量の検知の中から、本当に危険なものを瞬時に判別する「トリアージ」の仕組みまで含めた全体の能力が大事です。こうした準備により、セキュリティチームは、大量のアラートから自動的に仕分けられた「攻撃性が高いアラート」を優先してハンドリングできるようになり、防御が可能になります。

③判断と対処をどう迅速化するか

OT環境では、攻撃を検知しても直ちに設備を停止したりネットワークを遮断できるとは限りません。計画にないOT設備の停止は、大規模な停電、交通障害、サプライチェーン全体の停止や、環境・人命を危険にさらすこともあるため、IT環境以上に慎重な判断が求められます。

一方で、フロンティアAIの悪用によって攻撃者側の行動速度はさらに向上すると考えられています。侵入後の情報収集や横展開、攻撃準備が短時間で進むようになれば、従来のように「検知・調査・判断・対処」を順番に進めているだけでは対応が間に合わなくなる可能性があります。

そのために重要になるのが、インシデント対応の標準化です。調査手順や判断基準をプレイブックとして整備し、誰が対応しても一定の品質と速度で対応できる状態を目指します。また、対応担当者の経験や勘に依存せず、調査手順やエスカレーションルールを明確化することで、属人化による遅延を防ぐことができます。

またプレイブックでは手順の出口も大切です。OTでは操業判断をともなう事業レベルの意思決定につながるため、攻撃や被害の是正手段は何があるか、どんな情報を共有すべきか、など業務レベル・事業レベルのインシデント対応計画と接続できるよう準備します。

さらに今後は、防御側にとってもAIによる調査や判断の⾼速化・効率化が武器になると考えられます。

このように、攻撃の高速化に対抗するには、検知能力だけでなく、調査・判断・対処そのものを高速化する仕組み作りが有効です。

④増え続ける脆弱性にどう優先順位を付けるか

フロンティアAIにより脆弱性の発見が加速し、企業が向き合う公開脆弱性の数は増加していくと考えられます。しかし、OT環境ではIT環境のように「脆弱性が見つかったらすぐにパッチを適用する」という対策が必ずしも実現できません。

製造設備や制御システムは24時間稼働していることも多く、稼働中のパッチ適用や、パッチ適用のためのシステム停止は困難です。またパッチ適用前に設備に対する影響を十分に検証する必要があり、「脆弱性が見つかったらすぐに修正」は本質的に無理なのです。

さらにITと比べてOT資産は以下のように多種多様であり、脆弱性の数の増加は容易に「対応不可能」な状況をもたらします。

これを克服する有効なアプローチは、自社にとって本当にリスクの高い脆弱性を見極めて対応する「リスクベース脆弱性対策」です。これはSANSの ICS Five Critical Controls（*0）でも提唱されており、脆弱性の特性を上手く利用した効果的な対策方法です。

脆弱性は、発見された後にエクスプロイト開発が行われ、攻撃者が利用可能な状態となることでリスクが高まります。しかし実際に攻撃に使えるよう「武器化」される脆弱性は全体のほんの⼀部に限られています。

例えば、KEV（Known Exploited Vulnerabilities）に登録されている脆弱性は2025年9⽉10⽇時点で1,414件です(*1)。また、OT環境を保有する組織にとって「今すぐ対処すべき脆弱性」は公開脆弱性の約2％と、ごく一部であるという調査結果もあります（*2）。

そこで重要なのは、公開された脆弱性を一律に対応するのではなく、実際に攻撃へ悪用可能な、リスクをもたらす脆弱性を優先対策することです。

脆弱性のスコアCVSS（Common Vulnerability Scoring System：共通脆弱性評価システム）は、脆弱性の悪用と相関がありません。このためCVSSスコアに基づいて対策対象を決めた場合は攻撃の穴が残ります。「攻撃に悪用されている」「攻撃に悪用できる状態にある」という情報に基づくリスク対策が欠かせません。（*3）

常に脆弱性の悪用に関する最新情報を入手し、悪用手法（エクスプロイト）から逆算した、悪用させないための「パッチ以外の対策」を積極的に投入します。そして現時点で悪用方法がない脆弱性は対策を保留し、その分の人員稼働は更なるリスク削減につながる別の対策に振り向けます。

⑤ゼロデイ攻撃にどう備えるか

フロンティアAIによって懸念されるもう一つの課題が、ゼロデイ攻撃リスクの増加です。ゼロデイ攻撃とは、脆弱性が一般公開される前に攻撃者によって悪用される攻撃を指します。

従来、ゼロデイ攻撃を実行するためには、高度な解析技術や研究能力が必要でした。しかし今後は、フロンティアAIが脆弱性の探索とエクスプロイト開発を高速に行うことで、攻撃者が未知の脆弱性を発見し、その悪用手段を獲得する可能性が高くなります。

有効な対策手段は、「ゼロデイ攻撃を検知できる状態を作ること」です。OT環境では従来から、設定変更や通信内容の変化、制御ロジックの異常などを監視するベースラインコントロールやアノマリー検知が採用されてきました。これらはゼロデイ攻撃を発見する手段としても有効です。ただし、検知できても大量のアラートに埋もれてしまっては意味がありません。一方、キルチェーンの最初から最後まで全てをゼロデイ攻撃で埋め尽くすような攻撃はなく、既知の攻撃手法や攻撃ツールと組み合わされます。すなわち、アノマリー検知情報を攻撃検知や脅威インテリジェンスと組み合わせ、本当に危険な兆候を識別できるように準備し、これを前述の①②③の要素として構築します。

3.まとめ：防御は準備で決まる

法規制とフロンティアAIに対抗するOT防御のポイントは以下の通りです：

• 説明責任：　EDRに代わる「攻撃検知・攻撃識別・侵害調査」基盤の構築
• アラート急増対応：　脅威情報に基づく「自動トリアージ」の準備
• 判断と対処の迅速化：　属人的対応ではなく「プレイブック」の準備
• 脆弱性急増：　攻撃リスクに基づく「リスクベース対応」の仕組み化
• ゼロデイ：　アノマリーと攻撃検知を組み合わせた「検知と対応」の構築

これらは、過去２回のブログで解説した「３つのセキュリティコントロール」として実装できます。

重要なのは、新しい脅威やテクノロジーが登場するたびに個別最適な対策を積み上げることではありません。インシデント発生時に「何を検知し、どのように判断し、どう対処するか」をあらかじめ設計し、その中に必要なコントロールやテクノロジーを組み込んでいくことです。

ツールは「どう使うか」で決まります。つまり、どう防御するか、そのための設計こそがカギなのです。法規制とフロンティアAIは、そのための考慮すべき前提条件と言えます。
対策ツール選びや対応体制作りにお悩みの際は、ぜひ弊社にご相談ください。

◇過去２回のブログはこちら
・第1弾：https://mnb.macnica.co.jp/2026/06/cpsiotot/OTDefense.html
・第2弾：https://mnb.macnica.co.jp/2026/06/cpsiotot/OTDefense2.html

出典
*0 The Five ICS Cybersecurity Critical Controls
URL (https://www.sans.org/white-papers/five-ics-cybersecurity-critical-controls)
*1 Detailed Analysis of Recent Trends in Known Exploited Vulnerabilities,
URL (https://medium.com/s2wblog/detailed-analysis-of-recent-trends-in-known-exploited-vulnerabilities-c81678a47f39)
*2 2026 OT Cybersecurity Year in Review, Dragos,
URL (https://www.dragos.com/ot-cybersecurity-year-in-review)
*3 OTセキュリティ脆弱性対策の核心 ～頓挫する理由と成功する手法～
URL (https://mnb.macnica.co.jp/2025/08/cpsiotot/vulnerability.html)

関連ソリューション

Dragos　～世界最高峰の脅威インテリジェンス活用型OTセキュリティ～
◇Dragos製品に関する資料のDLはこちら
　
◇Dragos製品のお問い合わせはこちら

DeviceTotal　～OT/IoT/ネットワーク機器向け脆弱性管理プラットフォーム～
◇DeviceTotal製品に関する資料のDLはこちら
　
◇DeviceTotal製品のお問い合わせはこちら

◇最前線から読み解くOT脅威動向と防御戦略2025
動画の視聴はこちら↓

こんにちは！マクニカ　コミュニティマネージャーの髙橋です！ 
マクニカでは、サイバーセキュリティをテーマに、立場や役割の異なる人たちが集い、リアルな知見を持ち寄りながら学び合うコミュニティ活動を行っています。

東海地域で展開するIkomaiでは、『止めたらあかん責任がある。モノづくりの東海から、いこまい、セキュリティ。』をスローガンに掲げ、セキュリティを担う皆さんと一緒に活動しています。サプライチェーンの要である東海エリアだからこそ、一社の取り組みが地域全体の力になってほしいという想いを込めています。また、私たちが大切にしているのは、「本音」「考えの整理」「つながり」「実践」「自信を持つ」、という5つのキーワードです。

これらのスローガンや大切にしていることを、多くの皆さんにも体感いただき、皆さんにとってのコミュニティの場を一緒に作っていければと思っています。

2026年5月29日（金）に開催した、Ikomai Meetup Vol.3では、「昨年度のセキュリティ対策、何をした！？」をテーマに、各社が昨年度に実施した取り組みの"振り返り"にフォーカスし、それぞれの「リアル」を語り合う時間となりました。このブログを通して、当日の熱量を少しでも感じていただけたら嬉しく思います！！

目次

1. なぜ「昨年度の振り返り」をテーマにしたのか？
2. 当日の様子とライトニングトーク
3. 各社の取り組みから見えた、3つの視点
4. グループディスカッション
5. Vol.3の新たな試み
6. おわりに

なぜ「昨年度の振り返り」をテーマにしたのか？

セキュリティ対策は、限られた予算と時間の中で、意思決定の連続です。

「なぜその施策を選んだのか」「その投資は妥当だったのか」「やってみて、新たに見えたものは何か」など、そうした"判断の背景"と"実施後のリアル"は、普段なかなか他社と共有する機会がありません。成功事例として語られることはあっても、迷いや失敗、見送った判断まで含めて赤裸々に語られる場は、ほとんど存在しないのではないでしょうか。

だからこそ今回は、チャタムハウスルールのもと、オフレコ前提で「正解」ではなく「リアル」を持ち寄る場にしたいと、リーダー企業と協議を行い、テーマを設定しました。

各社の取り組みを評価したり、優劣をつけたりする場ではなく、それぞれの取り組みをもとに「自社ならどう判断するか」を考え、判断軸を持ち帰っていただく。迷いや試行錯誤も含めた共有を通じて、次の一手に自信を持てるように思いを込めています。 

当日の様子とライトニングトーク

冒頭のライトニングトークでは、初参加の方を中心に、複数名の方にご登壇いただきました。それぞれ異なるキャリアを歩みながらも、「事業を支えたい」「組織をより良くしたい」という想いを持ってセキュリティに向き合われている姿が印象的でした。バックグラウンドは様々でも、経営との向き合い方や、組織全体をどう巻き込むかといった共通の悩みが次々と語られ、初対面とは思えない一体感が生まれていました。

そして、セキュリティの話だけでなく、釣りや家庭菜園、スポーツといった趣味の話題も飛び出し、気付けば「釣り好きが意外と多い」という事実も判明しました（笑）。仕事の話から始まりながらも、人となりに触れることで会話が広がっていくのも、コミュニティの楽しい一面だと感じました！

各社のセキュリティ投資から見えた、3つのポイント

今回のメインは、各社による昨年度の取り組みの共有です。複数の企業の方々に「何をして、何が見えたか」を語っていただきました。

ここで共有された内容は、正直、このブログでは詳しくお伝えできないほど赤裸々なものばかりでした。チャタムハウスルールのもとだからこそ語っていただけた、生々しい実態や葛藤は、ここに集まる人しか聞けないという言葉そのものでした。

具体的な中身はお伝えできませんが、事務局として強く印象に残ったことを「3つの視点」という形で、お届けしたいと思います。

 ① 投資判断には「解像度」がある

「いつ・どのくらいの投資をして・その結果どうなったか」を共有いただきました。
完全な対策が不可能であることを前提に、できていないことまで含めて、経営層に正直に伝えるという姿勢。
「できたことだけを報告する」よりも、「できていないことを整理して伝える」方が、経営層との信頼関係を築き、次の投資につながっていくというメッセージ。
シンプルですが、実践するには覚悟がいる考え方だと思います。

セキュリティの本質は、ツールの優劣ではなく「どこに・なぜ投資するか」という意思決定にあるということを、改めて教えていただいた気がします。

② 計画は「立てた瞬間」から変化に晒される

語られたのは成功談だけではありません。

マンネリ化してしまった施策、思うように進まなかった取り組み、整備したはずの体制やルールがいつの間にか形骸化していた現実など、「やってみて初めて分かる限界」を、包み隠さず共有いただきました。

特に印象的だったのは、「策定したばかりの計画を、他社で起きた大きなインシデントを受けて、すぐ見直した」というお話です。計画は、立てた瞬間から脅威の変化に晒されていくため、完璧な計画を一度つくることよりも、変化に追従し続ける力の方が大切なのだと、多くの参加者がうなずいていました。

③ 「踏み込んで語る勇気」が、場の熱量をつくる

何より印象的だったのは、皆さんの熱量でした。

「これはうまくいかなかった」という失敗を、具体的に語ることや、「それ以前は行き当たりばったりだった」と正直に明言すること。
自社の体制やリソースの現実を、建前ではなく本音で見せること。
フレームワークを使って自社の対策を体系的に整理し、できていること・できていないことを一つひとつ開示すること。

誰かが正直に一歩踏み込むと、場全体に「本音で話していい」という空気が広がっていきます。その連鎖こそが、今回のMeetupの熱量そのものでした。こうした本音の共有は、Ikomaiが大切にしている「本音」「つながり」「実践」「自信を持つ」という価値が、まさに体現された瞬間だったと思います。踏み込んで勇気ある共有をいただいたご登壇者の皆さま、本当にありがとうございました！

今回、実はオープニングの時点ですでに10分以上のオーバータイム。もちろん時間管理はしていたのですが、それを上回る勢いで登壇内容、質疑応答が盛り上がってしまい、最終的には全体で30分オーバー。それでも、それだけ皆さんの熱量が高かったということで、アンケートにも時間が足りないとうフィードバックもありました！事務局としては、嬉しい誤算でした...！

グループディスカッションの様子

事例の共有を踏まえ、「学び＆興味深かったこと」と「持ち帰りたいこと」の2軸で、グループディスカッションを行いました。

学びを付箋に書いてホワイトボードに貼っていくスタイルでしたが、参加者の皆さんの会話があまりにも活発で、付箋が追いつかない...！そこで急遽、事務局メンバーが議論の流れをホワイトボードに直接メモ書きしていくスタイルへと、自然に進化しました（笑）。運営側も皆さんに楽しんでディスカッションいただけるよう、必死に支援させていただきました！

各グループからは、予算の考え方、サプライチェーンセキュリティ評価制度への対応、グループ全体のセキュリティ統制、経営層への説明、社内教育、アカウント乗っ取り後の対応など、現場の切実なテーマが次々と挙がりました。「ここでしか話せない」本音の議論が、あちこちで展開されていました。

Vol.3の新たな試み

今回のVol.3では、コミュニティをさらに盛り上げるべく、いくつかの新しい試みにチャレンジしました！

①MVP（Most Ikomai Player）制度＆オリジナルステッカー作成

Ikomaiを体現してくださった方に、オリジナルステッカーを進呈する制度を始めました。選定基準は3つの観点で、「Emulation（敬意を持って見習いたい共有）」「Real（最もリアルだった共有）」「Brave（最も踏み込んでくれた共有）」です。ステッカーをたくさん集めた方には、表彰式での授与も企画しています。さっそく今回だけで2枚を獲得された方も！

②オフレコ質問BOX

当日のセッションでは、質問しきれないことも多い、というフィードバックがあったことで、匿名で質問を投稿できるBOXを新設しました。投稿いただいた質問は、懇親会でお披露目です！

③新リーダー企業のご紹介

新たにIkomaiを盛り上げてくださるリーダー企業をご紹介しました。地域のコミュニティは、こうした有志の方々に支えられています。引き続き、よろしくお願いいたします！

こうした新しい仕掛けも取り入れながら、Ikomaiに「参加して楽しい」「また来たい」と思っていただける場を目指していきます。

懇親会の様子

第2部の懇親会は、いままで以上に大盛況でした！

会場を貸し切り、周りを気にせず、遠慮なく議論できる環境だったこともあり、円卓で中華料理を囲みながら、本音トークがさらに加速しました。

目玉は、オフレコ質問BOXです。回収した質問用紙の裏に番号を振り、「○番の方！」と当てられた人がその質問と書かれていることを読み上げて、ご自身の考えを回答するスタイルで、回答を終えた方が次の番号をコールします。どのタイミングで回ってくるかわからないワクワク感もあり(?)、想像以上に盛り上がりました！指名された方の回答に対して、「それ、うちはこうしてます」と割り込みの回答が飛んできたり、「自分にも言わせてくれ」と手が挙がったり...。気付けば、一つの質問から議論がどんどん広がりました。普段は言えないような「ここでしか話せない」を、最後の最後まで体現してくれたような懇親会でした。

おわりに

今回のMeetupを通じて、改めて感じたことがあります。
それは、セキュリティは技術だけでは成り立たない、ということです。どんなに優れたツールや仕組みがあっても、それを動かすのは「人」であり、限られたリソースの中で「どこに・なぜ投資するか」を判断するのも、最後は人です。その判断の背景や迷いを、立場を越えて本音で共有できる場があることが、何より価値のあることだと思います。

「自社だけじゃなかった」「あの判断、参考になる」、そんな気づきを一つでも多く持ち帰っていただけていたら、事務局としてこれ以上嬉しいことはありません。

もう一つ大切なことは、一人で抱え込まないことです。同じ課題に向き合う人たちと出会い、言葉を交わし、互いの視点に触れることで、見える景色が変わります。Ikomaiは、そんな「つながり」の中から次の一歩が生まれる場所でありたいと思います。

これからも、東海エリアのセキュリティ担当者が互いに学び、正解を教わるのではなく、自分なりの判断軸を見つけられる、次の一手に少しだけ自信を持って踏み出せるような発見がある場を作れるよう、皆さんと歩んでいきたいと思います。

次回のMeetupでも、また皆さまとお会いできることを楽しみにしています！！

▼Taneva（対象：自社のセキュリティを担う方はどなたでもご参加可能）　参加お申込みはこちら
▼IST2：東京版コミュニティ（対象：マクニカから製品・サービスをご購入いただいているお客様） 参加お申し込みはこちら
▼KISC：関西版コミュニティ（対象：マクニカから製品・サービスをご購入いただいているお客様） 参加お申し込みはこちら

▼Ikomai：東海版コミュニティ（対象：マクニカから製品・サービスをご購入いただいているお客様） 参加お申し込みはこちら

近年、OT環境におけるサイバー攻撃は⾼度化しており、従来の「事前に守り切る」という発想だけでは対応が難しくなっています。皆様の中にも、「防御をすり抜けて攻撃が侵⼊しているか分からない」、「検知はしたものの、攻撃か判断できず、様⼦を⾒るしかなかった」といった経験をお持ちの⽅もいらっしゃるのではないでしょうか。

これはツールの問題ではありません。「判断できる状態が整っていない」ことに起因する課題です。

⾃動遮断が利⽤できないOT環境では、検知→調査→判断→対処のフローを、迅速かつ再現性⾼く実⾏できるかどうかが、防御のカギです。

本記事では、インシデント時に適切な意思決定と対処するための"準備"について、具体的に説明します。

目次

1. 予防的コントロールの再定義
2. 正確な判断を可能にする「⾃社情報」の整備
3. 検知を「判断材料」に変える仕掛け作り
4. 是正＝判断と対処の再現性を準備する
5. 準備ができている時のインシデント対応例
6. まとめ 

1.予防的コントロールの再定義

予防的コントロールでは、攻撃対象面を減らすことを目的に、主に以下を実施しています。

• 資産管理
• ハードニング
• 脆弱性対策
• セグメンテーション
• アクセス制御

しかし、上記の対応だけでは、攻撃を100%防ぐことは理論上不可能なため、突破された時の備えが重要です。

インシデント発⽣時に、判断と対処ができる状態を作ることが、予防の重要な観点であり、防御の本質とも⾔えます。

2.正確な判断を可能にする「⾃社情報」の整備

インシデント発⽣時に検知した内容に、以下のような情報が紐づいて、初めて判断ができる「判断材料」になります。

• どの設備か？
• どのライン・⼯程か？
• 停⽌した場合の業務影響は？
• 管理や運転の担当部署は？

例えば、同じPLCとWindowsワークステーションであっても、「重要ラインの制御機器」なのか、「⼀時的に停⽌可能な補助設備」なのかによって、対応判断は⼤きく変わります。

そのため、セキュリティツールやベンダの脅威情報だけではなく、⾃社固有の内部情報が必要です。従来のアセットマネジメントを「意思決定のための情報基盤」にするには、管理のための資産台帳から、判断に使うための環境情報として整備し、後述の検知・是正の中で活⽤できるよう配備します。

3.検知を「判断材料」に変える仕掛け作り

検知の本質は、異常パターンを⽰すだけでなく、是正判断に必要な情報を提供することにあります。検知的コントロールの結果を使って、どこで何が起きているか、影響はどこまでか、⽌めるべきか、様⼦を⾒るべきかを速やかに判断できるようにします。

検知を機能させる３要素

"検知"は検知装置（IDSなど）単体では実現できず、以下3つの情報が必要です。これらを統合し、判断材料となる情報を素早く⽣み出すことが、検知的コントロールの役割です。

アラートの選別

更に、セキュリティアラートをその場で以下の３つに選別できることが重要です。この整理が事前にできていない場合、現場はアラートの仕分けに追われ、攻撃に気付けず、是正も機能しません。

4.是正＝判断と対処の再現性を準備する

インシデント対応では、「調査・判断・対処」を再現性をもって実施するために、以下を準備します。

• IT／OT現場／事業部⾨の連携ワークフロー
• 判断主体とエスカレーションルール
• プレイブック

特にプレイブックは、ITにおけるアラート対処アクションと混同しがちです。

OTでは、対処の範囲がコンピュータ端末とネットワーク内に留まらず、⼯程設備・運転作業・事業判断にもつながっています。このため、こうしたITを専⾨としないステークホルダーとの連携まで考慮して整備します。

• 攻撃と過検知との⾒分け⽅・調査⽅法
• 侵害の確認⽅法
• 判断基準と対応の選択肢
• 対処⼿順

更に、検知の段落で述べたように、対応を平時・有事に分けた設計も有効です。

• 平時：脅威ハンティング
• 有事：インシデントレスポンス

OT環境の対処は「⽣産システムを⽌める／⽌めない」という重い意思決定を伴います。この選択を場当たり的に⾏うのではなく、準備段階で設計しておき、誰が⾒ても同じ判断ができる状態を作っておきます。

5.準備ができている時のインシデント対応例

ここまでの準備を整えた上で、インシデント対応は次のように機能します。技術的な対応だけでなく、業務⾯の対応や、対外報告のためのインシデント情報もこのフローの中で揃います。

準備ができている状態でのインシデント対応例

6.まとめ

予防・検知・対処の３つのコントロールは互いに密接に関わっています。特に検知を起点として意思決定と対処につなげるための準備の重要性を今回は解説しました。

準備段階で考えていない対策は、有事に選択することができません。

OTでは、脅威もろともネットワークを遮断したり端末を隔離したりする⽅法を、ほとんどの場合では使えません。そのため、どんな対処を取り得るか、そのための判断はどう⾏うのか、これを整理して準備することがOTの防御と⾔えます。

弊社では、こうした観点から単なるツール提案に留まらず防御作りを⽀援しています。ぜひお気軽にご相談ください。

関連ソリューション

Dragos　～世界最高峰の脅威インテリジェンス活用型OTセキュリティ～
◇Dragos製品に関する資料のDLはこちら
　
◇Dragos製品のお問い合わせはこちら

DeviceTotal　～OT/IoT/ネットワーク機器向け脆弱性管理プラットフォーム～
◇DeviceTotal製品に関する資料のDLはこちら
　
◇DeviceTotal製品のお問い合わせはこちら

◇OT-IDS運用課題を解決するOTセキュリティの新標準「脅威インテリジェンス活用」アプローチ
動画の視聴はこちら↓

• CISA BOD 26-04は、米国の連邦政府機関に対し、セキュリティパッチの適用についてリスクに基づく優先順位付けを求める、拘束力のある運用指令です。
• 最大のポイントは、CVSSスコアを優先順位付けの主軸として使わないことです。外部公開、KEV掲載、悪用の自動化、技術的影響の4つの観点で、対応期限を定めています。
• 本指令の対象は米国政府機関ですが、官民問わず参考になる考え方です。日系組織にとっても、外部公開資産を正確に把握し、本当に危ないものから対処する「現実的なリスクベースの脆弱性対応・セキュリティ運用」へ移行していくことが重要です。

はじめに

脆弱性管理は「全部見る」から「本当に危ないものを見極める」段階へ

脆弱性管理の現場では、以前から下記のような悩みをたびたび耳にします。

「脆弱性が多すぎて、どこから手を付ければよいかわからない」
「CVSSが高いものから対応しているが、現場が回りきらない」
「本当に攻撃されやすいものを優先できているのか、自信がない」

こうした課題が続く中、脆弱性の公開件数は急増し、攻撃者による調査・悪用のスピードは速くなっています。従来の「CVSSスコアが高いものから順に対応する」運用を続ける組織では、今後、優先順位付けや対応判断がさらに難しくなります。

2026年6月に米国CISAが、BOD 26-04: Prioritizing Security Updates Based on Risk を発令しました。BOD 26-04は、セキュリティパッチの適用についてリスクに基づく優先順位付けを求める、拘束力のある運用指令です。「すべての脆弱性を同じように扱う」のではなく、「攻撃される可能性と影響が大きいものから対処する」ための運用ルールであり、単なるパッチ適用期限の見直しではありません。

対象は米国政府機関のため、日系組織に直接適用される指令ではありませんが、記載されている考え方は、これからの脆弱性管理を考えるうえで参考になる点が多くあります。

本記事では、BOD 26-04の要点と、CVSS依存からリスクベース運用への転換を解説します。また、2026年6月14日から5日間にわたり米国デンバーで開催されたFIRST（Forum of Incident Response and Security Teams）*の、第38回年次カンファレンス「FIRST Conference 2026」に参加した弊社メンバーが、現場で聞いた各国の有識者の反応などについても紹介します。

　*FIRST（Forum of Incident Response and Security Teams）：各国のCSIRT/CERTなどインシデント対応・セキュリティチーム間の連携と情報共有を目的とする国際組織

目次

1. BOD 26-04とは何か：適用範囲を正しく理解
2. なぜ今、BOD 26-04が必要になったのか
3. BOD 26-04が示す最大の転換：「CVSS依存」からの脱却
4. BOD 26-04の対策を回すための運用モデル：ROC（Risk Operation Center）
5. リスクベース運用の第一歩は、なぜEASMなのか
6. まとめ：日系組織が学ぶべき2つのポイント

1.BOD 26-04とは何か：適用範囲を正しく理解

BOD 26-04は、CISAが発令したBinding Operational Directive、つまり拘束力のある運用指令です。

対象は、米国のFederal Civilian Executive Branch（FCEB）、日本語では連邦文民行政機関と呼ばれる政府機関の情報システムです。民間企業や日本企業に直接の法的義務があるわけではありません。それでも、BOD 26-04を「米国政府向けの指令」として片付けてしまうには惜しいほど、実務で参考になる考え方が多く含まれています。

この指令では、従来のようにCVSSスコアや一律の期限だけで脆弱性対応を進めるのではなく、資産の露出状況、既知悪用の有無、攻撃の自動化可能性、技術的影響を組み合わせて、対応期限を決める考え方が示されています。

BOD 26-04は、過去の指令であるBOD 19-02・BOD 22-01の考え方を統合し、「インターネットに出ているから危ない」「KEVに載っているから危ない」という個別判断を、より体系化したものと見ることができます。

• BOD 19-02：インターネットからアクセス可能なシステムの脆弱性対応
• BOD 22-01：CISA KEVカタログに掲載された既知悪用脆弱性への対応
• BOD 26-04：外部公開、KEV、悪用自動化、技術的影響を組み合わせたリスクベース対応

2.なぜ今、BOD 26-04が必要になったのか

BOD 26-04が出てきた背景には、脆弱性管理を取り巻く環境の変化があります。

大きな変化の一つが、CVE件数の急増です。FIRSTが2026年6月15日に公開した中間予測で、2026年のCVE件数が約66,000件に達する可能性を示しました。これは2月時点の予測を46.3%も上回るペースで、年間のCVE件数が7万件に迫るのは史上初めてです。

AIによって脆弱性の発見が加速し、例えば、これまで見つけきれなかった古いソフトウェアの欠陥や、埋もれていた脆弱性が掘り起こされる可能性が高まっています。攻撃者も同じようにAIを使い、脆弱性の発見から悪用コードの作成までを高速化させています。FIRSTも、今後はAIによる悪用コードの生成とAIによる修正の競争が、2026年後半のセキュリティ動向を象徴する動きの一つになると指摘しています。

さらに重要なのは、脆弱性の母数は増えているものの、KEV（CISAが公開する実際に悪用が確認された脆弱性のカタログ）やEPSS（FIRSTが提供する悪用される確率を予測するスコア）で見た「本当に悪用される可能性が高いもの」まで同じペースで増えているわけではない、という点です。つまり、脆弱性の発見件数が急増する中で、本当に対応すべきリスクを見極めること自体が難しくなっているともいえます。だからこそ、悪用の実態に基づいて優先順位を付ける重要性がさらに増しています。

2026年6月に開催されたFIRST Conference 2026でも、この点は大きなテーマでした。弊社メンバーも参加し、現地で世界各国のCSIRT担当者に話を伺うと、課題は「検知できるか」にとどまらず、検知した情報をどう処理し、誰と連携し、どの順番で対処するかという運用全体に広がっていることが分かりました。

この章のポイント：必要なのは、増え続ける情報の中から、本当に危ないものを早く見つけ、対処へつなげる仕組み

3.BOD 26-04が示す最大の転換：「CVSS依存」からの脱却

BOD 26-04の最大の転換は、CVSSスコアを優先順位付けの主軸として使わないことです。

もちろん、CVSSそのものが不要になるわけではありません。CVSSは、脆弱性そのものの技術的な深刻度を把握するための指標として参考情報となります。ただし、CVSSだけでは「自社にとって本当に危ないか」を判断できません。

たとえば、CVSSが高くても、外部から到達できない内部環境の資産であれば、攻撃される可能性は限定的かもしれません。逆に、CVSSが中程度でも、インターネットに公開され、すでに悪用が確認され、攻撃が自動化しやすい脆弱性であれば、最優先で対応すべきです。

BOD 26-04では、以下の4つの属性でリスクを判断します。

また、BOD 26-04は「危なそうなものから対応する」という曖昧な判断ではなく、明確な判断軸に基づいて具体的な期限を定めています。対応期限は、大きく次の4段階に整理できます。

特に注目すべき点は、最も重大なリスクに対して「3日以内の対応」と「フォレンジックトリアージ」が求められていることです。これまでの単にパッチを適用すれば完了という運用ではなく、重大度の高いリスクに関してはパッチ適用の前後で、すでに侵害が発生していないかを確認する必要があります。
攻撃者がすでに侵入している場合、パッチを適用しても侵害が解消されるとは限らず、Webシェル、バックドア、不正アカウント、盗まれた認証情報などが残っていれば、修正後も被害が継続する可能性があります。

このようにBOD 26-04は、CVSSスコア順に対応していく運用ではなく、攻撃者から見て到達できるか、すでに悪用されているか、攻撃が自動化されるか、侵害された場合の影響が大きいかで判断する運用です。

この章のポイント：CVSS ベースの優先順位付けを主軸にする時代は終わりつつある。BOD 26-04 では、外部公開、KEV、自動化、技術的影響という 4 属性で、対処期限まで定めている

4.BOD 26-04の対策を回すための運用モデル：ROC（Risk Operation Center）

ここからは、BOD 26-04そのものの解説から一歩進み、これらをどのように実務に落とすかを解説します。

弊社では従来から、現実的なリスクベースのセキュリティ運用が重要だと考え、その考え方を自社開発サービス「ANTERAS ASM」のリスク評価ロジックにも反映してきました。BOD 26-04が示す方向性は、こうした弊社の問題意識とも重なります。そして、こうした運用を継続的に回す仕組みとして注目しているのが、ROC（Risk Operation Center）というコンセプトです。皆さんもよくご存知のSOCは、侵入後の検知やインシデント対応を担う一方で、ROCは、攻撃が起きる前にリスクを可視化し、優先順位を付け、対処を進める役割を持ちます。

BOD 26-04を実務に落とし込むには、単発のパッチ対応ではなく、継続的にリスクを見つけ、優先順位を付け、対処を進める運用モデルが必要となり、ROCへの理解を深めることは、BOD 26-04の考え方を現場の運用に具体化するうえで有効な手がかりになります。

BOD 26-04の考え方をROCの運用に落とし込むと、次のように整理できます。

1. 脅威情報を継続的に収集・把握する
2. 自社資産を継続的に把握・更新する
3. リスクベースで優先順位付けする
4. 対処を推進する

SOCは、侵入後の検知、分析、対応、復旧において今後も不可欠です。ただし、外部公開資産の脆弱性や設定不備、漏洩認証情報、未管理資産といった侵入の「火種」が多すぎると、SOCはノイズに埋もれてしまい、運用が回らなくなります。ROCは、その前段で火種を減らす役割を果たし、本当に危ない資産を先に見つけ、優先順位を付け、対処を動かすことで、SOCが重要なアラートに集中できる状態を作ります。

この章のポイント：BOD 26-04を実務に落とすには、パッチ担当だけでは不十分。脅威情報把握、資産把握、優先度付け、対処推進を体系的に回すROC的な運用が必要

5.リスクベース運用の第一歩は、なぜEASMなのか

では、ROCでリスクベースの運用を始めるにあたり、日系組織はまず何から取り組むべきでしょうか。BOD 26-04の4属性のうち、最初に出てくるのがAsset Exposureです。警察庁のレポートにおいても、外部公開資産（VPN・RDP）による侵入は過去5年の合計で80%以上を占めています。そこでまず取り組むべきは、EASM（External Attack Surface Management）で、外部から見える攻撃対象領域を継続的に把握し、管理することです。

BOD 26-04型の運用に必要なのは、以下のような資産も含め、自組織が把握できていない外部公開資産を網羅的かつ正確に発見できるEASMです。

• 海外拠点が独自に公開している資産
• グループ会社や関連会社のドメイン
• 委託先が管理する環境
• 放置されたサブドメイン
• クラウド上の公開設定ミス
• 管理画面、VPN、テスト環境などの見落とされやすい資産

よくある誤解として、「ASMを入れているから大丈夫」というケースがありますが、既知資産をスキャンし、CVSS順にアラートを並べるだけでは、BOD 26-04が求めるリスクベース運用には届きません。本質的なEASMの価値は、未把握資産を洗い出し、脅威情報と照合し、優先順位付けを行うことで、その後の対処までつなげることです。

この章のポイント：EASMは、BOD 26-04型のリスクベース運用の入口。見えていない資産は、優先順位付けも、パッチ適用も、侵害調査も実施できない

6.まとめ：日系組織が学ぶべき2つのポイント

BOD 26-04から、日系組織が学ぶべき点は大きく2つあります。

ポイント1：外部公開資産の網羅的な把握

まずは、いまランサムウェアの主要な侵入口となっている外部公開資産を把握するところから始めましょう。

自組織の担当者がすべての外部公開資産を把握できているとは限りません。例えば、会社の備品を棚卸する際に、別拠点の倉庫や過去プロジェクト用の保管棚から、台帳に載っていない備品が発見されることがあります。同じように、海外拠点、グループ会社、委託先、クラウド環境、買収企業が持っていた古いドメイン、過去プロジェクトのテスト環境なども、同じように管理台帳外に残りやすい資産です。

攻撃者から見れば、それが本社管理か、海外拠点管理か、委託先管理かは関係なく、インターネットから見えていて、攻撃できるようであれば、そこが入口になります。

ポイント2：本質的なリスクから対応

もう一つは、脆弱性対応の順番を変えることです。

これまで、全件対応やCVSSが高いものを優先する運用だった場合は、以下のBOD26-04と同じ観点で優先順位を決めるよう見直すことを推奨します。

• 外部から到達できるか
• すでに悪用されているか
• 攻撃が自動化しやすいか
• 侵害時の影響が大きいか
• 事業上重要な資産か
• すぐにパッチを当てられない場合、代替策が取れるか
• すでに侵害されている可能性を確認できるか

これは、単なるセキュリティ製品の導入ではなく、運用の設計そのものです。
EASMで資産を見つけ、脅威情報と突き合わせてリスクベースの優先度付けを行い、対処まで推進する流れを持てるかどうかが、今後の侵入リスクの差に影響します。これを機に、自組織の資産把握と優先順位付けを見直してみてはいかがでしょうか。

この章のポイント：日系組織がまず見るべきは、外部公開資産の抜け漏れと、優先順位付けの基準です。BOD 26-04は、その両方を見直すきっかけになります。

関連資料のご案内

ASMについてもっと詳しく知りたい方に向けて、資料を無料提供しています。
ANTERAS ASM（旧Macnica ASM）の概要や導入事例など、ASMの検討に役立つ情報が満載です。
今すぐ、下記のリンクからダウンロードしてください。

ANTERAS ASMについて、詳しくはこちら

お問い合わせはこちら

動画で視聴したい方はこちら

参考情報

• CISA：BOD 26-04: Prioritizing Security Updates Based on Risk
• CISA：BOD 26-04 Implementation Guidance for Prioritizing Security Updates Based on Risk
• FIRST：FIRST Mid-Year Vulnerability Forecast Confirms Historic Surge, Projects ~66,000 CVEs in 2026
• FIRST：The 2026 Vulnerability Forecast Update: Navigating the AI Epoch
• 警察庁サイバー警察局：令和７年における サイバー空間をめぐる脅威の情勢等について
• マクニカネットワークスブログ：ランサムウェア攻撃に先回り！インシデントリスクを最小化する「ROC」とは
• マクニカネットワークスブログ：脆弱性対処の優先順位を決める"脱CVSS"のススメ

こんにちは！Tanevaコミュニティマネージャーの引野です。
私たちは「サイバーセキュリティ」をテーマに、経営者・現場担当者・アナリストなど、立場や役割の異なる人たちが集い、リアルな知見を持ち寄りながら学び合うコミュニティ「Taneva」を運営しています。

2026年6月5日、Meetup Vol.2を開催しました！今回のテーマは、「セキュリティ組織の変革」と「チームの熱量」。

正解がないからこそ悩み続けるテーマに、現場で向き合い続けるメンバーが集まり、それぞれの「リアル」を語り合う3時間となりました。このブログを通して、当日の熱気を少しでも感じていただけたらと思います。

　Meetupの詳細はこちら：https://go.macnica.co.jp/Entry-MNC-CSSCU-Community-20260605-TanevaVol2.html　
　X上でのみんなのつぶやき：https://x.com/search?q=%23TanevaMeetup&src=typed_query

目次

• なぜ「組織変革と熱量」をテーマにしたのか？
• 組織変革の実践事例 変革のトリガーとその難所
• 「楽しい」はつくれる！？セキュリティチームのモチベ事情
• 懇親会の様子
• おわりに

なぜ「組織変革と熱量」をテーマにしたのか？

今年1月、私たちはある企業のセキュリティチームに一週間密着し、日常業務を観察しました。セキュリティ担当者のリアルを知るためです。その中で気がついたのは、「意思決定が特定の人に集中している」ことと、「役割分担に必要なスキルを揃えるのに膨大な時間がかかる」ことでした。

セキュリティ上の判断には内部環境への深い理解が不可欠です。数千台に及ぶ端末リストの中から、限られた手がかりでインシデントの根本原因を探っていく作業や、グローバルに分散した情報資産の中から管理者を見つけて連絡を取り、対応していく作業は容易ではありません。その一方で、SOCアナリストや関連部門からの膨大な問い合わせにタイムリーに応答する必要があります。

日々高度化する脅威に対して深い洞察を持ち、内部コンテキストを踏まえて意思決定できる人材は組織内で限られています。しかも、そうした専門家の暗黙知を形式化するのは簡単ではなく、結果として負荷が特定の人材に集中しがちです。人材不足や流動化、技術の急速な進展、守るべき領域の拡大といった外的要因が重なり、この負の構造は一層深刻化していると感じています。

こうした背景から、セキュリティの現場は今、大きな転換が求められていると感じています。

必要なことは最適な組織設計と、日々高度化する脅威に対抗するための技術力です。しかし、制度やツールを変えるだけでは十分ではありません。セキュリティも結局は「人」が担うものです。人の想いや熱量こそが組織変革を支え、新たな組織づくりの原動力となります。

Tanevaが扱うのは、教科書的な組織論や技術論ではなく、「人」を起点としたセキュリティです。人と組織が変革の必要性を自覚し、自発的に変わっていくには何が必要か。周囲を巻き込み、高いモチベーションで攻撃者を上回るスピードで進化する組織をどう作るか。答えが一つに定まらない問いに真正面から向き合う価値があると考えています。現場で奮闘するすべてのセキュリティ担当者を支援したい――その想いでこのテーマを掲げました。

組織変革の実践事例 変革のトリガーとその難所

最初のパネルトークでは、実際に組織変革を経験してこられたお二人から、変革の「きっかけ」と「乗り越える難しさ」、「誰をどのように巻き込み説得したのか」などリアルな取り組み事例を共有いただきました。 

変革は"理屈"ではなく"きっかけ"から始まる

たとえば、インシデントをきっかけに、組織横断の連携が生まれたり、経営層との対話を通じて、優先順位が変わる（ウチは大丈夫か！？的な話題）ことは、さまざまな組織でも共通かもしれません。

そして、その先には、既存の組織文化との摩擦、変化に対する抵抗、何を優先すべきかの迷いなどの「壁」が必ずあります。だからこそ重要なのは、トップのマインドと、現場との対話です。

トップダウンでの受動的組織から能動的組織への変革

まず語られたのは、トップダウンの変革。しかしそれは単なる指示強化ではなく、組織を"動かす側"に変えるための変革でした。鍵となるのは、CISO自身のマインドとして、セキュリティに失敗はないので、完璧さではなく、挑戦を許容する姿勢＝"まじめすぎない真剣さ"をもつことです。

CISO自らが失敗を許容し、挑戦を後押しすることで、現場もまた「動いていい」と思えるようになる。その積み重ねが、結果的にリスクへの対応力を高め、より強い組織につながっていくーーそんな示唆がありました。

ボトムアップで進む「インテリジェンス駆動型」への転換

一方で、変革はトップだけでは完結しません。現場からの情報と意思決定がかみ合ったとき、組織は初めて前に進みます。

これまで、ベンダーやニュースに依存した意思決定が中心だった組織から、「自社にとって何が重要かを見極める意思決定」へと変えていく必要があります。ポイントは、下記のように単なる情報共有ではなく、意思決定につながるインプットができるかどうか。そこが大きな分岐点である、という話が印象的でした。

• 他社で発生した事例を有効活用し、自社のリスクを正しく上層部にインプットすることで変化を起こす
• ただし、全ての脅威を連携するのでは無く、今やるべき対応をリスクベースで洗い出す
• 単なるレポートではなく、自社にとって必要なアクションを明確に伝える
• サイバーハイジーン等の基本を徹底するように言い続ける

そして最後に強調されていたのはとてもシンプルで、でも最も本質的なこと「人と直接向き合うこと」です。現場に足を運ぶ、顔を覚えてもらう、対話を重ねる、こうした地道な積み重ねが、組織を動かす土台になります。

どれだけ優れた仕組みや戦略があっても、最終的に動くのは"人"。
だからこそ、コミュニケーションそのものが変革のインフラである、というメッセージが強く伝わってきました。

私がこのセッションで学んだのは、「変わらなければ」という焦りをいったん手放し、肩の力を抜いて取り組むことの大切さです。楽しむ余裕を持ち、「まず試してみる」姿勢で行動する方が、失敗を恐れて受動的になるよりも現実的な前進につながります。失敗を過度に避けようとすると行動が縮こまり、攻撃者に隙を与えてしまいます。むしろ失敗を許容しながら積極的に動き、多様な人と関わり、柔軟に学びを取り入れて自分と組織をアップデートしていくことが、ポテンヒットを許さない強いセキュリティ組織をつくると感じました。

「変革」と文字で書くと堅いイメージがありますが、柔軟な思考を持って、楽しむ余白を大事にしながら、一歩ずつ前に進んでいきましょう！

「楽しい」はつくれる！？セキュリティチームのモチベ事情

セキュリティの仕事は、決して楽な仕事ではありません。
業務負荷は高く、評価は見えにくく、そして"正解"も終わりもありません。
だからこそ、多くの現場で問い続けられているのが「どうすればチームが前向きに動き続けられるのか？」というテーマです。

パネルトーク②では、その問いに対する"現場からのリアルな取り組み"が共有されました。

モチベーションを下げる要因と反対のことをしてみては？

現場では、気づかないうちにモチベーションを下げる状況が積み重なっているかもしれません。「過剰な業務に追われ続ける」「意味を感じにくい作業に時間を使ってしまう」「評価や報酬と見合わない業務を抱える」「優秀な人材が取れない」といった状態に対してついつい頑張ってしまいがちですが、それではモチベーションが下がる一方です。そこで逆の発想を使って、あえて"逆の打ち手"をとってみるのはどうでしょうかということです。

例えば、

• 無理に抱え込まず、あえて滞らせたりSLAを見直す
• 誰も見ない報告など不要な業務はやめる
• 評価されにくい作業はAIに任せる
• リソースが足りなければ、新人でも良いから人を増やす

など、無理なものは無理として「頑張り方」を見直すこともまた、重要な意思決定かもしれません。

個人のモチベーションは「つくる時間」と「外との接点」から

個人のモチベーションは、自然に湧いてくるものではなく、意図してつくっていくものである、という点も印象的でした。

例えば、自由に使える自己研鑽の時間を意図的に確保する、外部コミュニティに参加し他社とつながるなど、日々の業務に埋もれがちな「学ぶ時間」を守り、異なる環境や考え方に触れることで、新たな解決策やモチベーションが生まれてくることもあります。

特に印象的だったのは、「他者貢献が自己強化ループを生む」というお話です。誰かの役に立った実感（意義）、成果としての手応え、周囲からの感謝、そこから得られる経験といった積み重ねが、自然とモチベーションを高めていく循環を生み出していきます。

モチベーションは"内側から湧いてくるもの"というより、環境の中で育てていくものだと感じさせられました。

組織としてモチベーションをどう支えるか

そして重要なのが、組織としてのあり方です。
トークの中では、「良いチームほど主体性が高い」という言葉が共有されました。

そのために必要なのは、やらされ仕事を減らす、仕事の範囲と責任を明確にする、個人の目標設定と価値観の共有を行うといった"前提の設計"です。

さらに忘れてはいけないことが、現場任せにしないこと。

任せるだけではなく、対話する、一緒に考える、必要な場面では支える、という"伴走型"の関わりが、チームの推進力を支えていくという話が印象的でした。

「楽しいチーム」は偶然生まれるものではありません。

負荷のかけ方、役割の設計、関係性の作り方。その一つひとつの積み重ねによって、"熱量のあるチーム"はつくられていく。そんな実感が残ったセッションでした。

懇親会の様子

19時から始まった懇親会では、「●●の壁」をテーマに、お酒を片手にワイワイ語り合いました！チャタムハウスルールのもと、普段は言えないような本音の話が飛び交っていたように思います。

おわりに

今回のMeetupを通じて改めて感じたのは、セキュリティは、技術だけでは成り立たないということです。

どれだけ優れたツールや仕組みがあっても、それを動かすのは「人」であり、その力を引き出すのが「組織」であり、そしてそれを前に進めるのが「熱量」です。

組織変革も、モチベーションも、決して一朝一夕で実現できるものではありません。

それでも、小さなマインドチェンジや日々のコミュニケーション、外の世界とのつながりなどの積み重ねが、少しずつ組織を変え、チームを前に進めていくのかもしれません。

そしてもう一つ大切なことは、一人で抱え込まないことです。

同じ課題に向き合う人たちと出会い、言葉を交わし、互いの視点に触れることで、見える景色が変わる、そんな瞬間を私たちはTanevaに集うみなさんと一緒に作りたいと考えています。Tanevaは、そんな「つながり」の中から、次の一歩が生まれる場所でありたいと思います。次回のMeetupでも、また皆さまとお会いできることを楽しみにしています！

▼Taneva（対象：自社のセキュリティを担う方はどなたでもご参加可能）　参加お申込みはこちら
▼Ikomai：東海版コミュニティ（対象：マクニカから製品・サービスをご購入いただいているお客様） 参加お申し込みはこちら

▼IST2：東京版コミュニティ（対象：マクニカから製品・サービスをご購入いただいているお客様） 参加お申し込みはこちら
▼KISC：関西版コミュニティ（対象：マクニカから製品・サービスをご購入いただいているお客様） 参加お申し込みはこちら

⽇本国内では「能動的サイバー防御」に関する議論が進み、企業には「攻撃されてから対応する」だけではなく、攻撃を前提とした備えが求められています。
重要インフラ、重要産業においては、重要設備の機能を担う計算機システム、すなわちOTを含むサイバーインシデントの報告も必要になるなど、サイバー攻撃に対抗する総合的な防御実装が急務です。
しかし、OTにおいては依然として次のような課題が⾒られます。

• 何を準備すべきか分からない
• セキュリティ対策がIT前提で議論されている

本記事では、OTセキュリティにおいて「適切に機能する防御」と、その作り⽅を⽰します。

目次

• OTセキュリティにおける前提：画⼀的な防御は成⽴しない
• OT現場のインシデント対応、そこから逆算した"備え"
• ３つのセキュリティ・コントロールで⾒るOT対策
• 能動的サイバー防御に必要なOTセキュリティ実装
• 最後に

OTセキュリティにおける前提：画⼀的な防御は成⽴しない

IT環境では、⾃動化・標準化された防御対策が有効です。優れた検知能⼒を持ち、⾃動的に隔離遮断するソリューションが⼈気で、遮断による業務影響は多少あれど、それを最⼩に抑えながら企業レベルでの障害を防ぐ有効な対策です。

しかし、OT環境ではこの⽅法が通じません。OTを担うコンピュータを無条件に遮断隔離した場合、
①システムの停⽌
②安全性への影響
などがあり、場合によっては操業と経営に打撃を与える事態を引き起こします。

他にも、OT特有の制約があります。
・レガシー機器が多い
・現場固有の構成が⽀配的、かつ、個社ごと・設備ごとに違う

すなわち、「とりあえず導⼊する」「⾃動で守る」「⼊れておけば安⼼」...は成⽴しないのが実態なのです。

OT現場のインシデント対応、そこから逆算した"備え"

「不正検知したら⾃動で遮断する」という防御に代わり、現場で⾏われているのは、次のプロセスです。
・検知・調査
・判断
・対処（必要に応じて隔離・封じ込め）

この⼀連の流れが成⽴しなければ、どれだけ⾼度なツールを導⼊しても意味を持ちません。こうした流れを成⽴させるためには、OT環境に適した検知と準備が重要です。

３つのセキュリティ・コントロールで⾒るOT対策

OT対策の全体像は、古くから⽤いられる「３つのセキュリティ・コントロール」で説明できます。

このように、各コントロールのつながりを意識し、何をするかを具体化することが⼤事です。
特に★印は、本稿のタイトルでもある、能動的サイバー防御の観点でも必要になります。

• インシデント対応に必要な情報、状態の把握
• 是正に必要な判断材料の迅速なアウトプット
• 迅速な事象確認、現場調査、対策案の列挙
• 運転状態・ビジネス影響を加味した素早い対策決定

これらができると、
規制が求める「説明性の⾼い、かつ、技術的なインシデント報告」も⾃ずと可能になります。

能動的サイバー防御に必要なOTセキュリティ実装

これらを踏まえると、OTセキュリティにおける「防御」とは、 単なる防御壁と⾃動遮断ではありません。

検知によって状況を可視化し、
判断によって最適な対応を選択し、
対処によって影響を制御する

これらが上⼿く機能するよう情報や仕掛けごと組み込む
―― この⼀連の流れと、それを成⽴させる設計と実装が防御です。

能動的サイバー防御時代においては、 「何を⼊れるか」ではなく、「どう機能させるか」が求められます。
個々の対策やツールを活かしながら、 検知・判断・対処を⼀体として機能させることこそが、OTセキュリティの本質だと考えています。

最後に

ツール導⼊だけでは実現できないOT防御において、⾃社のOT対策を機能させるにはどうしたらいいかなど、
OTセキュリティに関するご相談、お困りごとは、何でも遠慮なくご相談ください。
次回、サイバーハイジーン、サイバーレジリエンスの視点で、OTの防御実装を⾒ていきます。

関連ソリューション

Dragos　～世界最高峰の脅威インテリジェンス活用型OTセキュリティ～
◇Dragos製品に関する資料のDLはこちら
　
◇Dragos製品のお問い合わせはこちら

DeviceTotal　～OT/IoT/ネットワーク機器向け脆弱性管理プラットフォーム～
◇DeviceTotal製品に関する資料のDLはこちら
　
◇DeviceTotal製品のお問い合わせはこちら

◇事業を止めないためのOTセキュリティ～ランサムウェアなど最新動向を交えて解説～
動画の視聴はこちら↓

マクニカでは、セキュリティの企画・導入・文化浸透を担う人たちが集まって互いの知見を共有し、現場の課題に取り組むためのコミュニティ「関西情報セキュリティコミュニティ（通称：KISC）」を運営しています。

2025年4月に、自社サービスや製品をリリース・運用するためのお悩みや知見を共有する分科会「製品セキュリティ分科会」を発足し、2026年4月17日(金)に第3回目となるMeetupを弊社大阪オフィスにて実施しました。過去最高人数となる17名の方に参加いただき、「SBOMに関する取り組み」について、たくさんの意見交換が行われました。今回はその様子をお届けします。

製品セキュリティ分科会Vo.1のレポートはこちら：
「製品セキュリティの組織体制や人材の在り方とは？【関西コミュニティ（KISC）活動レポート】」
製品セキュリティ分科会Vo.2のレポートはこちら：
「CRAなど法規制や規格対応の実情とは？【関西コミュニティ（KISC）活動レポート】」

目次

• テーマ設定の背景
  • イベントアジェンダ
• 当日の様子
  
• まとめ
  • 参加者の皆様からの評価

テーマ設定の背景

製品セキュリティを取り巻く法規制や規格がますます多様化・高度化し、製造業を中心に対応が急務となる中で、今回はその中でも導入・運用における課題感が多いSBOM（Software Bill of Materials／ソフトウェア部品表）に焦点を当てMeetupを開催しました。

イベントアジェンダ

• 事例①自社での取り組み事例について
• 事例②日本の製造業の取り組み事情とあるべき姿
• 全員参加型ライトニングトーク～SBOM取り組み事例共有会～

当日の様子

今回の参加者の属性としては、製造業を中心に、研究開発、ソフトウェア／ハードウェア開発、品質保証、生産技術、情報システム部門など、製品セキュリティに関わる多様な部門の方々に参加いただきました。

また、担当者クラスだけでなく、リーダーやマネージャークラス、プロジェクトを統括する立場の方まで、幅広い役職層が参加しており、実務目線の課題から、組織・体制づくりに関する観点まで、さまざまな立場からの意見が交わされました。

第1回・第2回から継続してご参加いただいている方も多く、回を重ねることで参加者同士の距離感がより近くなった気がします。

製品セキュリティという、明確な正解が見えづらく、手探りで取り組む企業が多いテーマだからこそ、社名や立場を越えて本音を共有できる、数少ない場として機能し始めていることを改めて実感する時間となりました。

事例①では、過去の製品セキュリティ分科会すべてにご参加いただいている方から、自社でのSBOM取り組み事例を発表いただきました。
昨年度立ち上げた製品セキュリティ専任組織化の取り組みを中心に、立ち上げ時の苦労や、ベテラン技術者を専任チームに引き入れるための説得プロセス、さらにモチベーション維持や教育コンテンツの準備・拡充など、幅広い実践的な知見をご共有いただきました。

事例②では、製品セキュリティの分野で豊富な知見を持つ方から、製品セキュリティを取り巻く現状の課題と、今後あるべき姿について俯瞰的な視点からご紹介いただきました。
また、AI活用がもたらす環境変化にも触れられ、参加者にとって視野が広がる示唆に富んだセッションとなりました。

続く全員参加型ライトニングトークでは、総勢12名の方にSBOMに関する自社の取り組み状況や課題感、悩みごとを共有いただきました。
議論されたトピックとしては大きく、以下の3つです。

①SBOMは"どこまで・何の目的で"作るのか

法規制対応を主目的とするのか、脆弱性影響の把握を重視するのか、あるいはサプライヤへの説明に使いたいのかなど、自社におけるSBOMの位置づけを明確にしたうえで、「どこまで作るか」「どこまでの不完全性を許容するか」を定義することの重要性が共有されました。

②SBOMを"作った後"、脆弱性トリアージをどう回すか

NVDやJVDBなどの公開情報だけでは、現場の判断が難しいという課題が挙がりました。CVSSに加え、EPSSやKEV、アタックベクターなど複数の判断軸を組み合わせ始めている企業もありつつ、トリアージの基準や役割分担が属人化し、運用負荷が高くなっているという悩みも共通していました。 

③サプライチェーン/3^rdパーティにSBOMを"どう要求し、どう使うか"

法規制への理解度の差や、SBOMは企業秘密ではないかという心理的なハードルが議論になりました。また、SBOMを受け取ったとしても、それをどのように管理・活用するのかが課題になるケースも多く、一社だけでは完結しない難しさが改めて浮き彫りになりました。 

企業によって定義や考え方、目的意識が異なる中でベストプラクティスを探るために様々な意見が飛び交い、同じ立場の方が集まるコミュニティならではのやり取りがとても印象的でした。

まとめ

SBOMは重要性が高まる一方で、「どこまで作るのか」「どう運用につなげるのか」「サプライチェーンとどう向き合うのか」など、多くの企業が明確な答えを持てないまま手探りで取り組んでいるテーマです。
今回の製品セキュリティ分科会 Vol.3 では、そうした"迷い"を前提に、実務者同士が現場のリアルを持ち寄り、率直な意見交換が行われました。

参加者の皆様からの評価

今回は、参加者全員から満足度の高いイベントを開催することができ、７割を超える参加者の方が「コミュニティでの情報交換や交流が役に立った」と回答しており、参加者同士の対話や知見共有の価値が改めて確認されました。

アンケートでも、
「各社のさまざまな取り組みが参考になった」
「他社の状況を知ることで、自社の立ち位置を把握できた」
「具体的な事例やツール、AI活用の話が実践のヒントになった」
といった声が多く寄せられ、実務に直結する学びの多い場となったことがうかがえます。

最後に

本分科会では、ユーザ企業同士の情報交換に加え、製品セキュリティ分野における豊富な経験や知見を持つ有識者にも参加いただき、実務に即した視点でのコメントやアドバイスが得られる点も特長の一つです。

現場で直面している課題や悩みを共有しながら、専門的な知見も交えて議論できる場として、単なる情報交換にとどまらない、より実践的な学びの機会を提供しています。

今後もマクニカでは、製品セキュリティに携わる実務者が立場やフェーズを越えて学び合える場として、KISC製品セキュリティ分科会を継続して開催していく予定です。

SBOMや製品セキュリティへの取り組みに課題意識をお持ちの方は、ぜひ次回のMeetupにもご参加ください。
「関西情報セキュリティコミュニティ」に是非参加してみたい、という方は以下HPからコミュニティへの登録、お待ちしています！ 　
※東京・名古屋にも開催地を拡大中！
※本コミュニティは企業のサイバーセキュリティを担う方限定のコミュニティとなります。

▼Taneva（対象：自社のセキュリティを担う方はどなたでもご参加可能）　参加お申込みはこちら

▼KISC：関西版コミュニティ（対象：マクニカから製品・サービスをご購入いただいているお客様） 参加お申し込みはこちら

▼IST2：東京版コミュニティ（対象：マクニカから製品・サービスをご購入いただいているお客様） 参加お申し込みはこちら

▼Ikomai：東海版コミュニティ（対象：マクニカから製品・サービスをご購入いただいているお客様） 参加お申し込みはこちら