マクニカでは、セキュリティの企画・導入・文化浸透を担う人たちが集まって互いの知見を共有し、現場の課題に取り組むためのコミュニティ「関西情報セキュリティコミュニティ（通称：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：東海版コミュニティ（対象：マクニカから製品・サービスをご購入いただいているお客様） 参加お申し込みはこちら

近年、製品セキュリティに対する法規制が国内外で急速に強化されています。とりわけ欧州で施行が進むCRA（EUサイバーレジリエンス法）などの影響は大きく、製品開発を手がける企業は全社規格に則ったセキュリティ体制の整備が求められています。

CRAでは、デジタル要素を含むすべての製品を対象に、重い罰則と厳格な認証基準が設定されています。これに含まれる脆弱性管理義務は、単なる開発部門の個別対応では乗り切れないものです。全社的な標準化と効率的な対応体制を実現するためには、PSIRTを基軸とした社内連携体制の構築が急務です。

本記事では、今まさに喫緊のテーマとなっている「PSIRT（Product Security Incident Response Team）」の必要性と効果的な運用方法について、組織横断のセキュリティ対応と脆弱性管理ツール活用を軸に解説します。

目次

• PSIRTが必要とされる背景と法規制動向
  • 製品開発を取り巻く規制強化
  • CRAの概要と企業への影響
• 製品セキュリティ体制とPSIRTの役割
  • PSIRT組織の必要性
  • PSIRTの具体的役割分担
• 効率的な脆弱性管理体制の構築
  • CRA対応における脆弱性管理フローの要点
  • 脆弱性管理ツールの導入ポイント
• マクニカが提供する主なツールとサービス
  • Black Duckによる自動SBOM・脆弱性検出
  • LeanSeeksによるリスクベーストリアージの自動化
  • コンサルティング・導入支援

PSIRTが必要とされる背景と法規制動向

製品開発を取り巻く規制強化

IoT、自動車、医療機器など、製品の種類に応じてさまざまな法令や規制が登場しています。CRA（EUサイバーレジリエンス法）に加え、米国大統領令やISO/SAE 21434、自動車分野のUN-R155/156、医療機器関連のIMDRFガイドラインなども、製品ライフサイクル全体でセキュリティ対応を強く求めています。特に欧州向けの製品においては、2026年9月から厳しい報告義務が課され、2027年12月以降はCEマーキング適合が不可欠となります。

この図により、自社製品がどの規制の対象となるかを俯瞰でき、CRAへの対応がいかに「全社的な課題」となるかを理解できます。

CRAの概要と企業への影響

CRAは、デバイスやネットワークに接続可能なすべての製品が対象としています。企業には、セキュリティリスクアセスメントの実施、脆弱性報告・対応、SBOM（ソフトウェア部品表）の作成、脆弱性連絡窓口の設置など、多岐にわたるコンプライアンス義務が生じます。違反時の罰則は最大1,500万ユーロまたは全世界売上2.5%（いずれか高い方）と、経営リスクの観点からも無視できません。

製品セキュリティ体制とPSIRTの役割

PSIRT組織の必要性

こうした規制への実効的な対応は、製品開発部門ごとの個別裁量では限界があります。社内横断型の対応を担うのが、PSIRT（Product Security Incident Response Team）です。PSIRT組織の目的は、脆弱性管理を標準化・効率化し、会社全体でセキュリティ対応レベルを引き上げることにあります。

この図は、本社・事業部・グループ会社といった多階層でPSIRTが組織される場合の関係性を示しており、全社方針の浸透と現場実装との橋渡し役としてのPSIRTの重要性が一目で理解できます。

PSIRTの具体的役割分担

本社PSIRT： 司令塔・ガバナンス機能

• 全社方針や脆弱性対応ルールの策定
• 標準フロー・通知テンプレート整備、インシデント管理システムなどツール選定
• 社外・規制当局との連携窓口
• 社内教育・部門支援

事業部PSIRT：現場部隊・実装推進機能

• 担当製品の脆弱性調査、分析、技術的対応
• 開発部門との密接な調整と対応策の実装
• 顧客通知や本社への報告連携
• 製品品質保証

PSIRTが本社・事業部・開発部門を横断して連携することで、脆弱性発見から修正・顧客対応までの一連フローが標準化され、対応漏れや工数の肥大化を抑えられます。

効率的な脆弱性管理体制の構築

CRA対応における脆弱性管理フローの要点

CRAでは製品リリース前のSBOM整備と、リリース後の継続的脆弱性管理が求められます。リリース後は外部報告窓口の運用、迅速な警告通知（24時間以内）、是正措置の提供（72時間以内）など、時間軸にも厳格なルールがあります。これらを満たすには組織横断の情報管理と、工数削減のためのツール導入が不可欠です。

脆弱性管理ツールの導入ポイント

脆弱性管理ツールを活用することで、リリース前後のSBOM作成、脆弱性情報の自動検出、優先度付け（トリアージ）、パッチ作成・承認までの一連業務を効率化できます。特に次の観点が重要です。

• 各開発現場ごとのルール・ポリシー設定が可能
• 多様な開発言語・環境に対応した解析手法が選択できる
• 構成ファイルからの自動SBOM生成
• 利用OSSやライセンスの自動検出と脆弱性優先度自動化
• 脆弱性情報DBとの連携・最新情報の即時反映

これらによって日々増加する脆弱性情報の管理工数を大幅に削減できます。

マクニカが提供する主なツールとサービス

Black Duckによる自動SBOM・脆弱性検出

Black Duckは、開発中のOSSコンポーネントを自動的にSBOM化し、ライセンス情報・既知脆弱性・新たな脆弱性を継続的に検出します。事業部や開発チームごとに利用ルールを設定できるため、現場運用を阻害せず管理レベルを引き上げられます。

LeanSeeksによるリスクベーストリアージの自動化

マクニカ独自のサービスLeanSeeksは、増え続ける脆弱性情報群の中から対応優先度の高いものを精度よく絞り込みます。Black Duckの検出能力と組み合わせることで、社内対応の工数削減・修正判断基準の明確化が可能になります。これにより煩雑になりがちな対応フローを簡素化でき、規制対応のための運用標準化が進みます。

コンサルティング・導入支援

マクニカでは、PSIRT組織の新規構築から各種ツールの選定、社内運用環境のグランドデザインまで、コンサルティング・導入支援サービスを展開しています。導入前の検証（PoC）から運用後の改善・現場トレーニングまで一貫サポートを提供し、安心してDX成果につなげることができます。

法規制強化が進む現状では、開発チーム個別裁量に頼る時代はもう終わりました。全社的なセキュリティ対応を実現し、標準化・効率化するにはPSIRT組織の構築と適切なツール導入が不可欠です。脆弱性管理体制を見直したい方は、ぜひマクニカのコンサルティングやツール活用をご検討ください。

関連ソリューション

・Black Duck Software
・LeanSeeks

本記事の詳細は、無料動画ポータル「Macnica Security& DX Stream」で公開中。
今すぐ動画を視聴（無料登録）する方は、サムネ▽をクリック！

まずは動画で実践的なノウハウを手に入れ、最新情報や個別相談もお気軽にご連絡ください。

こんにちは！マクニカ コミュニティマネージャーの髙橋です。

マクニカでは、東海地域でサイバーセキュリティを担う人たちが集うコミュニティ「Ikomai Security Community」を運営しています。Ikomaiでは、『見えない不安も、話せば力に。いこまい、セキュリティ。』をスローガンに、下記のビジョンを掲げて活動しています。

2026年2月12日（木）に開催したIkomai Meetup Vol.2では、「セキュリティインシデントの備え、どうしてる！？」をテーマに、実践的な取り組みを続ける企業の方々による事例共有や、参加者同士のグループディスカッションを行い、テーマについて議論を深めました。

今回は、前回よりも多くの仲間が集まり、現場のリアルな声が飛び交う活発なMeetupとなりました。本記事では、当日の内容をお届けします！

目次

1. 当日の様子
2. 取り組み事例①：インシデント対応の「備え」をどう実践するか
3. 取り組み事例② ：実際のインシデント経験と、継続的な訓練の取り組みについて
4. ミニセッション：攻撃者はわざわざ高い壁を乗り越えない
5. グループディスカッション
6. まとめ

当日の様子

Meetupは、参加者同士の挨拶や名刺交換などで始まりを躊躇してしまうくらいの盛り上がりの中、半ば強引に開始させていただく形となりました！今回も「チャタムハウスルール」のもと、参加者が心理的安全性を持って話せる場づくりを意識した運営としました。
はじめは、複数のテーブルに分かれて参加者同士が自己紹介を行い、日頃の取り組みやちょっとした悩みを共有。初対面でもすぐに打ち解ける空気が生まれ、自然とコミュニティらしい温かさが広がりました。

取り組み事例①：インシデント対応の「備え」をどう実践するか

最初の事例登壇では、インシデント対応の「備え」をどう実践するか、というテーマでお話いただきました。

