脆弱性診断は受けたけれど ― SSVCで考える「脆弱性管理」と優先順位付け

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

~とある会社Aと脆弱性診断の結果を受け取った関係者とのやり取り~

脆弱性診断を受けたA社では入社3年目のセキュリティ担当・Bさんが結果に頭を抱えています。なぜなら、社内ネットワークに使っているスイッチにCVSSスコア9.8の脆弱性、リモートアクセスに使用しているVPNゲートウェイにCVSSスコア8.8、オンラインショップ用の受発注管理に利用しているデータベースにCVSSスコア7.5の脆弱性が見つかってしまったからです。リスクはどれも「高」レベルとして報告されたため、Bさんは上司に相談し、すべてに修正パッチを当てるようスイッチとVPNゲートウェイについてはインフラチームの担当者に、データベースについては開発部に連絡することにしました。

インフラチームのCさんとSlackでやり取りをしていたBさんはCさんからこんなことを伝えられます。

インフラチームCさん「修正パッチを適用するとなると、インフラチームは基本みんなリモートだから、誰かを土日のどこかで休日出勤させるか、急ぎだったら平日の夜間に勤務させて、パッチを当てることになるけど、どれぐらい急ぎなの?」

「あと、VPNとスイッチ、どっちを先に作業したほうがいいの?パッチの情報を調べてみたら、VPNのほうは一度途中のバージョンまで上げてから最新バージョンまで上げないといけないみたいで、作業時間がすごくかかりそうだから、別日で作業しないとだめかもしれないんだよね」

Bさんは答えに詰まってしまいました。リスクレベルは高だといわれているけれども、どれぐらい急ぐのかは誰も教えてくれないからです。

答えに詰まって「確認してから折り返し連絡します」と返したところ、「セキュリティ担当はいいなあ。土日とか夜間に作業しなくていいし、すぐに答えなくてもいいんだから」と嫌味までいわれてしまいました。

Bさんは脆弱性診断の結果が返ってきてから1週間後、開発部門のD部長にセキュリティ担当と開発部門の定例会議の際に報告事項としてパッチ適用の件を報告しました。するとD部長はこういいました。

開発部D部長「この件、1週間ほど報告に時間を要したようですが、脆弱性診断の結果以外に何か追加の情報はありますか?あと、この脆弱性診断の結果によるとリスクレベル高とありますが、社内の規定としてどの程度急ぐかといった判断はされましたか?」

開発部のほかの人にもこんなことをいわれてしまいます。

開発部担当者「パッチを適用する場合、ステージング環境で影響を調査したうえで必要であればコードや設定の修正などを行う必要がありますが、その時間や工数は考慮されていないですよね。通常の開発業務とどちらを優先すべきかといった判断はどうなっているんですか?」

Bさんはまたもや言葉に詰まってしまいます。セキュリティ担当は自分と上司の2人だけ、上司は別の業務との兼務でパッチの適用の優先順位付けまで考えている時間はありません。自分もEDRやファイアウォールの運用をしながら脆弱性診断の依頼や結果を受け取るだけで、とても他の部門の業務内容や環境のことまで把握しきる余裕がないのです。


ここまで、架空の会社A社と脆弱性診断の結果を受け取った関係者の反応を物語形式でお送りいたしました。現在、弊社の脆弱性診断サービスでは脆弱性単体のリスクの度合いの結果をご提供させていただくことはあっても、その脆弱性をどういった優先度で修正しなければならないかといった情報はご提供しておりません。なぜならば、パッチを適用するにあたって優先順位をつけるためにはお客様しか知りえない、以下の要素が必要になるためです。

パッチ適用の優先順位をつけるための3つの要素

  1. 脆弱性を持つアセットが置かれている環境
    ・インターネット上で公開された状態か、IPSやFWなどで制御されたネットワーク内か、もしくはローカル環境依存といった非常に限定的な環境かといった分類
    ・CVSSでいう環境スコア(CVSS-E)の攻撃区分(MAV)にあたる、実際の環境依存の要素
  2. アセットが攻撃を受けた場合に事業継続性に与える影響
  3. アセットが攻撃を受けた場合に社会や社内(運用保守・人材)に与える影響

冒頭のA社のケースでは以下のように整理できるでしょう。

アセットが置かれている環境

  • VPN:インターネット上で公開された状態
  • データベース:設定を間違っていなければIPSやFWなどで制御されたネットワーク配下だが、公開ネットワーク寄り
  • スイッチ:設置環境によって制御されたネットワーク内かローカル環境になる。

アセットが公開されている場合、攻撃者からよりアクセスしやすいことからより緊急度が高いといえるので、VPN=データベース>スイッチの順になると考えられるでしょう。

アセットが攻撃を受けた場合に事業継続性に与える影響

アセットが攻撃を受けた場合に自社の事業継続にどの程度影響が出るかといった要素です。
仮にランサムウェア攻撃によって影響を受けた場合、それぞれのアセットの停止でどの程度の影響が出るかを想定してください。A社の場合事業継続性への影響度順でいうと、データベース>VPN>スイッチの順になると考えられます。

今回の場合はデータベースが事業に直結しており、顧客情報を含むデータを持っているため、継続性への影響度が高いという想定です。アセットの利用目的や環境によってはこの順番が入れ替わることもあります。

アセットが攻撃を受けた場合に社会や社内に対して与える影響

A社がランサムウェア攻撃を受けた場合はオンラインショッピングサイトのデータベース関連で以下の影響が見込まれます。

  • 顧客情報の漏洩
  • 運用およびシステムの復旧にかかる費用と工数

このほかにVPNやスイッチもフォレンジック調査の対象となって業務が行えなくなる可能性が高いと考えられます。VPNに関しては利用できない期間、社員の出社が必須になるなどワークスタイルへの影響も出る可能性もあります。こういったことから、社会および社内に対して与える影響でA社の例を考えると影響度は、データベース>VPN=スイッチと考えられるでしょう。

SSVCとは

こうした情報があったうえで利用ができようになる優先順位付けの方法があります。それが「SSVC(Stakeholder-Specific Vulnerability Categorization)」です。SSVCは脆弱性管理プロセスに関与する利害関係者のニーズに基づいて脆弱性に優先順位を付けるための方法論とされており、経営・マネジメント層、システム開発者、システム運用者といったステークホルダーと一緒に脆弱性に対処していくための方法論といえます。SSVCは脆弱性そのものの技術的評価ではなく、脆弱性にどのように対処するかという観点での評価を行うフレームワークになります。

SSVCの3つのモデル

  1. ソフトウェアやハードウェアの供給者、すなわちパッチを開発する人が用いる「Supplier Decision Model
  2. ソフトウェアやハードウェアを利用する側、つまりパッチを適用する人が用いる「Deployer Decision Model
  3. CSIRTやPSIRT、セキュリティ研究者やBug Bounty Programなど、脆弱性に対して何らかの調整やコミュニケーションのハブとなりうる人、コーディネーターが用いる「Coordinator Decision Model

このうち、「Deployer Decision Model」と「Supplier Decision Model」ではプライオリティ(対応優先度)付けの結果を4つにわけています。

SSVCで得られるプライオリティ付けの結果

Deployer ModelSupplier Model
Immediateすべてのリソースを投入し、通常業務を止めてでもパッチの適用を直ちに行うべきである全社的にすべてのリソースを投入して修正パッチを開発し、リリース
Out-of-cycle定期的なメンテナンスウィンドウより前に、やむを得ない場合は残業を伴う形で緩和策または解消策を適用緩和策または解消策を他のプロジェクトからリソースを借りてでも開発し、完成次第セキュリティパッチとして修正パッチをリリース
Scheduled定期的なメンテナンスウィンドウで適用通常のリソース内で定期的な修正パッチのリリースタイミングでパッチをリリース
Defer現時点で特に行うことはない現時点で特に行うことはない

ここではDeployer Decision ModelをもとにA社がどのようにパッチを適用すべきか検討してみましょう。

まず、Bさんは上司に相談したうえで、前述した3つの要素、「脆弱性を持つアセットが置かれている環境」、「事業継続性への影響」、「社会や社内への影響度」を定義していく必要があります。また、この定義に当たっては実際の環境や利用用途、部門内のリソースなどをよく知っているインフラチームや開発部といった当事者、つまりステークホルダーの関与(少なくとも承認)が必要となってきます。このほかに優先順位付けの結果、”Immediate”や”Out-of-Cycle”が出た場合の対応プロセスも用意しておく必要があります。Bさん1人で何かできることはそれほど多くはなく、社内のステークホルダーへの聞き取りや経営層への説明、必要なプロセスの準備と合意形成など、上司や部門全体も含めて組織的に取り組まなければならないといえます。さらに、Bさんは脆弱性自体が持つ以下の要素を調べる必要があります。

脆弱性が持つ要素

自動化の可能性

攻撃者がツール化して脆弱性を悪用するかどうかを判定するものとなります。これは攻撃者がツール化した場合、攻撃者間でツールの売買が行われるなど汎用的に悪用される可能性があるため、把握が必要な要素となります。一部の脆弱性はCISA VulnrichmentやCVSS4.0のSupplement MetricsのAutomatableの値が参照できますが、情報の参照先がないものについてはPoCの有無やPoCの内容から自動化の可否を判断する必要があります。この点はSSVC利用の難点として挙げられることもあります。

悪用の状況

実際に攻撃されていることを示すActive、PoCのみを示すPoC、悪用されていないことを表すNoneの3つに分類されます。この情報は時間の経過とともに変化する可能性が最も高く、逐次状況を確認する必要があります。情報の参照先は、KEVカタログ、CISA VulnrichmentのExploitationの値、CVSS4.0のThreat MetricsやNVDのReferenceのPoCの有無といったものが利用できます。唯一難点があるとすれば、日本国内でシェアの高い国内メーカー機器の情報がKEVカタログやCISA Vulnrichmentなどにあまり反映されない点にあります。

まとめ ~CVSSとSSVCの活用~

これまではCVSSが高い値のものだけ対処していた、という組織も多いでしょう。CVSSは脆弱性の単体評価ができ、脆弱性が広く悪用された場合の深刻度を測るための評価システムです。ただし、その脆弱性が存在するアセットがどのように利用されているか、そのアセットが業務継続性や運用保守、ひいては社会全体に対してどのような影響を与えるかといった観点が欠けていることが長らく問題視されてきたのも事実です。

脆弱性管理は手間がかかる、登場人物が多い、意見がまとまらないといったこともあるでしょうし、「自動化の可能性とかわからないし、攻撃の状況をずっと見ているほどの時間の余裕はない!」といった様々なお声があるかと思います。しかし、今この瞬間どの企業がいつサイバー攻撃を受けるのか全く見当もつかない状況の中、少しでもリスクを回避したい、どこにリスクがあるのか手がかりをはっきりしておきたいという企業の皆さまもいらっしゃるかもしれません。本記事を通じて、こういった脆弱性管理手法があることを知っていただき、活用することでリスク回避ができるようになるための役立つ情報提供となれば幸いです。

参考情報:


公開日:2024年9月10日
更新日:2026年5月13日

編集責任:木下

Security NEWS TOPに戻る
バックナンバー TOPに戻る

サイバーインシデント緊急対応

サイバーセキュリティ緊急対応電話受付ボタン
SQAT緊急対応バナー

ウェビナー開催のお知らせ

最新情報はこちら

Youtubeチャンネルのご案内

SQATチャンネル(@sqatchannel9896)では毎月、アナリストが語る「セキュリティトピック」解説動画やウェビナー動画を更新しています。 ぜひチャンネル登録をして、チェックしてみてください。


資料ダウンロードボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
お問い合わせボタン
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像

情報漏洩対策とは何か ―企業が知るべき原因・リスク・防止策の全体像―

Share

情報漏洩対策とは何か ―企業が知るべき原因・リスク・防止策の全体像―アイキャッチ画像

情報漏洩対策は、単にウイルス対策ソフトを入れたり、アクセス制限を強めたりするだけでは不十分で、「何が漏れるのか」「なぜ起きるのか」「起きたときに何が起きるのか」「どう防ぐのか」を分けて整理することが重要です。なぜならば、実際の情報漏洩は不正アクセスのような外部からの攻撃だけでなく、誤送信や設定不備、委託先での事故など、日常業務の延長線上で発生することが少なくないためです。

