クレジットカード情報漏洩に備える ―非保持化・PCI DSS準拠でも漏洩が起きる理由とは―

Share
クレジットカード情報漏洩に備える ―非保持化・PCI DSS準拠でも漏洩が起きる理由とは―アイキャッチ画像

クレジットカード情報漏洩は、ECサイト加盟店だけの問題ではありません。非保持化やPCI DSS準拠を実施していても、Webサイトの脆弱性や設定不備を起点に漏洩が発生するケースは少なくありません。本記事では、実際の漏洩事例や発生後に直面する課題を踏まえながら、情報漏洩に備えるために押さえておきたいポイントを解説します。

なぜクレジットカード情報漏洩が起きるのか

クレジットカード情報漏洩は、ECサイト加盟店だけの問題として発生するわけではありません。ECサイトの決済は、ECサイト加盟店、決済代行事業者(PSP:Payment Service Provider)、アクワイアラ、国際ブランドなど、複数の事業者が連携して成り立っています。そのため、サイバー攻撃者に狙われる対象は、カード情報を直接保有するシステムだけに限られません。

実際には、ECサイト加盟店のECサイトや管理画面、CMS、外部委託先、決済画面へ遷移する前後の処理など、周辺のどこかにWebアプリケーションの脆弱性や設定不備が存在するだけで、カード情報の窃取につながる可能性があります。カード情報を自社で保持していない場合でも、サイト改竄や悪意あるコードの挿入によって、利用者が入力した情報が攻撃者へ送信されてしまうケースがあります。弊社のPFI調査資料でも、カード情報を自社保有していない企業からの漏洩に関する相談が多く発生していることが示されています。

ECサイトでは外部サービス連携、プラグイン更新、機能追加などが継続的に発生します。そのため、一度安全な構成を整備したとしても、それだけで安全性が維持されるわけではありません。日々の運用の中で新たに生まれた脆弱性が、攻撃の端緒となる場合があります。特に、Webアプリケーションの脆弱性や管理画面の設定不備は、PFI調査において主要な漏洩の原因として挙げられています。決済は複数の事業者が関与する仕組みであるため、そのサプライチェーンの一箇所で発生したサイバー攻撃が、ECサイト加盟店の業務停止、PSPへの問い合わせ対応、アクワイアラや国際ブランドへの報告対応へと波及する可能性があります。クレジットカードの情報漏洩は、単なる技術的な事故ではなく、決済サプライチェーン全体へ影響を及ぼすインシデントとして捉える必要があります。

実際に発生している情報漏洩事例

公表資料や業界資料を見ると、漏洩のきっかけは一様ではありません。ECサイトの改竄、不正ファイルの設置、偽の決済画面への誘導、委託先や関連システムの不備など、さまざまな経路からカード情報の窃取につながっています。経済産業省の資料でも、ECサイト加盟店、ECシステム提供事業者、PSP、消費者を狙ったフィッシング被害など、複数の漏洩事案の類型が整理されています。たとえば、ECサイト加盟店のECサイトに存在する脆弱性を突かれ、サイトが改竄されるケースがあります。この場合、カード情報を保持していなくても、不正ファイルの設置や偽の決済画面への誘導により、利用者が入力したカード番号等が攻撃者へ送信される可能性があります。また、委託先業者によるサイト更新時の設定不備を起点に、不正アクセスや情報漏洩につながるケースもあります。さらに、決済関連システム側の脆弱なアプリケーションへ不正アクセスされる事例も挙げられています。

PSPで情報漏洩が発生すると、利用者、ECサイト加盟店、クレジットカード会社など、多くの関係者を巻き込む被害につながるおそれがあります。これらの事例は、クレジットカード情報漏洩が単一のセキュリティ製品だけで防げる問題ではなく、開発、運用、委託管理、監視のすべてが関係する問題であることを示しています。また、近年は発覚経緯にも変化が見られます。2024年のカード情報流出事件では、警察の指摘により発覚した事案が35.1%を占めたとの分析もあります。また、2024年のクレジットカード不正利用被害額は555億円とされ、その9割超がECサイトでの番号盗用によるものとされています*1

これらの事例から分かるのは、クレジットカード情報漏洩が例外的な事故ではなく、現実的にはEC決済の現場で継続的に発生する身近なリスクだということです。PSPにとっても、漏洩元が自社であるか否かにかかわらず、問い合わせ、調査協力、ECサイト加盟店支援、関係者への説明といった対応が発生し得る点を踏まえる必要があります。

なぜ対策していても防げないのか

クレジットカードの情報漏洩対策として、「カード情報を保持しない非保持化」や「PCI DSS準拠」といった取り組みは非常に重要です。しかし、これらはリスクを低減するための対策であり、残念ながら漏洩を完全に防ぐことを保証してくれるものではありません。たとえば、カード情報の非保持化を行っている場合でも、ECサイトが改竄され、偽の入力フォームや悪意あるスクリプトが設置されてしまえば、利用者が入力したカード情報が攻撃者へと送信される可能性があります。つまり、カード情報を「保管していない」ことと、「情報入力時に窃取されない」ことは別の問題なのです。ECサイト全体の安全性まで担保されるわけではありません。PCI DSSについても同様です。PCI DSSに準拠していること自体が将来の侵害を否定してくれるものではありません。実際のインシデントでは、Webアプリケーションの脆弱性、管理画面の設定不備、委託管理先の不備、脆弱なパスワード設定など、複数の問題が重なって発生するケースが見られます。弊社のPFI調査資料でも、アプリケーションの脆弱性や管理画面の設定不備が主要な漏洩原因として挙げられています。

重要なのは、「非保持化しているから安全」、「PCI DSSに準拠しているから安全」と受け止めるのではなく、それぞれの対策が守れる範囲と限界を理解することです。クレジットカード情報漏洩は、技術、運用、管理といった複数の要因が重なって発生するため、防御だけではなく、継続的な監視や発生時の対応体制まで含めて備える必要があります。

インシデント発生後の現実

クレジットカード情報漏洩が疑われる事態に直面すると、現場では短時間で多くの判断が求められます。特に、次のような課題が発生する可能性があります。

  • 初動対応の遅れ
    被害拡大を防ぐため、ECサイトの停止、クレジットカード決済の一時停止、不正ファイルの確認、関係者への連絡などを並行して進める必要があります。対応が遅れた場合、新たな被害につながるおそれがあります。
  • ログ不足
    原因や影響範囲を調査しようとしても、必要なログが保存されていない、保存期間が短い、委託先から提供されないといった状況では、調査が難航します。ログの保全・管理体制が不十分であることが課題となるケースも少なくありません。
  • 調査・報告対応
    インシデント対応では、被害拡大を防ぐための封じ込めも重要です。さらに、個人情報保護委員会への報告や本人通知、公表対応など、時間的制約のある対外対応も並行して進めなければなりません。
  • 業務・信用への影響
    決済停止やECサイト停止は、売上の減少、顧客対応、問い合わせ対応の発生に直結します。実際に、クレジットカード決済の停止が長期化した事例や、決済再開までの期間、クレジットカード決済以外でECサイトを継続できるかといった相談も挙げられています。決済再開に向けた調整や関係者との連携も必要となり、事業運営や信用面にも大きな影響を及ぼす可能性があります。

PSPはどこまで責任を負うのか?

クレジットカード情報漏洩のインシデントでは、実際に情報漏洩が発生したECサイト加盟店やシステム事業者だけでなく、決済に関わる複数の事業者が対応を求められる場合があります。特にPSPはインシデント発生時に一定の関与が発生する可能性があります。たとえば、ECサイト加盟店からの問い合わせ対応、決済停止や再開に関する調整、関係各所への情報共有、調査協力などが挙げられます。また、利用者への影響範囲や決済への影響を整理する中で、PSPが保有するログや取引情報の確認が必要になるケースもあります。

もちろん、すべてのケースでPSPが法的責任を負うとは限りません。しかし実際には、「どのシステムで何が起きたのか」、「どこまで影響が及んでいるのか」を整理する過程で、決済のハブとしての対応が求められる場面があります。関係者間で認識や説明内容に差異が生じれば、公表内容や顧客説明にも影響する可能性があります。また、インシデント発生時には、技術的な問題だけでなく、ECサイト加盟店や委託先との調整、問い合わせ対応、事実確認など、実務面での負荷も大きくなります。そのためPSPにとっても、インシデント対応は「加盟店側の問題」と安易に切り離して考えられるものではありません。重要なのは、インシデント発生後に責任範囲を議論することだけではなく、平時から、どのような連携体制で対応するのか、どの情報を誰が保有しているのか、どのように調査や報告を進めるのかを十分に整理しておくことです。