ツールを導入することがゴールではなく、有事の際に"点ではなく面で機能するか"どうかが重要という視点のもと、実際に訓練を回してみることで初めて見えてくる課題や、対策が時間とともに陳腐化していくリスクについて語っていただきました。「完璧より継続」という言葉の通り、一度整えて終わりではなく、改善をやり続ける覚悟を持つことの大切さが伝わる内容でした。

抜き打ち訓練時に見つかった期待するフローとの乖離、机上訓練で判明した復旧時の落とし穴など具体的な事例を共有いただき、会場からも「盲点だった」とうなる声も。

業務を"どう復旧させるか"まで踏み込んで対応することで初めて完結する、という考え方も共有され、経営層との事前のすり合わせや、復旧を見据えた検証の重要性が参加者の印象に残りました。

取り組み事例②：実際のインシデント経験と、継続的な訓練の取り組みについて

続く事例登壇では、実際のインシデント経験と、継続的な訓練の取り組みについてお話いただきました。

実インシデントの初動で素早く関係者が集まり、「分かっていること・分かっていないこと・今やること」を即座に整理・共有できたことで、迷いなく対応を進められたというエピソードは、「これは真似したい」という声が上がるほど具体的で印象的でした。

また、「24時間365日すべてを見ることはできない」という率直な前提のもと、自社でカバーする範囲と外部を活用する範囲を現実的に切り分けていくことの重要性も語られました。体制やルールを整えることと、実際に動けることは別物であるというメッセージは、多くの参加者が自分事として受け止めていた様子でした。そして、こうした訓練を繰り返し、小さな穴を一つずつ塞いでいくことで、攻撃者にとって「割に合わない会社」になっていくという考え方も印象的でした。一度で完璧を目指すのではなく、地道に続けることが備えの質を高めていく、そして、その過程では「失敗してもよい環境づくり」が重要で、"訓練だから笑い話で済む"くらいの気持ちでというメッセージは参加者の心に響いたのではないでしょうか。

ミニセッション：攻撃者はわざわざ高い壁を乗り越えない

マクニカ セキュリティ研究センターの山崎から、攻撃者の視点でどのようなポイントを把握しておくべきかを具体的に紹介しました。

攻撃者はいきなり強固な防御を突破しようとするのではなく、まず弱いところを探すという実態をもとに、OSの標準コマンドの悪用・弱い認証方式・EDR未導入端末の存在など、初期侵入で特に狙われやすいポイントを具体例を交えて解説しました。

「これ、うちは大丈夫だっけ？」と自社に置き換えて考えるきっかけとなるよう、攻撃者目線で自社の弱点を把握することの重要性をお伝えしました。会場からは、自社でもすぐに攻撃者に使われていそうなコマンドのログを調査したい、との声があがりました。

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

事例登壇とミニセッションを踏まえ、参加者が少人数グループに分かれてディスカッションを行いました。チャタムハウスルールのもと、自社の現状や悩みを率直に話し合える場となりました。

「訓練をまだ実施できていない」「バックアップは取っているが戻し方まで確認できていない」といったもやもやが共有される一方、「他社のシナリオを参考にして自社でも机上訓練をやってみたい」「初動の整理フレームはすぐに使えそう」など、次の行動につながる前向きなアイデアも生まれました。

まとめ

セキュリティインシデントの発生が多発するなかで、「うちは大丈夫か？」という不安は、きっと多くの情シス担当者が感じていることと思います。今回のMeetupでは、実践的な訓練から得た学びを、2社の事例登壇という形でIkomaiの参加者メンバーに発表いただきました。事務局が印象に残ったポイントをまとめてみました。

訓練は"設計の正しさ"ではなく"運用の耐久性"を試す

インシデントに関わる訓練は一度やったことがある、という企業も多いと思います。
ただ、訓練後のワークフローをしばらく見直せていない...という方もいるのではないでしょうか。
被害がいつ起きてもおかしくない今だからこそ、改めて見直してみると、思わぬ抜け穴に気づけるかもしれません。

訓練実施時のポイント

・実際にインシデントが起きた想定で、マニュアル通りにエスカレーションが上がってくるかを試してみる
・想定外が起きたときに、どこで立ち止まるのかを確認し、運用上の弱点を一つずつ埋めていく
・全システムの半分が暗号化、バックアップも感染しているなど、具体的なシナリオを想定した業務復旧プロセスを確認しておく

対策は"見直した瞬間"から陳腐化が始まる

対策を見直したときは万全のつもりでも、脅威は気づかないうちに変化しています。
「最後に見直したのいつだっけ？」と思った方は、ちょうど良い振り返りのタイミングかもしれません。

見直し時のポイント

・定期的に脅威トレンドと自社対策のギャップを確認してみる
・マニュアルや体制に"更新期限"を設けて、陳腐化を防ぐ

"万全な備え"より"継続する仕組み"が組織を強くする

万全な対策を一度で作ろうとすると、プレッシャーが大きくて続きません。
小さな改善を繰り返し、昨日より今日がベターであり続けるくらいの気持ちで取り組むと意識が変わるかもしれません。

継続するためのポイント

・一度で完璧を目指さず、地道でもコツコツとマニュアルをアップデートするための時間を確保する
・訓練だからこそ失敗を許容する雰囲気をつくることが、訓練の質と継続性を高める、失敗を楽しむくらいの気持ちで。
・改善の積み重ねが、関係者の意識を高め、攻撃者にとって"コスパの悪い組織"につながると意識する

Tips：一人で抱えず、外部や、有識者の知見をうまく使う

すべてを自社だけでやりきろうとしている企業は多いのかもしれません。
外部をうまく組み合わせることで、限られたリソースでも現実的な体制が組めるという意見もあります。
できるところから下記のポイントをご参照ください！

活用のポイント

・訓練シナリオの作成は外部に依頼するという手もある
・運用監視や初動対応は、外部SOCとの役割分担で負荷を分散する (その他、AIの活用など)
・攻撃者目線で改善ポイントを洗い出してみることにより対策の優先順位が整理しやすくなる

おわりに

Ikomaiはこれからも、東海エリアのセキュリティ担当者が互いに学び、支え合える場となり、"持ち帰りのある場"を作れるよう運営一同盛り上げていきます！コミュニティから得られる知見は人それぞれですので、Ikomaiへの参加で、自分なりの気づきを体感してみていただけると運営一同嬉しく思います。

次回Vol.3はさらにパワーアップしていきますのでもぜひご期待ください！！

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

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

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

クラウドの普及、OT環境のネットワーク接続、SaaSの増加などにより、企業が管理すべき資産はここ数年で急速に拡大しています。一方で、多くの組織が「何を守るべきか」を正確に把握できていないという課題を抱えています。セキュリティ対策の高度化が進むなかでも、前提となる資産情報が不十分であれば、適切なリスク判断を行うことはできません。

本記事では、資産を起点にリスクを捉えるアプローチであるCAASM（Cyber Asset Attack Surface Management）に焦点を当て、なぜ今この考え方が求められているのか、そして可視化をどのように意思決定へ接続すべきかを解説します。さらに、従来の資産管理との違いや、これからのセキュリティ運用に求められる視点についても整理します。

 目次

• セキュリティ運用の前提の変化
  • 資産管理を難しくする構造的課題
• CAASMは「検知」ではなく「判断」の基盤
  • CAASMとSIEMの役割を正しく理解する
• 可視化だけでは意思決定につながらない
  • Exposureベースの意思決定への進化
• まとめ：リスク管理は資産理解から始まる

セキュリティ運用の前提の変化

従来の企業ITでは、管理対象の大半が社内ネットワーク上に存在していました。いわば「境界の内側」を把握することで、防御は一定程度成立していたと言えます。しかし、現在は状況が大きく変化しています。クラウドサービスの利用拡大に加え、リモートワークの定着、モバイルデバイスの増加、さらには工場設備などのOT環境がネットワークへ接続されるようになり、資産の所在は大きく分散しました。加えて、業務委託先や海外拠点など、自社の直接管理が及ばない領域にも重要な資産が存在します。

このような環境において、台帳管理や定期棚卸だけで最新状態を維持することは現実的ではありません。変化のスピードが速い現代のIT環境では、「把握しているつもり」と「実際に把握できている状態」の間にギャップが生まれやすくなっています。今、企業が直面している本質的な課題は、「検知の不足」ではなく、「判断の前提となる資産情報が揃っていないこと」にあるのです。

資産管理を難しくする構造的課題

資産の増加以上に問題となるのが、管理情報の分断です。多くの企業では用途ごとに異なるツールが導入されており、IT資産管理ツール、EDR、脆弱性管理、クラウド管理ツールなどが個別に運用されています。その結果、重複登録や記録漏れが発生しやすく、どの情報が最新なのか判断しづらい状況が生まれます。また、棚卸のタイミングでしか更新されない情報も少なくありません。

こうした断片的な情報環境では、仮に高度な検知基盤を導入していたとしても、そのアラートが事業にどの程度の影響を与えるのかを即座に判断することは困難です。セキュリティ対策は個別最適でも成立しますが、意思決定は常に全体最適で行う必要があります。そのためには、組織全体を俯瞰できる資産情報が不可欠です。資産管理の課題は運用の問題というより、構造の問題として捉えるべき段階にきていると言えるでしょう。