個人情報保護委員会は、漏えい等事案への対応体制の整備や定期的な点検、見直しの必要性を示しており、IPA(独立行政法人情報処理推進機構)でも企業の情報セキュリティ対策を経営課題として継続的に進める必要があるとしています。本記事では、情報漏洩対策の全体像や基本的な考え方について整理します。

情報漏洩がなぜ起きるのか、実際の原因や事例については以下の記事で詳しく解説しています。
「情報漏洩はなぜ起きるのか ―企業で多い原因と最新事例から見るリスクの実態―」

情報漏洩とは何か

情報漏洩とは、本来アクセス権限を持たない第三者に、企業が保有する情報が意図せず、あるいは不正に渡ってしまうことを指します。ここでいう情報には、顧客情報や従業員情報のような個人情報だけでなく、営業秘密、契約情報、設計情報、認証情報、メール本文、取引先とのやり取り、さらにはクラウド上で扱う業務データまで含まれます。

個人情報保護委員会が公表している「個人情報の保護に関する法律についてのガイドライン(通則編)」でも、個人データの漏えい等を防ぐために安全かつ適切な管理措置を講じるための内容が示されており、企業にとって情報漏洩は法務、経営、現場運用のすべてに関わる問題です。

近年、情報漏洩がより起こりやすくなっている背景には、業務のデジタル化が急速に進んだことがあります。クラウドサービスやSaaSの利用拡大により、データは社内サーバだけでなく外部環境にも分散して保存・共有されるようになりました。その結果、設定不備や共有範囲の誤りが事故の起点になる場面が増えています。

さらに、委託先や外部サービスを含めたサプライチェーン全体で情報を扱うことが当たり前になり、自社だけを守っていればよい時代ではなくなっています。経済産業省でも国内外のサプライチェーンでつながる関係者への目配りの必要性を明記しており、IPA「情報セキュリティ10大脅威2026」でもサプライチェーンや委託先を狙った攻撃が上位に挙げられています。

情報漏洩が企業に与える影響

情報漏洩が起きた企業に生じる大きな影響は以下のとおりです。

信用低下

まず生じるのは、信用の低下です。漏洩した情報の件数や内容だけでなく、「管理が甘い企業ではないか」「再発防止ができるのか」といった不信感が、顧客や取引先、株主、採用候補者にまで広がります。情報セキュリティ事故は単発のITトラブルではなく、企業の信頼基盤そのものを揺るがす経営リスクとして扱う必要があります。経済産業省およびIPAが公開している「サイバーセキュリティ経営ガイドライン Ver 3.0」でもサイバーリスクを経営者が主導して把握し、組織的に対処すべき課題として位置付けています。

損害賠償・対応コストの増大

漏洩の可能性が判明した後には、事実関係の調査、影響範囲の特定、本人通知、関係機関への報告、公表、問い合わせ対応、再発防止策の策定など、多くの業務が短期間に発生します。個人情報保護委員会のガイドラインでも、漏えい等事案の発生時には、調査、本人通知、報告、再発防止策の決定、公表などを行う体制をあらかじめ整備しておくことが求められています。つまり、情報漏洩対策は事故後のためにも必要であり、平時の備えが不十分だと、事故後の負担はさらに重くなります。

事業停止の可能性

さらに、情報漏洩は事業停止リスクにも直結します。不正アクセスやランサムウェア攻撃を伴うケースでは、単なる情報流出にとどまらず、システム停止や業務遅延、取引停止が同時に発生することがあります。

JPCERT/CCが2021年11月に公開した資料「経営リスクと情報セキュリティ  ~ CSIRT:緊急対応体制が必要な理由 ~」の中で、インシデント発生時には対処方針の決定、問題解決、収束、再発防止の分析、教育啓発までを含めた緊急対応体制が必要であると整理しています。情報漏洩は「漏れたら終わり」ではなく、「漏れた瞬間から事業継続の問題になる」という視点が重要です。

情報漏洩による影響や損失の考え方については、以下の記事で詳しく解説しています。
サイバー攻撃被害コストの真実―ランサムウェア被害は平均2億円?サイバー攻撃のリスク評価で“事業停止損害”を可視化

情報漏洩が起きる主な原因

情報漏洩の原因として最も見落とされやすいのが、人的ミスです。宛先の誤送信、ファイルの添付ミス、書類の紛失、権限設定の誤り、持ち出しルール違反などは、特別な攻撃を受けなくても起こります。個人情報保護委員会の年次報告でも、書類の誤交付や紛失、誤送付といった事案が多く見られるとされています。情報漏洩という言葉から外部攻撃を想像しがちですが、実務では人の確認不足やルール運用の甘さが起点になる事故が依然として多いのが実態です。

一方で、近年無視できないのが不正アクセスによる情報漏洩です。個人情報保護法サイバーセキュリティ連絡会が公表した資料「不正アクセス発生時のフォレンジック調査の有効活用に向けた着眼点」(令和8年1月16日)でも、不正アクセス被害は近年多発しており、同委員会が受け付ける不正アクセスによる漏えい等報告件数も増加していると明記しています。また、「令和6年度個人情報保護委員会 年次報告」では、SaaS事業者への不正アクセスが多数の利用企業に影響した事案の影響も含まれるものの、不正アクセス由来の報告件数が大きく増えたことが示されています。この点は、企業が自社環境だけでなく、利用中のサービスや委託先のセキュリティ状況も確認しなければならないことを意味します。

さらに、委託先やサプライチェーン経由の漏洩リスクも大きくなっています。自社では適切に管理していても、外部ベンダー、運用委託先、クラウドサービス事業者、グループ会社のいずれかに弱点があれば、そこが侵入口になります。

情報漏洩がなぜ起きるのか、実際の原因や事例については以下の記事で詳しく解説しています。
「情報漏洩はなぜ起きるのか ―企業で多い原因と最新事例から見るリスクの実態―」

委託先や外部サービスを経由したリスクについては、サプライチェーン攻撃の記事も参考になります。
サプライチェーン攻撃とは ―委託先・外注先リスクから情報漏えいを防ぐ全体像―

企業が取るべき情報漏洩対策

企業の情報漏洩対策は、技術対策、運用対策、組織・体制整備の三層で考えると整理しやすくなります。

技術対策

アクセス制御、認証強化、ログ取得、暗号化、端末管理、バックアップ、脆弱性対応などが含まれます。ただし、技術対策だけでは事故を防ぎきれません。たとえばアクセス制御の仕組みがあっても、権限付与の運用が曖昧であれば過剰権限が残り、ログを取っていても見直されなければ不審な操作に気付けません。

運用対策

運用対策として重要なのは、ルールを定めることではなく、現場で守られる状態をつくることです。個人情報保護委員会は、安全管理措置として、組織的、人的、物理的、技術的な観点での対応を示しています。これは裏を返せば、教育や承認手続、持ち出し管理、点検、監査、見直しまで含めて初めて情報漏洩対策になるということです。従業員教育を年一回実施しただけで対策済みとは言えず、権限棚卸しやルールの実効性確認が継続して回っているかが問われます。

組織・体制整備

事故が起きたときに誰が判断し、誰が調査し、誰が報告し、誰が公表を担うのかを曖昧にしないことも重要です。個人情報保護委員会のガイドラインは、漏えい等事案の発生時に備えた報告連絡体制や対応体制の整備を求めています。また、JPCERT/CCは、緊急対応、分析、普及啓発、注意喚起、演習を含めた機能の必要性を示しています。情報漏洩対策は、製品導入の話ではなく、事故前提で回る組織づくりの話でもあります。

具体的な情報漏洩対策や運用のポイントについては、以下の記事で詳しく解説しています。
「企業の情報漏洩対策 すぐに実践できる防止策と運用のポイント」

まず何から始めるべきか

情報漏洩対策を強化したい企業が最初にやるべきことは、新しいツールを入れることではなく、「現状把握」です。どの情報を、どこで、誰が、何の目的で扱っているのかが見えていなければ、守るべき対象も優先順位も定まりません。

IPA「中小企業の情報セキュリティ対策ガイドライン」でも、情報資産を洗い出し、台帳化し、重要度に応じて管理することが実践の出発点として示されています。情報漏洩対策は、漠然とした不安に対して製品を足していくのではなく、自社の重要情報と業務フローを見える化するところから始めるべきです。さらにそのうえで、優先順位付けも必要になります。すべてを同じ強さで守るのではなく、情報漏洩時の影響が大きい情報、外部共有が多い情報、委託先を含めて扱われる情報、インターネット経由でアクセスされる情報から順に見直すほうが実務的です。また、「サイバーセキュリティ経営ガイドライン Ver 3.0」でも、リスクの識別と変化に応じた見直しの重要性が示されています。情報漏洩対策は一度整えたら終わりではなく、事業環境や利用サービスの変化に応じて見直し続ける運用そのものが重要です。

どの対策を優先すべきかについては、脆弱性管理の考え方が重要になります。以下の記事もあわせてぜひご覧ください。
脆弱性管理とは?企業が行うべき脆弱性管理の基本と実践手順【2026年版】

まとめ

情報漏洩対策とは、個人情報や機密情報が外部に漏れるのを防ぐための技術、運用、組織的な取り組み全体を指します。実際の情報漏洩は、人的ミス、不正アクセス、設定不備、委託先事故など複数の原因で発生し、企業には信用低下、対応コスト増大、事業停止といった深刻な影響をもたらします。だからこそ、企業は「攻撃を防ぐ」だけでなく、「漏れてしまう前提で備える」視点を持たなければなりません。重要なのは、守るべき情報を把握し、優先順位を付け、技術対策と運用対策と体制整備を一体で進めることです。公的ガイドラインでも、体制整備、点検、監査、教育、報告連絡体制の重要性が繰り返し示されています。情報漏洩対策は、担当者任せの部分最適ではなく、企業全体で継続的に回すべき経営課題です。

具体的な情報漏洩対策や運用のポイントについては、以下の記事で詳しく解説しています。
「企業の情報漏洩対策 すぐに実践できる防止策と運用のポイント」

【参考情報】


ウェビナー開催のお知らせ

最新情報はこちら

編集責任:木下

Security NEWS TOPに戻る
バックナンバー TOPに戻る


年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

サービスに関する疑問や質問はこちらからお気軽にお問合せください。


Security Serviceへのリンクバナー画像

BBSecコーポレートサイトへのリンクバナー画像

セキュリティ緊急対応のバナー画像

ウェビナーアーカイブ動画ページバナー画像

IPA情報セキュリティ10大脅威2026にみる、AI時代のサイバーリスク

Share
「IPA情報セキュリティ10大脅威 2026に見る、AI時代のサイバーリスク」アイキャッチ画像

近年、生成AIをはじめとするAI技術の進展により、組織におけるAIの活用は急速に広がっています。本記事では、IPA「情報セキュリティ10大脅威 2026」の内容をもとに、AIの利用をめぐるサイバーリスクについて整理するとともに、企業に求められる対応の方向性について解説します。

IPA「情報セキュリティ10大脅威」速報版の記事はこちら。「AIの利用をめぐるサイバーリスク」以外の脅威の項目についても知りたい方は、こちらもぜひあわせてご覧ください。
【速報版】情報セキュリティ10大脅威 2026 -脅威と対策を解説-

はじめに

業務効率の向上や新たな価値創出の手段として、多くの企業がAIの導入を進めています。一方でAI利用に伴うリスクについても、十分な注意が求められています。こうした状況を反映して、IPA(独立行政法人情報処理推進機構)が公表した「情報セキュリティ10大脅威 2026」において、「AIの利用をめぐるサイバーリスク」という脅威が初めてランクインし、3位に位置付けられました。

なぜいま「AIの利用」が脅威として注目されるのか

IPA「情報セキュリティ10大脅威」は、前年に発生した社会的影響の大きい事案等をもとに選定されたものであり、順位は単純に危険度の高さを示すものではありません。しかし、AI利用に関するリスクが新たに選出されたことは、企業や組織におけるAI活用の拡大と、それに伴う課題の顕在化を示すものといえるでしょう。

2026年3月12日に公開された、IPA「情報セキュリティ10大脅威 2026」解説書では、AIは有用なツールである一方で、十分な理解がないまま利用した場合、情報漏洩や権利侵害といった問題につながる可能性があると指摘されています。特に、生成AIへの入力内容が外部に取り扱われることによる機密情報の漏洩や、生成された情報の正確性を確認せずに業務に利用することによって発生するトラブルなど、従来の情報システム利用とは異なる観点でのリスクが挙げられています。 また、AIは利用者の裾野が広く、専門的な知識がなくても活用できるという特性を持っています。そのため、組織として利用状況を把握しきれないまま、個人単位で業務利用が進むケースも想定されます。このような利用形態は、管理の行き届かないリスク、いわゆるシャドーITに類似した問題を引き起こす可能性があります。