インシデント対応で求められるフォレンジック調査

クレジットカード情報漏洩が疑われる場合、適切な封じ込めや再発防止につなげるためにも、何が起きたのかを客観的に把握することが重要です。そのため、フォレンジック調査では次のような対応を行います。

  • 原因の特定
    ECサイトの改竄、不正ファイルの設置、管理画面からの侵入など、どのような経路で侵害が発生したのかを調査し、事実関係を整理します。
  • 被害範囲の把握
    どの期間に、どの画面やシステムが影響を受け、どの情報が漏洩した可能性があるのかを確認します。影響範囲を把握することで、関係者への説明、外部報告、顧客対応、決済再開の判断をしやすくなります。
  • 侵入経路や影響の分析
    ログ、ファイル、通信履歴、システム構成などを調査し、侵入経路や改竄内容、攻撃の時系列、影響範囲を明らかにします。
  • 報告・説明対応の支援
    クレジットカード情報漏洩が疑われる場合には、アクワイアラや国際ブランド等への報告対応が求められることがあります。第三者による調査結果は、事実確認や説明責任を果たすうえで重要な根拠となります。
  • 再発防止にむけた基盤づくり
    フォレンジック調査は単なる原因調査ではなく、被害拡大防止、再発防止、関係者への説明を支えるための重要なプロセスです。ログ、ファイル、通信、システム構成などを確認し、侵入経路や改竄内容、攻撃の時系列、影響範囲を明らかにしていきます。何が分かり、何が分からないのかを整理することで、その後の対応につなげることができます。特にクレジットカード情報漏洩が疑われる場合には、アクワイアラや国際ブランド等への報告対応も想定されるため、第三者による調査結果が重要になる場面があります。

初動対応を左右する平時の備え

クレジットカード情報漏洩のインシデントでは、発生後の初動対応がその後の調査、報告、復旧に大きく影響します。どのシステムを確認するのか、どのログを保全するのか、誰に連絡するのかが整理されていなければ、対応開始までに時間を要してしまいます。結果として、被害範囲の特定や関係者への説明も遅れる可能性があります。そのため重要になるのが、「平時からの備え」です。具体的には、システム構成や委託先の把握、ログの保存場所や保全方針の確認、関係者の連絡先や判断権限の整理、初動対応手順の整備、外部専門家との連携体制の確保などが挙げられます。さらに、NDAや基本契約を事前に整えておけば、インシデント発生後に契約条件や情報共有範囲を調整する時間を減らし、調査や封じ込めに着手しやすくなります。これらを事前に確認しておくことで、発生時に「何から手を付けるか」と迷う時間を減らすことができます。

平時の備えは技術部門だけの課題ではありません。法務、広報、顧客対応、経営層、委託先を含めた体制整備が必要です。インシデント発生時には、技術調査と並行して、報告、通知、公表、問い合わせ対応が進むためです。クレジットカード情報漏洩対策では、防御策を強化することはもちろん重要です。しかし、それだけでは十分とはいえません。万一に発生した場合は、速やかに封じ込め、調査し、説明できる状態を作っておくことが重要です。

有事に備えた準備はできていますか?

クレジットカード情報漏えいが発生した場合、初動対応、原因調査、被害範囲の特定、関係各所への報告など、多くの対応を短期間で進める必要があります。BBSecでは、PCI SSC認定のPFIとして、クレジットカード情報漏えいフォレンジック調査を提供しています。万が一の際に迅速な対応を行うためにも、平時からの備えをご検討ください。
クレジットカード情報漏えいフォレンジック調査サービスはこちら

まとめ

クレジットカード情報漏洩は、ECサイト加盟店だけの問題ではなく、PSPを含む決済サプライチェーン全体に影響を及ぼすインシデントです。情報の非保持化やPCI DSS準拠といった対策は重要ですが、それだけでリスクを完全に防ぐことはできません。だからこそ、防御策に加え、発生時の初動対応、調査、関係者連携まで含めて、平時から備えておくことが重要です。


「非保持化しているから安心」とは言い切れない時代へ
情報漏洩インシデントは、Webアプリケーションの脆弱性や設定不備、運用上の課題など、複数の要因が重なって発生します。PCI DSS v4.0では、継続的な脆弱性管理やペネトレーションテストなど、従来以上に運用・監視を重視した対応が求められています。情報漏洩リスクに備えるために、PCI DSS v4.0で押さえておきたいポイントをウェビナーで詳しく解説しています。
【関連ウェビナー】「今さら聞けない!PCI DSS v4.0で求められる脆弱性診断
詳細・お申し込みはこちら


無料PDF|SQAT® Security Report 2026春夏号

サービスに関する疑問や質問はこちら


Security Serviceへのリンクバナー画像
BBSecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
BBSecホワイトペーパー「企業のセキュリティ成熟度チェックリスト」資料ダウンロードボタン

編集責任:木下

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

企業のセキュリティ成熟度 vol.1

Share

企業のセキュリティ成熟度チェック

このようなお悩みはありませんか?

  • 自社のセキュリティ対策レベルがわからない
  • どこに課題があるかわからない
  • セキュリティ対策の状況を客観的に確認したい

本資料では、40項目のチェックシートを通じて
セキュリティ対策状況の可視化と改善優先度の整理を支援します。

資料イメージ

BBSecセキュリティ成熟度チェック_チェックの概要イメージ
資料概要
BBSecセキュリティ成熟度チェック_チェックシートイメージ
40項目のチェックシート
BBSecセキュリティ成熟度チェック_スコア判定と改善アクション
スコア判定と改善アクション

診断結果の次の一手をお考えの方へ

vol.1「企業のセキュリティ成熟度チェック」で現状を把握した後は、結果に応じた対策の優先順位を整理することが重要です。vol.2「セキュリティ成熟度別ロードマップ」では、成熟度に応じて何から取り組むべきか、どのような順番で対策を進めるべきかを解説しています。チェック結果を具体的な改善アクションにつなげたい方は、ぜひあわせてご活用ください。

セキュリティ成熟度別ロードマップページリンクボタン

企業のセキュリティ成熟度チェックがダウンロードできるURLをお送りいたします。
ダウンロードご希望の方は下記の申し込みフォームからお申し込みください。

関連サービス


チェック結果を次のアクションにつなげませんか?

チェック結果を踏まえ、優先的に取り組むべき対策や改善の進め方について
専門家がご相談を承ります。自社に適した対策の整理にぜひご活用ください。


Security NEWS TOPに戻る

企業のセキュリティ成熟度 vol.2

Share

セキュリティ成熟度別ロードマップ

このようなお悩みはありませんか?

  • 何から対策を始めるべきかわからない
  • 対策の優先順位を整理したい
  • 限られたリソースで効率的に改善を進めたい

本資料ではセキュリティ成熟度に応じて優先的に取り組むべき対策と、
段階的な改善の進め方をわかりやすく整理しています。

資料イメージ

セキュリティ成熟度ロードマップ_全体像
成熟度別の対策ロードマップ
成熟度向上で得られる効果
改善に向けた次のアクション

まずは現状把握から始めたい方へ

セキュリティ対策の優先順位を検討する前に、まずは自社の対策状況を把握することが重要です。「企業のセキュリティ成熟度チェック」では、40項目のセルフチェックを通じて、現在の対策状況や改善が必要な領域を確認できます。

企業のセキュリティ成熟度チェックリストページリンクボタン

企業のセキュリティ成熟度チェックがダウンロードできるURLをお送りいたします。
ダウンロードご希望の方は下記の申し込みフォームからお申し込みください。

関連サービス


改善計画の策定や対策の優先順位付けでお悩みではありませんか?

セキュリティ対策は、企業の状況や成熟度によって優先すべき取り組みが異なります。
「何から着手すべきかわからない」
「自社に適した対策を整理したい」
といった場合は、お気軽にご相談ください。
BBSecが現状や課題を整理し、改善に向けた進め方をご提案します。