CAASMは「検知」ではなく「判断」の基盤

CAASMは新たな検知機能を追加するソリューションではありません。既存ツールに散在する情報を事実ベースで整理し、判断や優先付けに活用できる状態を整えるためのフレームワークです。

重要なのは、新しいデータを増やすことではなく、既に存在している情報を横断的に結び付けることにあります。統合される情報は、存在している資産、重要度、リスク、そして状態変化といった要素です。これらを一元的に把握することで、「どこから対応すべきか」「なぜ今対応するのか」「なぜ後回しにできるのか」といった説明可能な意思決定が実現します。特に経営層への説明責任が求められる場面では、客観的な根拠に基づいた判断が不可欠です。

可視化はゴールではなく、判断の質を高めるための手段である――これがCAASMの本質と言えるでしょう。

CAASMとSIEMの役割を正しく理解する

CAASMを検討する際、「SIEMがあれば十分ではないか」という疑問を持たれることがあります。しかし両者の役割は明確に異なります。CAASMは「何が存在するか」という実態を把握し、組織の攻撃対象領域を明らかにします。一方、SIEMはログやイベントを分析し、「何が起きているか」という動きを捉えます。

つまり、CAASMが静的な視点を提供するのに対し、SIEMは動的な視点を担います。CAASMが判断の土台を形成し、SIEMが検知能力を高めることで、セキュリティは単なる監視運用から経営判断に活用できるレベルへと引き上げられます。

両者は競合ではなく相互補完の関係にあり、組み合わせて活用することで、より実効性の高いセキュリティ運用が実現します。

可視化だけでは意思決定につながらない

多くの組織で既に脆弱性一覧やアラート、リスクスコアなどを可視化しています。しかし、情報が並んでいるだけでは意思決定には直結しません。なぜなら、そこには業務との関連性や影響度といった文脈が欠けていることが多いためです。

重要なのは、資産・リスク・変化という三つの要素を結び付けて捉えることです。どの業務に関係する資産なのか、どの部門が利用しているのか、停止した場合にどの程度の影響があるのか。さらに、どのようなリスクを抱えているのか、そして何が変化したのかを継続的に把握する必要があります。

この文脈が揃って初めて、「いま対応すべきリスク」が明確になります。リスクの量ではなく、対応判断に直結する形で情報を提示できるかどうかが、可視化の価値を左右します。

Exposureベースの意思決定への進化

近年、CAASMの思想は「Exposure Assessment」という考え方へと発展しつつあります。ここでは重要度、影響度、状態変化といった複数の観点を組み合わせ、リスクを対応優先度へと落とし込みます。全てのリスクに同時に対応することが難しい現実において、優先順位付けは不可欠です。

Exposureベースのアプローチは、限られたリソースを最も効果的に配分するための判断を支援します。これは単なる運用効率化ではありません。セキュリティを対策の集合体から、説明可能な経営判断へと進化させるアプローチと言えるでしょう。結果として、セキュリティ部門は守る役割にとどまらず、事業継続を支える戦略的機能へと変化していきます。

まとめ：リスク管理は資産理解から始まる

高度なセキュリティ対策を導入していても、不安が払拭されない組織は少なくありません。その背景には、対策不足ではなく前提情報の不足がある可能性があります。

これからのセキュリティに求められるのは、「何を守るのか」を正しく理解できる状態です。

「資産を正確に把握し、リスクと結び付け、変化を捉える」――その基盤が整って初めて、合理的で説明可能な意思決定が実現します。

CAASMは、この状態を支える重要なアプローチとして注目されています。まずは、自社の資産がどこまで把握できているかを確認し、判断に必要な情報が揃っているかを見直すことから始めてみてはいかがでしょうか。それが、持続可能なセキュリティ運用への第一歩となります。

弊社ではCAASM製品として「Axonius」、「runZero」を取り扱っております。ぜひ以下からお問い合わせください。

▼Axonius製品に関する資料のDLはこちら

▼runZero製品に関する資料のDLはこちら

生成AIの"見えない利用"＝シャドーAIが拡大しており、放置すればデータ露出や監査上の問題に直結します。しかし、今やだれでも簡単にAIサービスが利用でき、従業員の業務効率化の面でもシャドーAIを完全に防ぐことは難しいのが現状です。そこで、本記事ではシャドーAIのリスクをおさらいし、その利用を前提とした現実的な対策（発見・検出・保護）を解説します。

目次

1. シャドーAIとは？――"善意の近道"が企業リスクになる理由
2. シャドーAI対策の現実解：発見→検出→保護の３ステップ
3. まとめ：シャドーAIは"止める"より"守って活かす"へ

１．シャドーAIとは？――"善意の近道"が企業リスクになる理由

生成AIが当たり前になり、現場では要約・文章作成・コードのたたき台などを、ブラウザですぐ使える外部AIに頼る場面が増えています。その中で問題になるのが 「シャドーAI」です。シャドーAIとは、IT部門の正式な承認や監督がないまま、従業員がAIツール／AI機能を利用する状態を指します。 重要なのは、シャドーAIが"悪意のある行為"というよりも、"生産性を上げたい"という善意の近道として発生しやすい点です。

なぜ今、シャドーAIが増えているのか

ChatGPTやCopilotのようなクラウドサービスが増加しており、「サイトにアクセスして入力するだけ」で動くため、従来のシャドーITのようにインストールや購買を伴いません。結果として、セキュリティや法務のレビューを待たずに利用が広がり、IT部門は「誰が」「どのAIで」「どんなやり取りを」しているか把握しにくくなります。

シャドーAIの主なリスク

シャドーAIのリスクは大きく3つに整理できます。

①機密データの外部持ち出し（情報漏えい）

従業員が社内資料、顧客情報、ソースコードなどをプロンプトやファイルとして外部AIに投入してしまうと、組織の管理外にデータが漏洩する可能性があります。
そのため、シャドーAIはデータセキュリティ面の重大なリスクになり得ます。

②コンプライアンス／監査の破綻

どのAIにどんな情報を渡したかが追えないと、監査証跡が不足し、規制や社内ルールへの適合性を説明できなくなります。
シャドーAIがセキュリティやコンプライアンス事故につながる可能性が高いため、継続的な監査やポリシー整備の必要性があります。

③生成AI特有の脅威（悪性プロンプトや不正な応答の伝播）

生成AIは「入力（プロンプト）」「出力（応答）」が新しい攻撃面になります。たとえば、悪意ある入力で挙動を誘導したり、危険な出力が業務に混入したりするリスクは、従来のWeb利用とは性質が異なります。プロンプトや応答といった攻撃面を守る"ガードレール"で不適切な利用や脅威の伝播を抑えることが重要です。

２．シャドーAI対策の現実解：発見→検出→保護の３ステップ

シャドーAI対策は「全面禁止」だけではうまくいきません。業務上のニーズが残る限り、利用が私物端末や私用回線に"潜る"ことで、かえって統制が効かなくなる可能性があるためです。こうした背景から、組織としては「使う前提で守る」設計に寄せるのが現実的です。 

ここで軸になるのが、次の3ステップです。

①発見：何が使われているかを知る（シャドーAIの棚卸し）
②検出：どれが危険かを判断する（利用文脈・リスクスコアで優先度付け）
③保護：業務を止めずに守る（許可/ブロック/誘導、DLP、ガードレール）

①発見

最初に必要なのは、社内で利用されているAIツールやAI機能の棚卸しです。
具体的には、(a)ネットワークログやWebアクセスの観測、 (b)未承認SaaSの棚卸し（シャドーIT可視化の延長）などを組み合わせ、「誰が・何に・どれくらい」アクセスしているかを掴みます。 

②検出

「全部を止める」ではなく優先順位をつけます。
次に、利用されているAIを一律に扱うのではなく、リスクの高いものから優先順位を付けます。シャドーAIはデータ管理・出力の信頼性・意思決定への影響など、従来のシャドーITより"AI特有の論点"が増えます。 

③保護

ガードレールで"安全に使える道"を作ります。
最後は、ルールと仕組みで「安全に使える道」を整備します。柔軟なガバナンスフレームワークとガードレール、モニタリングが重要なポイントとなり、以下が具体策の例です。

ポリシー整備（AI利用ルール）

入力禁止情報（個人情報・機密・取引先情報など）や、許可ツール/用途を明文化します。ガイドラインがないと現場が自己判断に寄り、誤入力や過剰利用が起きやすくなります。 

技術的なデータ保護（DLP等）

機密情報のアップロードや入力を抑止する仕組みを用意します。これにより「うっかり流出」を減らせます。
この"発見→ 検出→ 保護 "を、Web/ネットワークの入口で実装できると、現場の体験を壊さずに統制しやすくなります。

しかし、実務では「発見」「検出」「保護」を別々のツールや運用で組み合わせると、設計・運用コストが膨らみがちです。そこでこれらを"アクセスの入口"でまとめて実装する具体策として、Cisco Secure Access の「 AI Access」を紹介します。

Cisco Secure Access の「AI Access」で何ができるのか