AI利用をめぐる主なリスク

IPAはAIの利用拡大に伴い、いくつかの代表的なリスクが指摘しています。これらは、AIの技術そのものというよりも、その利用方法や特性に起因するものが多い点が特徴です。

  • 情報漏洩リスク
  • 誤情報生成リスク(ハルシネーション)
  • サイバー攻撃の高度化リスク
  • 利用実態の把握困難(シャドーAI)
  • 権利侵害リスク

生成AIへの入力内容に起因する情報漏洩

クラウドサービスとして提供されるAIに対し、機密情報を入力することで、意図せず外部に情報が送信される可能性があるというリスクです。

AIの出力結果に関するリスク

対話型AIは実在しない情報を生成する(=ハルシネーション)場合があり、このことを十分に理解せずに利用すると、誤った判断や誤情報発信につながるおそれがあります。

AIの悪用によるサイバー攻撃の高度化

AIを活用することで、攻撃の効率化や手口の巧妙化が進む可能性があります。さらに、組織における利用実態の把握が難しい点も重要なリスクです。

シャドーAIのリスク

個人単位でAIサービスを利用されてしまうことで、組織の目の届かない範囲での利用が発生する可能性があります。

著作権侵害などの権利問題

AIの利用に関する理解不足により、著作権侵害などの権利問題が生じる可能性も指摘されています。

AI利用において想定される主な事例

AI利用に伴うリスクは、特別な環境でのみ発生するものではなく、日常業務の中で自然に発生し得るものです。例えば業務の効率化を目的として、従業員が個人で利用している生成AIサービスを業務に活用するケースが考えられます。メール文面の作成や資料作成の補助としてAIを利用する延長で、社内資料の内容や顧客情報をそのまま入力してしまうことがありえます。生成AIはクラウド上で動作しており、入力した内容はサービス側で処理されます。場合によっては、入力内容がサービスの改善や学習に利用されることもありえます。この点を十分に理解しないまま利用すると、機密情報を外部サービスに送信してしまうことになり、情報漏洩につながるおそれがあるのです。

また、対話型AIの回答をそのまま精査せずに業務に利用してしまうことで問題に発展する可能性もあります。調査や資料作成の過程でAIが生成した情報を十分に確認せずに利用した結果、ハルシネーションの内容を含んだまま社内外に共有してしまうといった事態が起こり得ます。このように、AI利用に伴うリスクは特定の専門領域に限らず、日常業務の延長線上で発生する点に特徴があります。

組織における課題

AIの利用が広がる一方で、組織としてこれらのリスクを適切に管理することにはいくつかの課題があります。

社内でのAI利用の促進とルールの策定のバランス

まず、AI利用に関するルールやガイドラインの整備が追いついていない点が挙げられます。現場での利用が先行する中で、組織としての利用方針が明確でない場合、統一的な管理が難しくなります。また、利用状況の把握が困難であることも大きな課題です。クラウド型のAIサービスは個人単位で容易に利用可能なため、組織として誰がどのように利用しているかを正確に把握することが難しくなります。実際には、想定以上に広範囲で利用が進んでいるケースも少なくありません。さらに、ポリシーを整備しても現場に浸透しないという課題もあります。AIは業務効率の向上に直結するため、利便性を優先してルールが守られないケースや、現場ごとに独自の運用が行われるといった状況も発生し得ます。加えて、AI利用と既存のセキュリティ対策との間にギャップが生じる点も課題です。従来のセキュリティ対策は想定していなかった利用形態が増えることで、管理や統制が追いつかない場面が生じる可能性があります。さらに、利用者への教育不足も課題の一つです。AIの特性やリスクに関する教育や周知が十分でないために、組織として意図しない利用が広がり、統制が効かなくなるおそれがあります。

このように、AIの活用においては、ルール整備や利用状況の把握といった基本的な対応に加え、実際の運用における課題も踏まえた継続的な対応が求められます。

企業が取るべきアクション

AIの利用に伴うリスクに対応するためには、個別の技術対策にとどまらず、組織としての管理と運用の整備が重要となります。AI利用に関しては、ルール整備や教育、基本的なセキュリティ対策の徹底といった観点での対応が求められています。

  1. AIの利用に関するルールやガイドラインの整備
    どのような用途でAIを利用してよいのか、入力してよい情報の範囲、利用してはならない行為などを明確に定めることで、利用に伴うリスクを一定程度抑制することが可能となります。
  2. 利用状況の把握と管理
    AIサービスは個人単位でも容易に利用できるため、組織としてどのように利用されているかを把握し、必要に応じて管理の対象とすることが重要です。これにより、管理の行き届かない利用、いわゆるシャドーAIの発生を抑制することが期待されます。
  3. AI利用者への教育
    AIの特性やリスクについて正しく理解させることで、生成結果の確認や適切な情報の取り扱いといった基本的な行動を促すことができます。技術的な制御だけでなく、利用者の理解を前提とした運用が不可欠です。
  4. 基本的なセキュリティ対策の徹底・見直し
    認証の適切な運用や情報管理の強化といった既存の対策は、AI利用においても引き続き基盤となるものです。その上で、AIの利用が業務に広く組み込まれる中では、従来の対策だけでは対応しきれない場面も想定されるため、AI利用を前提としたセキュリティの見直しや再設計が必要となる可能性もあります。

このように、AIの安全な活用には、ルール、管理、教育、AIを前提とした基本的なセキュリティ対策といった複数の観点からの継続的な取り組みが重要です。

AI時代に求められるセキュリティ支援

こうした課題に対応するためには、組織単独での取り組みだけでなく、専門的な支援の活用も有効です。以下のようなセキュリティ支援の例が挙げられます。

  • セキュリティ診断・リスクアセスメント
    AI利用に伴うリスクを把握するためのセキュリティ診断やリスクアセスメントが重要となります。現状の利用状況や潜在的なリスクを可視化することで、適切な対策の検討につなげることができます。
  • 運用監視体制の強化
    AIの利用状況を継続的に監視し、問題の早期発見や対応を行う体制を整備することで、リスクの低減が期待されます。
  • AI利用ガイドライン策定支援
    組織の実態に即したルールを整備し、現場で実際に運用可能な形に落とし込むことが求められます。

さいごに

「情報セキュリティ10大脅威 2026」において、「AIの利用をめぐるサイバーリスク」が新たにランクインしたことは、AI活用の拡大と、それに伴う課題の顕在化を示すものといえます。AIに関するリスクは、新たな技術そのものに起因するというよりも、その利用方法や理解不足に起因する側面が大きい点が特徴です。そのため、対策としては、ルール整備や利用状況の把握、教育といった組織的な対応に加え、基本的なセキュリティ対策を継続して実施することが重要となります。

また、IPAが示す通り、10大脅威の順位は危険度の高さを示すものではなく、自組織の状況に応じて適切にリスクを評価し、優先順位を定めて対策を講じることが求められます。 AIの活用は今後さらに進むことが想定されますが、その利便性を最大限に活かすためにも、リスクを正しく理解し、組織として適切に管理・運用していくことが重要です。


【関連ウェビナーのご案内】
本記事では、生成AIの利用に伴うサイバーリスクと、企業への影響について整理しました。AIの活用が進む一方で、情報漏えいや誤利用、統制の難しさといった課題が現実のものとなっています。では、こうしたリスクは実際にどのように悪用され、どのような攻撃として現れているのでしょうか。2026年4月15日に開催のウェビナーでは、生成AIを悪用した具体的な事例をもとに、サイバー脅威の実態と防御戦略を詳しく解説します。リスクの「背景」だけでなく、「実際に何が起きるのか」を理解したい方は、ぜひご参加ください。

ウェビナー最新情報はこちら


BBSecでは

当社では様々なご支援が可能です。お客様のご状況に合わせて最適なご提案をいたします。当当サイトSQAT® jpのお問い合わせページよりお気軽にお問い合わせください。後日営業担当者よりご連絡させていただきます。

SQAT® 脆弱性診断

BBSecの脆弱性診断は、精度の高い手動診断と独自開発による自動診断を組み合わせ、悪意ある攻撃を受ける前にリスクを発見し、防御するための問題を特定します。Webアプリケーション、ネットワークはもちろんのこと、ソースコード診断やクラウドの設定に関する診断など、診断対象やご事情に応じて様々なメニューをご用意しております。

SQAT脆弱性診断サービスバナー画像

SQAT® ペネトレーションテスト

「ペネトレーションテスト」では実際に攻撃者が侵入できるかどうかの確認を行うことが可能です。脆弱性診断で発見したリスクをもとに、実際に悪用可能かどうかを確認いたします。

編集責任:木下

Security NEWS TOPに戻る
バックナンバー TOPに戻る


資料ダウンロードボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
お問い合わせボタン
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
ウェビナーアーカイブ動画ページバナー画像

セキュリティ運用は何から始めるべきか 担当者が最初に整理すべきポイント

Share
「セキュリティ運用は何から始めるべきか」アイキャッチ画像

セキュリティ運用を始める際に最初に必要なのはツール導入ではなく、「何を守るか」と「どの順序で対応するか」を整理することです。セキュリティは単発の施策ではなく、継続的に判断と改善を繰り返す活動であるため、最初の設計を誤ると後から修正が難しくなります。本記事では、実務担当者が最初に整理すべきポイントを現場目線で解説します。

セキュリティ運用の全体像や考え方については、以下の記事で整理しています。
セキュリティ運用とは?属人化を防ぎ継続的に回す基本の考え方

「セキュリティ運用を始めたいが、何から手を付ければよいのか分からない」。これは多くの企業担当者が最初に直面する課題です。検索でも「セキュリティ運用 何から始める」「セキュリティ運用 方法」「セキュリティ運用 チェックリスト」といったキーワードが増えており、導入段階から運用段階へ関心が移っていることがうかがえます。セキュリティ対策そのものについての情報は多く存在しますが、実際の運用をどの順序で立ち上げるべきかについては、体系的に語られることが少ないのが現状です。

「何を守っているか分からない」状態が最大の問題

セキュリティ運用を始める際、多くの組織がいきなりツール導入やチェックリスト作成に進みます。しかし提供された文脈に基づくと、最初に取り組むべき課題は技術ではありません。「自分たちは何を守っているのか」を把握することです。企業には業務システム、クラウドサービス、端末、アカウント、外部委託先など、さまざまな資産が存在します。ところが実際には、全体像が整理されないまま個別対策が積み重なっているケースが少なくありません。この状態では、どのリスクが重要なのか判断できず、対応が場当たり的になります。資産やシステムの棚卸しは単なる一覧作成ではなく、「事業にとって停止すると困るものは何か」という視点で整理する作業です。優先順位が存在しない運用では、軽微な問題に時間を使い、本来対応すべきリスクを見逃す可能性があります。

守るべき対象や優先順位を整理する際には、サイバー攻撃リスク評価の考え方が役立ちます。 「サイバー攻撃リスク評価の進め方:見えない脅威を可視化するプロセスと実践

セキュリティ運用の最小単位を作る

セキュリティ運用という言葉から大規模な仕組みを想像すると、着手のハードルが高くなります。しかし実務では、まず「最小単位」を作ることが重要です。運用は、情報を集め、それを判断し、必要な対応を行い、その結果を記録するという循環によって成立します。この四つの流れが成立していれば、規模が小さくても運用は始まっています。情報収集とは脆弱性情報や注意喚起の把握を指します。判断とは自社への影響を考える行為であり、対応は設定変更やパッチ適用など具体的な行動です。そして記録は、後から判断理由を再確認できる状態を作ります。多くの組織では対応だけが行われ、判断理由や経緯が残されません。その結果、同じ問題が繰り返されます。最小単位とは作業量を減らすことではなく、循環を成立させることを意味します。

日常業務に組み込める運用とは

セキュリティ運用が続かない理由の一つは、「特別な仕事」として設計されてしまう点にあります。通常業務とは別に毎日実施する作業を増やすと、忙しい時期に必ず停止します。 現実的な運用は、毎日行うものではなく、一定の周期や条件に応じて動く仕組みとして設計されます。たとえば月次で確認する作業、更新時のみ実施する確認、アラート発生時に対応する流れなど、業務のリズムに合わせることが重要になります。提供された構成意図に基づくと、セキュリティ運用とは負担を増やすことではなく、既存業務の中に判断ポイントを組み込むことだと理解できます。運用が日常に溶け込んだとき、初めて継続性が生まれます。