Security NEWS TOPに戻る

ゼロデイ脆弱性とは?最新事例と企業が取るべき対策を解説

Share
ゼロデイ脆弱性とは?最新事例と企業が取るべき対策を解説アイキャッチ画像

ゼロデイ脆弱性は、修正パッチが提供される前に悪用される極めて危険な脆弱性です。ChromeやFirefox、VPN機器など、企業で日常的に利用される製品でも継続的に確認されており、情報漏えいや業務停止につながるケースもあります。本記事では、ゼロデイ脆弱性の基本的な仕組みや実際の被害事例、従来対策が通用しにくい理由を整理しながら、企業に求められる現実的な対策について解説します。

ゼロデイ脆弱性が実際にどのように悪用されるのかについては、以下の記事で詳しく解説しています。
世界で多発するゼロデイ攻撃とは?Apple・Google・Ciscoを襲った脆弱性の実態と対策

本記事は2026年5月時点の情報をもとに作成しています。記載している脆弱性情報やCVE詳細は、公開後に内容が更新される場合があります。最新情報は各ベンダーおよびNVD・CISAの公式情報をご確認ください。

はじめに

ChromeやFirefoxなど、日常業務で広く使われている主要ブラウザでも、ゼロデイ脆弱性は繰り返し確認されています。ゼロデイ脆弱性とは、製品ベンダーや利用企業が十分な修正猶予を持てないまま悪用される、極めて危険度の高い脆弱性です。企業にとってゼロデイ脆弱性が厄介なのは、単に危険な脆弱性であるという点だけではありません。多くの場合、攻撃が確認された時点では、すでに悪用が始まっているか、修正パッチの適用が間に合っていない状態です。つまり、通常のパッチ管理や既知のマルウェア検知だけでは、防御が後手に回る可能性があります。 Webブラウザ、VPN機器、セキュリティ製品、業務アプリケーション、開発支援ツールなど、企業活動を支えるソフトウェアの多くは、常に外部との接点を持っています。そのため、ゼロデイ脆弱性は情報漏えい、業務停止、信用毀損、取引先への影響といったビジネスリスクに直結します。まず押さえたいのは、ゼロデイ脆弱性を悪用した攻撃に対し、完全に避けるのではなく、発生を前提に、侵入されにくく、侵入されても早期に検知し、被害を抑え込める体制を整えることです。

ゼロデイ脆弱性とは何か

ゼロデイ脆弱性とは、製品ベンダーや利用者がまだ十分に把握していない、または修正パッチが提供されていない脆弱性を指します。「ゼロデイ」という言葉は、攻撃者に悪用される可能性があるにもかかわらず、防御側に残された対応猶予が実質的にゼロ日であることに由来します。ここで整理しておきたいのが、「脆弱性」と「攻撃」は同じものではないという点です。脆弱性は、ソフトウェアやシステムに存在するセキュリティ上の欠陥です。一方で、ゼロデイ攻撃は、その未知または未修正の欠陥を悪用して、情報の窃取、権限昇格、不正コード実行、システム侵入などを行う攻撃行為を指します。NIST(米国立標準技術研究所)では、ゼロデイ攻撃を「これまで知られていなかったハードウェア、ファームウェア、ソフトウェアの脆弱性を悪用する攻撃」と定義しています。

たとえば、あるブラウザに不正なHTMLページを処理した際に任意のコード実行につながる欠陥があったとします。その欠陥自体がゼロデイ脆弱性であり、攻撃者が細工したWebページへ利用者を誘導して実際に悪用すれば、それがゼロデイ攻撃になります。CVEはこうした脆弱性を識別するための共通番号であり、NVD(米国国立脆弱性データベース)ではCVEプログラムについて、「特定のコードベースで確認された脆弱性を参照するための辞書、または用語集のような仕組みだ」と説明しています。

なぜゼロデイ脆弱性は危険なのか

ゼロデイ脆弱性が危険視される最大の理由は、修正パッチが存在しない、または広く適用される前に攻撃が始まることです。一般的な脆弱性対応では、ベンダーが脆弱性情報を公開し、修正パッチを提供し、企業が影響範囲を確認して適用するという流れになります。しかしゼロデイの場合、この順番が崩れます。攻撃者が先に脆弱性を把握し、攻撃に利用してから、ベンダーや利用者が気づくことがあるためです。もう一つの問題は、従来型のシグネチャ検知が効きにくいことです。シグネチャ型のセキュリティ対策は、既知のマルウェアや既知の攻撃パターンを検出するうえでは有効です。しかし、まだ十分に解析されていない攻撃コードや、新しい悪用手法に対しては、検知が遅れる可能性があります。NISTの関連文献でも、「ゼロデイ攻撃は未知の脆弱性を悪用するため従来のシグネチャ型検知では事前に攻撃シグネチャを用意できず有効性に限界がある*2」とされています。

ゼロデイ攻撃は、標的型攻撃にも使われやすい傾向があります。攻撃者にとって、未修正の脆弱性は価値の高い侵入口です。特に、ブラウザ、VPN、ファイアウォール、メールサーバ、リモートアクセス製品、エンドポイント管理製品などは、企業ネットワークの入口や重要な業務環境とつながっているため、攻撃が成功した場合の影響が大きくなります。 ビジネス面では、ゼロデイ脆弱性の悪用は情報漏えい、業務停止、顧客対応コストの増加、監督官庁や取引先への報告、ブランド信用の低下などに発展します。攻撃の起点が一台の端末や一つのWebアクセスであっても、その後に認証情報の窃取、横展開、機密情報の持ち出しが行われれば、被害は組織全体へ拡大します。

実際の被害事例

Google Chromeで相次いだゼロデイ脆弱性

ゼロデイ脆弱性の代表的な事例として、Google Chromeの脆弱性が挙げられます。Chromeは多くの企業で標準ブラウザとして利用されており、Webメール、SaaS、業務システム、クラウド管理画面などへのアクセスにも使われています。そのため、Chromeのゼロデイ脆弱性は、単なる個人利用者向けブラウザの問題ではなく、企業の業務端末リスクとして捉える必要があります。

2025年には、Chromeで悪用が確認されたゼロデイ脆弱性が複数回修正されました。BleepingComputerでは、2025年から2026年にかけてChromeは複数のゼロデイ脆弱性を修正したと報じています*2。2026年2月には、CVE-2026-2441が修正されました。NVDによれば、この脆弱性はChromeのCSSにおけるUse After Free(解放済メモリの再利用)の問題であり、 Google Chrome 145.0.7632.75より前のバージョンでは、細工されたHTMLページを介してリモート攻撃者がサンドボックス内で任意のコードを実行できる可能性がありました。GoogleのChrome Releasesでも、この脆弱性について「実際に悪用が確認されている」旨が記載されています。2026年3月には、CVE-2026-3909CVE-2026-3910が修正されました。CVE-2026-3909は「Skia(Chromeが使用するグラフィック処理ライブラリ)における境界外の書き込み」で、細工されたHTMLページを介して境界外メモリアクセスにつながる可能性があります。CVE-2026-3910は「V8(ChromeのJavaScript実行エンジン)における不適切な実装」で、細工されたHTMLページを介してサンドボックス内で任意のコード実行が可能となるおそれがありました。GoogleはCVE-2026-3910について、「実際に悪用が確認されている」と公表しています。また、2026年3月末にはCVE-2026-5281も修正されています。NVDによれば、これはChromeのDawnにおける解放済メモリの再利用の脆弱性で、レンダラープロセスが侵害された状態で、細工されたHTMLページを通じて任意のコード実行につながる可能性があるものです。Googleはこの脆弱性についても、「実際に悪用が確認されている」と公表しています。

これらの事例が示しているのは、Webブラウザが単なる閲覧ツールではなく、企業ネットワークへの入口になり得るということです。利用者が業務中にWebサイトを閲覧する、SaaSへアクセスする、メール内のリンクを開くといった日常的な操作が、ゼロデイ攻撃のきっかけになる可能性があります。

OpenAI Codexに関するサンドボックス迂回の事例