AI Accessは、生成AIを含む第三者AIアプリの利用に対して、アクセス制御やDLPを統合的に提供する機能です。

大きくは以下の3つの機能が提供されています。

1) シャドーAIアプリの発見
Webトラフィックを検査して、組織内で使われているAIサービス（AI機能付きサービス含む）を把握します。

2) シャドーAIのリスク評価
利用状況、端末、場所、ネットワークなどの文脈情報を踏まえ、従業員が利用しているアプリを評価し、リスクの高いアプリを洗い出します。
これにより「何を許可し、何を制限するか」を、感覚ではなく根拠を持って進めやすくなります。

3) アクセス制御とデータ保護
IT部門承認済みAIの安全な利用を支援しつつ、未承認AIへのアクセスをブロックまたは承認済みサービスへ誘導（リダイレクト）します。

アクセス制御・リダイレクトの例

また、単純な文字列検出でのブロックだけではなく、プロンプトの内容や出力の文脈を踏まえ、プライバシー/安全/セキュリティ上の懸念がある入力をブロックしたり、悪性の応答を遮断して脅威の伝播を防いだりする"ガードレール"の機能を備えており、柔軟に対策することができます。

ガードレールの動作例

動作時のログ例

３．まとめ：シャドーAIは"止める"より"守って活かす"へ

シャドーAIは、現場の工夫として自然発生しやすく、全面禁止だけでゼロにするのは現実的ではありません。だからこそ、発見→ 検出 → 保護 の枠組みで、業務を止めずに安全に使える環境を整えることが重要です。

Cisco Secure Access「AI Access」 は、シャドーAIの発見、リスク検出、アクセス制御とデータ保護を一連の流れとして扱える選択肢です。「何が使われているか分からない」「許可/不許可の判断が難しい」「データ持ち出しが不安」という課題がある組織では、まず"入口の統制"から始めるのが近道になるはずです。

従業員の生成AI利用を"禁止"ではなく"統制"で前に進めたい方はぜひお気軽にご相談ください。

▼Cisco Secure Accessについての詳細は、こちらの動画をご視聴ください。（クリックすると動画視聴サイトへ飛びます）

こんにちは！マクニカ コミュニティマネージャーの堀内です。

マクニカでは、セキュリティの企画・導入・文化の浸透を担う方々が集まり、互いの知見を共有しながら課題解決に取り組むことを目的としたコミュニティ「関西情報セキュリティコミュニティ（通称：KISC）」を運営しています。

2025年12月に開催したMeetup Vol.7では、14名の方に参加いただき、各社の内部不正対策の取り組み状況や課題について、たくさんの意見交換が行われました。
本記事では、当日の様子や話題となったポイントをご紹介します！

目次

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

イベントアジェンダ

• 『オープニング』
• 『初参加企業LT』
• 『事例セッション：～内部不正対策計画をふりかえって～』
  • JCOM株式会社　渡辺さん
• 『事例セッション： ～自社の取り組み紹介～』
  • フェンリル株式会社　上原さん
• 『グループディスカッション』
  • 各社の学びや課題の共有
  • 課題についてディスカッション
  • 全体共有
• 『クロージング』

テーマ設定の背景

KISC Vol.7では「内部不正」をテーマにMeetupを開催しました。これまでメンバーからの要望が多かったテーマではあるものの、対策が各社の事情に大きく依存するため、コミュニティで明確な解決策を出すのは難しいテーマだと感じていました。それでも、答えが一つに定まらない課題を皆で語り合う場こそコミュニティの価値だと考え、これまでの試行錯誤や苦労を共有してくれるメンバーの協力を得て、満を持して今回のMeetupを開催しました✨

当日の様子

「ライトニングトーク」では、KISC Meetupに初めて参加いただいた4名の方に、自己紹介を兼ねてご登壇いただきました。

KISCでは、はじめてご参加いただいた方には、自己紹介のライトニングトークをしてもらっています。コミュニティは、情報を発信する人に自然と情報が集まっていきます。なので、まずは、自己紹介という話しやすいテーマで発信していただくことで、初参加者の方でもコミュニティに溶け込み、参加した目的を果たせるようにしています♪今回のライトニングトークでも、それぞれのセキュリティに対する想いを語っていただいたことによって、場の雰囲気も一気に和らぎ、参加者同士の距離が縮まったように感じられました。

（皆様、今後ともよろしくお願いいたします！）

続く「事例セッション」では、「自社にとって何を不正と定義し、どう対処するか」「そもそも不正を起こさせない工夫」という２つの観点から、2名の登壇者の方に自社の取り組みや工夫について、具体的な運用事例を交えながらお話しいただきました。
参加者の皆さんも頷きながらメモを取ったり、撮影OKの資料で気になった箇所を写真に収めたりと、会場はかなり興味津々といった雰囲気でした。

また、各セッション後のQ&Aも活発に行われ、全体を通してとても充実した空気が流れていたように感じます。

最後にグループディスカッションを実施し、各社の事例発表で得た学びや気づき、そして自社が抱える課題について、テーブルごとに意見交換を行い、全体で共有しました。

まとめ

今回のイベントで事務局が特に印象に残ったポイントをまとめました：

• 「内部不正」の定義と目標設定の重要性
  対策を始める前に、「内部不正」の定義を組織内で明確に共有し、どこまでの対策を目指すのか具体的な目標を設定しなければ、効果的な施策は打つことが難しい

• 多部門連携の不可欠性
  内部不正対策は IT 部門だけで完結せず、人事、法務、総務、リスク管理といった複数の部門と連携し、全社的な取り組みとして進める必要がある

• プライバシーとの線引きの難しさ
  従業員の PC ログや操作をどこまで監視するかというプライバシーの問題は、法的な側面と従業員の心理的な側面の両方から非常にデリケートであり、明確な基準を設けることが難しい

• コミュニケーション戦略の重要性
  「監視」や「犯人探し」といったネガティブな印象を避けるため、「保護」や「見守り」といったポジティブな言葉を使い、対策の目的を丁寧に説明するコミュニケーションが不可欠である

• 海外拠点における対策の課題
  各国の法律（特にプライバシー関連）や文化が異なるため、グローバルで統一された内部不正対策を導入することは非常に困難であり、国ごとのカスタマイズが必要となる

参加者の反応

今回は、8割を超える参加者の方から「コミュニティ内での情報交換が役に立った」との回答をいただき、非常に盛況なイベントとなりました。
アンケートでも、「事例発表がためになった」「社内告知のニュアンスがとても参考になった」など、普段はなかなか聞けない他社の取り組みや工夫に関するポジティブなコメントを多くいただきました。

最後に

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

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

▼関西版コミュニティ（対象：マクニカから製品・サービスをご購入いただいているお客様）

▼東京版コミュニティ（対象：マクニカから製品・サービスをご購入いただいているお客様）

▼東海版コミュニティ（対象：マクニカから製品・サービスをご購入いただいているお客様）

こんにちは！セキュリティコミュニティマネージャの福地です！

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

12月に開催したMeetup Vol.3は、「社外向け自社サービスや製品のセキュリティ、情シスとしてどう関わる？」をテーマに15名の方が集まり、各社の製品のセキュリティへの取り組み、課題についてディスカッションを行いました。

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

イベントアジェンダ

• 『オープニング』
• 『事例講演①』
  • 東京海上日動システムズ株式会社　中西 祐介様
• 『事例講演②』
  • GMOペイメントゲートウェイ株式会社　高橋 大輔様
• 『事例登壇③』
  • アズビル株式会社　上田 祐司様
• 『グループディスカッション』
  • 各社の学びや課題の共有
  • 課題についてディスカッショング
  • 発表
• 『クロージング』

テーマ設定の背景

セキュリティは、今や企業の信頼そのものに直結する時代になり、社内システムの安全性を守るだけではなく、自社サービスや製品リリース前後の脆弱性対応や、万一のインシデント発生時の影響を最小化する体制づくりなど多岐にわたります。
一方で、こうした「プロダクトセキュリティ」や「開発セキュリティ」において、

• 情シスはどう関わるのが現実的なのか
• 開発や事業部門をどう巻き込めばよいか
• 対策の優先順位をどう考えるべきか

など、多くの現場で悩みや試行錯誤が続いています。

そこで第3回目の今回は、「社外向け自社サービスや製品のセキュリティ、情シスとしてどう関わる？」と題し、
情シスの立場で実際に取り組む皆さんの考え方や実践を持ち寄り、ディスカッションを行いました。

当日の様子

事例講演では3社の企業様にご講演いただき、自社が提供するサービス、製品に対するセキュリティの開発・運用・製品それぞれのフェーズに対する日頃の取り組みや工夫が共有されました。

どの講演も実例が多く、会場では写真を撮ったりメモを取ったりする参加者が多くいらっしゃいました。開発ではどうスピードと安全を両立するか、運用では続けられる仕組みをどう作るか、製品では企画段階から守りを組み込むといった、それぞれのリアルな工夫が紹介され、参加者の学びにつながるポイントが満載となり、QAも活発に行われ終始前のめりな空気が流れていました。