よくある失敗例

セキュリティ運用を開始した組織が直面しやすいのが、形骸化です。チェックリストを作成しても実際には確認されず、記録だけが残る状態は珍しくありません。チェックそのものが目的化すると、リスク低減という本来の目的が見えなくなります。また、ツール導入によって運用が自動化されたと誤解されるケースもあります。ツールは検知や可視化を支援しますが、最終的な判断は組織側に残ります。判断基準がなければ、アラートは増えるだけで改善につながりません。さらに問題となるのが属人化の放置です。「詳しい人がいるから大丈夫」という状態は短期的には効率的ですが、長期的には運用停止リスクを高めます。

実際に、運用が形骸化した結果、ランサムウェアや委託先経由の被害につながるケースもあります。
サプライチェーン攻撃とは ―委託先・外注先リスクから情報漏えいを防ぐ全体像―

小さく始めて回し続けるコツ

セキュリティ運用を成功させる組織に共通しているのは、最初から完成形を目指さない点です。理想的な運用設計を追求すると準備期間が長期化し、実運用が始まらないことがあります。むしろ重要なのは、小さく始めて継続することです。判断軸を共有し、「どのように考えて対応したのか」を残すだけでも、組織の知識は蓄積されていきます。運用は改善を前提とした活動です。最初から完璧である必要はなく、回しながら修正することで現実に適合していきます。提供された文脈に基づくと、セキュリティ成熟度は導入規模ではなく継続期間によって高まる傾向があると整理できます。

体制の話は次のステップ

ここまでの内容は、担当者レベルで始められるセキュリティ運用の基礎です。しかし運用を継続し、属人化を防ぐためには、やがて役割分担や体制設計が必要になります。誰が判断し、誰が実行し、どこに記録が集約されるのかが明確になることで、運用は個人依存から組織運用へと移行します。ただし体制設計は最初の段階で無理に行う必要はありません。まずは回る運用を作ることが先になります。

運用を属人化させず、継続的に回すための体制づくりについては、次の記事で詳しく解説します。
「セキュリティ運用体制の作り方 属人化を防ぐための役割分担と外部活用の考え方」

セキュリティ運用は「始め方」で成否が決まる

セキュリティ運用は高度な技術から始まるものではありません。何を守るのかを理解し、小さな循環を作り、それを日常業務の中で継続することから始まります。チェックリストやツールは重要な要素ですが、それだけでは運用は成立しません。判断・対応・記録という流れが回り始めたとき、セキュリティは単発対応から継続的な活動へ変わります。「セキュリティ運用は何から始めるべきか」という問いへの答えは一つではありませんが、提供された構成意図に基づくと、最初に必要なのは完璧な設計ではなく、回り続ける最小単位を作ることだと言えるでしょう。

本記事は、企業におけるセキュリティ運用支援およびインシデント対応の実務知見をもとに、一般的に公開されているセキュリティ運用の考え方を整理したものです。特定製品への依存を避け、組織運用の観点から解説しています。


運用を属人化させず、継続的に回すためには体制づくりが欠かせません。次の記事で詳しく解説します。
「セキュリティ運用体制の作り方 属人化を防ぐための役割分担と外部活用の考え方」

BBSecでは

委託先が関係する情報漏えいでは、自社だけで完結する対応はほとんどありません。複数の関係者が絡むからこそ、事前の整理や体制づくりが結果を大きく左右します。ブロードバンドセキュリティ(BBSec)では、サプライチェーン全体を前提としたインシデント対応体制の整理や、外部起因の事故を想定した初動対応の支援を行っています。「起きてから考える」のではなく、「起きる前提で備える」ことが、これからの企業に求められる姿勢です。もし、委託先を含めた情報管理やインシデント対応に不安を感じている場合は、一度立ち止まって体制を見直すことが、将来のリスクを減らす確かな一歩になるでしょう。

セキュリティ運用サービス(BBSec)

慎重かつ堅実な継続的作業を求められるセキュリティ運用を、セキュリティのプロフェッショナルが24時間・365日体制で支援いたします。
詳細はこちら
※外部サイトへリンクします。

編集責任:木下

Security NEWS TOPに戻る
バックナンバー TOPに戻る


年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

サービスに関する疑問や質問はこちらからお気軽にお問合せください。


Security Serviceへのリンクバナー画像
BBSecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
ウェビナーアーカイブ動画ページバナー画像

CVSSスコアの正しい使い方 ―脆弱性対応の判断にどう活かすべきか―

Share
CVSSスコアの正しい使い方 ―脆弱性対応の判断にどう活かすべきか―アイキャッチ画像

脆弱性対応を検討する際、多くの担当者が参考にする指標が CVSSスコアです。しかし、CVSSは正しく理解して使わなければ、かえって判断ミスを招いてしまう原因になります。本記事では、CVSSスコアの基本的な考え方と、企業の脆弱性対応判断にどう活かすべきかを整理します。

CVSSスコアとは何か

CVSS(Common Vulnerability Scoring System)は、脆弱性の深刻度を数値で表すための共通指標です。多くの場合、0.0〜10.0のスコアで示され、数値が高いほど深刻とされます。

【深刻度(例)】

  • 低(Low)
  • 中(Medium)
  • 高(High)
  • 緊急(Critical)

重要なのは、CVSSは「脆弱性そのものの性質」を評価する指標であり、個々の企業環境を前提としていないという点です。本来の目的は、脆弱性の危険度を関係者間で共通認識として共有することにあります。

CVSSスコアが「分かりやすいが危険」な理由

CVSSは便利な指標ですが、これだけで対応の優先順位を決めるのは危険です。なぜならCVSSは自社環境を前提にしておらず、その脆弱性が実際に攻撃されるかどうかを保証していないためです。同じCVSSスコアでも、「インターネットから誰でもアクセスできるWebサービス」と「内部ネットワークでしか使われていない管理系システム」では、実際のリスクは大きく異なります。CVSSは「脆弱性そのものの性質」を示すものであり、「自社にとっての危険度」そのものではないことを理解しておく必要があります。

CVSSを構成する3つの要素

CVSSは主に次の3要素で構成されています。

  1. ベーススコア
    脆弱性が持つ本質的な深刻度を表します。多くの脆弱性情報で表示されるのがこのスコアです。
  2. Temporalスコア
    攻撃コード(PoC)の公開状況や対策情報の有無など、時間とともに変化する要素を反映します。
  3. Environmentalスコア
    実際の利用環境や影響度を考慮したスコアです。企業の判断に最も近いのはこの要素ですが、実際には十分に使われていないことが多いのが実情です。

CVSSスコアだけで判断してはいけない理由

CVSSスコアが高くても、必ずしも「今すぐ対応すべき」とは限りません。例えば、内部ネットワーク限定で利用されている、認証が必須で、悪用難易度が高い、該当機能が実際には使われていない、などの場合、実際のリスクは限定的です。逆に、CVSSスコアが中程度でも、「インターネットから直接アクセス可能」「既に攻撃事例が出ている」「業務停止に直結する」といったケースでは、優先度は高くなります。

脆弱性対応判断におけるCVSSの正しい位置づけ

CVSSスコアは、次のように使うのが現実的です。

候補の洗い出し:スコアが高い脆弱性を把握する
自社環境への当てはめ:実際の優先順位は「利用状況 × 公開範囲 × 業務影響」で決める
対応方法の検討:即時対応か、回避策か、計画対応かを判断

CVSSが高い脆弱性は、「詳細に確認すべき候補」として扱うのが適切です。

CVSSスコアを見るときのチェックポイント

実務では、CVSSスコアに加えて以下を確認します。これらを組み合わせることで、「今すぐ対応すべきか」「計画対応でよいか」の判断材料が見えてきます。

  • 攻撃条件は現実的か(認証不要/公開範囲)
  • 攻撃コード(PoC)は出回っているか
  • 悪用された場合の影響はどこまで及ぶか
  • 一時的な回避策でリスクを下げられるか

CVSSとあわせて確認すべき情報

CVSSだけでなく、次の情報もあわせて確認することが重要です。

  • 実際の攻撃事例や観測情報
  • ベンダーのアドバイザリ内容
  • 自社システム構成・利用実態
  • 業務影響や復旧にかかるコスト

これらを総合的に見ることで、自社にとっての“本当の優先度”が見えてきます。

本記事は、脆弱性対応全体の考え方を整理した
脆弱性対応の優先順位と判断基準|すべてを今すぐ直す必要はあるのか?
の中で、CVSSという判断材料を深掘りした位置づけです。 CVSSはあくまで道具の一つであり、最終判断は全体像を踏まえて行う必要があります。

まとめ:CVSSは「判断を助ける指標」として使う

CVSSスコアは非常に便利ですが、万能ではありません。「CVSSは優先順位判断の補助として使い、スコアだけで判断を出さない」「自社環境を考慮する」「攻撃されやすさ × 影響度」で判断する」―この考え方を持つことで、脆弱性対応の精度は大きく向上します。

脆弱性対応全体の判断基準については、
脆弱性対応の優先順位と判断基準―限られたリソースでリスクを下げる考え方 の記事で詳しく解説しています。

次の記事は…
緊急パッチ適用の判断基準 ―業務影響を抑えるにはどうすべきか―

Security NEWS TOPに戻る
バックナンバー TOPに戻る


年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

サービスに関する疑問や質問はこちらからお気軽にお問合せください。


Security Serviceへのリンクバナー画像
BBSecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
ウェビナーアーカイブ動画ページバナー画像

サプライチェーン攻撃と経営責任 ―委託先が原因でも問われる企業の判断とは ―

Share
サプライチェーン攻撃と経営責任 ―委託先が原因でも問われる企業の判断とは ―アイキャッチ画像

サプライチェーン攻撃は、もはやIT部門だけで完結する問題ではありません。委託先や外注先が原因で情報漏えいが発生した場合でも、最終的に問われるのは企業としての説明責任と経営判断です。顧客や取引先にとって重要なのは原因の所在ではなく、どのように向き合い、被害を最小化し、再発を防ぐのかという姿勢です。本記事では、サプライチェーン攻撃がなぜ経営リスクと直結するのか、そして経営層が押さえるべき判断ポイントを整理します。

サプライチェーン攻撃の基本的な仕組みや特徴については、以下の記事で整理しています。 「サプライチェーン攻撃とは ―委託先・外注先リスクから情報漏えいを防ぐ全体像―」

情報漏えいは現場だけの問題では終わらない

情報漏えいが起きたとき多くの経営者が最初に口にするのは、「それはIT部門の問題ではないのか」という言葉です。確かに、直接的な原因はシステムの設定ミスや不正アクセスかもしれません。しかし近年増えている事故の多くは、自社ではなく委託先や外注先、外部サービスを起点として発生しています。このとき、経営層は否応なく判断を迫られます。それは技術的な是非ではなく、企業としてどう向き合うのかという判断です。

サプライチェーン攻撃は経営リスクそのものである

サプライチェーン攻撃とは、標的企業を直接狙うのではなく、その周囲にある取引先や委託先を踏み台に侵入する攻撃です。この攻撃が厄介なのは、「自社は直接何もしていない」という状況でも、結果として責任を問われる点にあります。顧客や取引先から見れば、「原因が委託先かどうか」よりも「自分の情報が守られたのか」の方が重要だからです。つまり、サプライチェーン攻撃はITリスクであると同時に、信頼・ブランド・事業継続に直結する経営リスクなのです。

なぜ経営が関与しなければならないのか

サプライチェーンリスクは、現場だけではコントロールしきれません。委託の判断、外注範囲の決定、契約条件の承認、事故時の公表方針。これらはいずれも、最終的には経営判断に行き着きます。現場がどれだけ対策を講じていても、「便利だから」「コストが安いから」という理由でリスクの高い委託が選ばれていれば、事故の可能性は高まります。経営が関与しないままでは、リスクの全体像を誰も把握していない状態が生まれてしまいます。

「委託先が原因」は経営の言い訳にならない