近年は、開発支援ツールやAI関連ツールもゼロデイリスクの対象になっています。Zero Day Initiativeは2026年4月、OpenAI Codexに関するZDI-26-305を公開しました*3。この脆弱性は、影響を受けるOpenAI Codex環境においてサンドボックスを迂回できる可能性があるものとされ、攻撃には、「標的ユーザーが悪意あるJavaScriptを含むリポジトリをCodexで処理する必要がある」と説明されています。OpenAI Codex CLIでは2025年にも、サンドボックス設定ロジックの問題により、意図したワークスペース境界を迂回し、Codexプロセスが権限を持つ範囲で任意のファイル書き込みやコマンド実行につながる可能性がある脆弱性が、GitHub Security Advisoryで公開されています*4。この問題はCodex CLI 0.39.0で修正され、利用者には更新が推奨されています。

この事例から分かるのは、ゼロデイ脆弱性がOSやブラウザだけの問題ではないということです。開発者が利用するCLIツール、AIエージェント、コード生成支援ツール、CI/CD環境も、企業の重要な攻撃面になりつつあります。特に、ソースコード、認証情報、クラウド設定、APIキーにアクセスする可能性があるツールでは、サンドボックスや権限管理を過信しない運用が必要です。

ゼロデイ攻撃の仕組み

ゼロデイ攻撃の流れ概要図

※ゼロデイ攻撃では、脆弱性公開前や修正前に攻撃が始まるため、従来型のシグネチャ検知だけでは防御が難しい場合があります。

ゼロデイ攻撃は、脆弱性の発見から攻撃実行までが非常に速い場合があります。攻撃者は、ソフトウェアの不具合を独自に発見することもあれば、脆弱性情報が闇市場や限定的なコミュニティで売買されることもあります。その後、攻撃者はその脆弱性を悪用するエクスプロイトコードを作成し、標的組織に対して攻撃を実行します。まず、未公開または未修正の脆弱性が発見されるところから始まります。次に、その脆弱性を悪用するための攻撃コードが作成されます。ブラウザの脆弱性であれば、細工されたHTMLページやJavaScriptが使われることがあります。VPNや外部公開サーバの脆弱性であれば、インターネット越しに直接攻撃が行われることもあります。攻撃が成功すると、攻撃者は端末やサーバへ侵入し、認証情報の取得、権限昇格、内部ネットワークへの横展開を試みます。その後、機密情報の収集、データの持ち出し、ランサムウェアの展開、バックドア設置などへ進む可能性があります。

ゼロデイ攻撃の基本的な仕組みについては、以下の記事でも詳しく解説しています。
世界で多発するゼロデイ攻撃とは?Apple・Google・Ciscoを襲った脆弱性の実態と対策

従来対策が通用しない理由

ゼロデイ脆弱性への対応で難しいのは、従来のセキュリティ対策が必ずしも十分に機能しないことです。もちろん、ウイルス対策ソフト、ファイアウォール、パッチ管理、メールセキュリティ、URLフィルタリングといった対策は今でも重要です。しかし、ゼロデイ攻撃では、これらをすり抜ける可能性があります。シグネチャ型対策は、既知の攻撃には強い一方で、未知の攻撃には限界があります。攻撃コードが新しく、まだ検体や攻撃パターンが共有されていない場合、検知ルールが存在しないことがあります。さらに、攻撃者は正規のWeb通信、正規のプロセス、正規の認証情報を利用して侵入後の活動を行うため、外形上は通常の業務通信に見えることもあります。また、境界防御だけに依存した対策では対応が難しいケースも増えています。クラウドサービスやリモートワークの拡大により、従来の「社内は安全」という前提だけでは、ゼロデイ攻撃のような未知の脅威への対応が難しくなっています。ゼロデイ攻撃では、社内端末、クラウドアカウント、開発端末、外部公開資産のどこからでも侵入口が生まれる可能性があります。

ゼロトラストの考え方を含め、従来型セキュリティ対策の課題については、こちらの記事でも詳しく解説しています。
ゼロトラストセキュリティ -今、必須のセキュリティモデルとそのポイント-

ゼロデイ脆弱性への対策

ゼロデイ脆弱性への対策では、未知の攻撃を完全に防ぐことだけでなく、侵入後の被害を最小限に抑えるアプローチが重要です。ゼロトラストに基づく権限管理や多要素認証に加え、EDRやXDRによる侵入後の検知、ASMによる攻撃面の把握、SOCによる継続監視などを組み合わせた多層的な対策が求められます。

ゼロデイ攻撃対策を支援するBBSecのアプローチ

ゼロデイ攻撃へ備えるには「脆弱性情報を知ること」だけでなく、「自社がどの製品を利用しているのか」「どこが外部公開されているのか」を知ることで自社環境への影響を迅速に把握し、継続的に監視・対応できる体制を持つことが重要になります。

ブロードバンドセキュリティ(BBSec)では、EDR-MSSによる侵入後の検知・対応、G-MDRによる高度な脅威分析、ASMによる攻撃面の可視化を通じて、企業のゼロデイ対策を支援しています。ゼロデイ脆弱性への備えを強化したい方は、以下のサービスページもあわせてご覧ください。

ASM(アタックサーフェス管理)の考え方や、攻撃面を継続的に把握する重要性については、こちらの記事でも詳しく解説しています。
脆弱性管理とIT資産管理 -サイバー攻撃から組織を守る取り組み-

まとめ

ゼロデイ脆弱性は、主要ブラウザやVPN機器、業務ソフトウェアなど、企業が利用するさまざまな環境で発生する可能性があります。ゼロデイ攻撃による被害を抑えるためには、パッチ管理だけでなく、ゼロトラストに基づく権限管理、EDRやXDRによる侵入後の検知、ASMによる攻撃面の把握、SOCによる継続監視などを組み合わせた多層的な対策が求められます。