グループディスカッションでは「学び」「自社の取り組み」「課題・もやもや」について、ホワイトボードに付箋を貼りながら、テーブルごとにディスカッションをしました。

まとめ

今回のイベントで、事務局が印象に残っているポイントを3つにまとめました。

1. 責任と役割を曖昧にしない
   アウトソースの有無にかかわらず説明責任は自社に残る。誰が判断し誰が責任を負うかを企画・設計段階で固定化する。
2. セキュリティは"後付け"にしない
   企画～設計から関与し、SAST/DAST/設計レビューを標準化。チェックリストではなくリスクベースで濃淡を付ける。
3. 運用・出荷後まで守る体制
   事故が起きやすいイレギュラーをワークフロー化・半自動化・監視で抑制。PSIRT等の横断組織で脆弱性対応を継続する。

今回の3つのポイントが、各社それぞれの立場やフェーズに合わせて、自社なりの関わり方を考えるきっかけになればと思います。
私たちのコミュニティでは、こうした悩みや試行錯誤を、これからも皆さんと一緒に共有していきます。

参加者の反応

今回は、9割を超える参加者の方から「コミュニティ内での情報交換が役に立った」との回答をいただき、非常に盛況なイベントとなりました。

アンケートでも「色んな視点での意見を知ることができた」「自社の課題の解決策のヒントを得られた」と言った学びのコメントや、「同じような悩みを抱えているとわかりホッとした」と言ったような安心のコメントなどポジティブなコメントを多くいただきました。

最後に

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

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

▼東京版コミュニティ（対象：マクニカから製品・サービスをご購入いただいているお客様）

▼関西版コミュニティ（対象：マクニカから製品・サービスをご購入いただいているお客様）

▼東海版コミュニティ（対象：マクニカから製品・サービスをご購入いただいているお客様）

本記事では、OT/ICSとITシステムのインシデントレスポンスの違いについて、ランサムウェアのケースを題材とし、マクニカセキュリティ研究センターの柳下が考察します。

 目次

1. OT/ICSシステムのインシデントレスポンスについて
2. ITシステムのインシデントレスポンスについて
3. さいごに

1.OT/ICSシステムのインシデントレスポンスについて

OT/ICSのシステムでは、WindowsやLinuxベースのマシンを使っている場合でも、ベンダーの動作保証範囲では、セキュリティ製品も含めてソフトウェアを自由にインストールすることができません。そのため、OT/ICSの基本的なログとして、次のようなヒストリアンのデータを調査して、いつからどのシステムがどのような手法で侵害されたのかを調査し始めます。

ヒストリアンのデータ例

データログ
Timestamp　　　　　　　　　TagName　　　　　　　Value Quality
2026-01-05 08:00:00.000  PLC1.Pump01.Speed_RPM   1480  Good
2026-01-05 08:00:01.000  PLC1.Pump01.Speed_RPM   1482  Good
2026-01-05 08:00:02.000  PLC1.Pump01.Speed_RPM   1479  Good
2026-01-05 08:00:03.000  PLC1.Pump01.Speed_RPM 　　0 　Bad (Comm Loss)
2026-01-05 08:00:04.000  PLC1.Pump01.Speed_RPM   1481  Good

システムログ
[2026-01-05 07:59:58] INFO  HistorianService: Data collection started
[2026-01-05 08:00:03] WARN  DataCollector: Lost connection to PLC1
[2026-01-05 08:00:04] INFO  DataCollector: Connection to PLC1 restored
[2026-01-05 08:05:12] INFO  ArchiveManager: New archive file created

アラームとイベントログ
Timestamp　　　　　　　　　Alarm Name         　  State    　 Severity　Source
2026-01-05 08:10:15.221  Pump01_HighPressure　ACTIVE    　High　　PLC1
2026-01-05 08:10:45.876  Pump01_HighPressure　CLEARED　High　　PLC1
2026-01-05 08:12:02.114  Tank02_LowLevel 　　　ACTIVE　　Medium  PLC2

ヒストリアンからは、いつ頃からシステムが正常稼働していないのか、どのシステムが最初に停止したのかといった調査を行います。その他に、目視でコントローラや各ホストの画面を見て、ランサムノートから攻撃者を把握します。

昨今のケースでは、ランサムウェアによってログやバックアップデータまで暗号化や消去されるケースが多く、目視できる表示画面の他に開けるヒストリアンがなく、初期調査すら難しいケースも想定されます。また、ヒストリアンがある場合でも、システムの稼働関連のログが中心となるため、どのように侵入してきたのか、暗号化されたファイルを自力で復旧できる可能性があるかといった調査を行う事ができません。そのため、侵害されたホストからディスクやメモリイメージを収集してフォレンジック調査を行い、イベントログのリモートログオンの履歴、ファイルの書き込まれたタイムライン、ランサムウェアの回収と解析などの調査を行って、侵入経路や自力でのファイル復号の可否などを明らかにしていきます。

組織がランサムウェアに侵害されるケースでは、1台のホストのファイルが暗号化されるだけで済むケースはなく、つながったネットワークにあるすべてのホストのファイルが暗号化される傾向にあります。フォレンジック調査の対象とする台数も悩ましいところです。また、昨今ではDX構想のもと、OT/ICSも企業のIT側のネットワークと接続される傾向にあり、攻撃者がIT側のネットワークから侵入した後、OT/ICS側のネットワークにリモートログオンして侵害するケースがあり、次のようなIT側のインシデントレスポンスも必要になる場合が想定されます。

2.ITシステムのインシデントレスポンスについて

Windows/Linux/Macといった一般的な端末について、最近では各ホストにEDRの導入が進んでおり、ネットワークにもトラフィックを監視するNDRが導入されているケースもあり、それらがクラウドにアップロードしたログを調査します。特に、EDRのログからは、どのIPアドレスから、どのユーザアカウントを使って、いつから侵入があり、どうやってランサムウェアが実行されたかといった知見が得られます。

ただし、攻撃も高度化しており、EDRの入っていないホストを狙ってランサムウェアを実行する、EDRでも検出の難しいLOTLで組織内を移動して最後にランサムウェアを実行する、EDR自体を無効にしてEDRログをクラウドにアップロードさせないといった手法で、検出回避や解析妨害をしてくるケースが増えています。また、クラウドにアップロードされたEDRログの保存期間が短く、侵入からランサムウェア実行までの全体像までは調査できないというケースもあります。

NDRが導入されている場合は、EDRのそれら弱点をカバーしてネットワークの視点から侵入経路を調査しますが、それでも調査が難しい場合は、インシデントレスポンスを行っているセキュリティベンダーに調査を依頼します。ベンダーは各ホストで実行できるインシデントレスポンスツールを持っており、組織の端末に対してツールを実行してイベントログやファイル書き込みのタイムライン、ランサムウェアのファイルなどを収集して侵入経路などの調査を行うことができます。各ホストからディスクやメモリイメージを収集するフォレンジックまで至らず、ツールによる情報収集で最終調査まで完了することも多々あります。

3.さいごに

OT/ICS側でのインシデントレスポンスは、ITのインシデントレスポンスと比較して、次のような難しさがあります。

• OT/ICSのホスト端末にセキュリティ製品の導入が難しい
• ITで使うインシデントレスポンスツールが使えない可能性がある
• ヒストリアンは稼働関連のログが中心となるため、侵入経路などの調査には不十分
• ヒストリアンも暗号化される可能性がある

このような難しさに対して、OT/ICSネットワークにIDSなどのネットワークセンサーを設置することで、日常的な攻撃検出に活用するだけでなく、事後に侵入経路の分析といった調査にも活用でき、OT/ICSのインシデントレスポンスの難しさを緩和するソリューションとなっています。

関連ソリューション

Dragos～世界最高峰の脅威インテリジェンス活用型OTセキュリティ～
・Dragos製品紹介資料

・Dragos製品のお問い合わせ

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

生成AI（特に大規模言語モデル：LLM）は、問い合わせ対応、文章生成、開発支援など、業務効率を飛躍的に高めています。しかし、その柔軟性が従来のセキュリティ対策では捉えきれない新しいリスクを生み出しています。
LLMは自然言語で操作できるため、入出力の自由度が高く、従来のWebアプリ診断や脆弱性管理だけでは不十分です。代表的なリスクは以下の通りです。

• Security（セキュリティ）：プロンプトインジェクション、ジェイルブレイク、DoS攻撃など
• Privacy（プライバシー）：機密情報や個人情報の漏えい（プロンプト、ログ、学習データ経由）
• Safety（安全性）：不適切な助言、誤情報、差別的表現など

こうした背景から注目されているのが AIレッドチーミングです。本記事では、その概要とCisco AI Defenseによる実践的な対策をご紹介します。

目次

1. AIレッドチーミングとは？
2. AIレッドチーミングの理想的な実施ステップ
3. Cisco AI Defenseを例にした実践アプローチ
4. まとめ

１．AIレッドチーミングとは？