実際の事故対応でよく見られるのが、「原因は委託先でした」という説明です。しかしこの説明は、社外に対してはほとんど意味を持ちません。なぜなら、委託という判断をしたのは自社であり、その責任は発注元にあると見なされるからです。ここで経営判断を誤ると、

  • 説明が後手に回る
  • 対応が場当たり的になる
  • 結果として「誠実さがない」という評価を受ける

といった事態につながります。

委託先のセキュリティをどこまで確認すべきかについては、以下の記事も参考になります。
委託先・外注先のセキュリティはどこまで確認すべきか ―サプライチェーン攻撃を防ぐ実務判断―

経営が押さえるべき3つの視点

経営層が理解すべきなのは、個々の技術的対策ではありません。重要なのは、「どこにどれだけのリスクがあるのか」という構造です。

  1. どこにリスクが集中しているか
    どの業務を外部に委託しているのか。
  2. 委託範囲とアクセス権の把握
    委託先は、どの情報にアクセスできるのか。
  3. 事故発生時の意思決定フロー
    問題が起きたとき誰が、どの順番で、何を判断するのか。

この全体像を把握できていなければ、事故発生時に冷静な判断はできません。

サプライチェーン事故で問われるのは“初動”

経営にとって最も重要なのは、事故が起きた後の最初の判断です。責任の所在を明確にすることよりも先に、被害が拡大していないか、説明すべき相手は誰か、どのタイミングで何を伝えるかを判断する必要があります。この初動で迷いが生じるのは、平時に「委託先が原因だった場合」を想定していないからです。サプライチェーン攻撃が増えている今、外部起因の事故を前提にした意思決定フローを持っているかどうかが、企業の明暗を分けます。

具体的な初動対応の流れについては、以下の記事で詳しく解説しています。
サプライチェーン攻撃で委託先が原因の情報漏えい時に企業が取るべき初動対応とFAQ

技術より先に、経営としての姿勢が見られている

情報漏えい後、世間が注目するのは「どんな高度なセキュリティを使っていたか」ではありません。それよりも、

  • 状況を正しく説明しているか
  • 被害者に向き合っているか
  • 再発防止に本気で取り組んでいるか

といった姿勢が評価されます。これらはすべて、経営の判断とメッセージにかかっています。

まとめ:サプライチェーン攻撃は経営のテーマである

サプライチェーン攻撃は、IT部門だけの課題ではありません。委託という経営判断、事故時の説明責任、企業としての信頼維持。そのすべてが絡み合う、典型的な経営リスクです。 だからこそ、「技術的な話は分からないから任せる」ではなく、「全体像を理解したうえで判断する」という姿勢が、これからの経営には求められます。

BBSecでは

経営視点でサプライチェーンリスクを整理するために

サプライチェーンリスクは、現場任せにすると見えなくなり、経営だけで考えると実態が分からなくなります。BBSecでは、技術と経営の間に立ち、委託先や外注先を含めたサプライチェーン全体を整理し、経営判断につながる形でリスクを可視化する支援を行っています。 「どこにリスクがあるのか分からない」「事故が起きたとき、判断できるか不安だ」そう感じた段階で整理しておくことが、結果的に最もコストの低い対策になります。