【参考情報】


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

  • 2026年6月3日(水)14:00~15:00「金融機関の対応事例に学ぶPQC移行の進め方と実務ポイント
  • 2026年6月10日(水)14:00~14:30「Webサイトの見えない脅威を可視化する 外部タグ・サードパーティースクリプトの監視対策
  • 最新情報はこちら


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

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


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

    編集責任:木下

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

    バックナンバー

    Share

    バックナンバー


    情報漏洩対策とは何か ―企業が知るべき原因・リスク・防止策の全体像―アイキャッチ画像情報漏洩対策とは何か ―企業が知るべき原因・リスク・防止策の全体像―
    2026.4.15
    「IPA情報セキュリティ10大脅威 2026に見る、AI時代のサイバーリスク」アイキャッチ画像IPA情報セキュリティ10大脅威2026にみる、AI時代のサイバーリスク
    2026.4.8
    「脆弱性管理とは?企業が行うべき脆弱性管理の基本と実践手順」アイキャッチ画像脆弱性管理とは?企業が行うべき脆弱性管理の基本と実践手順【2026年版】
    2026.4.8
    Claude Code流出問題の全体像アイキャッチ画像Claude Code流出問題の全体像
    ―事件からわかるAI開発リスクとサプライチェーンリスク―

    2026.4.3
    Axiosのサプライチェーン攻撃とは何だったのかアイキャッチ画像Axiosのサプライチェーン攻撃とは何だったのか
    ―npm改ざんの経緯、影響範囲、企業が今すぐ確認すべき対応を解説―

    2026.4.3
    セキュリティ運用体制の作り方 属人化を防ぐ役割分担と外部活用の考え方アイキャッチ画像セキュリティ運用体制の作り方 属人化を防ぐ役割分担と外部活用の考え方
    2026.4.1
    TLS設定の安全性と確認ポイントアイキャッチ画像TLS設定の安全性と確認ポイント:古い暗号設定が引き起こすリスクと改善手順
    2026.4.1
    TLSバージョンの確認方法とは?アイキャッチ画像TLSバージョンの確認方法とは?
    ブラウザ・OpenSSL・ツールでのチェック手順と安全な設定ポイント

    2026.4.1
    セキュリティ運用は何から始めるべきか 担当者が最初に整理すべきポイントアイキャッチ画像セキュリティ運用は何から始めるべきか 担当者が最初に整理すべきポイント
    2026.3.25
    セキュリティ運用とは?属人化を防ぎ継続的に回す基本の考え方アイキャッチ画像セキュリティ運用とは?属人化を防ぎ継続的に回す基本の考え方
    2026.3.18
    緊急パッチ適用の判断基準 ―業務影響を抑えるにはどうすべきか―アイキャッチ画像緊急パッチ適用の判断基準 ―業務影響を抑えるにはどうすべきか―
    2026.3.11
    脆弱性の意味を正しく理解する―読み方・具体例・種類をわかりやすく解説アイキャッチ画像脆弱性の意味を正しく理解する―読み方・具体例・種類をわかりやすく解説
    2026.3.11
    脆弱性診断の必要性とは?ツールなど調査手法と進め方アイキャッチ画像脆弱性診断の必要性とは?ツールなど調査手法と進め方
    2026.3.11

    SQAT® Security Information TOPに戻る
    Security NEWS TOPに戻る

    Webアプリケーション脆弱性診断のサービスのご紹介資料および年二回発行されるセキュリティトレンドの詳細レポートをダウンロードできるURLをお送りいたします。
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

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

    ソーシャルエンジニアリングとは?代表的な手口・事例・対策を解説

    Share

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

    SQAT® Security Report 2020-2021年 秋冬号掲載
    「人という脆弱性~ソーシャル・エンジニアリング攻撃~」より一部抜粋

    特殊詐欺のイメージ画像(電話・お金・メモ)

    サイバー攻撃というとシステムの脆弱性を狙うイメージがありますが、実際には「人」を狙う攻撃が多く発生しています。ソーシャルエンジニアリングは、人間の心理や行動の隙を悪用して情報を窃取する攻撃手法です。標的型メール、なりすまし、SNSを利用した情報収集など、その手法は年々巧妙化しています。本記事では、ソーシャルエンジニアリングの代表的な手口や心理的脆弱性について解説します。

    ※本記事は「SQAT® Security Report 2020-2021年 秋冬号」の内容を一部再編集したものです。

    この記事でわかること

    • ソーシャルエンジニアリングとは何か
    • 人が騙される心理的要因
    • 代表的な攻撃手法
    • 企業で必要な対策
    • セキュリティ教育の重要性

    ソーシャルエンジニアリングとは

    そもそも、ソーシャル・エンジニアリングとは何なのだろうか? ソーシャル・エンジニアリングフレームワークの第一人者と知られるクリストファー・ハドナジー(Christopher Hadnagy)氏は、著作『ソーシャル・エンジニアリング』(日経BP社)の中で、ソーシャル・エンジニアリングを「人を操って行動を起こさせる行為。ただし、その行動が当人の最大の利益に適合しているか否かを問わないこともある」と定義づけている。これには警察官、弁護士、医師といった人々が、標的当人の利益となるように誘導するといったケースも含まれているが、一般的にサイバー攻撃におけるソーシャル・エンジニアリングとは、不正アクセスするのに必要なシステム情報、アカウント、パスワード、ネットワーク・アドレス等を正規のユーザあるいはその家族、友人などから人間の心理的な隙や、行動のミスにつけ込んで手に入れる手法と位置付けられることが多くなっている。ソーシャル・エンジニアリング攻撃の定義は様々なものがあるが、その共通するところは、人を介して攻撃を行うという点である。

    なぜ人は騙されるのか

    では、なぜ人が脆弱性となってしまうのか、この点について、原因の一つとなっていると考えられる、人に存在する心理的脆弱性を見ていきたい。ハドナジー氏は人には以下のような8つの心理的脆弱性が備わっていると主張している。

    返礼

    人からの親切に対し、お返しをせずにはいられない特性
    例:プレゼントのお返しに、何かしてほしいことはないかと聞く。

    義務感

    社会的、法的、道徳的に、人がなすべきだと感じている行動をとってしまう特性
    例:身体が不自由な人に、積極的に手を差し伸べなくてはならないと考えて寄付を行う。

    譲歩

    何かを譲ってもらったら、同じように譲らなくてはならないと考える特性
    例:相手の大きな要求を最初に断ったのだから、次の小さな要求には応じてあげたいと考える。

    希少性

    入手しづらいものであるほど貴重なものに思え、手に入れたくなってしまう特性
    例:同様の商品の中で手に入れるなら、期間限定で販売された商品を手に入れたいと考える。

    権威

    組織的、社会的に、強い権威者とみなされる者の命令に従ってしまう特性
    例:強い権威を持つ人間が言っているのだから、正しいと考える。

    言質と一貫性

    自分や他人の行動・言質が、過去から一貫性がとれていることを高く評価する特性
    例:一度購入すると言ったものが、予想よりも高かったとしても、前言を撤回するのは恥ずかしいと考える。

    好意

    好意を持っている人から頼まれると、承諾してしまう特性
    例:親密な人から何かを頼まれると、そうでない人から頼まれるよりも簡単に請け負ってしまう。

    コンセンサスもしくは社会的証明

    他人の考えにより、自分が正しいかどうかを判断する特性
    例:有名人が利用している商品を、自分も利用したいと考える。


    代表的なソーシャルエンジニアリング攻撃

    ここ数年、ソーシャル・エンジニアリングを用いた攻撃による大規模な事件が多数発生している。

    ・2015年に発生した日本年金機構の大規模な情報漏洩事件*5
    ・2017年の大手航空会社が3億8000万円をだましとられた事件*2
    ・2018年の暗号通貨の不正送金事件*3
    ・2020年7月に起きた大手SNSの大規模アカウントハック事件*4

    これらはすべてソーシャル・エンジニアリングを用いた攻撃に端を発しているといわれている。ソーシャル・エンジニアリングを用いた攻撃の高まりを受けて、IPA(独立行政法人 情報処理推進機構)が「ソーシャル・エンジニアリングを巧みに利用した攻撃の分析と対策」*5 を発表したのが2009年であるが、10年以上が経過した今も、ソーシャル・エンジニアリングを用いた攻撃は、収まる気配がない。それは、ソーシャル・エンジニアリングが持つ、人間という脆弱性を狙う性質に原因がある。ここでは、今一度、ソーシャル・エンジニアリングと人間とのかかわりを考えていきたいと思う。


    公開日:2021年9月17日
    更新日:2026年5月27日

    編集責任:木下


    Security Report 2020-2021年 秋冬号表紙画像

    弊社では、ソーシャルエンジニアリング攻撃や人的脆弱性について詳しく解説した
    SQAT® Security Report 2020-2021年 秋冬号」を無料公開中です。ぜひ資料ダウンロードをしてご一読ください。

    ※参考(続き)
    contents
    4.人へのバッファオーバーフロー攻撃
    5.人間の隙をつくソーシャル・エンジニアリング攻撃
    6.テクノロジーが人間を追い詰める
    7.ソーシャル・エンジニアリングに対する防御
    8.おわりに

    人的セキュリティ対策を強化したい方は、ぜひご活用ください。

    無料PDF|SQAT® Security Report 2020-2021秋冬号

    その他のSQAT® Security Report

    無料PDF|SQAT® Security Report 2026春夏号

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

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

    企業の情報漏洩対策 ―すぐに実践できる防止策と運用のポイント―

    Share
    企業の情報漏洩対策 ―すぐに実践できる防止策と運用のポイント―アイキャッチ画像

    情報漏洩対策をしているつもりでも、誤送信や設定ミス、委託先での事故は起き続けています。多くの企業では、セキュリティ製品を導入していても、運用上の抜け漏れから情報漏洩が発生しています。情報漏洩対策というと、まずはセキュリティ製品の導入やシステム強化を思い浮かべるかもしれません。しかし、実際の漏えい事故は、不正アクセスだけでなく、誤送信、設定ミス、権限管理の不備、委託先での事故など、日常運用の中からも発生します。情報漏洩対策は、製品導入の話ではなく、業務として回る仕組みづくりとして捉えることが重要です。本記事では、アクセス制御、ログ管理、権限管理、委託先管理まで、企業が実践すべき対策と運用のポイントを解説します。

    情報漏洩の基本的な仕組みやリスクについては、以下の記事で整理しています。
    情報漏洩対策とは何か ―企業が知るべき原因・リスク・防止策の全体像―

    情報漏洩対策は“技術だけでは防げない”

    技術対策は重要ですが、それだけで情報漏洩を防ぎ切ることはできません。たとえば、認証機能やアクセス制御が整っていても、過剰な権限が放置されていれば内部不正やアカウント侵害の被害は拡大します。ログを取得していても、監視やレビューの運用がなければ異常を見逃します。ファイルを暗号化していても、共有ルールや持ち出しルールが曖昧であれば、漏えいリスクは残ったままです。IPA(独立行政法人情報処理推進機構)「情報セキュリティ10大脅威 2025」解説書」でも、情報セキュリティ対策は「基本対策」と「共通対策」を組み合わせ、組織ごとの状況に応じて優先度を決めるべきだと示されています。また、情報漏洩対策では、まず「どこに情報があり、誰がアクセスでき、どの委託先に渡っているのか」を把握する必要があります。見えていない情報資産や権限、再委託先は、そのままリスクになります。

    個人情報保護委員会の考え方でも、委託先を含めた個人データの取扱いでは、適切な委託先の選定、委託契約の締結、委託先における取扱状況の把握が必要とされています。つまり、情報漏洩対策は社内システムの防御だけでなく、運用ルール、監督体制、委託先管理まで含めて初めて成立します。

    そもそも情報漏洩がどのように発生するのかについては、原因と事例をまとめた記事をご参照ください。
    情報漏洩はなぜ起きるのか ―企業で多い原因と最新事例から見るリスクの実態―

    基本となる情報漏洩対策

    アクセス制御

    情報漏洩対策の基本は、必要な人だけが必要な情報にアクセスできる状態を維持することです。IPA「情報セキュリティ10大脅威 2025」解説書の「セキュリティ対策の基本と共通対策」では、認証を適切に運用することが共通対策として示されており、ID・パスワード管理、多要素認証、権限管理の適正化は広範な脅威への基礎になります。過剰な権限は、内部不正だけでなく、アカウント侵害時の被害拡大にも直結します。実務では、退職者や異動者の権限削除漏れ、共有フォルダの開放状態、委託先アカウントの恒久利用などが起きやすいため、定期的な権限棚卸しが必要です。情報漏洩対策を強化するなら、まず「誰がどの情報にアクセスできるか」を見える化することが出発点になります。

    ログ管理

    ログ管理は、情報漏洩そのものを直接防ぐ対策ではありませんが、不審な挙動の検知、事故発生後の原因分析、被害範囲の特定に欠かせません。個人情報保護委員会が公表した「不正アクセス発生時のフォレンジック調査の有効活用に向けた着眼点(令和8年1月16日)」でも、フォレンジック調査や記録保全の有効性が整理されており、証跡が十分に残っていなければ初動判断も再発防止も難しくなることが示唆されています。そのため、ログは「取っている」だけでは不十分です。重要データへのアクセス、管理者操作、外部共有設定の変更、異常なログイン試行など、何を記録し、誰が見て、どうエスカレーションするかまで定めておく必要があります。情報漏洩対策におけるログ管理は、監査対応のためではなく、実際に異常を捉えるための運用として設計するべきです。

    暗号化

    暗号化は、端末紛失や媒体盗難、通信経路の盗聴などによる情報漏洩の被害を抑えるための基本対策です。すべての事故を防げるわけではありませんが、保存データや送受信データが適切に暗号化されていれば、漏えい時の実害を抑えられる可能性があります。IPAも基本対策について、「技術的な保護措置を一つで考えるのではなく、複数の対策を重ねて講じる考え方が重要」と示しています*6

    ただし、暗号化も運用が伴わなければ形骸化します。暗号鍵の管理が甘い、復号可能な状態でファイル共有している、個人端末へのデータ保存を許しているといった状態では、情報漏洩対策としての効果は限定的です。技術だけに依存せず、持ち出しルールや保存先の統制と組み合わせる必要があります。

    運用面で必要な対策

    教育とルール整備

    情報漏洩対策を実効的にするうえで、運用面の整備は避けて通れません。個人情報保護委員会の研修資料では、自己点検チェックリストや個人データ取扱要領の例が公開されており*2、ルール整備だけでなく、日常的な確認や点検の必要性が前提とされています。つまり、情報漏洩対策は「規程を作った」で終わるものではなく、実際に守られているかを確認し続けることが重要です。

    教育面では、標的型メールや不審なリンクへの注意だけでなく、誤送信防止、共有設定の確認、紙書類の扱い、委託先への情報提供時の確認など、現場で起こりやすい事故に即した内容が必要です。IPAも対策例として、情報リテラシーやモラルの向上、適切な報告・連絡・相談の実施を挙げています*3。また、ルール整備では例外運用を放置しないことが大切です。忙しい時だけ私物端末を使う、やむを得ず個人メールへ送る、臨時対応のために共有範囲を広げるといった運用が常態化すると、情報漏洩対策は一気に弱くなります。ルールは厳しさよりも、現場で守れる具体性と、逸脱時に気付ける仕組みが重要です。

    権限管理の継続運用

    権限管理では、最小権限の原則に基づき、業務に必要な範囲だけアクセスを付与することが基本になります。特に、異動・退職・組織変更・委託先変更などが発生した際に、権限変更が適切に行われているかを継続的に確認する必要があります。一度設定した権限を放置すると、「誰がどこにアクセスできるのか分からない状態」が生まれます。情報漏洩対策では、権限設定そのものよりも、定期的に見直し続けられる運用体制が重要です。

    委託先・外部サービスの管理

    近年の情報漏洩対策で特に重要なのが、委託先や外部サービスの管理です。個人情報保護委員会は、委託元には委託先に対する必要かつ適切な監督義務があると示しており、その具体例として、適切な委託先の選定、契約の締結、委託先における取扱状況の把握を挙げています。自社が直接事故を起こさなくても、委託先や再委託先での問題がそのまま自社の情報漏洩になる時代です。そのため、委託先の管理は契約書の締結だけでは足りません。どの情報を渡すのか、再委託はあるのか、保存先はどこか、アクセス権限はどう管理されるのか、事故時にどのタイミングで報告されるのかまで確認しておく必要があります。国家サイバー統括室(旧NISC)「サイバーセキュリティ2025」でも、委託先やサプライチェーンを通じたインシデントの深刻さが示されており、外部依存が高い企業ほど管理の精度が問われます。

    委託先や外部サービスに関するリスクについては、サプライチェーン攻撃の観点からも整理しておく必要があります。
    委託先・外注先のセキュリティはどこまで確認すべきか ―サプライチェーン攻撃を防ぐ実務判断―

    インシデント発生時の対応

    どれだけ対策を講じても、情報漏洩を完全にゼロにすることは困難です。そのため、情報漏洩対策では事故後の初動も重要になります。インシデント発生時の報告・連絡・相談体制を平時から決めておく必要があります。初動対応で重要なのは、まず被害拡大を防ぐことです。不正アクセスが疑われる場合には、該当アカウントや端末の隔離、ログ保全、外部接続の遮断、関係部門への即時連絡が必要になります。そのうえで、何が起きたのか、どの情報が影響を受けたのか、本人通知や公表が必要かを判断していきます。

    実際に情報漏洩が発生した場合の初動対応については、以下の記事で詳しく解説しています。セキュリティインシデントの基礎から対応・再発防止まで 第2回:セキュリティインシデント発生時の対応 ─初動から復旧まで

    継続的に対策を回すためのポイント

    情報漏洩対策は、一度整備して終わりではありません。業務フロー、利用サービス、委託先、働き方が変われば、リスクも変わります。IPAも、基本的な対策の重要性は変わらない一方で各組織は自社の状況を踏まえて優先度を決め継続的に対策を進める必要がある、としています。そのためには、定期レビューと可視化が不可欠です。情報資産の棚卸し、権限の見直し、委託先の確認、ログ監査、教育内容の更新、インシデント訓練などを、年に一度の形式的な点検で終わらせず、実態に合わせて回す必要があります。情報漏洩対策の成熟度は、立派な規程の有無ではなく、変更や例外に気付ける状態を保てているかで決まります。

    まとめ

    企業の情報漏洩対策は、アクセス制御、ログ管理、暗号化といった技術対策だけで完結しません。権限管理、教育、ルール整備、委託先管理、初動対応体制までを含めて設計し、継続的に見直していく必要があります。個人情報保護委員会やIPAの資料が共通して示しているのは、情報漏洩対策を単発の施策ではなく、組織的に回し続けるべき取り組みとして位置付けるべきだという点です。事故を防ぐことと同じくらい、事故が起きたときに被害を広げず、速やかに対応できる状態をつくることが重要です。情報漏洩対策は、IT部門だけではなく、業務設計・委託管理・組織運用を含めた経営課題です。「どこから漏れるか分からない」ことを前提に、継続的な見直しを行うことが求められるでしょう。

    情報漏洩対策の全体像をあらためて整理したい場合は、こちらの記事もあわせてご覧ください。
    情報漏洩対策とは何か ―企業が知るべき原因・リスク・防止策の全体像―

    【参考情報】


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

  • 2026年6月3日(水)14:00~15:00「金融機関の対応事例に学ぶPQC移行の進め方と実務ポイント
  • 2026年6月10日(水)14:00~14:30「Webサイトの見えない脅威を可視化する 外部タグ・サードパーティースクリプトの監視対策
  • 最新情報はこちら

    編集責任:木下

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


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

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


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

    ウェビナーダイジェスト動画

    Share

    アーカイブ動画

    過去ご好評いただいたウェビナーの抜粋動画を無料で公開しています。


    ピックアップ

    ウェビナーダイジェスト版:2026年、企業が直面するサイバー脅威― IPA『情報セキュリティ10大脅威 2026』から考える対応戦略 ―

    2025年

    ウェビナータイトル画面「フィッシング攻撃の最新脅威と被害事例〜企業を守る多層防御策〜」2025.9.10(水)開催
    フィッシング攻撃の最新脅威と被害事例〜企業を守る多層防御策〜
    再生時間:05:01
    ウェビナータイトル画面「進化するランサムウェア攻撃」2025.7.16(水)開催
    進化するランサムウェア攻撃-国内最新事例から学ぶ!被害を防ぐ実践ポイント10項目を解説-
    再生時間:05:00
    ウェビナータイトル画面「ランサムウェア対策の要! ペネトレーションテストとは?」2025.1.22(水)開催
    ランサムウェア対策の要! ペネトレーションテストとは?-ペネトレーションテストの効果、脆弱性診断との違い-
    再生時間:04:55

    2024年

    ウェビナーダイジェスト版:脆弱性診断の新提案!スピード診断と短納期で解決する「SQAT with Swift Delivery」セミナー2024.12.18(水)開催
    脆弱性診断の新提案!スピード診断と短納期で解決する「SQAT® with Swift Delivery」セミナー
    再生時間:05:09
    ウェビナーダイジェスト版:中小企業に迫るランサムウェア!  サプライチェーン攻撃とは- サプライチェーン攻撃から企業を守るための取り組み2024.11.20(水)開催
    中小企業に迫るランサムウェア! サプライチェーン攻撃とは- サプライチェーン攻撃から企業を守るための取り組み
    再生時間:05:11
    2024.11.13(水)開催
    ウェブ担当者必見!プライバシー保護規制対応と情報セキュリティ
    -サイバー攻撃への事前・事後対応-

    再生時間:05:07
    2024.8.7(水)開催
    AWS・Azure・GCPユーザー必見!企業が直面するクラウドセキュリティリスク
    再生時間:05:18
    2024.7.10(水)開催
    ランサムウェアの脅威を知る~脅威に備えるためのランサムウェア対策
    再生時間:05:02
    2024.6.19(水)開催
    サイバー攻撃に備えるために定期的な脆弱性診断の実施を!-ツール診断と手動診断の比較-
    再生時間:05:04
    2024.5.22(水)開催
    対応必須! 情報セキュリティ事故発生時の緊急対応とは
    再生時間:05:09
    2024.4.24(水)開催
    知っておきたいIPA『情報セキュリティ10大脅威 2024』~セキュリティ診断による予防的コントロール~
    再生時間:05:19
    2024.4.17(水)開催
    変化する不確実性の時代における「安心・安全・安定のWebサイト運営」セミナー
    再生時間:03:00

    2023年

    2023.11.15(水)開催
    Webアプリケーションの脆弱性対策-攻撃者はどのように攻撃するのか-
    再生時間:05:42
    2023.10.18(水)開催
    自動車産業・製造業におけるセキュリティ対策のポイント-サプライチェーン攻撃の手口と対策方法-
    再生時間:04:56
    2023.8.9(水)開催
    DevSecOpsを実現!-ソースコード診断によるセキュリティ対策のすすめ-
    再生時間:05:29
    2023.7.20(水)開催
    今さら聞けない!PCI DSSで求められる脆弱性診断あれこれ
    再生時間:05:00
    2023.6.21(水)開催
    今さら聞けない!クラウドセキュリティあれこれ
    再生時間:05:00
    2023.5.17(水)開催
    今さら聞けない!ペネトレーションテストあれこれ
    再生時間:05:20
    2023.4.19(水)開催
    知っておきたいIPA『情報セキュリティ10大脅威 2023』~セキュリティ診断による予防的コントロール~
    再生時間:05:00
    2023.3.15(水)開催
    予防で差がつく!脆弱性診断の話
    再生時間:04:57
    2023.1.27(水)開催
    今さら聞けない!ソースコード診断あれこれ
    再生時間:05:00

    2022年

    2022.6.22(水)開催
    テレワーク運用時代のセキュリティ情報の集め方-セキュリティに求められる情報収集とは-
    再生時間:04:51
    ウェビナーダイジェスト版:企業の対策すべき脆弱性入門2022.4.21(水)開催
    企業の対策すべき脆弱性入門
    再生時間:05:13

    TOP-更新情報に戻る


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

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

    情報漏洩はなぜ起きるのか ―企業で多い原因と最新事例から見るリスクの実態―

    Share
    情報漏洩はなぜ起きるのか ―企業で多い原因と最新事例から見るリスクの実態―アイキャッチ画像

    情報漏洩というと、外部の攻撃者による大規模な不正アクセスを思い浮かべる方が多いかもしれません。しかし実際には、誤送信や紛失、権限設定の不備、委託先での事故、クラウドの運用ミスなど、日常業務の延長で起きる事案も少なくありません。情報漏洩の原因を正しく理解することは、企業の情報漏洩対策を実効的なものにする第一歩です。本記事では、最新事例をもとに、企業で多い原因と情報漏洩リスク、対策の考え方を解説します。

    情報漏洩の全体像や基本的な考え方については、以下の記事で整理しています。
    情報漏洩対策とは何か ―企業が知るべき原因・リスク・防止策の全体像―

    情報漏洩の多くは“想定外”で起きている

    多くの企業が情報漏洩を「自社が攻撃される特殊な事故」と捉えがちですが、実際には“想定していなかった経路”から起きるケースが目立ちます。個人情報保護委員会から報告された年次報告によると、個人データの漏えい等事案について8,928件の報告処理が行われており、発生原因としては病院や薬局における要配慮個人情報を含む書類の誤交付や紛失、不正アクセス、クレジットカードの誤送付などが多かったとされています*4。つまり、情報漏洩は高度なサイバー攻撃だけでなく、紙・メール・業務フローといった身近な部分でも起き続けています。

    さらに厄介なのは、自社だけではコントロールしきれないところで事故が起きることです。個人情報保護委員会「不正アクセス発生時のフォレンジック調査の有効活用に向けた論点整理のための参考資料」(令和8年1月16日)によると、不正アクセスによる漏えい等報告件数が増加しており、令和6年度の直接受付分では不正アクセスによる報告件数が4,024件に達したことが示されています。この数値にはSaaS提供事業者への不正アクセスにより、多数の利用企業へ影響が及んだ事案も含まれており、企業が自社の運用だけを見ていても十分ではないことが分かります。

    見落とされやすいのは、「情報漏洩はセキュリティ部門だけの課題ではない」という点です。営業が使うクラウド、委託先が使う再委託先サービス、バックオフィスの紙帳票、現場の持ち出し端末など、事故の起点は部門横断で存在します。だからこそ、情報漏洩対策は製品導入だけでなく、業務設計や権限設計、委託先管理を含めて捉える必要があります。

    情報漏洩の主な原因とは?企業で多い5つのパターン

    人的ミス

    情報漏洩の原因として古くから多いのが人的ミスです。メールの誤送信、添付ファイルの取り違え、紙書類の誤交付、USBメモリやノートPCの紛失といった事故は、特別な攻撃がなくても発生します。人的ミスが減らない理由は、担当者の注意力だけに依存しているからです。確認手順が曖昧だったり、ダブルチェックが形骸化していたり、忙しい時に例外運用が常態化していたりすると、同じような事故は繰り返されます。情報漏洩対策では、個人の注意喚起だけでなく、ミスしても大事故にならない設計が求められます。

    権限管理ミス

    必要以上の権限が付与されたままになっていることも、情報漏洩の大きな原因です。退職者や異動者の権限が削除されていない、共有フォルダが広く閲覧可能になっている、クラウド上の情報に不要なアクセス権が残っていると、内部不正やアカウント侵害が起きた際の被害が一気に拡大します。個人情報保護委員会は安全管理措置の中で、組織的・技術的な統制の必要性を示しており、アクセス権限の適切な管理はその中心的な要素です。

    権限管理ミスは、事故が起きるまで表面化しにくい点が厄介です。実務では「業務が止まらないこと」を優先して権限が広がりがちですが、その積み重ねが情報漏洩リスクを高めます。情報漏洩対策を考える際は、誰がどの情報にアクセスできるのかを定期的に棚卸しする必要があります。

    設定不備

    クラウドやWebサービスの設定不備も、近年の情報漏洩で頻出する原因の一つです。これには単なる操作ミスではなく、誰が何を公開し、どこまで共有し、いつ見直すのかという運用ルールの不足が背景にあることが多くあります。また、設定不備は、システム担当者だけの問題でもありません。現場部門が便利さを優先して外部共有設定を変更したり、試験用データを本番と同じ場所に残したりすることで、情報漏洩につながるケースもあります。クラウド利用が前提となった今、設定ミスは特別な失敗ではなく、どの企業でも起こりうる実務上のリスクです。

    サイバー攻撃

    マルウェア(ランサムウェア)によるサイバー攻撃も、情報漏洩の主要因です。攻撃の目的は業務停止だけではなく、個人情報や企業情報の窃取と公開を組み合わせた二重脅迫に及ぶことが多く、被害は広範囲に及びます。

    サプライチェーン経由の情報漏洩

    近年、特に重要性が増しているのが、委託先や再委託先、利用中の外部サービスを経由した情報漏洩です。自社では直接不正アクセスを受けていなくても、業務を委託している先や、相手先が利用しているクラウド環境に問題があれば、結果として自社の顧客情報や取引情報が漏れることがあります。独立行政法人情報処理推進機構(IPA)が毎年公開する「情報セキュリティ10大脅威 2026」でも、「サプライチェーンや委託先を狙った攻撃」が「ランサム攻撃による被害」に続けて第2位に挙げられており、その継続的な深刻さを指摘しています。

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

    実際に起きている情報漏洩事例

    情報漏洩事例は、発生原因によっていくつかのパターンに整理できます。近年はサイバー攻撃だけでなく、委託先や外部サービス経由の事故も増えています。

    類型主な原因主な内容・特徴代表的な事例
    人的ミス型誤送信・紛失・誤交付日常業務の延長で発生。メール誤送信や紙書類の取り違え、端末紛失など病院・薬局での誤交付、書類紛失
    権限管理・設定不備型過剰権限・公開設定ミス共有フォルダやクラウド設定の不備によって情報が意図せず閲覧可能になるクラウド共有設定ミス、退職者権限の残存
    サイバー攻撃型不正アクセス・ランサムウェア情報窃取と業務停止が同時発生。二重脅迫型攻撃も増加KADOKAWA*2、損害保険ジャパン*3
    委託先・外部サービス型SaaS侵害・再委託先事故委託先やクラウドサービス経由で情報が漏えいみずほ証券*4、野村證券*5

    人的ミス型では、メールの誤送信や書類紛失、端末の置き忘れなど、日常業務の延長で情報漏洩が発生します。特別な攻撃がなくても起こりうるため、多くの企業で継続的な課題となっています。個人情報保護委員会の活動実績でも、病院や薬局における誤交付や紛失が主要原因として挙げられており、業務ミスがそのまま漏洩事故につながる実態が示されています。

    また、権限管理ミスや設定不備も、近年の情報漏洩で多く見られる原因です。退職者アカウントの権限が残ったままになっていたり、共有フォルダやクラウドストレージが過剰公開状態になっていたりすると、不正アクセスや内部不正が発生した際に被害が拡大しやすくなります。クラウド利用が一般化した現在では、設定ミスそのものが重要なリスク要因になっています。

    サイバー攻撃型では、ランサムウェアや不正アクセスによって、情報漏洩と業務停止が同時に発生するケースが増えています。近年は情報を窃取したうえで公開を脅迫する「二重脅迫」も広がっており、被害は長期化・広域化しやすくなっています。KADOKAWAの事例では、ランサムウェアを含むサイバー攻撃によって「ニコニコ」を含む複数サービスが停止し、約25万4,000人分の個人情報等の漏えいが確認されました*6。また、損害保険ジャパンも2025年に不正アクセスによる顧客情報漏えいの可能性を公表*7しており、初動対応後のフォレンジック調査の重要性も示されています。

    さらに近年は、委託先や再委託先、利用中のクラウドサービスを経由した情報漏洩も増加しています。自社が直接攻撃を受けていなくても、外部サービスや委託先で発生した事故によって顧客情報や取引情報が漏洩するケースも少なくありません。みずほ証券や野村證券では、再委託先企業が利用していたクラウドサービスへの不正アクセスにより、顧客関連情報の流出が公表されました。

    こうした事例に共通するのは、「想定外の場所が起点になる」「単一の対策だけでは防ぎきれない」「発覚後に影響範囲の特定が難しい」という点です。情報漏洩対策では、自社システムだけでなく、権限管理や業務運用、委託先管理を含めた全体的な見直しが重要になります。

    なぜ情報漏洩は繰り返し起きるのか

    同じような情報漏洩事故が繰り返される理由の一つは、業務の属人化です。担当者しか知らない運用、引き継がれていない例外ルール、慣習で続いている権限付与などが残っていると、問題が見えないままリスクが蓄積します。事故が起きたときだけルールを追加しても、実務の現場で運用可能な形になっていなければ再発防止にはつながりません。個人情報保護委員会が安全管理措置として組織的・人的・技術的対策を求めているのは、こうした属人的運用を避けるためでもあります。

    もう一つの理由は、可視化不足です。どの情報をどこで持ち、誰がアクセスでき、どの委託先に渡し、どのクラウドに保存しているのかが見えていない企業では、情報漏洩リスクを事前に評価できません。不正アクセスが増加している今、見えない資産、見えない権限、見えない再委託は、そのまま事故要因になります。

    さらに、事故が起きるまで「うちは大丈夫」と考えてしまうことも再発の温床です。IPAや国家サイバー統括室(旧NISC)「サイバーセキュリティ2025」が示しているように、ランサム攻撃やサプライチェーン経由の被害はすでに幅広い業種で発生しています。情報漏洩対策は特定業界の一部企業だけの話ではなく、どの企業にも関係する経営課題です。

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

    まとめ

    情報漏洩は、単純な「外部からの攻撃」だけで起きるものではありません。人的ミス、権限管理ミス、設定不備、サイバー攻撃、委託先や再委託先での事故など、複数の原因が複雑に絡み合って発生します。個人情報保護委員会の統計でも誤交付や紛失、不正アクセスが継続して多く報告されており、さらに近年はSaaS事業者や委託先を経由した広域的な影響も目立っています。つまり、情報漏洩対策では「どこから漏れるか分からない」という前提に立ち、社内運用、自社システム、委託先管理を一体で見直す必要があります。情報漏洩対策は、IT部門だけの課題ではなく、企業全体の業務設計と管理体制の問題です。「どこから漏れるか分からない」ことを前提に、継続的な見直しを行うことが求められます。

    情報漏洩を防ぐために企業が取るべき対策を整理した記事もあわせてご覧ください。
    企業の情報漏洩対策 ―すぐに実践できる防止策と運用のポイント


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

  • 2026年5月27日(水)14:00~15:00「~取引先から求められる前に押さえる~ SCS評価制度への対応準備と現実的な進め方
  • 2026年6月3日(水)14:00~15:00「金融機関の対応事例に学ぶPQC移行の進め方と実務ポイント
  • 2026年6月10日(水)14:00~14:30「Webサイトの見えない脅威を可視化する 外部タグ・サードパーティースクリプトの監視対策
  • 最新情報はこちら

    編集責任:木下

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


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

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


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

    脆弱性診断は受けたけれど ― 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コーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像