AIレッドチーミングは、LLMや関連アプリケーションに対して攻撃シナリオを与え、危険な挙動を引き起こせるかを検証する手法です。従来のレッドチーミングがネットワーク侵入や権限奪取などを中心に設計されてきたのに対し、こちらの手法では 入力（プロンプト）と出力（応答）、さらに LLMの周辺（RAG、ツール連携、データ、運用設定）まで含めて評価する点が特徴です。

その中でも、以下のポイントが重要になってきます。

• 一度きりではなく継続的な実施
  LLMアプリは、モデル差し替え・プロンプト改修・RAGデータ更新などで挙動が変わります。
  そのため継続的にレッドチーミングを実施し、回帰（以前塞いだ穴が再発）を防ぐ運用が必須です。
• 自動化の必要性
  手作業で何百・何千もの攻撃プロンプトを作り、応答を評価するのは非現実的であり、自動で評価できるかが鍵となります。

２．AIレッドチーミングの理想的な実施ステップ

AIレッドチーミングは、単なる脆弱性検証ではなく、攻撃者視点でAIシステムの安全性を徹底的に評価するプロセスです。理想的な実施ステップは以下の通りです。

ステップ1：資産の可視化（発見）

まず「何を守るべきか」を明確にするために、AIモデル、アプリケーション、API、学習データなど、関連する資産を棚卸し
社内環境に散在するAI資産を一元的に把握

ステップ2：AIレッドチーミング（検出）

棚卸した資産の中から今後使用予定のAIモデルやAIアプリに対して自動化ツールを活用し、大量の攻撃シナリオを投入して応答を分析
安全性を継続的に評価

ステップ3：運用時の防御（保護）

ステップ2のAIレッドチーミング結果をもとに実稼働環境での攻撃や不正利用を防ぐ
検出された脆弱性に対応したガードレールを設定し、危険な入力や出力をフィルタリングし、リアルタイム監視

こちらの理想的なステップを踏むことで、AIレッドチーミングは単なる検証ではなく、継続的な安全性確保の仕組みとして機能します。
次の章では、AIレッドチーミングの具体的な製品を例に出しながら、詳細を説明します。

３．Cisco AI Defenseを例にした実践アプローチ

Cisco AI Defenseとは？　-「発見 → 検出 → 保護」をつなぐ統合アプローチ

Cisco AI Defenseは、企業のAI活用におけるセキュリティ課題を解決するためのソリューションです。
特徴は、次の3つのコアコンポーネントを土台に、「発見 → 検出 → 保護」というAIセキュリティプロセスをカバーできる点です。

• AI Cloud Visibility（発見）：
  クラウド環境に存在するAI資産（モデル/エージェント等）を把握し、管理する機能
• AI Model & Application Validation（検出）：
  アルゴリズム的なAIレッドチーミングで、モデル/アプリの安全性・セキュリティ上の脆弱性を迅速に特定する機能
• AI Runtime Protection（保護）：
  運用時にガードレールを適用し、敵対的攻撃や危険な入出力をリアルタイムにブロックする機能

本記事では、AIレッドチーミングに関わる機能である、AI Cloud Visibility、AI Model & Application Validationに焦点を当てて、ご紹介します。AI Runtime Protectionの紹介については、『生成AIの安全運用を支える「LLMガードレール」』をご参照ください。

AIレッドチーミングを支える2つの機能

1) AI Cloud Visibility：まず"見えないAI資産"をなくす

AI Cloud Visibilityは、分散するクラウド環境にまたがってAI資産の棚卸し（インベントリ）と利用状況の可視化をすることで何を守るかを明確にし、可視化ギャップを解消します。

• AI Cloud Visibilityによって可視化された資産の情報
  

後述のAI Validationの実行を本画面から実行することもでき、「発見 → 検出 」というフローをスムーズに実行することが可能となります。

2) AI Model & Application Validation：アルゴリズムレッドチーミングによる脆弱性発見

この機能は、攻撃シナリオを大量に自動投入し、モデルやアプリの脆弱性を短時間で特定します。単なる危険ワード検出ではなく、実際の攻撃パターンを想定したテストが特徴です。

• AI Model & Application Validationで使用される攻撃シナリオのカテゴリの例
  

こちらのシナリオをもとに1,000以上の敵対的なプロンプトを対象モデルに自動投入し、その出力結果からモデル/アプリの安全性・セキュリティ上の脆弱性を評価します。

• AI Model & Application Validationを実行結果の画面
  

モデルのもともとのガードレール能力を診断したうえで、AI Runtime機能で補強すべき箇所を可視化し、どの部分に対応すべきかを明確にしてくれます。

４．まとめ

LLM活用が進むほど、AIは「便利な道具」であると同時に「新しい攻撃面」になります。プロンプトインジェクションやジェイルブレイク、情報漏えいといったAI特有の脅威は、従来のセキュリティ対策だけでは捉えにくく、AIレッドチーミングによる実践的な検証が重要になります。

さらにLLMアプリは、モデル・プロンプト・データの更新が短いサイクルで発生し得るため、評価は"一度きり"ではなく 継続的に回す運用が現実的です。
その意味で、手動評価だけに依存するのは難しく、自動化されたレッドチーミングと、運用時のガードレールを組み合わせた多層防御が鍵になります。

▼Cisco AI Defenseについての詳細は、こちらの動画をご視聴ください。（クリックすると動画視聴サイトへ飛びます）

クラウド活用が急速に拡大する一方で、ランサムウェアを始めとするネットワーク侵入型攻撃は年々巧妙化し、従来のEDRなど事後検知型のセキュリティ対策だけでは対応が困難になってきています。
昨今、セキュリティの世界では「検知から予防へ」のパラダイムシフトが起きており、攻撃が成功する前にリスクの芽を摘む"プロアクティブ"なアプローチが注目されています。その中核となるのが、CTEM（持続的脅威エクスポージャー管理）というセキュリティフレームワークです。
本記事では、なぜCTEMが必要なのか、そしてクラウド環境においてCTEMを適用する実践的な取り組み方について詳しく解説します。

目次

• ランサムウェア攻撃の現状と脅威の変化
  　猛威を振るうネットワーク侵入型攻撃
• 従来型セキュリティからプロアクティブセキュリティへ
  　リアクティブからプロアクティブへのシフト　
  　対処すべきリスクの絞り込み基準
• CTEMによる継続的脅威エクスポージャー管理
  　CTEMの5つのプロセス
  　CTEMを実現するソリューション分類
• クラウド環境に特化したCTEMソリューション：CNAPP
  　Wizによるクラウドセキュリティの実現
  　Wiz Security Graphによるアタックパス解析
  　Wizの実運用における効果

ランサムウェア攻撃の現状と脅威の変化 

猛威を振るうネットワーク侵入型攻撃

「情報セキュリティ10大脅威2025」において、ランサム攻撃による被害は5年連続で1位の脅威として君臨し続けています。その原因となっている脆弱性悪用、サプライチェーン攻撃、VPN機器への攻撃も上位にランクインしており、これらすべてがネットワーク侵入型攻撃の一環として位置づけられます。

現在のランサムウェア攻撃には、明確な3つの特徴があります。まず「脆弱性を突いた侵入」により、外部公開機器、海外拠点・工場、関係会社・サプライチェーン、そしてクラウドの脆弱性から侵入を試みます。次に「巧妙な横展開と拡散」により、内部ネットワークでラテラルムーブメントを展開し被害を拡大します。最後に「検知製品の回避・無効化」により、EDRを回避しつつ認証・ID侵害を実行し、広範囲な侵害を引き起こします。

特に注目すべきは、「脆弱性を突いた侵入」が近年も継続的に高い割合を占めていることです。"クレデンシャル侵害"なども新しく増加していますが、新しい脆弱性が年間4万件近くも公開されており（出典：Open CVE Statistics）、脆弱性対策の重要性は決して軽視できない状況が続いています。また、すべての脆弱性に対処することは技術的にも現実的にも不可能ですが、実際に悪用されるのは全体の数％であり、いかに対処すべき脆弱性を見極め、効率的に絞り込むかが重要な課題となっています。

従来型セキュリティからプロアクティブセキュリティへ

リアクティブからプロアクティブへのシフト

従来のセキュリティアプローチは、侵入された脅威をいかに事後で検知するかという「Detection（受動的な脅威検知）」に重点が置かれていました。しかし、現在求められているのは「Discover（能動的なリスク可視化と予防）」です。

脅威が発生してから対応する有事のセキュリティから、脅威になるリスクの芽を事前に摘む平時のセキュリティへの移行が、現代のセキュリティ戦略における最重要テーマとなっています。「NIST サイバーセキュリティフレームワーク」の5つの機能（識別・防御・検知・対応・復旧）のうち、特に「識別」の段階でリスクを可視化し、予防的な対策を講じることの重要性が高まっています。

対処すべきリスクの絞り込み基準

膨大な脆弱性情報の中から真に対処すべきリスクを特定するには、以下の3つの観点が重要です。
まず「脅威性の評価」として、深刻な脆弱性かどうか（CVSS）、悪用が確認されているか（KEV）、悪用される可能性があるか（EPSS）、脅威インテリジェンスで言及されているか（TI）を確認します。
次に「到達可能性の分析」として、外部に露出しているか（EASM）、到達する経路があるか（攻撃経路分析）、実際に攻撃が成立するか（Validation）を検証します。
最後に「資産の重要度判定」として、事業停止に直結するシステムかどうか（資産分類機能・CMDB連携の活用）を評価し、最優先で対処すべきリスクを特定します。

