CWE Top 25 2025年版(後編)– メモリ安全性が上位に増えた理由と対策の要点

Share
CWE Top 25 2025年版– メモリ安全性が上位に増えた理由と対策の要点アイキャッチ画像

CWE Top 25:2025」では、もう一つ見逃せない特徴があります。それが、メモリ領域の安全性に関わる弱点が複数上位に含まれている点です。本記事では、CWE Top 25 2025年版で目立つメモリ系弱点を整理したうえで、なぜ上位に増えているのか、Webサービス運用の観点でどのように備えるべきかを解説します。

はじめに:前編の振り返り(Web/API 12項目)

前編では、CWE Top 25 2025年版のうち、WebアプリケーションやAPIで特に問題になりやすい弱点をピックアップし、リスクと診断観点を整理しました。具体的には、XSSやCSRFといった入力・リクエスト起点の脆弱性に加え、「認可の欠如不備」のようにログインしていても不正操作が成立するタイプの脆弱性が、実被害につながりやすいポイントとして挙げられます。Web/APIは機能追加や仕様変更が多いため、対策しているつもりでも抜けが生まれやすく、定期的な点検が重要です。

前編の記事はこちらからご覧いただけます。
CWE Top 25 2025年版(前編)– Web/APIで狙われやすい弱点12項目と診断ポイント」(https://www.sqat.jp/kawaraban/41257/

前編で取り上げたWeb/APIの脆弱性は、日々の開発や運用の中で発生しやすく、脆弱性診断でも頻出する領域です。一方で、CWE Top 25 2025年版を俯瞰すると、もう一つ見逃せない特徴があります。それが、メモリ領域の安全性に関わる脆弱性が複数上位に含まれている点です。

メモリ系の脆弱性は、C/C++など低レベル言語で起きやすい印象が強く、「Webアプリ中心の開発では関係が薄い」と思われることもあります。しかし実際には、Webサービスを支える基盤やOSS、ミドルウェア、各種ライブラリにはネイティブ実装が含まれることも多く、アプリケーションの外側でリスクが顕在化するケースも少なくありません。また、メモリ破壊系の脆弱性は、単なるサービス停止(DoS)に留まらず、条件次第では任意コード実行など深刻な侵害につながる可能性があります。攻撃の影響が大きく、対応にも専門性が求められることから、近年あらためて注目されている領域といえます。

そこで後編では、CWE Top 25 2025年版で目立つメモリ系弱点を整理したうえで、なぜ上位に増えているのか、Webサービス運用の観点でどのように備えるべきかを解説します。

メモリ領域の安全に関する脆弱性が上位に増えている理由

CWE Top 25 2025年版ではメモリ安全性に関わる脆弱性が複数ランクインしている傾向もみてとれます。一見すると「これはC言語など低レベル言語の話で、Webアプリ開発とは関係が薄いのでは?」と思われるかもしれません。しかし実際には、Webサービスを提供する側にとっても無視できないテーマになっています。ここでは、2025年版で目立つメモリ系の脆弱性と、上位に増えている背景を整理します。

2025年に目立つメモリ系6項目

CWE Top 25 2025年版の中で、特にメモリ領域の安全性に関連する項目としては以下が挙げられます。

  1. CWE-787:範囲外の書き込み
  2. CWE-416:解放したメモリの使用
  3. CWE-125:範囲外の読み取り
  4. CWE-476:NULLポインター逆参照
  5. CWE-121:スタックベースバッファオーバーフロー
  6. CWE-122:ヒープベースバッファオーバーフロー

これらは主にC/C++言語などで発生しやすい脆弱性で、メモリ破壊を起点としてアプリケーションの異常動作やクラッシュ、条件次第では任意コード実行にまでつながる可能性があります。

メモリ系が“ランク上昇”した背景

OSS・ミドルウェア・実行環境の影響が大きい

近年のシステム開発では、自社でゼロからすべてを実装することはほとんどありません。
Webアプリケーション自体は高水準言語(Java、PHP、Python、Ruby、JavaScriptなど)で書かれていたとしても、実際には裏側で多くのソフトウェア資産に依存しています。 例えば、以下のような領域はネイティブ実装(C/C++など)が含まれることが多く、メモリ安全性の影響を受けやすい代表例です。

  • 画像・動画の変換や解析
  • 圧縮・解凍処理
  • 暗号処理
  • OSやコンテナの周辺コンポーネント
  • Webサーバやロードバランサなどの基盤ソフトウェア

つまり「アプリはWebだからメモリ破壊は関係ない」と切り分けるのではなく、サービス全体を構成する要素としてメモリ安全性の弱点が影響し得る、という視点が必要になります。

「攻撃が成立した時のインパクト」が大きい

メモリ破壊系の脆弱性は、単にアプリがダウンする(DoS攻撃等の影響による)だけでなく、条件がそろうと攻撃者にとって非常に強力な結果につながることがあります。たとえば、任意コード実行や権限奪取の足がかりになるケースもあり、被害の深刻度が高くなりやすい点が特徴です。

Webアプリケーションの脆弱性は「データが漏れる」「不正操作される」といった被害が中心になりやすい一方で、メモリ系は侵害の方向性が変わり、“システムそのものの制御”に影響する可能性がある点で性質が異なります。このインパクトの大きさが、ランキング上でも目立ちやすい要因の一つです。

“開発者の気付き”だけでは防ぎにくい

XSSやSQLインジェクションは、実装者の意識と共通部品の整備で減らしていける領域です。一方でメモリ安全性の弱点は、そもそも自社コードではなく、依存しているライブラリやミドルウェアの脆弱性として露出することも少なくありません。この場合、開発者が気を付けて実装していても防ぎきれず、必要になるのは次のような対策です。

  • 利用コンポーネントの把握(棚卸し)
  • 脆弱性情報の継続的な収集
  • バージョンアップ・パッチ適用の判断と運用
  • 影響範囲の評価(どの機能が影響を受けるか)

つまり、メモリ系の脆弱性は「作り込みで防ぐ」だけではなく、運用で守る力も問われる領域だと言えます。

脆弱性対応は「作り込み」+「運用」の両輪

Webアプリケーションのセキュリティ対策というと、入力チェックや認可実装など“作り込み”に注目が集まりがちです。もちろんこれは重要ですが、メモリ系の弱点が示すように、脆弱性対応には運用面の強さも求められます。

運用面で意識したいポイントは、以下のように整理できます。

  • 利用しているライブラリ/ミドルウェアの把握(棚卸し)
  • 脆弱性情報の継続的な収集と影響評価
  • パッチ適用・アップデートの判断と実施
  • 監視・ログによる異常兆候の検知
  • 必要に応じた防御策(WAFなど)による被害軽減

特に「アップデートできる体制があるか」「影響範囲を素早く見積もれるか」は、脆弱性が公開された際の対応スピードに直結します。メモリ系の脆弱性は影響が大きくなりやすい分、発覚後の初動が被害を左右するため、日頃から“運用で守る仕組み”を整えておくことが重要です。

脆弱性診断でどう確認するか(診断観点の例)

メモリ領域の安全性の脆弱性は、Web/APIの脆弱性とは性質が異なり、「画面やAPIを触るだけでは見えにくい」ケースもあります。そのため、脆弱性診断ではアプリケーションの挙動確認に加えて、実装・構成・依存関係といった複数の観点からリスクを洗い出すことが有効です。

Webアプリケーション診断/API診断

実際の画面・APIに対して攻撃パターンを当て、脆弱性が成立するかどうかを確認します。
メモリ系の弱点そのものを直接検出するのは難しい場合もありますが、前編で整理した認可不備・IDOR・SSRF・ファイル関連など、実被害につながりやすい脆弱性を網羅的に確認できる点が強みです。

ソースコード診断(SAST)

危険な実装パターンや、入力値の扱い方、権限判定の実装の偏りなどを、コードレベルで洗い出せる手法です。メモリ領域の安全性の観点でも、ネイティブコードを含む箇所や危険APIの利用状況、例外処理の不足などを確認することで、潜在的なリスクを把握しやすくなります。特に、開発を継続しながら対策を積み上げる場合、設計や共通部品の見直しにも活用できます。

プラットフォーム診断/OSS観点(依存関係・構成)

メモリ系の脆弱性を含む“依存資産のリスク”に対応するには、構成・依存関係の観点が欠かせません。アプリケーションの外側に原因がある場合、どれだけアプリの実装を直してもリスクが残るためです。「脆弱性が出たときに、すぐ把握できる・すぐ対応できる」状態を作ることが、結果的にリスクを下げる近道になります。

まとめ

CWE Top 25 2025年版から読み取れるのは、Webアプリ・APIで頻出する脆弱性が依然として事故につながりやすい一方で、メモリ安全性のように“アプリの外側”に潜むリスクも無視できない存在になっているという点です。この2つを両立できるかどうかが、2025年のセキュリティ対策の分かれ道になると言えます。

“定期的な診断+改善”でリスクを下げる

脆弱性対策は、一度対応して終わりではなく、仕様変更・機能追加・依存資産の更新によって状況が変化します。だからこそ、CWE Top 25のような指標を参考にしながら、第三者視点の脆弱性診断で現状を確認し、優先度を付けて改善していくことが有効です。Webアプリケーション診断・API診断・ソースコード診断を組み合わせることで、「攻撃が成立するポイント」と「根本原因」を整理しやすくなり、修正の手戻りを減らしながら安全性を高められます。継続的な診断と改善を通じて、インシデントの予防と品質向上につなげていきましょう。

BBSecでは

「どこが危ないのか」を把握しないまま対策を進めると、重要な弱点が残ったり、修正の手戻りが増えたりすることがあります。Webアプリケーション/APIの脆弱性診断により、実際に攻撃が成立するポイントを洗い出し、優先度を付けて改善につなげることが可能です。まずは現状の課題や診断範囲について、お気軽にご相談ください。

限定キャンペーン実施中!

ソースコード診断 アップチャージプランのご案内

Web診断に加えて、アプリケーション内部の脆弱性を確認できるソースコード診断(アップチャージプラン)もご用意しています。

詳細・お申し込みボタン

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


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

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

TLS設定の安全性と確認ポイント:古い暗号設定が引き起こすリスクと改善手順

Share

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

「TLS設定の安全性と確認ポイント:古い暗号設定が引き起こすリスクと改善手順」アイキャッチ画像

Webサイトやオンラインサービスを安全に運用するためには、TLS(暗号化通信)のバージョンや設定状況を正しく把握することが重要です。古いTLSバージョンや不十分な暗号設定を放置すると、通信の安全性が低下するだけでなく、攻撃リスクやサービス停止につながる可能性があります。

本記事では、TLS設定の安全性を判断するために押さえておくべき基本的な考え方と確認ポイントを整理します。具体的なバージョン確認や設定チェックの手順については、実践編の記事で詳しく解説しています。

ブラウザや外部ツールを使った TLSバージョンの具体的な確認手順については、
→ 「TLSバージョン確認と安全な暗号設定方法」 で詳しく解説しています。

TLSとは?安全な通信を支える基本と目的

TLS(Transport Layer Security)は、インターネット上でやり取りされる通信を暗号化し、第三者による盗聴や改ざんを防ぐための仕組みです。Webサイトのログイン情報や個人情報、業務データなどを安全に送受信するための、通信の土台となる技術といえます。

かつてはSSLと呼ばれていましたが、現在はTLSが標準となっており、SSLはすでに非推奨です。TLSが正しく設定されていない場合、通信内容が外部から読み取られたり、不正に操作されたりするリスクが高まります。

TLSバージョンの違いと推奨設定

TLSには複数のバージョンが存在し、それぞれ安全性や対応状況が異なります。

  • TLS 1.0 / 1.1
    すでに脆弱性が指摘されており、主要ブラウザやサービスでは非推奨・無効化が進んでいます
  • TLS 1.2
    適切な暗号スイートを選択すれば安全に利用できます。
  • TLS 1.3
    最新バージョンであり、セキュリティとパフォーマンスの両面で改善されています

基本方針としては、TLS 1.3を有効化し、古いバージョンを無効にすることが推奨されます。
現在どのバージョンが使われているかを把握することが、最初の重要なステップです。

実際の確認手順については、
→ 「TLSバージョン確認と安全な暗号設定方法:ブラウザ・ツールでのチェック手順」で詳しく解説しています。

TLSバージョンの利用率

ChromeやFirefoxなどの主要ブラウザ(クライアント)においては、2020年上半期をもってTLS 1.0/1.1が無効化され、相互接続の互換性維持目的でTLS 1.1以下をサポートするメリットは既になくなっています。加えて、常時HTTPS化という世界的な流れの中では、TLS 1.0/1.1が利用可能なWebサイトは「安全でない」とみなされる場合もあるでしょう。なお、SSL Pulseによる調査では、TLS 1.3の普及率は70.1%、TLS 1.2は99.9%にのぼっています(2024年5月時点のデータより)

TLSバージョンの利用率
出典:https://www.ssllabs.com/ssl-pulse/

最も普及しているのはTLS 1.2ですが、複数のプロトコルバージョンをサポートしている場合、サーバとブラウザの両者が使用可能なバージョンのうち、新しいものから優先的に使用するのが標準的なTLSの設定です。TLS 1.3およびTLS 1.2を有効にし、バージョンが新しいものから順に接続の優先度を高く設定してください。

TLS 1.3の導入のメリットと課題については以下の記事もあわせてご参照ください。
https://www.sqat.jp/kawaraban/19215/

また、IPA「TLS暗号設定ガイドライン」第3版からはプロトコルのバージョンだけでなく暗号スイートについても見直しが行われ、TLS 1.2に対してはPFS(Perfect Forward Secrecy)を有する鍵交換方式(ECDHE、DHE)を含む暗号スイートのみの使用が強く推奨されています。PFSは、2013年のスノーデン事件をきっかけにその重要性が認識され普及が進んだ暗号化技術です。TLS 1.3では、既定でPFSを有する鍵交換方式のみが採用されており、今後、鍵交換方式が満たすべき標準になると考えられます。

TLS暗号設定ガイドラインと基本設計方針

IPA「TLS暗号設定ガイドライン」第3.1.0版は電子政府推奨暗号の安全性の評価プロジェクト「CRYPTREC」が作成したWebサーバでのTLS暗号設定方法をまとめたガイドラインです。TLSサーバの構築者や運用者が適切なセキュリティを考慮して暗号設定を行うための指針として提供されています。

IPA/NICTの本ガイドラインでは、「高セキュリティ型」、「推奨セキュリティ型」、「セキュリティ例外型」(安全性上のリスクを受容してでも継続利用せざるを得ない場合の設定基準)という3つの設定基準が提唱されています。

  • 高セキュリティ型: TLS 1.3およびTLS 1.2を使用し、強い暗号スイートのみを利用。
  • 推奨セキュリティ型: 一般的に推奨される設定で、セキュリティとアクセス性のバランスが取れています。
  • セキュリティ例外型: TLS 1.3~TLS 1.0のいずれかで、アクセス性を確保しますが、セキュリティの強度は低下します。

(※セキュリティ例外型での設定内容は2029年度を目途に終了予定のため、速やかに推奨セキュリティ型への移行が推奨されます)

設定要求: 各設定基準に応じた具体的なプロトコルバージョンや暗号スイートの要求設定が示されています。これには、遵守項目と推奨項目が含まれ、安全性を確保するために満たすべき要件が詳細に説明されています。

チェックリスト: TLSサーバの構築者や運用者が設定を実施する際に利用できるチェックリストも用意されており、設定忘れを防ぐためのガイダンスを提供します。

まとめ

TLS設定は、Webサイトやサービスの安全性を支える重要な要素です。

  • TLSバージョンと暗号設定を把握する
  • 古い設定を放置しない
  • 定期的に確認・改善を行う

これらを意識することで、通信に関するリスクを最小限に抑えることができます。

実際のチェック方法については、
→「TLSバージョン確認と安全な暗号設定方法:ブラウザ・ツールでのチェック手順」もあわせて確認してください。

TLS暗号設定ガイドラインは、TLS通信における安全性考慮したセキュリティ設定基準を設けています。これにより、TLSサーバの構築者や運用者が実際の商業的背景やシステム要件に応じた適切な設定を行うための根拠を提供します。

本ガイドラインで提唱されている3つの設定基準(「推奨セキュリティ型」「高セキュリティ型」「セキュリティ例外型」)は、各種国際的標準(NIST SP800/PCI DSSv4.0/OWASP ASVS等)の指針に対応したものであり、準拠への取り組みや、暗号設定における今後のセキュリティ対策を検討する上でも役に立ちます。ぜひ参照されることをお勧めします。

TLS設定の見直しが必要かどうか判断に迷う場合や、自社だけでの確認が難しい場合は、第三者の視点で現状を整理することも有効です。通信設定を含めたWebサイト全体のセキュリティ状況を把握したい場合は、専門家によるセキュリティ診断や設定確認を検討するのも一つの方法です。

関連情報

● 量子コンピュータの実用化と耐量子暗号の標準化動向

限定キャンペーン実施中!

今なら新規お申込みで 初回診断料金 10%OFF
短期間での診断が可能な「SQAT® with Swift Delivery」で、あなたの企業をサイバー脅威から守りませんか?

詳細・お申し込みボタン

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


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

  • 2026年1月14日(水)13:00~14:00
    【好評アンコール配信】
    今さら聞けない!ソースコード診断あれこれ
  • 2026年1月21日(水)14:00~15:00
    「対策は万全」のはずだったのに、なぜ被害は止められなかったのか?~大手飲料メーカーの会見内容と攻撃手口から読み解く、防げなかった理由とは~
  • 2026年1月28日(水)13:00~14:00
    【好評アンコール配信】「直近のWeb改ざん事例にみる、改ざん攻撃の実態と早期発見の重要性
  • 最新情報はこちら


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

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

    TLSバージョン確認と安全な暗号設定方法:ブラウザ・ツールでのチェック手順

    Share

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

    「TLSバージョン確認と安全な暗号設定方法:ブラウザ・ツールでのチェック手順」アイキャッチ画像

    TLS(暗号化通信)の設定が適切かどうかを確認することは、Webサイトのセキュリティを維持するうえで欠かせない作業です。古いTLSバージョンや弱い暗号設定が残っていると、通信内容の盗聴や改ざん、接続トラブルといったリスクが発生するおそれがあります。

    本記事では、TLSのバージョンや暗号設定を確認するための具体的な手順を、ブラウザやツールを使った方法を中心に解説します。TLS設定の全体像やリスクについては、基礎解説の記事とあわせて確認すると理解が深まります。

    TLS設定の全体像やリスクを先に理解したい方は、
    →「TLS設定の安全性と確認ポイント(基礎解説)」 を先にお読みください。

    古いTLSバージョンを使い続けるリスクとは

    2022年2月1日、米 Googleがリリースした「Google Chrome 98」より、TLS 1.0/1.1が完全に無効化されました*1。「Microsoft Edge 98」や「Mozilla Firefox 97」といった、ほかのWebブラウザにおいても同様です*2

    2020年上半期には主要なWebブラウザでTLS 1.0/1.1はデフォルトで無効化されており、TLS 1.2以上に対応していないWebサイトへアクセスする際には「安全な接続ではない」旨の警告を示すエラーページが表示されていました*3 。今回のTLS 1.0/1.1の完全無効化はここからさらに進んだ対応で、TLS 1.0/1.1を有効化する機能も削除されました。

    WebサイトにおけるTLSの利用状況

    2022年1月時点で、世界の人気トップ15万件のWebサイトにおけるTLSのサポート状況は、TLS 1.0が39.3%、TLS 1.1が43.0%、TLS1.2が99.6%、TLS 1.3が51.4%です。

    最も普及しているのはTLS 1.2ですが、複数のプロトコルバージョンをサポートしている場合、サーバとブラウザの両者が使用可能なバージョンのうち、新しいものから優先的に使用するのが標準的なTLSの設定です。

    最新のブラウザでWebサイトを閲覧する場合、 世界の人気トップ15万件のWebサイトへのアクセスの約50%が最新のTLS 1.3を使用することになるでしょう。調査データの範囲では、TLS 1.3への移行が進んでいることがみてとれるため、今後も調査範囲の対象外でも一般的に、暗号化通信はTLS 1.3への移行が進んでいくと考えられます。

    また、主要WebブラウザにおいてTLS 1.0/1.1が完全無効化されたことで、TLS 1.1以下のバージョンは、互換性維持目的での使用すらされなくなりつつあります。

    【各プロトコルバージョンのサポート状況】

    2019年~2022年の「各プロトコルバージョンのサポート状況」の棒グラフ
    出典:Qualys SSL Labs SSL Pulse (https://www.ssllabs.com/ssl-pulse/)より当社作成

    TLSバージョンの確認方法

    TLSバージョンは、以下の方法で確認できます。

    ブラウザで確認(例:Chrome)

    1. Webサイトにアクセス
    2. F12で開発者ツールを起動
    3. [Security]タブを選択 →「Connection is secure」の項目を確認→ “TLS 1.3” などと表示されます

    OpenSSLコマンドで確認(Linux/Mac)

    “`bash
    openssl s_client -connect example.com:443 -tls1_3

    オンラインツールで確認

    • SSL Labs: https://www.ssllabs.com/ssltest/
    • CDN77: https://tools.cdn77.com/tls-test

    過去の経緯

    TLS 1.0/1.1についてはこれまでも、インターネット技術特別調査委員会(IETF)から2018年10月より非推奨と勧告されていました*4 。また、2020年7月に情報処理推進機構(IPA)と情報通信研究機構(NICT)より「TLS暗号設定ガイドライン第3.0.1版」が公開されています。さらに、2021年1月には、米国家安全保障局(NSA)より旧TLSプロトコル構成の削除に関するセキュリティガイダンス(Eliminating Obsolete Transport Layer Security (TLS) Protocol Configurations)も発行されています。

    国際標準化団体(IETF等)から発行された勧告およびガイドラインの年表

    【概要】

    TLS暗号設定ガイドライン第3版に関する概要紹介(推奨セキュリティ型・高セキュリティ型のプロトコルバージョン・鍵交換)

    TLS 1.2に対してはPFS(Perfect Forward Secrecy)を有する鍵交換方式(ECDHE、DHE)を含む暗号スイートのみの使用が強く推奨されています。PFSは、2013年のスノーデン事件をきっかけにその重要性が認識され普及が進んだ暗号化技術です。TLS 1.3では、既定でPFSを有する鍵交換方式のみが採用されており、今後、鍵交換方式が満たすべき標準になると考えられます。

    ガイドラインの概要図(非推奨TLSバージョンの排除)
    ガイドラインの概要図(非推奨暗号スイート・鍵交換方式の排除)

    古いTLSが引き起こす問題と影響

    主要Webブラウザが、TLS 1.0/1.1を完全無効化したことにより、 TLS 1.2以上が有効化されていない場合は主要ブラウザからの接続ができなくなるため、セキュリティが強化されたWebサーバ上でサイトを運用することが必要となります。

    攻撃者は、サーバを攻撃するにあたって必ずブラウザを経由するわけではないため、TLS 1.1以下の接続を許容すること自体が危険であり、攻撃者にとって狙いやすいターゲットとなる可能性があります。脆弱性を悪用された場合、通信を盗聴し復号することで重要情報の窃取が可能になるというリスクも考えられます。

    古いTLSバージョンの危険性:BEAST/ダウングレード攻撃とは

    BEAST攻撃SSL 2.0、SSL 3.0およびTLS 1.0 プロトコルに影響を及ぼし、攻撃者はWebブラウザとWebサイトとの間のSSL暗号化、またはTLS暗号化されたセッションのコンテンツを復号することができる*5
    ダウングレード攻撃TLS 1.1以下のプロトコルでは、認証付き秘匿モード等の安全性の高いアルゴリズムがサポートされていないため、強度の低い暗号アルゴリズムを強制的に使用させることができる*6

    現在のセキュリティ対策の指標として一般的に用いられる各種国際的標準でも、TLS 1.1以下の継続使用は下記のとおり推奨されていないため、利用している場合には、早急に対策を検討することが求められます。

    NIST(National Institute of Standards and Technology、
    米国立標準技術研究所)
    2018年10月、ガイドライン案公開。2024年1月1日までにTLSを使用するすべての米国政府のサーバでTLS 1.3をサポートすることを提案
    PCI DSS(Payment Card Industry Data Security Standard)2018年6月30日以降、初期TLSを利用しているシステムはクレジットカード業界における監査基準に適合しない
    ※POS POI環境のように既知の脆弱性の悪用が困難であったり、SSL/TLSをセキュリティコントロールとしては使用していなかったりする等、例外的にTLS 1.1以下が許容される場合がありますが、情報セキュリティのベストプラクティスではTLS 1.1以下のプロトコルバージョンはすべて非推奨とされています。*7

    TLS1.2/1.3への移行手順と設定のポイント

    早急にTLS 1.1以下での接続可否を確認し、接続が可能な場合は対処を実施することが推奨されます。具体的には、TLS 1.1以下は無効(利用不可)とし、TLS 1.3およびTLS 1.2を有効にし、バージョンが新しいものから順に接続の優先度を高く設定してください。

    2018年8月には、TLS 1.3が正式リリースされました。以降、TLS 1.3に対応するプラットフォーム等が次々に利用可能になっています。例としては、OpenSSL 1.1.1系(2018年9月)、OpenSSL 3.0系*8(2021年9月)、Java SE/JDK 11(2018年9月)、Java SE/JDK 8バージョン8u261以上*9(2020年7月)や、そのほかにもRed Hat Enterprise Linux 8(2019年5月)が挙げられます。

    TLS 1.3のサポートにより、パフォーマンスとセキュリティが向上します。TLS 1.3を利用するメリットと導入時の課題については、下表のとおりです。 構成上または仕組み上、現時点ではTLS 1.3を実装することが困難な場合、上記よりさらに古いシステムが稼働している可能性が考えられます。それらのシステムは、経年に伴う脆弱性の蓄積による影響や、サポート終了により新たに発見された脆弱性への対応策がなくなること等も危惧されます。

    TLS 1.3を利用するメリットと導入時の課題

    TLS 1.3を利用するメリットと導入時の課題

    各種ガイドラインの紹介

    PCI DSSについては、 2022年3月31日、Payment Card Industry Security Standards Council (PCI SSC)により、v4.0が公開されました。 *10

    本ガイドラインは、各種国際的標準(NIST SP800/PCI DSSv4.0/OWASP ASVS等)の準拠に向けた取り組みや、暗号設定における今後のセキュリティ対策を検討する上でも役に立ちます。ぜひ参照されることをおすすめします。

    TLS設定を確認した後に考えるべきこと

    TLSのバージョンや暗号設定は、確認しただけで終わりではありません。実際の運用環境では、サーバ構成や他システムとの兼ね合いにより、「安全そうに見えてもリスクが残っている」ケースも少なくありません。自社サイトのTLS設定について、

    • 現在の設定が本当に適切か判断できない
    • 古い設定や見落としがないか不安がある
    • 他のセキュリティリスクとあわせて確認したい

    と感じた場合は、第三者の視点で状況を整理することも有効です。

    BBSecでは

    ネットワーク脆弱性診断

    悪意ある第三者の視点で、ネットワークをインターネット経由またはオンサイトにて診断し、攻撃の入口となる可能性のある箇所を検出します。システムの導入・変更・アップグレード時、運用中のシステムの定期チェックにご活用いただけます。

    ネットワーク診断バナー広告

    デイリー自動脆弱性診断

    内部ネットワークおよびWEBサイトの脆弱性を自動診断し、その結果を専用のWEBページで報告します。新規設備投資が不要で、即時に結果を確認できるので、脅威が現実となる前に対策を施すことが可能になります。

    CPEバナー広告

    TLS設定を含めた通信の安全性や、Webサイト全体のリスク評価については、専門家によるセキュリティ診断や設定確認を活用することで、運用上の不安を減らすことができます。

    TLS設定の基本的な考え方やリスクについては、
    →「TLS設定の安全性と確認ポイント」もあわせてご覧ください。

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


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

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

    企業がランサムウェアに感染したら?被害事例から学ぶ初動対応と経営者が取るべき対策

    Share

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

    企業がランサムウェアに感染したら?被害事例から学ぶ初動対応と経営者が取るべき対策アイキャッチ画像

    近年、企業を狙ったサイバー攻撃は巧妙化・高度化し、なかでも「ランサムウェア」被害は深刻さを増しています。業務停止や顧客情報の漏えい、取引先・株主からの信頼低下など、企業経営を直撃するリスクが現実のものとなっています。もし企業がランサムウェアに感染したら、対応の遅れは損害の拡大を招きます。経営層こそ、リスクを正しく理解し、事前の備えと発生時の迅速な意思決定を行う必要があります。本記事では、企業向けにランサムウェアの最新動向と、感染した際に最優先で行うべき初動対応、そして再発防止策について解説します。

    ランサムウェアとは

    ランサムウェアは企業の重要データを暗号化し、復元と引き換えに身代金(Ransom)を支払うよう要求するマルウェアの一種です。

    かつては個人を標的とするケースが中心でしたが、近年では高額な金銭を得られる企業が主な攻撃対象となっています。製造、医療、インフラ、小売、自治体など業界を問わず被害が発生しており、サプライチェーン全体に影響を与えるケースも増加しています。

    身代金はビットコインなどの仮想通貨で要求されることがほとんどです。ただし、支払ってもデータ等が必ず元に戻るとは限りません。また、暗号化されたファイルのパスワードを解析して、自力で元に戻すことは、ほぼ不可能です。

    なぜ企業が狙われるのか

    企業が持つデータは攻撃者にとって高い価値を持ちます。特に以下の理由が挙げられます。

    • 業務停止を避けるため、身代金が支払われやすい
    • 顧客・取引先データなど外部へ悪用できる情報を保有している
    • セキュリティレベルのばらつきがある
    • クラウド移行、DX加速に伴い防御範囲が拡大している

    攻撃者は従業員のメールや脆弱なVPNを突破口として企業ネットワークに侵入し、内部に潜伏しながらバックアップ破壊など周到な準備を行った上で暗号化を実行します。

    被害を拡大させる「二重脅迫」が主流

    従来はファイルを暗号化して身代金を要求するだけだったランサムウェア攻撃ですが、近年主流となっているのが「二重脅迫(二重恐喝)」型です。これは、暗号化する前にデータを盗み出し、身代金の要求に加え、企業の機密情報をインターネットに公開するぞと、二重に脅迫を行う手法です。

    復旧可能なバックアップがあったとしても、情報漏えいリスクから身代金の支払いに追い込まれるケースが後を絶ちません。また、支払い後もデータ公開を止めない犯罪グループも存在します。

    企業のランサムウェア被害がもたらす影響

    ランサムウェア感染により、企業は多面的な損害を受けます。

    影響範囲内容
    業務面生産ライン停止、受注業務・物流遅延、顧客対応停止
    経済面身代金、復旧費、情報漏えい対応費、機会損失
    信頼面顧客・取引先・株主・社会的信用の失墜
    法的責任個人情報保護法、業界規制等による報告義務

    被害の総額は数千万円〜数十億円規模にのぼる例もめずらしくありません。

    どこから感染するのか(ランサムウェアの主な感染経路)

    多くは企業のセキュリティ対策が不十分な“穴”(=セキュリティホール)をついて侵入されます。

    • 標的型攻撃メール(添付ファイル・悪意あるリンク)
    • 脆弱性のあるVPN装置・リモート環境
    • 不正なソフトウェア・USBデバイス
    • サプライチェーンを介した侵入
    • 不正アクセスにより管理権限を奪取

    「メールを開いただけ」といった小さな油断から大被害へと発展します。このように、1つのマルウェアに感染することで様々なランサムウェアに感染する可能性があり、攻撃のパターンも複数あるということを認識しておく必要があります。

    企業がランサムウェアに感染したら:最初の72時間で何をすべきか

    感染発覚後の初動対応が、復旧の成否と被害額を大きく左右します。以下は企業が取るべき基本手順です。

    1. 被害範囲の特定と隔離
      ネットワークから切り離し、被害が拡大しないよう封じ込めます。
    2. 外部専門機関への早期連絡
      フォレンジック調査、インシデントレスポンス(CSIRT)と連携し、被害を技術的に分析します。
    3. 重要関係者への状況共有
      経営層/法務/広報/顧客/取引先/監督官庁など、情報開示を適切に実施します。
    4. バックアップからの復旧検討
      データの安全性を確認した上で、段階的に業務を再開します。
    5. 法的観点に基づく対応
      情報漏えいが発生した場合は報告義務が生じる可能性があります。

    “自社だけで判断しない”ことが極めて重要です。

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

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

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

    身代金を支払えば解決するのか?

    結論から言えば、身代金支払いは推奨されません。その主な理由は以下の通りです。

    • 復号ツールを受け取れる保証がない
    • データ公開を止める保証がない
    • 再び標的にされる可能性が高まる
    • 資金が犯罪組織の活動に利用される
    • 法令や国際規制に抵触するリスク

    国際的にも支払いは原則「NG」とされており、法務と専門家の判断を必須とすべき領域です。

    企業が導入すべきランサムウェア対策

    感染防止と被害最小化は両輪で取り組む必要があります。

    予防策(侵入させない)

    • EDR/XDRの導入
    • 脆弱性管理・パッチ適用
    • ゼロトラスト型アクセス制御
    • メール訓練と従業員教育

    ランサムウェアの対策として、EDR(Endpoint Detection and Response)やSIEM(Security Information and Event Management)製品を活用して、早期検知とブロックを行う方法がよく知られていますが、最大の感染経路のひとつである「メール」を対象にした訓練を行うことも有効でしょう。

    ランサムウェア対策のメール訓練としては、「定型のメールを一斉送信し、部署毎に開封率のレポートを出す」ことに加え、事前に会社の組織図や業務手順等のヒアリングを行ったうえで、よりクリックされやすいカスタマイズした攻撃メールを作成し、添付ファイルや危険なURLをクリックすることで最終的にどんな知財や資産に対してどんな被害が発生するか、具体的なリスク予測までを実施することをおすすめします。

    標的型メール訓練

    https://www.bbsec.co.jp/service/training_information/mail-practice.html
    ※外部サイトへリンクします。

    被害軽減策(侵入されても止める)

    • 隔離可能なネットワーク構成
    • 攻撃検知・自動遮断システム
    • 権限最小化・多要素認証

    復旧策(迅速に回復する)

    • オフライン・多重バックアップ
    • 復旧手順の事前検証
    • インシデント対応訓練

    経営者が担うべき役割

    ランサムウェアはIT部門だけでは対応できません。経営者視点で求められるのは以下です。

    • セキュリティ投資判断と優先順位付け
    • リスクを踏まえた継続的な管理体制の構築
    • 社内文化としてのセキュリティ意識向上
    • インシデント発生時の意思決定と情報開示方針の確立

    セキュリティは経営課題であり、企業価値を守るための投資です。

    まとめ:感染したら“すぐ動ける企業”へ

    企業がランサムウェアに感染したら、時間との戦いが始まります。初動が遅れるほど被害は拡大し、業務停止や情報漏えい、社会的信用喪失といった影響は深刻さを増します。だからこそ、「事前の備え(体制・技術・教育)」「迅速な判断(経営レベル)」「確実な復旧(検証された手順)」が不可欠です。

    攻撃はいつ起きてもおかしくありません。“感染したらどうするか”ではなく、“必ず起きる前提で備える”―それが企業のセキュリティ対策の出発点です。

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


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

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

    2025年3Q KEVカタログ掲載CVEの統計と分析

    Share

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

    2025年3QKEVカタログ掲載CVEの統計と分析アイキャッチ画像

    米国サイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)から公開されている「KEVカタログ(Known Exploited Vulnerabilities)」は、実際に攻撃に悪用された脆弱性の権威あるリストとして、組織のセキュリティ対策の優先順位付けに不可欠なツールとなっています。本記事では、KEVカタログに掲載された全データのうち2025年7月1日~9月30日に登録・公開された脆弱性の統計データと分析結果をみながら、2025年10月以降に注意すべきポイントや、組織における実践的な脆弱性管理策について考察します。

    本記事は2025年第1四半期~第4四半期の統計分析レポートです。以下の記事もぜひあわせてご覧ください。
    2025年1Q KEVカタログ掲載CVEの統計と分析
    2025年2Q KEVカタログ掲載CVEの統計と分析
    2025年4Q KEVカタログ掲載CVEの掲載と分析

    KEVカタログの概要と目的

    米政府CISAが公開するKEV(Known Exploited Vulnerabilities)カタログは、実際の攻撃で悪用が確認された脆弱性のみを掲載した公式リストです。セキュリティ担当者はこのカタログを参照することで、攻撃者の優先ターゲットを把握し、限られたリソースの中でも緊急度の高いパッチ適用など対策の優先順位を付けることができます。四半期ごとに更新され、米連邦政府機関(FCEB)は規定期限内の修正が義務付けられています(BOD 22-01)。民間企業・組織もこの知見を活用し、自組織の資産に影響する項目を常に監視・修正することでセキュリティリスクを低減できます。

    2025年Q3の統計データ概要

    登録件数推移:2025年7月~9月の3か月間に新規追加されたKEV登録脆弱性(CVE)は51件でした(7月:20件、8月:15件、9月:16件)。四半期全体では昨年同期よりやや減少していますが、依然として月によるバラつきが見られ(例:7月の米国定例更新後に登録が集中)、継続的な注視が必要です。

    ベンダー別状況:登録数の多かったベンダーは Microsoft 5件、Cisco 5件、Citrix 4件、Google 3件、D-Link 3件、TP-Link 3件 などです。特にMicrosoftとCiscoが最多件数を占め、WindowsやCiscoネットワーク機器への攻撃が続いています。D-Link/TP-Linkなど家庭用・SOHO機器向け製品も含まれており、これらは脆弱な旧機種のファームウェア更新が滞っている可能性があります。

    脆弱性タイプ(CWE):不適切なデータ逆シリアル化(CWE-502)関連の脆弱性が5件と最多で、続いてコマンドインジェクション(CWE-77, 4件)やサーバサイドリクエストフォージェリ(SSRF)(CWE-918, 2件)、OSコマンドインジェクション(CWE-78, 2件)、SQLインジェクション(CWE-89, 2件)などが目立ちます。これらは過去に頻出した攻撃手法であり、継続的に悪用されています。

    攻撃の自動化容易性(Automatable):「攻撃の自動化容易性(Automatable)」では、32件がNo(63%)、19件がYes(37%)でした。多くは手動操作や特定条件を要するため、自動スキャンによる大規模攻撃には向かない脆弱性です。

    Technical Impact:影響範囲では39件(約76%)がTotal(完全乗っ取り可能)に分類され、12件(24%)がPartialでした。攻撃者は主にシステム全面制御を可能にする脆弱性を狙う傾向が続いており、特にCriticalやHighスコアの欠陥を悪用しています。

    CVSSスコア:Q3の脆弱性ではCVSSベーススコア10.0が5件、9.8が4件、8.8が9件などハイスコアが多く、Critical帯(9.0以上)が約43%、High帯(7.0~8.9)が約39%を占めています。Q1では上位が8.8止まりでしたが、Q3には最大10.0点が新規に含まれており、深刻度の高い欠陥が多いことが分かります。

    攻撃手法・影響の深掘り分析

    ランサムウェア vs APT:1Q同様、ランサムウェア攻撃で悪用が確認されている事例は依然わずかです。一方で、国家または高度な持続的脅威(APT)による攻撃・スパイ活動での利用が多く見られます。CVE-2018-0171(Cisco IOS Smart Install脆弱性)やCVE-2023-20198は、中国系APT「Salt Typhoon」が実際に悪用したことが報告されています。ただし、敵対的勢力に限定されず、複数の脆弱性が攻撃チェーンで組み合わされることもあるため(1QではMitel事例など)、ランサムウェア対策も同時に強化すべきです。

    特定脅威の事例:FBIは2024年末、D-Link製カメラの脆弱性(CVE-2020-25078等)を狙った「HiatusRAT」活動を警告しており、実際にこの攻撃で3件の古いD-Link脆弱性がKEVに登録されました。サポート終了機器の脆弱性が未修正のまま放置されると、こうしたボットネットや遠隔操作マルウェアに利用されるリスクが高まります。

    CWE別動向:過去同様、コマンドインジェクション(CWE-78/CWE-77)やパストラバーサル(CWE-22)といった入力系脆弱性が依然悪用されています。また3Qでは不適切なデータ逆シリアル化(CWE-502)やメモリバッファ境界内での不適切な処理制限(CWE-119)など、複雑なプログラム上のロジック欠陥も目立ちます。これらはシステム乗っ取りや権限昇格につながりやすく、修正優先度が高い種類です。

    攻撃影響:攻撃者は依然として完全制御可能な脆弱性を好みます。たとえ部分的な影響にとどまる脆弱性であっても、別のTotal脆弱性と組み合わせて悪用されるケースもあります。したがって、CVSS値の大小だけにとらわれず、KEVに掲載されている時点で高い優先度で対応すべきです。

    組織が取るべき対策

    KEV優先パッチの適用:CISAは「KEV掲載項目を修正リストの優先対象とする」ことを強く推奨しています。組織は定期的にKEVカタログを監視し、自社使用製品に該当するCVEがあれば速やかにパッチ適用・緩和を実施する体制を整えましょう。

    主要ベンダー製品の更新:Microsoft、Cisco、Apple、Googleなど主要ソフトウェア・機器ベンダーは攻撃者の標的になりやすく、3Qも多くの脆弱性が報告されています。特に月例セキュリティアップデートや緊急パッチ情報を速やかにキャッチアップし、テストを経て迅速に展開することが重要です。

    ネットワーク機器・IoT機器の点検:D-Link、TP-Link、Ciscoのネットワーク機器やカメラ、NAS等のファームウェアも最新化しましょう。サポート切れ機種はできるだけ更新・交換し、致命的脆弱性の放置を避けます。公開緩和策(設定変更やネットワーク分離)も併用しつつ、インターネット上に不要なポート・サービスを露出しないようにします。

    検知・インシデント対応強化:脆弱性が攻撃に使われた痕跡を検知する対策も欠かせません。IDS/EDRのシグネチャや検知ルールを最新化し、CISAやセキュリティベンダーが提供するIoC/YARAルールを適用します。たとえまだ被害が確認されていない場合でも、KEV脆弱性攻撃の兆候を積極的に探すことで早期発見につながります。

    資産管理と教育:社内システムの全資産(ハードウェア・ソフトウェア)の棚卸しを行い、インベントリを最新化します。利用していないシステムや旧OSの台数削減、サードパーティーソフトの更新状況もチェックし、脆弱性の見逃しを防ぎます。また、開発・運用部門に対しては「古い脆弱性は放置厳禁」「セキュリティアップデート必須」の意識を共有し、定期的な啓発・トレーニングを行いましょう。

    脆弱性管理体制の強化:上記対応を継続的に行うため、脆弱性管理プロセスやツールを整備します。パッチ適用状況の追跡、KEVカタログとの自動照合、レポート体制など、業務フローに組み込み、専門人員や自動化ツールの活用も検討します。新たな脆弱性報告が急増した場合でも迅速に対応できるよう、定期レビューと定量的なKPI設定も有効です。

    まとめ

    2025年3QのKEVカタログ分析からは、Microsoft/Cisco製品やネットワーク機器を狙った攻撃が依然として顕著であること、古い脆弱性も攻撃対象になりやすいことが分かります。また、攻撃者はCVSSスコア「Critical」に限らず、「High」の脆弱性も活用しています。組織はKEV掲載の脆弱性=攻撃で狙われた証拠と捉え、迅速に対策を講じる必要があります。具体的には、KEVカタログを自社の優先パッチリストに組み込み、主要ベンダー更新と旧式機器の点検・更新を徹底することが重要です。セキュリティ担当者・経営層はこれらの統計を踏まえ、脆弱性管理の体制強化と運用改善に積極的に取り組むべきでしょう。

    CISAおよび関連情報源から提供されるKEVカタログには、常に最新の悪用脆弱性情報が掲載されます。定期的な情報収集と早期対策実施により、組織のサイバーリスクを効果的に低減することができます。

    BBSecでは

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

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

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

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

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

  • 2025年11月12日(水)14:00~15:00
    なぜ今“脆弱性診断”が必要なのか?実績データで見る検出傾向とサービス比較
  • 2025年11月26日(水)13:00~14:00
    【好評アンコール配信】「クラウド設定ミスが招く情報漏洩リスク -今こそ取り組むべき「クラウドセキュリティ設定診断」の重要性-
  • 最新情報はこちら


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

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

    セキュリティインシデントの基礎から対応・再発防止まで
    第2回:セキュリティインシデント発生時の対応 ─初動から復旧まで

    Share
    セキュリティインシデント発生時の対応アイキャッチ画像

    セキュリティインシデントは、発生した瞬間から組織に深刻な影響を及ぼす可能性があります。そのため、どれほど迅速かつ的確に対応できるかが被害の拡大を防ぐ鍵となります。特に初動対応の遅れは、情報漏洩の範囲拡大やシステム停止の長期化といった二次被害を招きかねません。本記事では、セキュリティインシデントが発生した際に組織が取るべき対応を、初動から原因調査、復旧、そして報告体制まで段階的に解説します。

    インシデント対応が遅れると被害が拡大する―「初動対応」の重要性

    セキュリティインシデントが発生した際、最初に求められるのは「被害の拡大を防ぐこと」です。具体的には、該当システムのネットワーク接続を遮断する、影響範囲を限定する、ログを確保して証拠を保存するといった行動が挙げられます。ここで重要なのは、焦ってシステムを完全に停止させたり証拠を消去したりしてしまわないことです。例えば、感染が疑われるPCを慌てて初期化すると、攻撃経路やマルウェアの痕跡といった重要な調査情報を失うことになり、後続の対応が困難になります。そのため、インシデント発生時には「まず拡大防止と証拠保全を優先する」という基本原則を徹底する必要があります。初動段階での判断ミスが、被害規模や復旧にかかる時間を大きく左右するのです。

    セキュリティインシデント対応の基本フロー

    社内連携と報告体制

    セキュリティインシデントが発生した際、技術的な対応と同じくらい重要なのが「社内連携と報告体制」です。現場担当者が異常を検知した場合、直属の上司や情報システム部門への迅速な報告はもちろん、経営層へのエスカレーションルートを明確にしておくことが不可欠です。さらに、インシデント対応を一部門だけに任せるのではなく、法務・広報・総務など関連部門との連携が欠かせません。例えば、法務部門は法的リスクの確認や外部機関への届出判断を担い、広報部門は顧客や取引先への適切な情報発信を行います。これらが連携できていないと、組織全体としての対応が後手に回り、混乱や信頼失墜を招く恐れがあります。そのため、平常時から「誰が・どのタイミングで・誰に報告するか」を明文化したインシデント対応計画を整備しておくことが重要です。

    被害範囲の特定

    セキュリティインシデントが発生した際に、初動対応で重要なのが「被害範囲の特定」です。単なる障害や一時的な不具合と、外部からの不正アクセスやマルウェア感染といったインシデントを明確に区別する必要があります。具体的には、ログの解析やネットワーク監視、ユーザ報告などを通じて、侵入経路や影響を受けたシステム、漏洩が疑われる情報を洗い出します。この段階で誤った判断を下すと、被害を過小評価して対応が遅れたり、逆に過大評価して不要な混乱を招いたりするリスクがあります。そのため、迅速かつ客観的に状況を評価できる仕組みを整えておくことが欠かせません。

    被害の封じ込め・拡大防止

    被害範囲を特定した後は、被害の「封じ込め」が必要です。これは、インシデントの拡大を防ぎ、さらなる被害を最小限に抑えるための重要なプロセスです。例えば、侵害を受けたサーバをネットワークから切り離す、攻撃者が利用したアカウントを即座に無効化する、通信を一時的に遮断するなどの対応が考えられます。ただし、封じ込めの方法を誤ると、証拠が失われたり、攻撃者に異変を察知されて活動を隠蔽されたりする恐れもあります。そのため、封じ込めの対応はセキュリティチーム内で役割を明確にし、優先順位を付けて慎重に進めることが求められます。

    原因調査・ログ解析・フォレンジック調査

    封じ込めが完了した後は、インシデントの原因を突き止める「原因調査」が不可欠です。攻撃者がどのように侵入したのか、どの脆弱性を悪用したのか、内部関係者の過失や不正が関与していないかなど、多角的な視点から調査を進める必要があります。ログ解析やフォレンジック調査を通じて、攻撃経路や被害状況を正確に把握することが求められます。この段階で調査が不十分だと、再発防止策が不完全となり、再び同様の被害を招く可能性が高まります。そのため、外部のセキュリティ専門家の協力を得るケースも少なくありません。

    復旧対応

    原因が特定された後は、システムやサービスの復旧作業に移ります。ただ単に停止したサービスを再開させるのではなく、原因を取り除き、安全性を確認したうえで再稼働することが重要です。例えば、脆弱性が悪用されていた場合はセキュリティパッチを適用し、不正アクセスで改竄されたデータがあればバックアップから復旧します。また、復旧の際には「段階的な再開」を意識することが推奨されます。いきなり全システムを戻すのではなく、優先度の高いシステムから順に稼働させ、監視を強化しながら正常性を確認することで、再度の障害発生や攻撃再開のリスクを軽減できます。

    関係者への報告・情報共有

    復旧作業と並行して、関係者への適切な報告や情報共有も欠かせません。セキュリティインシデントは自社だけの問題ではなく、取引先や顧客、さらには規制当局にまで影響が及ぶ可能性があります。そのため、影響範囲を正確に把握したうえで、必要な関係者に迅速かつ誠実に情報を提供することが求められます。特に個人情報漏洩が発生した場合、法令やガイドラインに従った報告が義務付けられているケースも多く、対応を怠れば法的リスクや企業の信頼失墜につながります。また、社内向けの情報共有も重要であり、従業員が不安や誤情報に惑わされないよう、明確なメッセージを発信する体制を整えることが望まれます。

    再発防止策の検討

    インシデント対応の最終段階は、再発を防ぐための改善策を講じることです。単に原因を修正するだけでなく、組織全体のセキュリティ体制を見直す機会として活用することが重要です。例えば、脆弱性管理の仕組みを強化する、アクセス制御のルールを見直す、ログ監視やアラートの精度を高めるなど、技術的な改善が挙げられます。また、従業員へのセキュリティ教育や定期的な訓練を実施し、人為的なミスや不注意を減らす取り組みも効果的です。さらに、インシデント対応の流れを記録し、振り返り(ポストモーテム)を行うことで、今後同様の事態が発生した際に迅速かつ適切に対処できる体制を構築できます。

    BBSecでは

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

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

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

    まとめ

    本記事では、セキュリティインシデントが発生した際に組織が取るべき対応を、初動から原因調査、復旧、関係者への報告、そして再発防止まで段階的に解説しました。インシデント対応は単なる技術的作業ではなく、社内連携や外部機関との調整、法令遵守、そして企業全体の信頼維持といった広範な要素が関わります。特に初動対応の速さや正確さは被害の拡大を防ぐ鍵となるため、日頃からの対応体制の整備や訓練が欠かせません。次回第3回では、インシデントの発生を未然に防ぐ取り組みや、組織全体でのセキュリティ強化策について詳しく解説し、実践的な予防策のポイントを紹介します。


    ―第3回へ続く―

    【参考情報】


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

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

  • 2025年10月8日(水)14:00~15:00
    ウェビナー参加者限定特典付き!
    ソースコード診断で実現する安全な開発とは?脆弱性対策とDevSecOps実践
  • 2025年10月22日(水)14:00~15:00
    ランサムウェア対策セミナー2025 ~被害を防ぐための実践的アプローチ~
  • 2025年10月29日(水)13:00~14:00
    【好評アンコール配信】「フィッシング攻撃の最新脅威と被害事例〜企業を守る多層防御策〜
  • 最新情報はこちら


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

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

    セキュリティインシデントの基礎から対応・再発防止まで
    第1回:セキュリティインシデントとは何か?基礎知識と代表的な事例

    Share

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

    セキュリティインシデントとは何か?基礎知識と代表的な事例アイキャッチ画像

    近年、企業や組織を取り巻くサイバー攻撃はますます巧妙化しており、「セキュリティインシデント」が発生した場合、情報漏洩や不正アクセスなどによって、金銭的損失だけでなく企業の信用失墜にも直結します。本記事では、セキュリティインシデントの定義や種類、実際に発生した事例を取り上げ、その影響とリスクを理解するための基礎知識を解説します。

    セキュリティインシデントの定義

    セキュリティインシデントとは、情報システムやネットワークにおいて、情報のセキュリティの3要素、「機密性」「完全性」「可用性」を脅かす事象の総称です。具体的には、不正アクセスや情報漏洩、マルウェア感染、サービス運用妨害(DoS)攻撃などが含まれます。近年はクラウドやリモートワークの普及により、攻撃対象や被害の範囲が広がり、セキュリティインシデントの発生リスクは増大しています。国内外で大規模な事件が相次いで報道されるなか、インシデントの発生はもはや大企業に限られた問題ではなく、中小企業や自治体、教育機関に至るまで幅広い組織が直面しています。そのため、経営層から現場担当者に至るまで、セキュリティインシデントへの理解と備えが求められているのです。

    セキュリティインシデントの種類(例)

    一口にセキュリティインシデントといっても、その内容は多岐にわたります。代表的なものとしては、まず「不正アクセス」が挙げられます。攻撃者が外部からシステムに侵入し、機密情報を窃取したり改竄したりするケースです。次に「マルウェア感染」があります。ウイルスやランサムウェアなどの悪意あるソフトウェアにより、データが暗号化され業務が停止する被害が増えています。また、従業員による「内部不正」も見逃せません。権限を持つ社員が意図的に情報を持ち出すケースや、誤操作による情報流出が問題化しています。さらに「情報漏洩」や「サービス停止(DoS/DDoS攻撃など)」も、企業活動を直撃する深刻なインシデントです。このようにセキュリティインシデントは外部攻撃だけでなく、内部要因やシステム障害など多面的に発生し得るため、幅広い視点での備えが不可欠です。

    実際に発生した主なセキュリティインシデント事例

    セキュリティインシデントは国内外で日々多発しています。この表は2025年8月から9月にかけて発生した主要な国内インシデント事例をまとめたものです。ランサムウェア攻撃や不正アクセスによる被害が多く、特に製造業や重要インフラへの影響が深刻化している傾向が見られます。

    被害報告日被害企業概要主な原因影響範囲
    2025年9月国内ガス・電力会社人為的ミスLPガス検針端末の紛失顧客情報6,303件の漏洩等のおそれ*11
    2025年9月国内デジタルサービス運営委託事業者個人情報漏洩受講状況管理ツールへの登録作業ミスリスキリングプログラム受講者1名の個人情報が他の受講者1名に閲覧可能に*2
    2025年9月国内食料品小売業個人情報漏洩サーバへの第三者からの不正アクセス企業情報及び個人情報が流出した可能性*3
    2025年9月委託事業者操作・管理ミスオペレーターの利用者情報取り違い高齢者の見守り・安否確認が行われず*4
    2025年9月国内オフィス機器販売会社個人情報漏洩第三者による不正アクセスカード支払い顧客の情報漏洩の可能性*5
    2025年8月ハウステンボス株式会社システム障害第三者による不正アクセス一部サービスが利用できない状況に*6
    2025年8月国内電力関連会社不正ログインリスト型攻撃(複数IPアドレスから大量ログイン試行)ポイント不正利用444件*7
    2025年8月国内機器メーカー企業不正アクセス海外グループ会社を経由した第三者の不正アクセス一部サービス提供停止(8月16日復旧)*8
    2025年8月医療用メーカー企業マルウェア感染システムのランサムウェア感染2日間出荷停止、その後再開*9
    2025年8月国内建設事業者マルウェア感染システムのランサムウェア感染海外グループ会社の一部サーバが暗号化*10
    2025年8月国内外郭団体乗っ取り第三者による一部メールアドレスの乗っ取り迷惑メール送信元として悪用*11
    2025年8月暗号資産交換事業者クラウド設定ミス顧客データ移転作業中のクラウド設定ミス海外メディアの報道で発覚、アクセス制限不備*12
    2025年8月国内銀行元従業員による情報の不正取得出向職員による電子計算機使用詐欺アコムから出向の元行員が逮捕・懲戒解雇*13
    2025年8月国内病院個人情報不正利用委託職員が診療申込書から電話番号を不正入手LINEで患者に私的メッセージを送付*14
    2024年12月国内総合印刷事業者マルウェア感染VPNからの不正アクセス(パスワード漏洩または脆弱性悪用)複数のサーバが暗号化される被害*15

    これらの事例は「セキュリティインシデントは特定の大企業だけの問題ではない」という現実を示しており、規模や業種にかかわらず備えが不可欠であることを強調しています。

    セキュリティインシデントが企業に与える影響

    セキュリティインシデントが発生すると、企業は多方面に深刻な影響を受けます。最もわかりやすいのは、システム停止や情報漏洩に伴う金銭的損失です。業務が一時的に止まることで売上が減少し、復旧作業や調査にかかる費用も膨大になります。さらに、顧客情報や取引先情報が流出すれば、企業の信頼性が大きく揺らぎ、契約解除や取引停止に直結する可能性があります。また、個人情報保護法や業界ごとのセキュリティ基準に違反すれば、法的責任や行政処分を受けるリスクも高まります。株式市場に上場している企業であれば、セキュリティインシデントの公表によって株価が急落するケースも少なくありません。このように、単なるシステム障害にとどまらず、企業経営全体に打撃を与える点がセキュリティインシデントの恐ろしさといえます。

    まとめ

    本記事では、セキュリティインシデントの定義や種類、実際に発生した事例、そして企業に及ぼす影響について解説しました。改めて強調すべきは、セキュリティインシデントは大企業だけでなく、中小企業や自治体、教育機関などあらゆる組織にとって現実的な脅威であるという点です。しかも一度発生すると、金銭的損失だけでなく、顧客や取引先からの信頼低下、法的リスク、社会的信用の失墜といった連鎖的な被害を引き起こします。こうした背景から、セキュリティインシデントを「発生してから考える」姿勢ではなく、「発生する前提で備える」姿勢が求められています。次回は、実際にインシデントが発生した際にどのような対応が必要なのか、初動から復旧までの流れを詳しく解説します。

    【参考情報】


    ―第2回へ続く―

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

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

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

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

  • 2025年10月1日(水)13:00~14:00
    2025年10月Windows10サポート終了へ 今知るべきサポート切れのソフトウェアへのセキュリティ対策ガイド
  • 2025年10月8日(水)14:00~15:00
    ウェビナー参加者限定特典付き!
    ソースコード診断で実現する安全な開発とは?脆弱性対策とDevSecOps実践
  • 2025年10月22日(水)14:00~15:00
    ランサムウェア対策セミナー2025 ~被害を防ぐための実践的アプローチ~
  • 2025年10月29日(水)13:00~14:00
    【好評アンコール配信】「フィッシング攻撃の最新脅威と被害事例〜企業を守る多層防御策〜
  • 最新情報はこちら


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

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

    連載記事:企業の「攻め」と「守り」を支えるIoT活用とIoTセキュリティ
    第2回 身近に潜むIoTセキュリティの脅威とは?─リスクと被害事例から学ぶ必要性

    Share

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

    IoT活用とIoTセキュリティアイキャッチ画像(IoTセキュリティの脅威)

    IoTの普及は企業活動を大きく変革する一方で、新たなセキュリティリスクを急速に拡大させています。スマートカメラや複合機といった身近な機器が攻撃の標的となり、情報漏洩や業務停止といった深刻な被害につながる事例も増加中です。本記事では、IoTセキュリティ特有の脅威や実際の被害事例を取り上げ、そのリスクを正しく理解することで、経営層やIT担当者が取るべき対策の必要性を明らかにします。

    IoTセキュリティの特殊性

    PCやサーバであればOSベンダーが月例パッチを配布し、管理者もGUIで容易に適用できます。ところが、IoTデバイスは制御用の軽量OSを採用しており、そもそも自動更新機能が実装されていない機種が少なくありません。屋外や高所に長期設置される機器の場合、物理的にアクセスしてUSB経由でアップデートする手間が大きく、結果として脆弱性が放置される確率が跳ね上がります。NIST SP 800-213は「設置場所と更新手段の乖離がIoT固有のリスクを増幅させる」と分析しています。

    攻撃者がIoT機器を狙う3つの合理性

    まず第1に台数の多さです。SonicWall社が公開している「2023 SonicWall Cyber Threat Report」によると、「世界のマルウェア感染端末の40%以上がIoT由来である」と指摘されています。第2に防御の甘さが挙げられます。JPCERT/CCが2024年に国内8,000台を調査*16したところ、Telnetや SSHのデフォルト認証情報がそのままのIoTデバイスが12%存在しました。第3は“隠密性”です。プリンタや監視カメラがマルウェアのC&C通信に使われても、ユーザは映像も印刷も通常どおり動くため気づきにくいという状況があります。

    代表的な被害事例

    2016年のMiraiボットネットはコンシューマー向けルーターとネットワークカメラに感染し、最大620GbpsのDDoSトラフィックを発生させ、米DNSプロバイダーDynを一時機能停止に追い込みました。2021年3月に表面化した Verkada社のスマートカメラ大量侵入事件では、管理者アカウント情報がGitHubに誤って公開され、テスラ工場や病院を含む15万台超の映像が外部から閲覧可能となりました。直近ではRapid7が2024年12月に公表したBrother製複合機の脆弱性(CVE-2024-22475ほか)も、認証バイパスによる遠隔コード実行が可能だったため、印刷ジョブを改ざんできるリスクが指摘されました*2

    主要IoTセキュリティ事件年表(2016-2025年)

    事件概要影響・被害
    2016Miraiボットネットが家庭用ルーターやネットワークカメラを大量感染させ、620Gbps超のDDoS攻撃で米DNS大手Dynを一時停止*3 大規模サービス停止・インターネット障害
    2017国内外で小規模監視カメラへの不正ログインが相次ぎ、ライブ映像がストリーミングサイトに無断公開*4 プライバシー侵害・二次被害拡大
    2018スマート冷蔵庫を含む家電の脆弱性が複数報告され、メーカーが初のOTAアップデートを緊急配布*5 家電乗っ取りリスク・アップデート体制の課題顕在化
    2019スマートロックなど家庭IoT機器でデフォルト認証情報が放置され、遠隔でドア解錠される事例が報道*6 個人宅への侵入・安全確保への不安
    2020新型Mirai派生マルウェアが出現、IoT機器を踏み台にしたDDoS攻撃件数が前年比2倍に*7 ネットサービス障害・帯域逼迫
    2021Verkada社クラウド連携カメラの管理認証情報が流出し、15万台超の映像が外部閲覧可能に*8 大規模映像漏洩・企業ブランド毀損
    2022国内調査で初期パスワードのまま運用されるIoTデバイスが12%見つかり、ボット化被害が多発ネットワーク踏み台化・社内横展開
    2023複数メーカーのスマート照明とセンサーでAPI認証不備が発覚し、遠隔操作や情報流出の恐れ*9 遠隔操作リスク・業務影響
    2024Brother製複合機に遠隔コード実行脆弱性(CVE-2024-22475など)が公表、修正ファーム未適用機が残存*10 印刷ジョブ改ざん・情報漏えい
    2025ランサムウェアが産業用IoT機器を暗号化し、生産ラインを停止させる事例が欧州で初報告*11 業務停止・身代金要求

    ※上記事例ソースはすべて一次ソース/一次レポートへの直接リンクもしくは、当該数値・事件を初報として扱った公式発表・専門調査記事です。

    放置すると何が起こるのか

    攻撃によってネットワーク経由で制御を奪われた生産ラインは、最悪の場合でシャットダウンや誤動作を招きます。IPAの試算では、主要部品メーカーが72時間停止した際のサプライチェーン損失は300億円規模に及ぶとされています。さらに監視カメラ映像の流出は顧客や従業員のプライバシー侵害となり、個人情報保護法やGDPRの制裁金が発生する可能性も否定できません。攻撃が社会的信用の喪失に直結する点で、IoTセキュリティは経営課題と捉える必要があります。

    国際・国内動向が示す「対策の必然性」

    ETSI EN 303 645(欧州電気通信標準化機構)は「サイバーセキュリティを前提にIoTを設計せよ」という“セキュリティ・バイ・デザイン”指針を2020年に発効しました。日本でも総務省が2022年に『IoT セキュリティアクション』を改定し、企業規模を問わず「現状把握・リスク分析・対策実装・監視運用」というPDCAを回すことを推奨しています。こうした規制・ガイドラインは今後さらに強化されると見込まれ、早期に準拠体制を整えた企業ほど市場競争力を高める構図になりつつあります。


    ―第3回へ続く―

    【連載一覧】

    ―第1回「今さら聞けないIoTとは?─IoTデバイスの仕組みと活用例で学ぶ基礎知識」―
    ―第2回「身近に潜むIoTセキュリティの脅威とは?─リスクと被害事例から学ぶ必要性」―
    ―第3回「企業が取り組むべき IoT セキュリティ対策とは?─実践例に学ぶ安全確保のポイント」―


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

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

  • 2025年9月10日(水)14:00~15:00
    フィッシング攻撃の最新脅威と被害事例〜企業を守る多層防御策〜
  • 2025年9月17日(水)14:00~15:00
    サイバーリスクから企業を守る ─脆弱性診断サービスの比較ポイントとサイバー保険の活用法─
  • 最新情報はこちら


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

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

    連載記事:企業の「攻め」と「守り」を支えるIoT活用とIoTセキュリティ
    第1回:今さら聞けないIoTとは?─IoTデバイスの仕組みと活用例で学ぶ基礎知識―

    Share

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

    IoT活用とIoTセキュリティアイキャッチ画像(IoTデバイスの基本)

    はじめに:連載の背景

    新聞やビジネス誌を開くと「IoTとは」という見出しを見かける日も多くなりました。しかし、IT部門や経営層の会議で実際に自社では何をどう活用するのかと議論が始まると、抽象論のまま立ち往生してしまう例が多いのも事実です。本連載では「IoTデバイスの基本」「IoTセキュリティの脅威」「企業が実践すべき対策」を三回にわたって解説します。最後まで読むことで、読者の皆様が社内で議論を前に進めるための土台が整えられることを願っています。

    「Internet of Things」誕生の背景

    IoTという造語は 1999年、英 Auto-ID Center(現MIT Auto-ID Lab)でRFID研究に携わっていたケビン・アシュトン氏が提唱したのが始まりとされています。当時はネットワークに常時接続するセンサーは高価で、実用化は一部の製造ラインに限られていました。ところが2010年代に入り、3G/4G回線の広域整備とWi-Fiチップの低価格化が進んだことで導入コストが急速に低下し、クラウドが解析基盤を提供する現在の「IoT構造」が定着しました。総務省『情報通信白書令和5年版』によれば、世界のIoT機器(以降、本記事内ではIoTデバイスまたはIoT機器と表記します)の稼働台数は2022年時点で約147億台、2025年には270億台超へ倍増すると見込まれています。

    IoT機器の台数推移(2022-2025年)

    参考:IoT Analytics「IoT 2022: Connected Devices Growing 18% to 14.4 Billion Globally」,「State of IoT 2024: Number of connected IoT devices growing 13% to 18.8 billion globally」(PDF)

    IoTアーキテクチャの四層モデル

    多くの国際標準では「デバイス層・ネットワーク層・プラットフォーム層・アプリケーション層」という四つの階層で IoTシステムを整理します。デバイス層では温度や振動を“測る”センサーと、モーターやリレーを“動かす”アクチュエータが中心的な役割を担います。ネットワーク層ではWi-Fi、Bluetooth Low Energy、LoRaWAN、NB-IoT、5Gなど目的に応じた通信技術が選択され、プラットフォーム層ではAWS IoT CoreやMicrosoft Azure IoT Hub、NTT Communications Things Cloud®などがデータの収集・蓄積・分析をつかさどります。最上位のアプリケーション層が可視化ダッシュボードや制御アプリを提供し、ユーザ企業はそこから意思決定を行うという構造です。

    参考:NIST SP 800-213「IoT Device Cybersecurity Guidance for the Federal Governent: Establishing IoT Device Cybersecurity Requirements」,GeeksforGeek「Architecture of Internet of Things (IoT)」,Zipit Wireless Blog「4 Layers of IoT Architecture Explained

    身近に増えるIoTデバイスの実像

    今や一般家庭にも浸透するスマートスピーカーは、音声認識マイクと温湿度センサーを内蔵し、クラウド側で音声コマンドを解析してエアコンや照明を制御します。オフィス向けではネットワークカメラがクラウド映像分析サービスと連携し、不審者や深夜の残業者を自動検知します。製造現場で稼働する振動センサーは0.1秒単位でモーターの揺れを測定し、閾値しきいちを超える振幅を捉えると、PLC(Programmable Logic Controller)へ緊急停止信号を返します。農業分野では土壌水分センサーと気象APIを組み合わせ、最適な潅水量を算定してポンプを自動起動するスマート農業システムが普及し始めました。医療分野のウェアラブル端末は心拍・SpO₂・体温をクラウドに送信し、医師が専用アプリで異常を見逃さない仕組みを構築しています。

    IoT例から見えるビジネスインパクト

    製造業の典型的なIoT事例は予知保全です。独Bosch Rexroth社はラインに5,000個のセンサーを実装し、振動データと過去の故障ログをAIが突き合わせることでダウンタイムを25%削減したと発表しています。小売業では米WalmarがRFIDと重量センサーを併用してリアルタイム在庫を可視化し、欠品率を16%下げたことで年間10億ドル規模の機会損失を回避したと報告しました。日本国内でも関西電力がスマートメーター経由で収集した使用電力データを解析し、節電インセンティブのプログラムを顧客へ提示することでピークカットに成功した事例が公表されています。

    導入メリットの裏に潜む注意点

    リアルタイムデータに基づく迅速な意思決定、業務の自動化、新規サービス創出という恩恵は大きいものの、IoTセキュリティが後手に回るとその利点は一瞬で吹き飛びます。総務省『IoT セキュリティガイドライン ver 1.0』では、「初期パスワードのまま運用」「ファームウェアの自動更新機能が無効」といった“ありがちな設定”を放置すると、攻撃者にネットワークの踏み台として悪用される危険性が高いと明示しています。次回以降、脅威と対策を深掘りしますが、まずは“便利さとリスクは表裏一体”であると認識することが企業リーダーへの第一歩です。


    第2回へ続く―

    【連載一覧】

    ―第1回「今さら聞けないIoTとは?─IoTデバイスの仕組みと活用例で学ぶ基礎知識」―
    ―第2回「身近に潜むIoTセキュリティの脅威とは?─リスクと被害事例から学ぶ必要性」―
    ―第3回「企業が取り組むべき IoT セキュリティ対策とは?─実践例に学ぶ安全確保のポイント」―


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

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

  • 2025年9月3日(水)13:00~14:00
    止まらないサイバー被害、その“対応の遅れ”はなぜ起こる?~サイバー防衛の未来を拓く次世代XDR:大規模組織のセキュリティ運用を最適化する戦略的アプローチ~
  • 2025年9月10日(水)14:00~15:00
    フィッシング攻撃の最新脅威と被害事例〜企業を守る多層防御策〜
  • 2025年9月17日(水)14:00~15:00
    サイバーリスクから企業を守る ─脆弱性診断サービスの比較ポイントとサイバー保険の活用法─
  • 最新情報はこちら


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

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

    記録破りのDDoS攻撃!サイバー脅威の拡大と企業が取るべき対策とは?

    Share

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

    近年、DDoS攻撃の規模と頻度が急激に増加しており、企業や組織にとって無視できない脅威となっています。特に、2024年第4四半期には、過去最大規模となる5.6テラビット毎秒(Tbps)のDDoS攻撃が確認され、サイバー攻撃の新たな段階へと突入したことがわかりました。この攻撃は、わずか80秒間で1万3,000台以上のIoTデバイスを利用して実行され、Cloudflare社のDDoS防御システムによって自動的に検出・ブロックされました。

    お問い合わせ

    お問い合わせはこちらからお願いします。後ほど、担当者よりご連絡いたします。

    DDos攻撃の事例として、SQAT.jpでは日本航空へのサイバー攻撃の実態についても解説しています。こちらもあわせてぜひご覧ください。
    【徹底解説】 日本航空のDDoS攻撃被害の実態と復旧プロセス
    Dos攻撃とは?DDos攻撃との違い、すぐにできる3つの基本的な対策

    DDoS攻撃の増加と進化する手口

    2024年第4四半期には、Cloudflare社が軽減したDDoS攻撃の件数が690万件にのぼり、前四半期比16%、前年比83%の増加を記録しました。さらに、1Tbpsを超える大規模攻撃の件数は前四半期比で1,885%も増加し、これまで以上に大規模な攻撃が常態化しつつあります。

    HTTP DDoS攻撃では、既知のボットネットによる攻撃が全体の73%を占め、11%は正規のブラウザを装った攻撃、10%は疑わしいHTTPリクエストによる攻撃でした。ネットワーク層(L3/L4)攻撃では、SYNフラッド(38%)、DNSフラッド(16%)、UDPフラッド(14%)が主要な手法として確認されています。また、Miraiボットネットの亜種による攻撃が特に顕著であり、2024年第4四半期には、この攻撃手法の使用頻度が131%も増加しました。

    企業が直面するDDoS攻撃のリスクとは?

    DDoS攻撃がもたらす影響は多岐にわたります。最も直接的な被害は、システムのダウンによる業務停止であり、企業の信用低下や顧客離れにつながる可能性があります。また、近年増加している「ランサムDDoS攻撃(Ransom DDoS)」では、攻撃を受けた企業が身代金の支払いを要求されるケースが増えています。2024年第4四半期には、Cloudflare社の顧客でDDoS攻撃を受けた顧客のうち、12%が身代金の支払いを求められ、前年同期比で78%の増加を記録しました。

    業界別にみると、通信業界が最も多くの攻撃を受け、次いでインターネット関連業界、マーケティング・広告業界が標的となっています。特に、金融業界は依然としてサイバー犯罪者にとって魅力的なターゲットとなっており、資金詐取を目的とした攻撃が増加しています。

    DDoS攻撃から企業を守るための対策

    DDoS攻撃の脅威が拡大するなか、企業は効果的な防御策を講じる必要があります。特に、以下のような対策が推奨されます。

    1. 常時オンのDDoS防御システムの導入
      DDoS攻撃の多くは短時間で発生するため、人間の対応では間に合わないケースが多いです。自動検知・防御機能を備えたDDoS対策ソリューションを導入することで、攻撃を迅速に無力化できます。
    1. ネットワーク層とアプリケーション層の両方を保護
      DDoS攻撃には、L3/L4(ネットワーク層)攻撃とL7(アプリケーション層)攻撃があります。両方の層に対する防御対策を講じ、ファイアウォールやWAF(Web Application Firewall)を活用することが重要です。
    1. ゼロトラストアーキテクチャの採用
      攻撃者の侵入を最小限に抑えるために、ゼロトラストモデルを導入することも有効です。認証・認可プロセスを強化し、アクセス制御を厳格化することで、不正なトラフィックを遮断できます。
    1. クラウドベースのDDoS対策の活用
      オンプレミスのDDoS対策はコストが高く、攻撃の規模が拡大するにつれて対応が難しくなります。クラウドベースのDDoS防御サービスを活用することで、スケーラブルなセキュリティ対策を実現できます。
    1. 定期的な脆弱性診断とインシデント対応計画の策定
      攻撃のリスクを最小限に抑えるために、定期的なセキュリティ監査を実施し、DDoS攻撃を想定したインシデント対応計画を策定することが不可欠です。特に、SLA(サービスレベルアグリーメント)を明確にし、攻撃発生時の対応フローを事前に決めておくことが重要です。

    今後のDDoS攻撃トレンドと企業が取るべきアクション

    DDoS攻撃は今後さらに巧妙化し、大規模化すると予想されています。特に、AIを活用したボットネット攻撃や、IoTデバイスを悪用した攻撃が増加する見込みです。さらに、特定の企業や業界を標的とした「高度な標的型攻撃(APT)」の手法がDDoS攻撃にも応用される可能性があります。

    企業は、単に防御するだけでなく、プロアクティブなセキュリティ戦略を採用し、攻撃を未然に防ぐ体制を構築する必要があります。DDoS攻撃はもはや一部の企業だけの問題ではなく、あらゆる業界にとって喫緊の課題となっています。

    常に最新の脅威情報を把握し、効果的な防御策を講じることで、企業のシステムとデータを守ることができます。DDoS攻撃のリスクを最小限に抑えるためには、今すぐ適切な対策を実施することが求められるでしょう。


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

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

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

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

  • 2025年2月19日(水)14:00~15:00
    Web担当者に求められる役割とは?Webサイトのガバナンス強化とセキュリティ対策を解説
  • 2025年2月26日(水)13:00~14:00
    AWS/Azure/GCPユーザー必見!企業が直面するクラウドセキュリティリスク
  • 2025年3月5日(水)13:00~14:00
    ランサムウェア対策の要!ペネトレーションテストとは?-ペネトレーションテストの効果、脆弱性診断との違い-
  • 2025年3月12日(水)14:00~15:00
    サイバー攻撃に備えるために定期的な脆弱性診断の実施を!-ツール診断と手動診断の比較-
  • 最新情報はこちら


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

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