【参考情報】

  • NIST(米国国立標準技術研究所),Cybersecurity Supply Chain Risk Management C-SCRMhttps://csrc.nist.gov/projects/cyber-supply-chain-risk-management
  • Security NEWS TOPに戻る
    バックナンバー TOPに戻る


    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

    サービスに関する疑問や質問はこちらからお気軽にお問合せください。


    Security Serviceへのリンクバナー画像
    BBSecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像
    ウェビナーアーカイブ動画ページバナー画像

    特別寄稿/AI時代のセキュリティ戦略:トライコーダ上野宣氏が語る、攻撃と防御の最前線【後編】

    Share
    上野宣氏

    生成AIの進化により、サイバー攻撃と防御の双方でAI活用が加速する現代。前編では、AIがもたらす脅威の変化と、企業が直面する新たなリスク構造について、上野 宣氏に解説いただきました。

    後編では、こうした環境変化を踏まえ、企業はどのようにセキュリティ戦略を再構築すべきか、その具体的な方向性と実践のポイントについて掘り下げます。

    前編「AIが変える攻撃の現状と、防御側AI活用のリアル」はこちら


    AI時代に増えるリスクと、経営が取るべきアクション

    企業が直面するAIセキュリティリスク

    AIを活用する企業は、攻撃の標的になるだけでなく、自社が導入したAIがリスクの起点になる可能性も抱えます。ここで重要なのは、「AIを守る」という視点です。 AIは、データアクセスを統合し、業務フローに深く入り込みます。言い換えると、AIは便利なツールであると同時に、新たなリスクになり得ます。

    以下では、AI活用が進む現場で起きやすいリスクを、実務の観点で整理します。

    生成AI利用による情報漏えい・シャドーAI

    現場が便利さを優先して、個人アカウントの生成AIに機密情報を入力してしまう、いわゆるシャドーAIは、シャドーITと同じ構図で広がります。入力データの扱い(学習に使われるのか、保存されるのか)、ログに残るのか、社外に送信されるのか。利用ルールと技術的な制御がないと、情報資産の漏えいに繋がる可能性があります。

    対策は利用を禁止することではありません。ほとんどの従業員は悪意を持ってシャドーAIをするわけではなく、ビジネスに活用しようとしているだけです。現場の生産性要求は止められないからこそ、次のような使えるガードレールが必要です。

    • 会社が認めるAI利用チャネル(法人契約、社内AI、承認済みツール)を用意する
    • 機密分類に応じて「入力禁止」「要マスキング」「要承認」などを定義する
    • DLP、プロキシ、CASB等で、持ち出し・入力を技術的に抑止する(可能な範囲で)
    • 利用ログを残し、例外管理を行う

    プロンプトインジェクション/RAG汚染:AIアプリ特有の攻撃面

    社内ナレッジ検索(RAG)やAIチャットボットを業務に組み込むと、従来のWeb脆弱性とは別の攻撃面が生まれます。

    • プロンプトインジェクション:悪意ある指示でAIの挙動を変え、機密を引き出す
    • RAG汚染:参照ドキュメントに誘導文を仕込み、誤誘導・情報漏えいを誘発
    • 権限モデルの破綻:AIが見えてはいけない情報を横断的に回答してしまう
    • ツール連携の悪用:AIに「メール送信」「DB更新」「ワークフロー実行」などを許すと、誤操作や悪用の影響範囲が一気に広がる

    こうしたリスクは、アプリの仕様・権限・データ設計の問題として現れるため、情シス・開発・セキュリティが一体で設計し直す必要があります。

    学習データ汚染・モデル改ざん・信頼できない出力

    モデルそのもの、あるいは学習・評価・運用のパイプラインが攻撃されると、判断の信頼性が崩れます。たとえば、学習データやナレッジに悪意ある情報が混ざる、モデルの設定が変えられる、評価(テスト)が形骸化する。こうした問題は、結果として「AIが間違った結論を自信満々に出す」形で表面化します。業務に組み込むほど、誤りは事故になります。

    • 重要業務ほど根拠(参照元)を提示できる設計が必要
    • 出力の正しさを検証できない領域では人の確認を前提にする
    • 仕様変更・データ更新・モデル更新は変更管理(レビュー、承認、ロールバック)に乗せる

    モデル盗難・データ推定・API悪用

    外部APIや自社モデルを提供する側になると、今度は「モデルを盗まれる」「APIを乱用される」「出力から学習データが推定される」といった論点が生まれます。ここでは、認証・認可、レート制限、監査ログ、鍵管理、テナント分離など、従来のAPIセキュリティの要諦がそのまま効いてきます。

    ガバナンス・法令・説明責任

    AIは出力が意思決定に影響するため、誤りがビジネス事故に直結します。個人情報・機密情報・著作権・差別・説明責任など、論点は多岐にわたります。

    AIの利用に関する法規制も急速に整備されつつあり、2024年8月にはEUでArtificial Intelligence Act(欧州AI規制法)が施行されました。違反時の罰則は最大で全世界年間売上高の7%または3,500ユーロと非常に厳しいものです。

    海外取引がある企業であるほど、規制動向を踏まえたガバナンスが必要になります。重要なのは、法令対応を法務任せにせず、セキュリティと一体で運用設計に落とすことです。

    経営層・CISOが取るべきアクション:AIセキュリティを“経営課題”にする

    AI時代のセキュリティ戦略は、現場の頑張りだけでは成立しません。経営が意思決定すべきポイントは、概ね次の3つに分けられます。

    方針(何を守り、どこまで許容するか)

    • AIの利用目的と禁止事項を明文化(機密分類と紐付ける)
    • 人が最終責任を持つ領域を定義(例:与信、採用、重要判断、法的判断)
    • 委託・SaaS・外部APIの利用条件(データの持ち出し、学習利用、ログ保管、保存期間)
    • 例外申請の道を用意し、現場がこっそり使う状況を減らす

    体制(誰が意思決定し、運用を回すか)

    • AIガバナンス(責任者・審査プロセス・例外管理)の設置
    • CISO/CSIRT/SOCとAI開発・運用の接続(棚卸し・脅威モデリング・運用手順)
    • インシデント対応計画の更新(AI由来の誤回答、漏えい、改ざん、なりすましを含める)
    • 監査・品質・法務・広報も巻き込み、事故時の説明責任を担保する

    実装(どう測り、どう改善するか)

    • AIアプリのセキュリティ評価(権限設計、ログ、監査、耐プロンプト攻撃、データ境界)
    • 継続的なテストと監視(レッドチーミング、監視指標、評価データ更新)
    • 教育の刷新(AI時代のフィッシングやディープフェイクを含む訓練)
    • サードパーティ評価(ベンダーのデータ取り扱い、透明性、監査可能性)

    ここで、経営層・CISOが最初の一手として取り組みやすいのが、「AI利用の棚卸し」です。「誰が、どのAIを、何の業務で、どんなデータを扱っているか」を把握できない限り、リスク評価も投資判断もできません。

    棚卸しの結果をもとに、次のような優先順位付けを行います。

    • 高優先:機密データ×外部AI×自動実行(ツール連携)
      事故時の影響が大きく、設計変更が必要になりやすい領域
    • 中優先:社内AI×業務支援(要約・検索)
      ルールと権限、ログ、監査で事故を起こしにくい設計にする
    • 低優先:公開情報×個人利用(学習目的)
      教育・ガイドライン中心でコントロールする

    「AI導入=生産性向上」の議論は進みやすい一方で、「AI導入=新しいリスクの導入」という議論は後回しになりがちです。だからこそ、経営とCISOが同じテーブルで、“AIで守る”と“AIを守る”を同時に設計することが、競争力に直結します。

    CISO/経営が迷わないための90日ロードマップ

    AIセキュリティはやることが多く見えますが、最初から完璧を目指すと止まります。ここでは、取り掛かりやすく、成果が見えやすい90日プランを例示します。

    • 0〜30日:現状把握とルール整備(止血)
      • AI利用の棚卸し(部署・用途・データ種類・外部/社内)
      • 重要データの分類と、AI入力可否ルール(暫定版でもよい)
      • 決裁・送金・機密共有の“なりすまし耐性”点検(電話確認、二要素、手順の固定化)
    • 31〜60日:AIアプリの設計レビューと運用の接続(再発防止)
      • RAG/チャットボット等の権限設計レビュー(最小権限、データ境界、回答制御)
      • 監査ログ設計(入力・参照・出力・実行の記録)
      • SOC/CSIRTがAI起因の事故を扱えるよう、手順と訓練シナリオを更新
    • 61〜90日:継続改善の仕組み化
      • 定期評価(レッドチーミング/診断/演習)の計画化
      • KPIの設定(例:棚卸しカバー率、AI入力ルール遵守率、初動時間、復旧時間)
      • ベンダー・委託先に対する要求事項(データ取扱い、監査、透明性)のテンプレ化

    AIは導入のスピードが速い分、暫定のガードレールを早く敷き、走りながら改善する発想が現実的です。

    技術責任者向け AIアプリを“事故らせない”ための設計ポイント

    CTO/開発責任者の立場では、「AIを入れるかどうか」より「AIをどう組み込むか」が勝負になります。特に事故を起こしやすい論点は、次の5つです。

    1. 権限とデータ境界:AIの回答が横断参照にならないよう、検索・参照段階でアクセス制御する
    2. 根拠提示:可能な限り参照元(文書ID、URL、更新日時)を出し、検証可能性を担保する
    3. 入力と出力の制御:機密らしき文字列のマスキング、出力フィルタ、禁止操作の明確化
    4. ツール連携の安全化:実行系は二重確認・最小権限・レート制限・停止スイッチを前提にする
    5. 監査ログと再現性:入力・参照・出力・実行を記録し、事故時に再現できるようにする

    便利さは機能追加で得られますが、信頼性は設計でしか得られません。AIを業務に組み込むほど、セキュリティは後付けでは間に合わなくなります。

    次の5年で起きること、起きないこと

    今後数年で見えているのは、次の潮流です。

    • 攻撃の自動化はさらに進む:偵察から侵入、横展開まで“部分最適”が積み上がる
    • 防御は「検知」から「耐性設計」へ:侵入前提で、権限・ネットワーク・データの分離を徹底する
    • AIセキュリティが専門領域として独立:従来のAppSec/CloudSecに、AI特有の評価観点が加わる
    • 規制・顧客要求が増える:説明責任、監査、データ管理が調達条件になる
    • 人材の取り合いが起きる:AI×セキュリティ×事業の三領域を理解する人材が不足する

    AI関連のセキュリティは、単一の製品カテゴリに収束しにくい領域です。LLMの挙動評価、プロンプト攻撃耐性、データ境界、監査ログ、運用プロセスなど論点が横断的だからです。そのため今後は、ツール導入に加えて、第三者による評価(診断・レビュー・レッドチーミング)と、運用を回す支援(監視・手順整備)がセットで求められる場面が増えていくでしょう。

    一方で、変わらないものもあります。資産管理、脆弱性管理、特権管理、バックアップ、監視、訓練などのいわゆる基本は、AI時代でも依然として高い効果を示します。AIがさまざまな能力を拡張してくれる機能を提供するため、基本が弱い組織ほど被害も増幅されます。

    まとめ:これからのセキュリティに携わる人へ

    攻撃も防御もAI時代に突入し、企業は「AIで守る」だけでなく「AIを守る」視点を持つことが不可欠になりました。重要なのは、AIを恐れることでも、AIに依存することでもありません。現場の運用と、経営の意思決定をつなぎ、継続的に改善できる仕組みを作ることです。

    そして、これからセキュリティ業界に携わりたい人、すでに現場で経験を積みステップアップしたい人に伝えたいのは、AIが広がるほど「基礎」が価値を増すという事実です。 攻撃者がAIで効率化するほど、守る側には、設計・運用・検証の地味な力が求められます。AIは学習すれば追いつけますが、現場の勘所である何を優先し、どこに投資し、どう回すかは、積み上げでしか身につきません。

    最後に、AI時代のセキュリティを一言で表すなら、「スピードの時代」です。攻撃のスピードが上がる以上、防御も“検知してから考える”では遅れます。 平時からの設計(境界・権限・ログ)と、迷わず動ける手順(初動・連絡・隔離・復旧)が、被害の差になります。AIはそれを加速してくれる道具にも、穴を広げる要因にもなります。だからこそ、今このタイミングで戦略を更新する価値があります。

    付録:企業が「今すぐ」着手できるチェックリスト

    AI利用の棚卸し(ガバナンスの入口)

    • 生成AIの利用実態(シャドーAI)を把握できているか
    • どの部署が、どのAI(外部/社内)を、どの業務に使っているか一覧化できているか
    • 取り扱うデータ(機密/個人情報/顧客情報/ソースコード等)を分類できているか
    • 外部AIに投入するデータのマスキング・匿名化・要約など、代替手段を用意しているか

    AIアプリ(RAG/チャットボット等)の設計・運用

    • 権限(誰が何にアクセスできるか)をAIの回答レベルまで落とし込めているか
    • 参照データの取り込み経路は管理され、改ざん検知やレビューがあるか
    • 監査ログ(誰が何を聞き、何を参照し、何を出力したか)を残せているか
    • ツール連携(実行系)を許す場合、二重確認・最小権限・停止スイッチがあるか

    AI時代の“人”への対策

    • フィッシング訓練はAI時代(自然文・音声・偽装)に合わせて更新したか
    • なりすまし対策(決裁・送金・機密共有の手順)を見直したか
    • インシデント対応訓練で「深夜の役員なりすまし」「AIの誤回答による事故」などを扱っているか

    ブロードバンドセキュリティからのご案内

    AI活用が進むほど、攻撃面は「システム」だけでなく「データ」「運用」「人」に広がります。まずは現状の棚卸しと、優先順位付けが重要です。ブロードバンドセキュリティ(BBSec)では、脆弱性診断(Web/アプリ/クラウド)に加え、運用設計・監視・セキュリティ運用支援まで、状況に合わせてワンストップでご支援可能です。必要に応じて、AI導入・AIアプリ運用に伴うリスクの洗い出しや、運用プロセスの整備もご相談いただけます。


    ―END―
    【前編】「AIが変える攻撃の現状と、防御側AI活用のリアル」はこちら


    執筆:上野 宣 氏
    株式会社トライコーダ代表取締役
    奈良先端科学技術大学院大学で山口英教授のもと情報セキュリティを専攻、2006年にサイバーセキュリティ専門会社の株式会社トライコーダを設立。2019年より株式会社Flatt Security、2022年よりグローバルセキュリティエキスパート株式会社、2025年より株式会社ブロードバンドセキュリティの社外取締役を務める。あわせて、OWASP Japan代表、一般社団法人セキュリティ・キャンプ協議会理事、NICT CYDER推進委員などを歴任し、教育・人材育成分野にも尽力。情報経営イノベーション専門職大学(iU)客員教員。

    編集責任:木下・彦坂

    スペシャル記事 TOPに戻る
    バックナンバー TOPに戻る


    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

    サービスに関する疑問や質問はこちらからお気軽にお問合せください。


    Security Serviceへのリンクバナー画像
    BBSecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像
    ウェビナーアーカイブ動画ページバナー画像

    特別寄稿/AI時代のセキュリティ戦略:上野宣氏が語る、攻撃と防御の最前線【前編】

    Share
    上野宣氏

    生成AIの急速な進化は、私たちの業務やビジネスの在り方だけでなく、サイバーセキュリティの常識そのものを塗り替えつつあります。攻撃者によるAI活用が高度化・自動化を加速させる一方で、防御側もまたAIを駆使した新たな対策を模索する時代に突入しました。攻撃と防御の双方でAI化が進むなか、企業はこれまでの延長線上にある対策だけで十分と言えるのでしょうか。いま、セキュリティ戦略そのものの再定義が求められています。

    本記事では、現ブロードバンドセキュリティ(BBSec)およびグローバルセキュリティエキスパート株式会社の社外取締役、そして長年にわたりサイバーセキュリティ分野を牽引してきた上野 宣氏に、AIとセキュリティを取り巻く最新動向、企業が直面する課題、そしてこれからの時代に求められる戦略の方向性について伺います。

    後編「AI時代に増えるリスクと、経営が取るべきアクション」はこちら


    AIが変える攻撃の現状と、防御側AI活用のリアル

    生成AI(LLM)の普及によって、サイバー攻撃のコストが劇的に低下しています。フィッシング文面の作成、標的企業の調査、マルウェアの作成、侵入後の横展開など、これまで人手と経験を必要としていた工程が、現在では半自動化されつつあります。犯罪ビジネスとして収益最大化を狙う攻撃者にとって重要なのは「時間を掛けて大物を狙うこと」ではなく、「いかに効率的に稼げるか」です。その結果、防御側には「特定の攻撃を止める」だけではなく「被害を最小化し、迅速に復旧する」という視点がこれまで以上に求められています。一方、防御側も、EDR/XDRやログ分析の高度化、セキュリティ運用(SOC/CSIRT)の自動化など、AIを取り入れた対策が急速に進んでいます。

    また、独立行政法人情報処理推進機構(IPA)が2026年1月29日に公開した「情報セキュリティ10大脅威 2026 [組織編]」では、「AIの利用をめぐるサイバーリスク」が初めて3位に選出されました。

    攻撃と防御の双方でAI化が進む現在、企業のセキュリティ戦略はどう変わるべきなのでしょうか。本稿では、攻撃者の視点で侵入を行うペネトレーションテストの経験を踏まえ、AI時代のセキュリティ最前線を整理し、現場と経営の双方が「明日から動ける」論点を提示します。

    AIが変えるサイバー攻撃の現状

    攻撃者は「巧妙さ」よりも「スケール」と「成功確率」を取りに来る

    AIがもたらした本質的な変化は、攻撃手法そのものの高度化ではありません。最大の変化は攻撃のスケール(量)と、標的に適した攻撃手法を選択できる確率が大きく向上した点にあります。

    • フィッシング/ビジネスメール詐欺(BEC)の高精度化
      役職や業務内容、業界用語に合わせた文面、自然な敬語表現、過去メールの文体模倣、会話の継続まで、生成AIが支援することができます。結果として「日本語が不自然」「誤字が多い」といった従来の判別ポイントが機能しなくなっています。さらに、メールに限らず、チャット(Teams/Slackなど)やSMS、SNSのDM、ビデオ会議(Zoom/Teamsなど)など複数チャネルを横断した心理的誘導も増えています。
    • ディープフェイク(音声・映像)によるなりすまし
      役員の音声を模した緊急指示など、本人になりすましたリアルタイムの会話を通じた詐欺など、人の心理を突く攻撃が進化しています。特に決裁フローが「口頭承認」「チャットでOK」で通る組織ほど影響が大きくなります。
      2024年初頭には、香港でCFOをディープフェイクで偽装し、ビデオ会議を通じて2,500万米ドル(約38億円)を詐取した事件が報じられました。従来、本人確認は「見て・聞いて・確認する」という感覚に依存していましたが、その前提自体が崩れています。

    [CFO(最高財務責任者)になりすまして2500万米ドルを送金させたディープフェイク技術 |トレンドマイクロ](https://www.trendmicro.com/ja_jp/research/24/c/deepfake-video-calls.html)

    • マルウェアの派生と検知回避の高速化
      既存コードの改変、難読化、検知回避の試行錯誤を短時間で回せるため、シグネチャ依存の検知は追随が難しくなります。加えて、侵入後の活動(権限昇格、横展開、永続化)に必要なコマンドや手順を考えるコストが下がり、攻撃者の習熟速度が上がります。
    • 偵察(Recon)と脆弱性悪用の自動化
      公開情報(OSINT)の収集、サブドメイン列挙、設定不備の探索、既知脆弱性(CVE)の当たり付けなど、攻撃の前工程が加速します。攻撃者は「露出している資産」「更新されていないミドルウェア」「放置された管理画面」のような守りの穴をAIで素早く見つけ、手当たり次第に試行します。
    • 生成AIによるコード生成とその限界
      生成AIは攻撃コードのたたき台(PoC)や、攻撃後の痕跡隠し(ログ削除や設定変更)の手順を提案することができます。攻撃者が高速に試行錯誤を行うことができるようになりました。ただし、生成物は常に正しいとは限らず、環境依存のミスも多くあります。AIは攻撃を容易にしますが、万能ではありません。

    2024年5月にはIT分野の専門知識を持たない人物が、生成AIを悪用してランサムウェアを作成し逮捕されたという国内事案も起きています。従来は一定の技術力が必要だった領域でしたが、AIが参入障壁を引き下げています。
    [生成AI悪用しウイルス作成、有罪判決…IT知識なくとも「1か月ぐらいで簡単に作れた」 | 読売新聞](https://www.yomiuri.co.jp/national/20241025-OYT1T50209/)

    AIは攻撃者にとって新しい武器というより、「既存の攻撃を、安く、速く、個別最適化して量産する装置」として機能しています。

    守る側が見落としがちな本質的脅威:攻撃者の「工数」ではなく「意思決定」が変わる

    AIで工数が下がると、攻撃者の意思決定が変わります。たとえば以前なら「ROI(投資利益率)が合わない」と見送られていた中堅企業や子会社、地方拠点も、数を打つ前提で標的に入りやすくなります。また、ランサムウェアのように侵入後に人が関与する攻撃でも、初期侵入の候補が増えるだけで全体の被害母数は増えます。

    企業は「自社は狙われない」ではなく、狙われる前提で、侵入しにくく・侵入されても広がらない設計に投資する必要があります。

    一方で、AI攻撃にも限界があります。生成物の誤り、環境依存、権限・ネットワーク制約など、現実の侵入は地味な制約だらけです。 だからこそ防御側は、AIを過度に恐れるよりも、AIによって「攻撃の頻度と質が上がる」前提で、基本対策を徹底しつつ、運用を強化することが重要になります。

    防御側のAI活用と、その限界

    「検知モデル」と「生成モデル」は役割が異なる

    防御側のAI活用を考える際、まず押さえたいことは、AIには大きく2種類の使い方があることです。

    1. 検知(判別)に強いAI:振る舞いから異常を検知し、アラートを出す(EDR/XDR、UEBAなど)
    2. 生成(要約・支援)に強いAI:文章の要約、問い合わせ応答、手順提案、チケット起票など運用補助を担う

    両者を混同すると、「AIを入れたのに検知できない」「要約は便利だが判断が危ない」といったミスマッチが起きます。導入時はAIに何を任せ、何を人が担うかを明確にすることが出発点になります。

    AIはすでに防御のコアである

    防御側のAI活用は、AI製品を買えば解決という単純な話ではありません。多くの企業で現実に進んでいるのは、次のような領域です。

    • EDR/XDRの検知ロジック強化
      従来のルールベースに加え、行動分析や相関分析を組み合わせ、攻撃の兆候を早期に拾う。
    • ログ分析/異常検知の高度化
      分散したログを統合し、普段と違う通信・認証・権限変更などを検知する。特にクラウドでは、設定変更(IaC、権限付与、APIキー利用)のログが要になります。
    • SOCの一次分析(トリアージ)の効率化
      アラート要約、関連ログの自動収集、影響範囲の仮説立て、過去事例の類推など、人が疲弊する作業をAIが肩代わりする。SOAR(自動対応)と組み合わせ、軽微なインシデントを自動封じ込めする例も出ています。
    • 脅威インテリジェンスの取り込み
      攻撃者のTTPやIoCを取り込み、自社ログと突合する。AIは情報の整理・関連付けに強い一方、最終的な妥当性判断は人が担う必要があります。
      AIが得意なのは「大量データの整理・優先順位付け」であり、最終判断(ビジネス影響、止める/止めない、復旧手順)は人間の責務として残ることです。

    AI防御の落とし穴

    AIを活用した防御には、以下のようなリスクがあることを知っておいて下さい。

    • 誤検知/見逃し(False PosITive/Negative)
      AIはもっともらしい出力を返しますが、誤りをゼロにはできません。誤検知が多いと現場はアラート疲れを起こし、逆に見逃しが増えます。
    • 説明可能性(ExplAInabilITy)の不足
      「なぜ検知したのか」が説明できないと、現場の納得も、経営への説明も難しいことがあり、監査や顧客説明に耐えない可能性もあります。
    • データの偏り/経時変化
      組織の利用状況、システム構成、攻撃トレンドは常に変わります。過去データに最適化されたAIは、時間とともに精度が落ちる可能性があります。
    • 生成AIの幻覚(ハルシネーション)
      運用支援にLLMを使う場合、誤った要約や根拠不明の推論が混ざることがあります。検証手順(根拠ログの提示、再現確認)を確立しておくことが必須となります。
    • 機密ログの扱い
      生成AIにログを投入する場合、そのログ自体が機密情報の塊です。保存、外部送信、学習利用、権限管理の設計を誤ると、防御強化のつもりが漏えいリスクになります。
      AIは防御の万能薬ではなく、運用を強くするための一要素に過ぎません。AIを導入するなら「どのKPIを改善するのか(初動時間、検知率、分析工数、MTTRなど)」を定義し、運用とセットで設計する必要があります。

    ―【後編】「AI時代に増えるリスクと、経営が取るべきアクション」 に続く―


    執筆:上野 宣 氏
    株式会社トライコーダ代表取締役
    奈良先端科学技術大学院大学で山口英教授のもと情報セキュリティを専攻、2006年にサイバーセキュリティ専門会社の株式会社トライコーダを設立。2019年より株式会社Flatt Security、2022年よりグローバルセキュリティエキスパート株式会社、2025年より株式会社ブロードバンドセキュリティの社外取締役を務める。あわせて、OWASP Japan代表、一般社団法人セキュリティ・キャンプ協議会理事、NICT CYDER推進委員などを歴任し、教育・人材育成分野にも尽力。情報経営イノベーション専門職大学(iU)客員教員。

    編集責任:木下・彦坂

    スペシャル記事 TOPに戻る
    バックナンバー TOPに戻る


    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

    サービスに関する疑問や質問はこちらからお気軽にお問合せください。


    Security Serviceへのリンクバナー画像
    BBSecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像
    ウェビナーアーカイブ動画ページバナー画像

    サプライチェーン攻撃で委託先が原因の情報漏えい時に企業が取るべき初動対応とFAQ

    Share
    「サプライチェーン攻撃で委託先が原因の情報漏えい時に企業が取るべき初動対応とFAQ」アイキャッチ画像

    委託先や外注先が原因で情報漏えいが起きた場合、「自社は何をすべきか」「どこまで責任を負うのか」といった判断に迷う企業は多くあります。本記事では、サプライチェーン攻撃が疑われる際の初動対応の考え方や、公表判断、委託先との連携のポイントを整理します。あわせて、企業担当者が抱きやすい疑問をFAQ形式でまとめ、実務で迷わないための視点を提供します。

    委託先や外注先を起点としたサプライチェーン攻撃の全体像や、なぜこのような事故が起きるのかについては、以下の記事で整理しています。
    サプライチェーン攻撃とは ―委託先・外注先リスクから情報漏えいを防ぐ全体像―

    「原因は委託先です」で終わらない現実

    情報漏えいが発覚したとき調査の結果として、「原因は委託先・外注先でした」と判明するケースは、近年珍しくありません。しかし実務の現場では、その事実が分かった瞬間に新たな問題が生じます。それは、「では自社は何をすべきなのか」「どこまで責任を負うのか」という判断です。委託先が原因であっても、情報の管理主体が自社である以上、初動対応を誤れば被害は拡大し、企業の信用は大きく損なわれます。サプライチェーン攻撃が増えている今、外部起因の情報漏えいを前提とした初動対応を理解しておくことは、企業にとって不可欠になっています。

    初動対応で最も重要なのは「切り分けを急がない」こと

    情報漏えいの疑いが出た直後、多くの現場で起きがちなのが、原因の切り分けを急ぎすぎることです。「本当に漏えいしているのか」「どこから漏れたのか」「委託先の責任なのか」といった点を早く確定させたくなるのは自然な反応です。しかしこの段階で重要なのは、責任の所在を断定することではありません。まず優先すべきなのは、被害が現在も拡大している可能性があるかどうかを見極め、必要に応じて影響範囲を止める判断をすることです。委託先が関係している場合でも、自社システムとの接点や連携は一時的に見直す必要があります。この判断が遅れると、被害が広がり続けるリスクがあります。

    サプライチェーン攻撃は経営リスクでもあります。経営視点で整理した記事はこちら。
    サプライチェーン攻撃と経営責任 ―委託先が原因でも問われる企業の判断とは ―

    またそもそも、なぜ取引先や委託先を経由した攻撃は発見が遅れやすいのか、その背景を理解しておくことも重要です。
    なぜ取引先経由で情報漏えいが起きるのか ―国内で相次ぐサプライチェーン攻撃の実態―

    委託先との連携は「確認」ではなく「事実の共有」から始める

    初動対応において、委託先への連絡は避けて通れません。ただしここで重要なのは、相手を問い詰めることではなく、事実を正確に共有することです。どの情報に異常が見られたのか、いつ頃から兆候があったのか、現時点で分かっていることと分かっていないことを整理し、共通認識を作ることが先決です。感情的なやり取りや責任追及は、この段階では状況を悪化させるだけになりがちです。委託先が保有しているログや調査状況を早期に把握できるかどうかは、その後の対応スピードを大きく左右します。

    社内では「技術対応」と「説明責任」を同時に考える

    外部起因の情報漏えいが疑われる場合、社内では複数の視点で同時に動く必要があります。システム部門やセキュリティ担当は技術的な影響範囲の確認を進める一方で、法務や広報、経営層は対外的な説明の準備を始めなければなりません。このとき、「原因が委託先だから自社は関係ない」という認識で対応が遅れると、結果的に説明責任を果たせなくなります。実際には、顧客や取引先から見れば、委託先かどうかは本質的な問題ではなく、「自分の情報がどうなったのか」が最も重要だからです。

    公表判断は“事実が揃うまで待つ”ほど危険になる

    情報漏えいの公表タイミングは非常に難しい判断です。しかし、すべての事実が揃うまで何も発信しない、という判断はリスクを高めることがあります。特に外部起因の場合、委託先側の調査に時間がかかり、自社で状況を完全に把握できない期間が発生しがちです。その間に情報が外部に漏れたり、第三者から指摘されたりすると、「隠していた」という印象を与えてしまいます。現時点で分かっている事実と、調査中であることを切り分けて伝える姿勢が、結果的に企業の信頼を守ることにつながります。

    契約内容は「事後」ではなく「初動」で効いてくる

    委託先が原因の情報漏えいでは、契約内容が初動対応に大きく影響します。インシデント発生時の報告義務や対応範囲が明確であれば、調査や情報共有をスムーズに進めることができます。一方で、契約にそうした取り決めがなく、対応が委託先任せになってしまうと、自社として判断すべき情報が集まらず、対応が後手に回ります。このとき初めて「契約を見直しておけばよかった」と気づく企業も少なくありません。

    初動対応をスムーズに行うためには、平時から委託先・外注先のセキュリティをどこまで確認しておくべきかを整理しておく必要があります。
    委託先・外注先のセキュリティはどこまで確認すべきか ―サプライチェーン攻撃を防ぐ実務判断―

    まとめ:初動対応で問われるのは“原因”より“姿勢”

    委託先が原因で情報漏えいが起きた場合、企業が最初に問われるのは、誰が悪いかではありません。どれだけ早く状況を把握し、被害拡大を防ぎ、関係者に誠実に向き合ったかという姿勢です。外部起因のインシデントは、今後さらに増えていくと考えられます。だからこそ、「委託先が原因だったらどうするか」を平時から想定しておくことが、最大の初動対策になります。

    サプライチェーン攻撃は、予防・管理・初動対応のいずれか一つだけでは防ぎきれません。全体像を理解し、実態を知り、現実的な確認と備えを重ねていくことが重要です。
    サプライチェーン攻撃とは ―委託先・外注先リスクから情報漏えいを防ぐ全体像―

    FAQ



    ▼サプライチェーン攻撃とは何ですか?




    ▼サプライチェーン攻撃は大企業だけの問題ですか?




    ▼委託先が原因で情報漏えいが起きた場合、自社に責任はありますか?




    ▼委託先のセキュリティはどこまで確認すべきですか?




    ▼セキュリティチェックシートを回収すれば十分ですか?




    ▼委託先が多すぎて管理しきれない場合はどうすればいいですか?




    ▼情報漏えいが疑われたとき、最初にやるべきことは何ですか?




    ▼委託先への連絡はどのタイミングですべきですか?




    ▼事実がすべて分かるまで公表しない方が良いですか?




    ▼契約書でセキュリティ対策はどこまで決めるべきですか?




    ▼サプライチェーン攻撃は完全に防げますか?




    ▼サプライチェーンリスク対策で最も重要な考え方は何ですか?




    ▼サプライチェーン全体を考えた対策を進めるには


    BBSecでは

    委託先が関係する情報漏えいでは、自社だけで完結する対応はほとんどありません。複数の関係者が絡むからこそ、事前の整理や体制づくりが結果を大きく左右します。ブロードバンドセキュリティ(BBSec)では、サプライチェーン全体を前提としたインシデント対応体制の整理や、外部起因の事故を想定した初動対応の支援を行っています。「起きてから考える」のではなく、「起きる前提で備える」ことが、これからの企業に求められる姿勢です。もし、委託先を含めた情報管理やインシデント対応に不安を感じている場合は、一度立ち止まって体制を見直すことが、将来のリスクを減らす確かな一歩になるでしょう。

    【参考情報】

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る


    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

    サービスに関する疑問や質問はこちらからお気軽にお問合せください。


    Security Serviceへのリンクバナー画像
    BBSecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像
    ウェビナーアーカイブ動画ページバナー画像

    武蔵小杉病院へのランサムウェア攻撃 ―第2報から読み解くランサムウェア侵入経路と影響範囲―

    Share
    「武蔵小杉病院へのランサムウェア攻撃 ―第2報から読み解くランサムウェア侵入経路と影響範囲―」アイキャッチ画像

    2026年2月、日本医科大学武蔵小杉病院は「院内の医療情報システムの一部がランサムウェア攻撃を受け、障害が発生した」こと、そしてそれに伴い患者の個人情報漏洩が確認されたことを公表しました*1。病院の発表は「第2報」という位置づけで、被害範囲、時系列、侵入経路、当面の診療体制、相談窓口までが具体的に示されています。まず強調したいのは、憶測で語られがちな“病院のサイバー攻撃”を、ここでは病院自身が明言した事実ベースで解説する点です。本記事では今回の公表内容(第2報)を中心に、医療機関サイバーセキュリティの観点で「何が起きたのか」「なぜ起きやすいのか」「利用者は何に気を付けるべきか」をわかりやすくまとめます。

    侵入経路は“医療機器保守用VPN装置”

    病院の第2報で明記された「攻撃を受けたシステム」は、ナースコールシステムのサーバー3台です。ナースコールは入院患者が看護師を呼ぶための仕組みとして広く知られていますが、その裏側では端末やサーバーが稼働し、運用上の都合から患者情報と結び付いているケースも珍しくありません。今回、病院は当該サーバーがランサムウェア攻撃を受けたことを認め、さらに調査の結果として「侵入経路は医療機器保守用VPN装置であった」ことが確認されたとしています。

    ここでいうVPN装置は、医療機器メーカーなどが遠隔で保守作業を行う目的で用いられることが多い仕組みです。便利な一方で、通常のIT統制の枠外に置かれやすいのが現実です。たとえば、病院の標準的なIT統制から外れた管理になっていたり、資産管理やパッチ適用、アクセス制御、多要素認証などの基本対策が後回しになっていたりします。厚生労働省も注意喚起の中で、VPN装置を含むゲートウェイ機器の脆弱性対策、管理インターフェースのアクセス制限、認証強化などを重要ポイントとして挙げています。今回の発表内容は、まさにその“急所”が突かれ得ることを示す事例として受け止めるべきでしょう。

    漏洩した個人情報

    病院は、漏洩が確認された個人情報の項目として、氏名、性別、住所、電話番号、生年月日、患者IDを挙げています。また、漏洩が確認された人数は「約1万人」で、これは2026年2月14日11時時点の確認値だとされています。一方で、患者が特に気にすると考えられる医療内容そのものについて、病院は「カルテ情報」の漏洩は現時点で確認されていないと明記しています。さらに、クレジットカード情報、マイナンバーカード情報についても、現時点では漏洩確認がないとしています。ここは不安を抱く利用者にとって重要なポイントです。ただし、ここでの注意点は「現時点では確認されていない」という表現が示す通り、調査が進む過程で情報が更新される可能性がゼロではないことです。病院も、仮に漏洩拡大が判明した場合はホームページで速やかに報告するとしています。

    いつ気づき、どう動いたのか

    第2報には、攻撃を認識した日時と経緯が日付単位で整理されています。最初の兆候は2026年2月9日午前1時50分頃、病棟のナースコール端末が動作不良となり障害を把握したことでした。その後、ナースコールシステムのベンダー調査により、サーバーがランサムウェア攻撃を受けたことが判明したとされています。病院は当該システムと関連ネットワークを遮断し、同日に文部科学省、厚生労働省、所轄警察へ報告したと公表しています。

    続く2月10日には、厚生労働省の初動対応チームの派遣要請を行い、外部接続ネットワークを遮断してサーバー保全を開始。2月11日には初動対応チームの調査により、当該サーバーが院外と不正通信を行い、患者の個人情報を窃取していたことを確認したとされています。さらに、電子カルテを含む他の医療情報システムへの影響調査、外部接続ネットワーク機器の脆弱性や設定の調査も開始した、と時系列で説明されています。2月12日に個人情報保護委員会へ報告し、2月13日には漏洩した患者へ郵送でのお詫び連絡を開始した、と続きます。

    この流れを見ると、ポイントは二つあります。ひとつは「障害として最初に見えた」こと、もうひとつは「通信ログ等の調査で情報窃取の事実確認に至った」ことです。ランサムウェアは“暗号化して身代金要求”のイメージが強い一方で、近年は暗号化だけでなく情報窃取を組み合わせ、二重三重の脅迫に発展するケースが問題視されてきました。今回の発表でも「不正通信」と「窃取」が明確に言及されており、病院がそこを重要事実として公表している点は見落とせません。

    病院業務は止まったのか

    医療機関へのサイバー攻撃で最も懸念されるのは、診療の停止や救急の受け入れ停止など、医療提供体制への影響です。今回、病院は2026年2月14日時点で、外来、入院、救急受け入れはいずれも通常通り実施していると説明しています。また「他の医療情報システムへの影響は現時点では確認されていない」とし、病院業務は通常通りと明記しています。

    ここで大事なのは、“通常通り”という言葉の解釈を膨らませすぎないことです。病院が示したのは、その時点で確認できている範囲の診療体制であり、現場では臨時対応や負荷増が起きている可能性はあります。ただ、少なくとも公表文の事実としては、全面停止や救急停止を示す記述はなく、「止めずに継続している」という説明が中心です。

    病院がとった封じ込めと復旧対応

    第2報の中で、病院は「当該システム及び外部との通信を一切遮断し、専門家や電子カルテベンダーと共に、他のシステムへの影響について詳細な現況調査を継続して実施しております。」とし、原因となったランサムウェアの特定を完了し、「ウイルス対策ソフト会社より提供された最新のパターンファイルを用いて、現在、院内全域でのウイルス駆除作業を実施しております。」と説明しています。

    サイバーインシデント対応として見ると、ここには典型的な優先順位が現れています。まず“広げない”ための遮断、次に“証拠を残す”ための保全、その上で“横展開の確認”として他システム影響調査、そして“回復”のための駆除作業です。特に医療機関では、電子カルテだけ守っても安全とは言い切れません。ナースコールのような周辺系、委託業者や医療機器ベンダーの保守経路、ネットワーク機器設定など、境界にある仕組みが狙われると、想定外の入口になります。私たちが特に注目すべきと考えるのは、医療機器保守用VPN装置が侵入経路として公表された点です。これは医療機関のセキュリティ対策が“例外管理”に弱いことを改めて突き付けています。

    詐欺・なりすましへの警戒

    今回漏洩が確認された情報には、氏名、住所、電話番号、生年月日が含まれます。これは、金融情報そのものではない一方で、なりすまし、勧誘、フィッシング、特殊詐欺の“材料”として悪用されやすい属性情報です。病院は、漏洩した患者に対して「直接連絡する」とし、実際に2月13日から郵送によるお詫び連絡を開始したと公表しています。したがって利用者側の現実的な対策は、まず「病院から届く郵送物や案内」を冷静に確認し、連絡先や手続きが公表内容と整合するかを見極めることです。そして電話やSMS、メールで“病院を名乗る連絡”が来た場合、いきなり個人情報を追加で伝えたり、リンクを開いて入力したりせず、病院が設置した問い合わせ窓口など、公式に案内された経路へ折り返し確認するのが安全です。病院は本件の相談・問い合わせ専用窓口(専用ダイヤルの複数回線やフリーダイヤル運用開始予定)を案内していますので、確認の際はそうした公式窓口を使うのが基本になります。

    よくある疑問:電子カルテは大丈夫なのか、身代金は払ったのか

    「電子カルテは大丈夫なのか」という疑問に対しては、病院の公表では、「他の医療情報システムへの影響は現時点では確認されていない」とされています。つまり、“影響なし”と断定しているというより、調査継続の前提で“少なくとも現時点の確認では影響が見つかっていない”という説明です。ここは言葉通りに受け止め、今後の更新を注視するのが適切です。

    「身代金を払ったのか」という点については、第2報の本文からは読み取れません。少なくとも病院は、侵入経路、漏洩項目、診療状況、当局報告、遮断・調査・駆除といった事実を中心に説明しており、金銭要求や支払いに関する記載は確認できません。ここで外部の憶測を混ぜると正確性が落ちるため、本記事では触れません。

    なぜ医療機関は狙われるのか:つながる医療機器

    医療機関のサイバー攻撃を考えるとき、電子カルテだけを守ればよいという発想は危険です。病院には、医療機器、保守用回線、委託業者のネットワーク接続、建物設備、ナースコールのような周辺システムまで、多様な“つながる仕組み”があります。しかも医療の現場は24時間止められず、更新・停止・入れ替えが難しい機器も少なくありません。結果として、VPN装置のような境界機器が古い設定のまま残りやすかったり、管理者が限定されて全体の統制が効きにくかったりします。

    厚生労働省の注意喚起でも、VPN装置を含むゲートウェイ機器の脆弱性対策を迅速に行うこと、管理インターフェースのアクセス制限を行うこと、多要素認証などで認証を強化すること、資産(IoT機器を含む)の把握を行うことが示されています。武蔵小杉病院の件で侵入経路が医療機器保守用VPN装置である、と公表されたことは、これらが“机上の理想”ではなく、現実の被害と直結する論点であることを、改めて裏付ける材料になっています。

    企業・組織側が学ぶべき教訓:VPNと保守経路の統制はセキュリティの“盲点”

    今回の公表内容から読み取れる最大の教訓は、保守のための例外的な経路を放置しないことです。医療機関に限らず、製造業、ビル管理、自治体、教育機関などでも、ベンダー保守用VPNは現場の利便性を理由に残りやすく、監査や更新の網から漏れがちです。だからこそ、ネットワーク図に載っていない接続点、ベンダーしか触れない装置、管理台帳にない機器といった“影の資産”を可視化し、アクセス制御、ログ監視、脆弱性対応、認証強化、契約と運用ルールの整備まで含めて統制する必要があります。また、今回病院が行ったように、初動で外部接続を遮断し、当局に報告し、初動対応チームや専門家と連携しながら調査と封じ込めを進めることは、医療機関のインシデントレスポンスとして重要です。平時から、遮断判断の基準、連絡系統、証拠保全の手順、ベンダー連携の契約条項、代替運用を準備しておかなければ、同じ判断を迅速に実行するのは難しくなります。

    まとめ

    日本医科大学武蔵小杉病院の公表によれば、今回のサイバー攻撃はナースコールシステムがランサムウェア攻撃を受けたことに端を発し、医療機器保守用VPN装置が侵入経路として確認され、患者の個人情報が窃取されたとされています。漏洩は約1万人、項目は氏名や住所、電話番号、生年月日、患者IDであり、カルテ情報やクレジットカード情報、マイナンバーカード情報の漏洩は現時点で確認されていない、というのが病院の説明です。

    “病院のサイバー攻撃”という言葉は刺激的ですが、重要なのは、どのシステムが攻撃され、どの経路が弱点になり、どんな情報が漏洩し、利用者と組織が何に備えるべきかを、事実に即して理解することです。今回の事例は、電子カルテ以外の周辺システムも含めた医療機関サイバーセキュリティの必要性、そしてVPN装置や保守経路を例外扱いしない統制の重要性を、強く示しています。今後も病院の続報で情報が更新される可能性があるため、一次情報の確認を前提に、過度な憶測ではなく、現実的な警戒と備えにつなげることが肝要です。

    サイバーインシデント緊急対応

    セキュリティインシデントの再発防止や体制強化を確実に行うには、専門家の支援を受けることも有効です。BBSecでは緊急対応支援サービスをご提供しています。突然の大規模攻撃や情報漏洩の懸念等、緊急事態もしくはその可能性が発生した場合は、BBSecにご相談ください。セキュリティのスペシャリストが、御社システムの状況把握、防御、そして事後対策をトータルにサポートさせていただきます。

    サイバーセキュリティ緊急対応電話受付ボタン
    SQAT緊急対応バナー

    ウェビナー開催のお知らせ

  • 2026年3月4日(水)14:00~15:00
    脱PPAP対策、添付ファイル運用、本当に最適ですか? ―添付するだけで自動分離。運用を変えない選択肢―
  • 2026年3月18日(水)14:00~15:00
    2026年、企業が直面するサイバー脅威 ― IPA 『情報セキュリティ10大脅威 2026』から考える対応戦略 ―
  • 2026年4月15日(水)14:00~15:00
    AI時代のサイバー脅威最前線 ― IPA『情報セキュリティ10大脅威2026』から学ぶ防御戦略 ―
  • 最新情報はこちら

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像