CTEMによる継続的脅威エクスポージャー管理

CTEMの5つのプロセス

CTEM（Continuous Threat Exposure Management：継続的脅威エクスポージャー管理）は、脆弱性・設定不備などあらゆるエクスポージャーを洗い出し、優先順位を付けて対処するフレームワークです。以下の5つのプロセスで構成されます。

1. Scoping（範囲設定） - 管理対象とする範囲を設定
2. Discovery（検出） - 資産とエクスポージャーを可視化・検出
3. Prioritization（優先順位付け） - 脅威となるエクスポージャーの優先順位付け
4. Validation（検証） - 攻撃者目線からの攻撃可能性を検証
5. Mobilization（動員） - 危険な脆弱性・露出に対処

重要なのは、単に脆弱性を発見するだけでなく、実際にその脆弱性を突いて脅威が到達するかどうかを検証し、問題があれば適切に態勢を改善することです。仮説ではなく、本当にその脆弱性に至る攻撃経路が存在するかを確認した上で、パッチ適用などの対策を実施します。

CTEMを実現するソリューション分類

現在、CTEMを実現するためのソリューションは、対象となる資産によって以下のように分類されます。

外部公開資産に対してはEASM（External Attack Surface Management）により、外部公開機器のリスクを把握します。PC・サーバー機器などの内部資産に対しては、エージェントスキャンやUEM/EDR/VAによる端末管理・脆弱性管理を実施します。IT/OT/IoT機器に対しては、エージェントレススキャンによる可視化を行います。そして、クラウド環境に特化したCTEMソリューションとしてCNAPP（Cloud-Native Application Protection Platform）があります。

クラウド環境に特化したCTEMソリューション：CNAPP

CNAPPは、クラウド環境全体を横断的に可視化し、脆弱性、設定ミス、ID権限、外部公開、機密データといった複数のリスク領域を統合的に管理するためのプラットフォームです。

CNAPPはこれらの機能を一つに統合しますが、単にツールをまとめるだけではCTEMは成立しません。

CTEMの観点でCNAPPに求められるのは、アラートの数を減らすことではなく、複数のリスクが連鎖した結果、攻撃が成立するかどうかを見極めることが不可欠です。
この条件を満たして初めて、CNAPPはクラウド環境におけるCTEMソリューションとして機能します。

Wizによるクラウドセキュリティの実現

クラウド領域でCTEMを実現するソリューションとして、今回はWizをご紹介します。

Wizは2020年に米国で創業されたクラウドセキュリティ企業で、2024年に日本法人を設立した最新のCNAPPソリューションです。

従来のクラウドセキュリティでは、CSPM（設定ミス）、脆弱性スキャン、ASM（外部公開）、CIEM（ID権限）、DSPM（機密情報）などが個別のツールで提供され、リスクがバラバラに可視化されるだけで大量のアラートにより運用が困難でした。

Wizは、これら多様なリスクを相関分析・優先順位付けし、本当に脅威に発展するリスクだけを提示する「Security Graph」という技術を持っています。この技術により、複数のリスクが相関関係にある場合に、それらを一つのクリティカルなイシューとして統合し、効率的な対処を可能にしています。

Wiz Security Graphによるアタックパス解析

上述の通り、Wizの最大の特徴は、Security Graphによる攻撃経路の自動分析機能です。クラウド上の様々なリスクを相関分析して、攻撃が実際に成り立つ経路を発見します。

例えば、インターネットに露出した仮想マシンに高リスクな脆弱性があり、かつ過剰な権限が設定され、その先に機密データベースが存在する場合、これらの個別リスクを一つの攻撃経路として可視化します。このアタックパス解析により、数万件の脆弱性アラートが数十件の真に対処すべきイシューに自動的に絞り込まれ、セキュリティ担当者は優先的に対処すべき箇所を迅速に発見できます。

Wizの実運用における効果

これまで、検知された脆弱性や設定ミスの優先順位付けのために、人間が一つ一つアラートの内容を確認していたものが、Wizであれば自動的に優先順位付けを実現することが可能です。実際の運用では、従来であれば数千から数万件のセキュリティアラートが発生していた環境で、Wizの導入により管理可能な件数まで自動的に絞り込まれた事例が報告されています。これは、単純にアラート数を減らすのではなく、本当に攻撃経路が成立している重大なリスクのみを抽出した結果です。

さらに、各イシューに対しての細かな説明や、AIによる攻撃手法やビジネス影響の解説、具体的な修正手順を自動提示の機能があります。複数の対処法（パッチ適用、公開設定変更、データ削除等）から最適な選択肢を提案します。これにより、セキュリティ専門知識を持たない開発・運用担当者でも直観的に対処を実行できる環境が実現されています。

最後に

クラウド環境の複雑化に伴い、従来の個別対応型セキュリティでは限界が見えています。CTEMというフレームワークに基づき、プロアクティブなセキュリティアプローチを採用することで、真に危険なリスクに効率的にフォーカスできるようになります。15世紀の思想家エラスムスの「予防は治療に勝る」という言葉が示すように、可視化してリスクの芽をあらかじめ摘むことの重要性は、現代のサイバーセキュリティにおいても変わることはありません。

CTEM実現のためのご質問や、ご紹介したWizの詳細な情報や導入支援については、是非お気軽にご相談ください。 

関連ソリューション

Wiz ～1つのプラットフォームでクラウド環境を包括的に保護するCNAPP～

• Wiz製品紹介資料はこちら
  
• 15分で知る！Wiz製品紹介動画はこちら
  
  
  
• Wiz製品のお問い合わせ
  
  
  
• クラウドセキュリティの最新動向・市場トレンドについて

こんにちは！Tanevaコミュマネの引野です。
マクニカでは、企業のセキュリティを担う方々が集まるコミュニティ「Taneva（タネバ）」を運営しています。

2025年11月12日、Tanevaにとって最初の一歩となるMeetupが、渋谷ソラスタコンファレンスで実現しました。

テーマは、「企業変革を支えるセキュリティへの挑み方 」。業界を代表するリーダー達と「現場とトップの融合」について熱く議論しました。同じミッションを持つ仲間が集まるコミュニティだからこその知恵や経験の共有、そして意見のぶつけ合い。
その熱量に私自身も圧倒され、学びと興奮が止まらない3時間となりました。このブログを通して、当日の熱気を少しでもお届けできたらと思います！

　Meetupの詳細：https://go.macnica.co.jp/Entry-MNC-CSSCU-Community-20251112-TanevaVol1.html　

目次

• 「Taneva」とは？
• なぜ「現場とトップの融合」をテーマにしたのか？
• 現場とトップが融合するには？
• メディアを鵜呑みにしない情報収集のやり方
• 懇親会の様子

「Taneva」とは？

「Taneva」は、TaneとValueを掛け合わせた造語で、コミュニティで生まれた新しいタネが新たな価値へと成長する、そんな場所を作りたいという想いで名付けたコミュニティとです。
Tanevaの企画が始まったのは、約1年前。ユーザーさん達とどんなコミュニティにしていくのがいいか、どんなテーマを扱おうか、と色々議論している間にあっという間に1年がたってしまった、という感じです(笑)

なぜ「現場とトップの融合」をテーマにしたのか？

すべては、あるコミュニティメンバーからの、悲痛とも言える叫びがきっかけでした。

「現場はインシデントの種を見つけるだけでも必死なんです。なのに、経営層はその価値を評価してくれない。そもそも、私たちが何と戦っているのかさえ分かっていない」 

この言葉は、私たちが日頃コミュニティを運営する中で、肌で感じていた「大きな課題」そのものでした。

組織としてCISOを擁し、全社一丸となってセキュリティに取り組めている企業は、日本ではまだほんの一握り。現実は、特定のセキュリティエンジニア個人のスキルと責任感に、過度に依存してしまっている......それが日本の現状ではないでしょうか。

経営層と現場が見ている景色は、決定的に異なります。
事業に対する視座、時間軸、そして持っている情報とその背景、これらが異なるからこそ、両者の間には深い認識のギャップが生まれ、断絶が起きてしまいがちです。 

そのギャップのせいで、現場が孤独な戦いを強いられる現状を変えたい。
経営層と現場が、互いの見ている景色を理解し合い、組織としてセキュリティの「本質」を議論できる未来を作りたい。その想いが、今回のテーマへと私たちを突き動かしました。

現場とトップが融合するには？

記念すべき最初のセッション。そこで問いかけたのは、現場と経営の間に横たわるコミュニケーションの深い溝を、いかにして飛び越えるかというテーマでした。
経営層から不意に説明を求められた時の「守り」の局面、そして、投資を引き出すために自ら経営を動かしにいく「攻め」の局面、この2つのシチュエーションで、経営層は一体何を求め、現場はどう対応すべきなのか？
実際の経営を担う立場の方と、現場で活躍されるセキュリティ担当の方にご登壇いただき、セッションを進めていきました。

セッションをぎゅっと凝縮すると、以下の３つのポイントにまとめられます。

経営層が求める情報

まず突きつけられたのは、「共通言語」を持つことの重要性です。
経営層の頭の中には常に「KPI（重要業績評価指標）」があります。何かが起きた時、彼らが真っ先に知りたいのは技術的な詳細ではなく、「ビジネスのKPIにどう影響するのか？」という一点です。だからこそ、現場はその文脈で語らなければなりません。
もし指標が存在しないのなら、そこで諦めるのではなく、経営側と膝を突き合わせ、KPIそのものを共に創り上げることが大事です。それは、事業運営のステークホルダー全員が同じ前提で議論するための「軸」となり、組織が一丸となって同じ方向へ向かうための「道標」となるからです。

そしてもう一つ、経営層が求めているのは「戦場のリアル」です。
定期報告ではKPIの進捗だけではなく、今まさに自社で受けている攻撃の兆候を伝えることも大切です。
「どの拠点が狙われているのか」「どんな攻撃が仕掛けられているのか」。たとえインシデントに至っていない水面下の攻防であっても、その事実を正確に伝えていきましょう。
敵がどこを狙っているのかを明らかにすることこそが、次の投資をどこに重点的に配備すべきか、経営陣が正しい決断を下すための、重要な情報源となります。

経営層と現場がコミュニケーションする機会は、様々な場面であります。ここまで述べてきたように、「お互いの共通言語を持つこと」「戦場のリアルを伝えること」、それに加えて「確かな情報を伝える」ということも、経営層と現場のコミュニケーションにおいては、大事な要素になります。特に非常時においては、混沌とした状況の中で、事実と憶測を見極め、正しい情報を経営に伝えていく。そこに脚色は不要です。まずは確実な事実を、そして、状況が動けば即座にアップデートしていく。いざという時の密なコミュニケーションが、その企業のセキュリティを一枚岩にし、企業の危機を救います。そのための信頼関係を平時から積み上げておくことが経営層と現場、双方において重要だと感じました。

経営層を動かすための3つの武器

・対策の必要性を、経営層がわかる言葉で説明する
・自社の事業特性から、守るべきことの優先順位を決める
・発生可能性、被害時のインパクトを定量化して伝える
　例：工場の稼働停止が 2カ月続いたら売上損失はいくらか
　例：顧客の情報が漏えいしたら、取引停止の金額損失はいくらか

日々、脅威と対峙し続ける現場の人達には、組織のあらゆる「綻び」が見えています。
「やれることは全部やりたい！」
それは、責任感が強ければ強いほど湧き上がる、偽らざる本音でしょう。

しかし、現実はシビアです。情熱のままにすべてを網羅しようとするだけでは、「知恵がない」と判断されてしまう。
そこで必要となるのが、「優先順位」です。
自社の事業特性というフィルターを通し、リスクを定量的に見積もる。そして、経営層に届く「投資対効果」という共通言語に翻訳して伝えることこそが、現状打破の突破口となります。

「リスクの数値化なんて難しい」----その通りです。だからこそ、IT部門だけで孤独に戦ってはいけないのです。
経営企画やリスク管理部門、あるいは最前線の営業や生産部門へ。
自ら足を運び、密に連携し、泥臭く情報を集める。部門の壁を越えて味方をつけるコミュニケーションこそが不可欠です。気の遠くなるほど地道な作業ですが、そこまでやるからこそ人と組織、経営は動くのだと思いました。

百聞は一見にしかず、百見は一行にしかず

もし、経営層がセキュリティに関心を示さない時は、実際に体験してもらうのが効果的かもしれません。実際にセキュリティインシデントを起こしてみて、対応をシミュレーションしてみる。かなり荒業ではありますが、「自社がどれだけできていないか」を経営層に体験してもらうことで、セキュリティへの感度があがるのではないか、という議論で最初のセッションは締めくくられました。

メディアを鵜呑みにしない情報収集のやり方

情報過多の時代において、日々膨大な情報が流れてきますが、その中には誤った情報や過剰な誇張も少なくありません。適切な情報を適切なタイミングで入手し、それを適切なアクションに結びつけるために適切に処理するということが求められています。
本セッションでは、セキュリティ担当者としてどのように情報を収集し、どのように正確な判断を下すのかについて、実践的な方法やツール活用の工夫を中心にお届けしました。

セッションをぎゅっと凝縮すると、以下の３つのポイントにまとめられます。

信頼できる情報源は？

さまざまな情報が出回る中、特に重視すべきは、「in-the-wild」つまり実際に攻撃が発生している情報です。これは脅威として嘘をつきません。さらに、複数のセキュリティベンダーから同時多発的に情報が出てきたら、「遅かれ早かれうちにも来るな」と警戒レベルを上げると先回りした対策につながるのではないでしょうか。煽るタイトルの記事は特に、信ぴょう性を確認しましょう。

＜ポイント＞
・煽る見出しの記事は外れやすい、リサーチャー発の新種の攻撃手法も注意が必要
・脆弱性悪用事例や複数ベンダーによる注意喚起は警戒レベルをUPしよう
・情報収集を続けるうちに、読む価値がある/ないのノウハウは蓄積される

AI活用

情報収集にAIを活用する方も多いのではないでしょうか。昨今のツールは、情報の網羅性も申し分ない精度になってきています。ただし、分析してインサイトを出すことはまだまだ人間の判断が必要な部分です。単純作業だけ任せるなど、工夫して活用できると良いかもしれません。

 ＜ポイント＞
・収集能力に関しては8-9割の網羅性が出せる
・しかし、インサイト抽出は人間の判断が必要

情報整理の仕方

情報収集をするといっても、どこからやればよいか困っている方も多いかもしれません。セッションでは、マクロ情報（法令・ガイドライン・トレンドなど）と、ミクロ情報（ソリューション）に分けて整理する方法が紹介されました。パネラーの皆さんからは、ベンダーからの情報だけに頼るのではなく、同業他社の取り組みを把握することで、経営層への説明材料として役立てているという声もありました。その際のポイントとして強調されていたのは、単に「どの製品を使っているか」を聞くだけでなく、導入の背景や環境まで含めて情報交換すること。そうすることで、自社の環境に本当に適した選択肢を見極めやすくなるという点です。

また、他社の取り組みや実情は、普段なかなか表に出てこない情報でもあります。だからこそ、Tanevaをはじめとしたコミュニティを活用し、実践者同士で知見を共有する場を持つことで、より良い意思決定につなげていただければと思います。

＜ポイント＞
・事実と推測、憶測を仕分ける
・技術動向は、マクロ（トレンド）とミクロ（ソリューション）に分けて整理し、同業他社の動向も把握する
・情報量の多いガイドラインなどは、自分で要約してブログに残すとポイントが覚えられる

アウトプットする情報を活用してもらうためには？

整理した情報の中には不確かな情報が含まれることもあると思います。実はそれも伝え方次第。しっかりと確認したうえで確かな情報だけを伝えるのも一つの手ですが、「不確かな情報です」と前置きしたうえでスピード重視で小出しに情報共有するという手もあるかもしれません。

＜ポイント＞
・真偽不明だが広く出回ってしまっている情報については、「不確かな情報です」と明言した上で共有することで振り回されることを避ける
・「何かあればこの人に聞けばOK」と思ってもらえるように、社内関係者との信頼を地道に積み重ねておく（信頼貯金）
・貯金が足りない場合は、信頼できる人の名前と言葉を借りる

他社のインシデントニュースが起きた際、経営層から「うちは大丈夫なのか？」と問われる場面も多いのではないでしょうか。そんな時の情報収集の仕方、伝え方など、ぜひ皆さんも参考にしてみてください！

懇親会の様子

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

リソース不足への対処、経営層の理解を得る難しさ、インシデント発生時の対応など、立場や企業規模を超えて、同じ悩みを持つ仲間同士がつながり、具体的なアドバイスが飛び交う時間になりました。

最後に

「経営層にわかる言葉で会話をすることが一番大事」「人間は見たいものだけ見る」「信頼貯金を積む」など、この日、会場で交わされた言葉の一つ一つが、参加者の心に残ったのではないでしょうか。
すべては行動に移してこそ意味があるもの。ただセキュリティを語り合う場ではなく、マニュアルには載っていない、実践者だからこそ語れるリアルな知見を共有し合い、行動につなげていくことができる。そして、失敗しても同じ悩みを持つ仲間と励まし合い、成功に向けて共に切磋琢磨する場所。それがTanevaです。

冒頭でもご紹介しましたが、Tanevaという名前には、ここで共有されたアイデアが未来への種となり、参加者の活動を通じて価値に変わっていくという願いが込められています。今回のMeetupで得た学びが、皆様の組織で花開き、大きな価値を生み出すことを心から願っています。

次回の開催情報は、マクニカのウェブサイトおよびSNSでお知らせいたしますので、ぜひチェックしてみてください♪

▼Taneva公式サイトはこちら