ネットワーク

2026年4月21日2026年4月21日

CitrixBleed 3（CVE-2026-3055）の脆弱性：NetScaler ADC / Gatewayの影響・リスク・対策

CVE-2026-3055が注目される背景（CitrixBleedとの関連）

2026年3月、Cloud Software Groupは、Citrix NetScaler ADCおよびNetScaler Gatewayに関する複数の脆弱性情報を公表しました*1。その中でも特に注意が必要なのが、CVE-2026-3055です。

CVE-2026-3055は、NetScaler ADCおよびNetScaler GatewayがSAML IDPとして構成されている場合に影響を受ける、入力検証不備に起因するメモリオーバーリードの脆弱性です。Citrix公式アドバイザリでは、CWE-125、CVSS v4.0のベーススコア9.3、Criticalとして評価されています。本脆弱性は、通称「CitrixBleed 3」と呼ばれています。JPCERT/CCは、過去に大きな問題となったCitrix Bleed系の脆弱性、CVE-2023-4966、CVE-2025-5777との類似点が海外セキュリティ企業によって指摘されていると説明しています*2。

2025年7月に公表されたCitrix Bleed2（CVE-2025-5777）の脆弱性については以下の記事でご紹介しています。こちらもあわせてご覧ください。
「今すぐ対応を！Citrix Bleed2（CVE-2025-5777）の脆弱性情報まとめ」

企業にとって重要なのは、この脆弱性が単なる製品不具合ではなく、外部公開されている認証基盤やリモートアクセス基盤から情報漏洩につながる可能性がある点です。NetScaler GatewayはVPNやリモートアクセス、SSO連携の前段に置かれることが多く、侵害された場合の影響が社内ネットワーク全体に及ぶおそれがあります。

CVE-2026-3055の概要

CVE-2026-3055は、NetScaler ADCおよびNetScaler Gatewayにおけるメモリオーバーリードの脆弱性です。NVD（National Vulnerability Database）では、NetScaler ADCおよびNetScaler GatewayがSAML IDPとして構成されている場合、不十分な入力検証によりメモリオーバーリードが発生すると説明されています*3。

メモリオーバーリードとは、本来読み取るべきではないメモリ領域のデータが読み取られてしまう問題です。JPCERT/CCは、CVE-2026-3055について、遠隔の第三者によって意図しないメモリ領域のデータが読み取られる可能性があると注意喚起しています。この種の脆弱性で問題になるのは、攻撃者が直接ファイルを盗み出さなくても、メモリ上に一時的に残っていた情報が漏洩する可能性があることです。NetScalerのような認証や通信制御に関わる装置では、セッション情報、認証処理に関係する情報、SAML連携に関する情報などがメモリ上で扱われるため、情報漏洩の影響を慎重に評価する必要があります。

影響を受ける製品とバージョン

CVE-2026-3055の影響を受けるのは、NetScaler ADCおよびNetScaler Gatewayの一部バージョンです。Citrix公式アドバイザリでは、NetScaler ADCおよびNetScaler Gateway 14.1の14.1-60.58より前、13.1の13.1-62.23より前、NetScaler ADC FIPSおよびNDcPPの13.1-37.262より前が影響を受けるとされています。

ただし、バージョンだけでなく構成条件も重要です。Citrix公式は、CVE-2026-3055について、Citrix ADCまたはCitrix GatewayがSAML IDP Profileとして構成されていることを前提条件として示しています。確認方法として、NetScalerの設定内に “add authentication samlIdPProfile .*” が存在するかを確認するよう案内しています。つまり、NetScalerを利用しているすべての環境が同じ条件で影響を受けるわけではありません。しかし、SAML IDPはSSOや認証連携に関わる重要な構成で使われるため、該当する場合は優先度を上げて確認すべきです。

CVE-2026-3055はKEVカタログ登録済みの脆弱性

CVE-2026-3055は、すでに米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）のKEVカタログ（Known Exploited Vulnerabilities Catalog）に追加されています。NVD上でも、CVE-2026-3055がCISA KEVに登録されていること、追加日が2026年3月30日であること、米国連邦政府機関向けの対応期限が2026年4月2日であることが確認できます。KEVカタログへの追加は、少なくともCISAが既知の悪用済脆弱性として扱っていることを意味します。そのため、CVE-2026-3055は「将来的に悪用されるかもしれない脆弱性」ではなく、実際の攻撃リスクを前提として対応すべき脆弱性です。

JPCERT/CCも、2026年3月31日時点で海外セキュリティ企業から悪用に関する観測情報や詳細な技術情報が公表されていると説明しています。公開インターネット上にNetScaler ADCやNetScaler Gatewayを設置している企業は、すでに攻撃対象として探索されている可能性を考慮する必要があります。

CVE-2026-3055が「CitrixBleed 3」と呼ばれる理由

CVE-2026-3055は、正式名称として「CitrixBleed 3」と命名されているわけではありません。しかし、セキュリティ業界では、過去に大きな影響を与えたCitrix Bleed系の脆弱性との類似性から、このように呼ばれることがあります。過去のCitrix Bleedでは、NetScaler ADCやNetScaler Gatewayにおける情報漏洩が問題となり、認証情報やセッション情報の悪用が懸念されました。今回のCVE-2026-3055も、NetScaler製品におけるメモリ読み取りの問題であり、境界装置から情報が漏えいする可能性があるという点で、過去のCitrix Bleed系の問題を想起させます。JPCERT/CCも、CVE-2023-4966およびCVE-2025-5777との類似点が指摘されているとしています。

企業のセキュリティ担当者がこの名称に注意すべき理由は、名前そのものではなく、攻撃者が狙いやすい外部公開機器で、認証に関わる情報が漏洩する可能性があるという構図です。これは、ランサムウェア攻撃や標的型攻撃の初期侵入経路として悪用されるリスクを高めます。

悪用された場合のリスク

CVE-2026-3055を悪用された場合、最も懸念されるのは、NetScalerのメモリ上に存在する情報が第三者に読み取られることです。JPCERT/CCは、遠隔の第三者によって意図しないメモリ領域のデータが読み取られる可能性があると説明しています。

NetScalerは、社外から社内システムへアクセスする際の入口として利用されることがあります。SSL VPN、リモートアクセス、SSO、認証連携の前段に配置されることも多く、ここで情報漏えいが発生すると、単一システムの問題にとどまらず、社内ネットワークへの不正アクセスやアカウント悪用につながる可能性があります。

特に注意すべきなのは、パッチ適用だけでリスクが完全に消えるとは限らない点です。メモリ情報漏えい型の脆弱性では、修正前に何らかの情報が読み取られていた場合、その情報が後から悪用される可能性を否定できません。そのため、アップデートとあわせて、ログ調査、セッションの無効化、認証情報の見直し、関連アカウントの監視を実施することが重要です。

企業がまず確認すべきポイント

CVE-2026-3055への対応では、まず自社がNetScaler ADCまたはNetScaler Gatewayを利用しているかを確認する必要があります。特に、VPN、リモートアクセス、SSO、認証連携、社外公開システムの前段にNetScalerが配置されていないかを確認することが重要です。

次に、対象バージョンに該当するかを確認します。Citrix公式アドバイザリでは、NetScaler ADCおよびNetScaler Gateway 14.1の14.1-60.58より前、13.1の13.1-62.23より前、NetScaler ADC FIPSおよびNDcPPの13.1-37.262より前がCVE-2026-3055の影響を受けるとされています。

さらに、SAML IDPとして構成されているかを確認します。Citrix公式は、NetScaler Configuration内に”add authentication samlIdPProfile .* ”が存在するかを確認するよう案内しています。この設定が存在する場合、CVE-2026-3055の影響を受ける条件に該当する可能性があります。

対応方針：アップデートが最優先

CVE-2026-3055について、JPCERT/CCは、Cloud Software Groupが本脆弱性に対する回避策を提供していないと説明しています。そのため、アクセス制限や監視強化だけで対応を完了させるのではなく、修正済みバージョンへのアップグレードを基本方針とすべきです。Citrix公式アドバイザリでも、影響を受ける顧客に対して、関連する更新済みバージョンをできるだけ早くインストールするよう強く推奨しています。本番環境では検証や切り戻し計画が必要になる場合がありますが、KEVカタログに登録されていることを踏まえると、通常の月次パッチ対応よりも高い優先度で扱うべき脆弱性です。

侵害有無の確認方法

CVE-2026-3055では、パッチ適用と同時に侵害有無の確認も重要です。JPCERT/CCは、watchTowr Labsの情報として、CVE-2026-3055を悪用する攻撃の試行は、/saml/login への細工したPOSTリクエストや、/wsfed/passive?wctx へのGETリクエストによって行われると紹介しています。通常運用で想定されない送信元IPから、これらのエンドポイントへのアクセスがログに記録されていないか確認することが推奨されています。また、JPCERT/CCは、DEBUGレベルのログを有効化している場合、/var/log/ns.log に意図しない文字列が挿入される点もwatchTowr Labsが指摘していると説明しています。侵害が疑われる場合は、ログの保全、関係者への報告、メーカーや専門事業者への相談を検討すべきです。重要なのは、「アップデートしたから終わり」としないことです。すでに攻撃を受けていた場合、攻撃者が取得した可能性のある情報を前提に、セッションの無効化や認証情報の更新、管理者アカウントの確認、異常なログイン履歴の調査を進める必要があります。

なぜ境界装置は狙われるのか

近年、VPN装置、ADC、認証ゲートウェイ、ファイル転送装置など、インターネット境界に置かれる機器の脆弱性が繰り返し悪用されています。これらの機器は社内ネットワークへの入口に位置し、多くの場合、認証情報やセッション情報、社内システムへのアクセス経路を扱います。攻撃者にとっては、境界装置の侵害が効率のよい初期侵入手段となります。一般的な端末を一台ずつ狙うよりも、外部公開された認証基盤やリモートアクセス装置を突破する方が、社内環境へ到達しやすい場合があるためです。CVE-2026-3055は、まさにこの文脈で捉える必要があります。NetScaler ADCやNetScaler Gatewayを導入している企業は、単に脆弱なバージョンを更新するだけではなく、外部公開資産の棚卸し、設定確認、ログ監視、脆弱性情報の継続的な収集を組み合わせて対応する必要があります。

脆弱性管理で求められる実務対応

CVE-2026-3055のような重大なリスクレベルの脆弱性に対応するには、まず資産を把握していることが前提になります。どの拠点、どのクラウド環境、どのネットワーク境界にNetScalerが存在するのかを把握できていなければ、脆弱性情報が公開されても迅速に判断できません。また脆弱性の深刻度だけでなく、自社環境での露出状況を評価する必要があります。CVE-2026-3055はCVSS v4.0で9.3のCriticalと評価されていますが、実務上は、インターネットから到達可能か、SAML IDPとして構成されているか、認証基盤としてどの範囲に影響するかを確認することが重要です。さらに、KEVカタログへの登録の有無も優先順位付けの重要な判断材料になります。CVE-2026-3055はKEVカタログへ登録済みであり、NVD上でもその情報が確認できます。既知悪用脆弱性に該当する場合、通常の脆弱性対応よりも優先度を上げ、短期間での対応計画を立てるべきでしょう。

この脆弱性から学ぶべきポイント

CVE-2026-3055は、個別の製品脆弱性であると同時に、企業の脆弱性管理体制を見直すきっかけにもなります。特に、VPNや認証ゲートウェイのような外部公開機器は、業務継続に不可欠である一方、攻撃者にとっても魅力的な標的です。今後も、境界装置や認証基盤に関する脆弱性は継続的に公表されると考えられます。そのたびに場当たり的に対応するのではなく、外部公開資産の一覧化、バージョン管理、設定管理、ログ監視、緊急パッチ適用の判断基準をあらかじめ整備しておくことが求められます。特に、情シス部門やセキュリティ担当者が少人数で運用している企業では、脆弱性情報の収集、影響調査、優先順位付け、パッチ適用、侵害調査をすべて自社だけで行うことが難しい場合があります。その場合は、外部診断やセキュリティ監視サービス、インシデント対応支援を組み合わせ、重要な境界装置を継続的に確認できる体制を整えることが現実的です。

まとめ：CVE-2026-3055への対応ポイント

CVE-2026-3055は、NetScaler ADCおよびNetScaler GatewayがSAML IDPとして構成されている場合に影響を受ける、メモリオーバーリードの重大脆弱性です。この脆弱性の本質は、NetScalerという外部公開されやすい認証・通信制御基盤から、意図しないメモリ領域のデータが読み取られる可能性がある点にあります。企業は、NetScaler ADC / Gatewayの利用有無、対象バージョン、SAML IDP構成の有無を確認し、該当する場合は修正版へのアップグレードを速やかに進める必要があります。あわせて、/saml/loginや/wsfed/passive?wctxへの不審なアクセスの有無を確認し、侵害が疑われる場合はログ保全と専門的な調査を行うことが重要です。

CVE-2026-3055は、単なる一製品の脆弱性ではなく、外部公開資産と認証基盤の管理が企業のセキュリティに直結することを示す事例です。脆弱性管理は、パッチを当てる作業だけではありません。資産を把握し、影響を判断し、優先順位を付け、侵害有無まで確認する一連の運用として整備することが、今後ますます重要になるでしょう。

【参考情報】

Picus Security,BLOG”CVE-2026-3055 & CVE-2026-4368: Inside the NetScaler “CitrixBleed 3” Memory Overread”April 16, 2026,https://www.picussecurity.com/resource/blog/cve-2026-3055-cve-2026-4368-inside-the-netscaler-citrixbleed-3-memory-overread
Rapid7,BLOG”CVE-2026-3055: Citrix NetScaler ADC and NetScaler Gateway Out-of-Bounds Read”,Mar 31, 2026,https://www.rapid7.com/blog/post/etr-cve-2026-3055-citrix-netscaler-adc-and-netscaler-gateway-out-of-bounds-read/
watchTowr Labs,https://labs.watchtowr.com/
※7は記事タイトル・URLが変わる可能性があるため、watchTowr Labs内で「CVE-2026-3055」または「CitrixBleed 3」で検索するのが確実です。

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

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

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

2026年5月13日（水）13:00～14:00【好評アンコール配信】
「攻撃は本当に成立するのか？ペネトレーションテストで検証する実践的セキュリティ対策（デモ解説）」

2026年5月20日（水）14:00～15:30 <BBSec/Future/ハンモック共催>
「脆弱性管理の最適解 ― ASM・IT資産管理・脆弱性管理を分けて考え、統合するという選択」

2026年5月27日（水）14:00～15:00
「～取引先から求められる前に押さえる～ SCS評価制度への対応準備と現実的な進め方」

最新情報はこちら

編集責任：木下

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

2026年4月20日2026年4月21日

脆弱性スキャンとは？脆弱性診断ツールの選び方と導入ポイント

脆弱性スキャンは、企業のシステムやネットワーク、Webアプリケーション、クラウド環境に存在する既知の脆弱性を効率よく洗い出すための基本的な手段です。近年は、公開サーバーやVPN機器だけでなく、クラウド上のワークロード、コンテナ、OSSライブラリまで管理対象が広がっており、手作業だけで安全性を確認するのは現実的ではありません。そこで重要になるのが、脆弱性スキャナーや脆弱性診断ツールを使って、環境全体を継続的に確認する考え方です。CISAも、インターネット公開資産に対する継続的な脆弱性スキャンを、基本的な「サイバーハイジーン（Cyber Hygiene）」の一環として位置付けています。

ただし、脆弱性スキャンを導入すれば自動的に安全になるわけではありません。スキャンはあくまで既知の弱点を機械的に見つける仕組みであり、誤検知や過検知、設定不備の見落とし、業務影響を踏まえた優先順位判断までは自動では完結しません。そのため実務では、脆弱性スキャンの役割を正しく理解したうえで、脆弱性診断や脆弱性管理のプロセスと組み合わせて運用する必要があります。本記事では、脆弱性スキャンとは何か、脆弱性診断との違い、ツール比較のポイント、導入時の考え方までを整理します。

脆弱性スキャンとは

脆弱性スキャンとは、サーバー、ネットワーク機器、Webアプリケーション、クラウド環境などに対して自動的に検査を行い、既知の脆弱性や不適切な設定、不足している更新などを検出する仕組みです。企業が脆弱性スキャンを導入する目的は、攻撃者に悪用される前に自社環境の弱点を見つけ、修正につなげることにあります。米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）のCyber Hygiene Servicesでも、Vulnerability Scanning（脆弱性スキャン）はインターネットから到達可能な資産を継続的に監視し脆弱性の有無を評価するサービス、として説明されています。

脆弱性スキャンの特徴は、自動化にあります。人手では確認しきれない大量のIPアドレス、Webアプリケーション、仮想マシン、コンテナイメージなどを機械的に点検し、既知の脆弱性情報や設定ミスと突き合わせることで、短時間に広い範囲を確認できます。NIST SP 800-115『Technical Guide to Information Security Testing』でも、自動化されたテスト手法は情報セキュリティ評価の重要な手段とされ、SCAPのような標準化された枠組みが脆弱性管理の自動化を支えるものとして紹介されています。

一方で、脆弱性スキャンには限界もあります。自動スキャンは既知のパターンには強いものの、業務ロジックに起因する脆弱性や、文脈を踏まえた攻撃シナリオまでは把握しきれない場合があります。また、誤検知や重複検知が発生することもあるため、結果をそのまま鵜呑みにするのではなく、影響の確認と優先順位付けが必要です。つまり脆弱性スキャンは、脆弱性管理の入口として非常に有効ですが、それだけで完結するものではありません。

脆弱性スキャンを適切に実施するためには、対象となるIT資産を正確に把握することが重要です。サーバーやネットワークだけでなく、クラウド環境やOSSコンポーネントも対象となります。IT資産管理と脆弱性管理の関係については、以下の記事も参考になります。
「脆弱性管理とIT資産管理 -サイバー攻撃から組織を守る取り組み-」

脆弱性診断との違い

脆弱性スキャンと脆弱性診断は混同されやすい言葉ですが、実務上は役割が異なります。脆弱性スキャンは、既知の脆弱性や設定不備を自動的に広く洗い出すことに向いています。これに対して脆弱性診断は、専門家が対象システムの構造や挙動を踏まえながら、ツールだけでは見つけにくい問題も含めて詳細に評価する行為です。OWASPでは、ペネトレーションテストやセキュリティテストがスキャン単独よりも実際の攻撃可能性やリスク評価をより正確に把握する助けになる、と説明しています*4。

たとえば、Webアプリケーションに対する自動スキャンでは、SQLインジェクションやクロスサイトスクリプティングの典型的なパターンは検出しやすい一方で、権限管理の不備や業務フロー上のロジック欠陥、複数機能をまたいだ複雑な脆弱性は取り逃がす可能性があります。OWASPのOWASP Web Security Testing Guideでは、Webセキュリティ評価が単なる自動実行ではなく、アプリケーションの設計や攻撃面を踏まえた体系的なテストであることを示しています。

そのため企業では、脆弱性スキャンと脆弱性診断を対立概念として捉えるよりも、目的に応じて使い分けることが重要です。日常的な広範囲確認には脆弱性スキャンが向いており、公開Webサービスや重要システムの深い評価には脆弱性診断が向いています。脆弱性スキャンは継続運用の基盤、脆弱性診断は重点箇所の深掘りというように整理すると理解しやすいでしょう。

脆弱性スキャンの種類

脆弱性スキャンにはいくつかの種類があり、どこを対象にするかで使うツールや評価軸が変わります。

Webスキャン

OWASPでは、Webアプリケーション脆弱性スキャンを、外部からWebアプリケーションを自動検査し、XSS、SQLインジェクション、コマンドインジェクション、パストラバーサル、不適切な設定などの脆弱性を探すツール、として説明しています*2。いわゆるDAST（Dynamic Application Security Testing）に近い領域であり、インターネット公開されるサービスでは特に重要です。企業サイト、会員サイト、管理画面、APIなど、公開面があるならWebスキャンは有力な選択肢になります。

ネットワークスキャン

サーバー、ルーター、ファイアウォール、VPN装置などに対して、開いているポート、稼働サービス、既知の脆弱性、更新不足の状況を確認するものです。特にインターネットに公開された機器は攻撃対象になりやすいため、CISAも継続的なスキャンの重要性を強調しています。

クラウドスキャン

クラウドでは、OSやミドルウェアの脆弱性だけでなく、ストレージの公開設定、IAM権限、コンテナ設定、イメージの更新状況なども安全性に大きく影響します。従来型のネットワークスキャンだけでは十分でなく、CSPMやCNAPP系の機能を持つツールでクラウド設定やワークロードを可視化する必要があります。共有責任モデルのもとでは、クラウド事業者が管理しない部分は利用企業側が継続的に見なければなりません。

さらに、OSS脆弱性スキャン、いわゆるSCAも見逃せません。現代のソフトウェアは多くのOSSライブラリに依存しており、アプリケーション本体に問題がなくても、依存パッケージの脆弱性がリスクになります。NTIA（米国商務省電気通信情報局：National Telecommunications and Information Administration）が公開している「The Minimum Elements For a Software Bill of Materials (SBOM) 」では、SBOMをソフトウェアを構成する各種コンポーネントとサプライチェーン上の関係を記録する正式な記録、と定義しており、OSS脆弱性管理の前提として極めて重要です。SCAやSBOM対応ツールを使うことで、どのアプリケーションにどの部品が含まれているかを把握しやすくなります。

脆弱性スキャナーの比較

脆弱性スキャナーを比較するとき、まず見るべきなのはCVE対応の範囲です。脆弱性スキャンの基本は、既知の脆弱性データと自社環境を突き合わせることにあるため、どの程度広くCVE情報やベンダー情報に対応しているかは重要です。とはいえ、単に「CVEに対応している」と書かれているだけでは不十分で、更新頻度、対応製品の広さ、クラウドやコンテナへの追従性まで見たほうが実務では役立ちます。CISAが示す脆弱性管理の考え方*3でも、継続的に変化する資産や脅威を前提にした運用が重視されています。

次に確認したいのがスキャン精度です。脆弱性スキャナーは便利ですが、誤検知が多すぎると運用部門が疲弊し、逆に本当に重要な項目を見逃しやすくなります。逆に、検知が甘ければ見つかるべき脆弱性を取り逃がすことになります。ツールの比較では、単なる検知件数ではなく、結果がどれだけ実務で使いやすいか、重複排除や重要度の絞り込みがしやすいかも見ておく必要があります。OWASPが指摘するようにスキャン結果だけでは実際の攻撃可能性を完全に評価できない*4ため結果の解釈しやすさも重要です。

さらに、OSSライブラリ検出やSBOM生成の可否は、近年ますます重要になっています。SCAに対応していないツールでは、アプリケーション内部の依存関係まで把握できず、ソフトウェアサプライチェーンリスクへの対応が難しくなります。SBOMを生成・管理できるかどうかは、脆弱性スキャンの範囲をインフラからソフトウェア部品まで広げられるかどうかに直結します。NTIAはSBOMが脆弱性管理、ソフトウェア在庫管理、ライセンス管理などの基本ユースケースに役立つとしています。

脆弱性スキャン導入のポイント

脆弱性スキャンを導入する際に考えるべきポイントは以下のとおりです。

導入目的の明確化

公開Webサイトの安全性を高めたいのか、社内サーバーの更新漏れを防ぎたいのか、クラウド設定不備を見つけたいのか、OSS脆弱性を把握したいのかで、適したツールは変わります。目的が曖昧なまま「有名だから」という理由だけで導入すると、期待した検知ができなかったり、運用負荷だけが増えたりします。

導入後の運用体制の整備

脆弱性スキャンは、導入しただけでは意味がなく、誰が結果を確認し、どこまで精査し、どの基準で是正依頼を出し、修正後にどう再確認するかまで決めておく必要があります。NISTのパッチ・脆弱性管理ガイドでも、技術そのものより、継続運用のプロセス設計が重要であることが示されています。ツール導入はゴールではなく、脆弱性管理のサイクルを回すための手段です。

資産管理との連携

スキャン結果を脆弱性対応に直結させるためには、資産管理との連携も欠かせません。どのサーバーがどの業務に使われているのか、どのシステムが外部公開されているのか、どのアプリケーションがどのOSS部品を利用しているのかが分からなければ、検出された脆弱性の優先順位を決められません。特にクラウドやコンテナ環境では、資産の増減が激しいため、台帳やCMDB、クラウド資産可視化と組み合わせた運用が重要です。

脆弱性診断・ペネトレーションテストとの併用

脆弱性スキャンは広く速く確認するのに強い一方で、業務ロジックや複雑な攻撃経路までは十分に評価できないことがあります。公開サービスや重要システムでは、重点的な診断を組み合わせるほうが現実的です。OWASPも、ペネトレーションテストがスキャンだけでは見えない実攻撃視点の評価に役立つと説明しています。

脆弱性スキャンで脆弱性を発見した後は、迅速に対応を行うことが重要です。適切な優先順位付けやパッチ適用を行わなければ、攻撃リスクを低減することはできません。脆弱性対応の具体的な手順については、以下の記事で詳しく解説しています。
「脆弱性対応とは？CVE対応とパッチ管理の実務フロー」

脆弱性管理との関係

脆弱性スキャンは、脆弱性管理そのものではありませんが、脆弱性管理を支える重要な要素です。脆弱性管理は、資産把握、脆弱性情報収集、評価、是正、再確認を継続的に回す運用全体を指します。その中で脆弱性スキャンは、「発見」と「継続的な監視」を支える手段として機能します。CISAが脆弱性管理を、脆弱性や悪用可能な状態の頻度と影響を減らす取り組みとして整理している*5ことからも、スキャン単独ではなく運用全体の中で捉えるべきことが分かります。

脆弱性スキャンは、脆弱性管理の一部として実施される重要なプロセスです。しかし、スキャンを実施するだけでは不十分であり、発見した脆弱性を評価・対応まで含めて継続的に管理する必要があります。企業の脆弱性管理全体の流れについては、以下の記事で詳しく解説しています。
「脆弱性管理とは？企業が行うべき脆弱性管理の基本と実践手順【2026年版】」

実務では、脆弱性スキャンで見つけた結果をそのまま並べるだけでは意味がありません。資産の重要度、公開状態、CVSS、既知悪用の有無、業務影響などを踏まえて優先順位を決め、必要な修正や診断につなげていく必要があります。さらに、OSS脆弱性についてはSCAやSBOMを組み合わせて調査範囲を広げることが重要です。つまり脆弱性スキャンは、脆弱性管理の入口であり、全体運用へつなぐための観測手段だといえます。

まとめ

脆弱性スキャンとは、既知の脆弱性や設定不備を自動的に洗い出し、企業の攻撃面を継続的に可視化するための基本手段です。ネットワークスキャン、Webスキャン、クラウド環境スキャン、OSS脆弱性スキャンといった種類があり、企業のシステム構成に応じて適切に選ぶ必要があります。ただし、脆弱性スキャンは万能ではなく、脆弱性診断やペネトレーションテストのような深い評価とは役割が異なります。広く見つけるのがスキャン、深く確かめるのが診断、と整理すると理解しやすいです。

導入時に重要なのは、ツールの知名度ではなく、自社の目的に合っているかどうかです。CVE対応の広さ、スキャン精度、クラウド対応、OSSライブラリ検出、SBOM生成の可否などを見極めたうえで、導入後に誰がどのように結果を処理するかまで設計しておく必要があります。脆弱性スキャンを単独の製品選定で終わらせず、脆弱性管理の継続運用へつなげることが、企業にとって本当の導入効果につながります。

【参考情報】

NIST（米国立標準技術研究所）,NIST SP 800-40 Rev. 4,Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology（https://csrc.nist.gov/pubs/sp/800/40/r4/final）
NIST（米国立標準技術研究所）,NIST SP 800-40 Version 2（https://csrc.nist.gov/pubs/sp/800/40/ver2/final）

【関連ウェビナーのご案内】
本記事では、脆弱性スキャンとは何か、脆弱性診断との違い、ツール比較のポイント、導入時の考え方までを整理しました。次回、5月20日（水）14時からの開催のウェビナーでは、AssetViewとFutureVulsのメーカーが登壇し、各領域の役割をどのように整理し、どのように連携させれば実効性ある脆弱性管理が実現できるのか、解説します。脆弱性管理の考え方について深くを理解されたい方は、ぜひご参加ください。

その他のウェビナー開催情報はこちら

BBSecでは

BBSecでは以下のようなご支援が可能です。お客様のご状況に合わせて最適なご提案をいたします。

自ステムの状態を知る

SQAT^®脆弱性診断サービス

サイバー攻撃に対する備えとして、BBSecが提供する、SQAT脆弱性診断サービスでは、攻撃者の侵入を許す脆弱性の存在が見逃されていないかどうかを定期的に確認することができます。自組織の状態を知り、適切な脆弱性対策をすることが重要です。

アタックサーフェス調査サービス

インターネット上で「攻撃者にとって対象組織はどう見えているか」調査・報告するサービスです。攻撃者と同じ観点に立ち、企業ドメイン情報をはじめとする、公開情報（OSINT）を利用して攻撃可能なポイントの有無を、弊社セキュリティエンジニアが調査いたします。

編集責任：木下

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

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

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

2026年3月30日2026年3月30日

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

インターネット上の通信を安全に行うために欠かせない技術が「TLS（Transport Layer Security）」です。WebサイトのHTTPS通信は、このTLSによって保護されています。しかし、TLSは単に導入すれば安全というものではなく、バージョンや設定によってはセキュリティリスクが生じる可能性があります。本記事では、TLS設定の安全性を判断するために押さえておくべき基本的な考え方と確認ポイントを整理します。

具体的なバージョン確認や設定チェックの手順については、実践編の記事で詳しく解説しています。「TLSバージョン確認と安全な暗号設定方法」

TLSとは？

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

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

TLSの仕組み

TLSは主に以下の仕組みで通信を保護しています。

暗号化通信

送受信されるデータを暗号化することで、第三者に内容を読み取られないようにします。

認証（証明書）

サーバ証明書を用いて、通信先が正しい相手であることを確認します。

完全性の確保

通信内容が途中で改ざんされていないかを検証します。

TLSバージョンの違い

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

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

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

TLS1.2/1.3への移行手順と設定のポイントについては、以下の記事で詳しく解説しています。
「TLSバージョンの確認方法とは？ブラウザ・OpenSSL・ツールでのチェック手順と安全な設定ポイント」

TLSの脆弱性リスク

TLSは安全な通信技術ですが、バージョンや設定によっては脆弱性が存在します。

古いTLSのリスク

TLS1.0や1.1は既知の攻撃手法により、通信の安全性が低下する可能性があります。

設定不備によるリスク

設定不備によるリスク
証明書の不備
設定ミス

攻撃への悪用

これらの問題がある場合、

通信の盗聴
データ改ざん
不正アクセス

といった攻撃につながる可能性があります。

TLSの脆弱性は、発見後の対応も重要です。「脆弱性対応の基本と実践ポイント」

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

TLSを安全に運用するためには、適切な暗号設定が不可欠です。以下は基本的なガイドラインです。

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

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

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

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

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

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

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

定期的な設定確認

TLS設定は定期的に見直し、最新の推奨設定に更新する必要があります。

TLS設定の具体的な確認方法はこちら。
「TLSバージョンの確認方法とは？ブラウザ・OpenSSL・ツールでのチェック手順と安全な設定ポイント」

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

よくある質問（FAQ）

▼ TLSとは何ですか?

▼ TLS1.2とTLS1.3の違いは何ですか？

▼ TLSは導入すれば安全ですか？

▼ TLS1.0/1.1は使用しても問題ありませんか？

まとめ

TLSはWeb通信の安全性を支える重要な技術です。

通信の暗号化
認証
改ざん防止

といった役割を持ちますが、適切な設定と運用が不可欠です。

また、TLSバージョン設定の確認や脆弱性対応と組み合わせることで、より安全なシステム運用が可能になります。

【関連情報】

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

公開日：2020年7月29日
更新日：2026年4月1日

編集責任：木下

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

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

最新情報はこちら

2026年3月30日2026年3月30日

TLSバージョンの確認方法とは？ブラウザ・OpenSSL・ツールでのチェック手順と安全な設定ポイント

サイバー攻撃の多くは、暗号化通信の不備や古いセキュリティ設定を狙って行われます。特に、TLS（Transport Layer Security）の設定が適切でない場合、通信の盗聴や改ざんといったリスクが高まります。そのため、企業のWebサイトやシステムでは、現在使用しているTLSバージョンを正しく把握し、安全な設定を維持することが重要です。本記事では、TLSバージョンの確認方法と、安全な設定・運用のポイントを実務視点で解説します。

TLS設定の全体像やリスクについては、基礎解説の記事とあわせて確認すると理解が深まります。TLS設定の全体像やリスクを先に理解したい方は、「TLS設定の安全性と確認ポイント」を先にお読みください。

TLSとは？（基本の整理）

TLSは、インターネット上の通信を暗号化するためのプロトコルです。HTTPS通信は、このTLSによって保護されており、通信内容の盗聴や改ざんを防ぐ役割を担っています。

TLSのバージョン移行の背景

TLSはこれまで複数のバージョンが提供されてきましたが、セキュリティ上の問題により、古いバージョンは段階的に非推奨となってきました。特にTLS1.0およびTLS1.1は、暗号技術の脆弱性や攻撃手法の進化により安全性が不十分とされ、現在では主要なブラウザやサービスにおいて無効化されています。その結果、現在のWeb環境ではTLS1.2以上の利用が標準となり、さらにセキュリティと性能を強化したTLS1.3への移行が進んでいます。

TLSの仕組みやバージョンごとの違いについては、以下の記事で詳しく解説しています。
「TLS設定の安全性と確認ポイント：古い暗号設定が引き起こすリスクと改善手順」

TLSバージョンの確認方法

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

ブラウザで確認（例：Chrome）

Webサイトにアクセス
F12で開発者ツールを起動
[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（TLS1.0 / 1.1）バージョンを使い続けるリスク

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

多くのサイバー攻撃は、古いTLSバージョンなどの脆弱性を悪用して侵入されます。
脆弱性への具体的な対応方法については、以下の記事で詳しく解説しています。
→ 脆弱性対応の基本と実践ポイント

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

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

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

現在のセキュリティ対策の指標として一般的に用いられる各種国際的標準でも、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以下のプロトコルバージョンはすべて非推奨とされています。*3

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

安全な通信のためには、TLS1.2以上の利用が推奨されます。具体的には、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系*4（2021年9月）、Java SE/JDK 11（2018年9月）、Java SE/JDK 8バージョン8u261以上*5（2020年7月）や、そのほかにもRed Hat Enterprise Linux 8（2019年5月）が挙げられます。

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

設定時のチェックポイント

TLS1.0 / 1.1の無効化
安全な暗号スイートの使用
証明書の適切な管理

TLS設定を継続的に管理する重要性

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

定期的なチェック
設定変更時の再確認
最新のセキュリティ情報の把握

といった継続的な運用が重要です。

各種ガイドラインの紹介

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

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

PCI DSS v4.0で求められるセキュリティ対策のポイントについては以下の記事で詳しく解説しています。ぜひあわせてご覧ください。
「PCI DSS v4.0で変わるセキュリティ対策のポイント」

TLS設定確認を効率化する方法

TLS設定の確認・管理を効率化するには、ツールや外部サービスの活用が有効です。

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

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

BBSecでは

TLS設定の確認だけでなく、システム全体のセキュリティを強化するには、専門的な診断の実施が有効です。脆弱性診断やセキュリティ対策についてご検討の方は、お気軽にご相談ください。

ネットワーク脆弱性診断

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

デイリー自動脆弱性診断

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

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

公開日：2022年4月6日
更新日：2026年4月1日

編集責任：木下

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

2026年3月11日2026年3月11日

脆弱性診断の必要性とは？ツールなど調査手法と進め方

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

企業が施すセキュリティ対策は広範かつ複雑になっています。外部からのサイバー攻撃や、内部での情報の持ち出しなど、セキュリティの脅威が多様化しているためです。企業が保護すべき情報、アプリケーション、機器の種類・数などが拡大していることも理由に挙げられます。

「脆弱性診断」ではアプリケーションやサーバ、ネットワークに、悪用できる脆弱性がないかを診断します。本記事では、ライフサイクル別にどんな診断が必要か、ツール診断と手動診断、ペネトレーションテストとの違いなどを解説します。

脆弱性診断とは

脆弱性診断とは、企業・組織のシステムに内在するセキュリティ上の既知の欠陥（＝脆弱性）を特定する検査です。

脆弱性とは、システムやソフトウェアに存在するセキュリティ上の弱点を指します。
→「脆弱性の意味を正しく理解する―読み方・具体例・種類をわかりやすく解説」

Webアプリケーション、スマホアプリケーション、サーバ、ネットワークなど診断対象により様々な脆弱性診断があります。セキュリティ上の問題点を可視化することで、情報漏洩やサービス停止等のセキュリティ事故を防ぐために、どのような対策を実施すればよいか検討するのに役立ちます。

脆弱性診断の必要性

情報資産を守るため

情報のセキュリティの3要素、「機密性」「完全性」「可用性」を守るためにも、脆弱性診断は必要な理由の一つです。

「機密性」…限られた人だけが情報に接触できるように制限をかけること。
「完全性」…不正な改ざんなどから保護すること。
「可用性」…利用者が必要なときに安全にアクセスできる環境であること。

これらの要素を適切に満たすことが、情報セキュリティを担保する上では欠かせないものとなります。

情報セキュリティ事故を未然に防ぐため

攻撃者より先にシステムに隠れた脆弱性を検出して対策することで、攻撃や事故発生の確率を下げることができます。ひとたび個人情報やクレジットカード情報の漏えい事故が発生すれば、さまざまな対応・復旧費用や対策工数の発生は避けられません。ブランドの毀損や企業イメージの低下も招きます。

サービス利用者の安心のため

パソコンやインターネットを補助的に利用していた昔と異なり、現在はWebサービスやアプリケーションそのものが利益を生み出しています。生活や経済がネットワークなしに成り立たない現在、脆弱性診断などのセキュリティ対策は、事業を継続しサービス利用者の安心を守るため、欠かせないものとなっています。

脆弱性診断の種類

診断対象により、さまざまな脆弱性診断サービスがあります。まず、企業が開発したWebアプリケーションが挙げられます。問合せや会員登録といった、入力フォームの入出力値の処理、ログイン機能の認証処理などに対して、幅広く網羅的に脆弱性診断が行われます。

次に、そのWebアプリケーションを実行するサーバやネットワーク機器、OSやミドルウェアに脆弱性がないか検査するプラットフォーム診断があります。

アプリケーションの脆弱性診断には、既知の攻撃パターンを送付して対象システムやソフトウェアの挙動を確認する「ブラックボックステスト」という方法があります。「ブラックボックステスト」では、実装時における脆弱性は検出できますが、そもそもプログラムの設計図であるソースコード中に存在する脆弱性を網羅的には検査することには適していません。

この場合、ソースコード開示のもと「ソースコード診断」する方法が有効です。「ソースコード診断」は「ブラックボックステスト」に対して「ホワイトボックステスト」とも呼ばれます。また、「ソースコード診断」はさらに、プログラムを実行しないで行う「静的解析」と、実行して行う「動的解析」に分類できます。

ソースコード診断についてはこちらの記事もあわせてご参照ください。
「ソースコード診断の必要性とは？目的とメリットを紹介」

そのほか、近年増加の一途をたどるスマホアプリケーションやIoT機器を対象とした脆弱性診断もあります。

（株式会社ブロードバンドセキュリティのサービス分類に基づく）

脆弱性診断とペネトレーションテストの違い

脆弱性診断とペネトレーションテストは、双方とも脆弱性などを検出する点では似ていますが、目的と方法が少し異なります。脆弱性診断は既知の脆弱性を網羅的に検出することを目的としています。

ペネトレーションテストは、「侵入テスト」の名前のとおり、疑似的なサイバー攻撃を仕掛けてセキュリティ対策の有効性を評価するために実施します。技術的アプローチだけでなく、対象となる組織の構成や、業務手順、ときには物理的な施設の特徴すら加味して、攻撃シナリオを作成する「レッドチーム演習」と呼ばれるテストを実施することもあります。

シナリオに沿ってペネトレーションテスターが攻撃を実行し、システムに侵入できるか、ターゲットとする資産（多くは知的財産）にたどり着くことができるかどうかなどをテストします。ペネトレーションテストは脆弱性診断と比べて、技術力はもちろん、より幅広い見識やセンスが求められます。

脆弱性診断のやり方（方法）

脆弱性診断にはツールを使って自動で診断する「ツール診断」とエンジニアが診断する「手動診断」があります。

ツール診断

「ツール診断」では、セキュリティベンダーが、商用または自社開発した脆弱性診断ツールを用いて脆弱性を見つけ出します。脆弱性診断ツールと呼ばれるコンピュータプログラムを実行して、その応答から脆弱性を検知していくもので、自動診断とも呼ばれます。機械的に不正なHTTPリクエストを送り付ける疑似攻撃を行いますが、クラッカーによる攻撃とは異なり、あくまでも 脆弱性を見つけ出すことが目的であるため、システムを破壊することはありません。

ツール診断は機械的な検査であるため、過検知や誤検知なども含まれることが多く、その結果は担当者が補正することで正確な情報が得られます。比較的手軽に行えることから、開発段階で実施されることも多い診断です。また、定期的な簡易診断として用いることで、コストを低減しつつ最新の状態を保つことができるといった利用方法もあります。

脆弱性診断ツールとは

脆弱性診断ツールには、たとえばWebアプリケーション診断の場合に、検査コードと呼ばれる不正なHTTPリクエストを送信し 擬似攻撃するプログラムがあります。

手動診断

技術者がプロキシツールを介してWebブラウザでサイトにアクセスした際に発生するリクエストを書き換える形で、脆弱性を確認する方法です。ツール診断と比べ検査項目も広く、また細かな検査ができるのが特徴です。

手動診断は、経験と専門性を持つ技術者によって実施され、機械的な判断では見落としてしまう画面遷移・分岐にも対応できるメリットがあります。発見した脆弱性の再現手順や、最新動向を加味した対策方法などを提示してくれるのも、手動診断ならではの特徴と言えます。

ツール診断と手動診断は、どちらが優れていると比較するものではありません。それぞれの特長を生かし、予算に合わせて組み合わせることで、コストパフォーマンスを発揮できるでしょう。

脆弱性診断サービスの流れ

セキュリティベンダーに脆弱性診断を依頼する際は、まず 診断する範囲を決めます。組織にとって重要度が高い部分、すなわちサイバー攻撃を許してはいけないシステムやサーバ、Webアプリケーションを選定します。

診断が終了するとベンダーからレポートが提供され、報告会が行われることもあります。レポートに記載された脆弱性には深刻度などがスコア化されていることもあります。内容に応じて優先度をつけて、脆弱性をふさぐ必要があります。

継続的なセキュリティ対策の実施を

脆弱性診断は一度実施したらそれで終わり、というものではありません。脆弱性診断により発見された問題に対し対策を実施することで、より堅牢なシステム・環境・体制を構築することができます。

重要なのは、システムライフサイクルの各フェーズで、適切な診断を実施し、洗い出されたセキュリティ上の問題に優先順位をつけて、ひとつひとつ対処することです。診断ツールの検討に関しては自組織の環境やシステム特性に合わせたものを選定し、継続的なセキュリティ対策に有効活用できるようにしましょう。

まとめ

企業の情報システムが複雑かつ大規模になった現在、カード情報や個人情報・機密情報を狙う内外からの脅威に対して、企業もさまざまな予防手段を打っていく必要があります。情報システムやそれを取り巻く環境・体制が堅牢であるかどうかを検査、評価する方法として「脆弱性診断」があります。

・脆弱性診断とは企業・組織のシステムに内在するセキュリティ上の既知の欠陥（＝脆弱性）
　を特定する検査
・Webアプリケーション、スマホアプリケーション、サーバ、ネットワークなど診断対象により様々な脆弱性診断がある
・脆弱性診断を実施し洗い出されたセキュリティ上の問題に優先順位をつけて、ひとつひとつ対処することが重要である

公開日：2020年5月23日
更新日：2026年3月11日

編集責任：木下

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

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

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

2026年2月16日2026年2月16日

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

2026年2月、日本医科大学武蔵小杉病院は「院内の医療情報システムの一部がランサムウェア攻撃を受け、障害が発生した」こと、そしてそれに伴い患者の個人情報漏洩が確認されたことを公表しました*6。病院の発表は「第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装置や保守経路を例外扱いしない統制の重要性を、強く示しています。今後も病院の続報で情報が更新される可能性があるため、一次情報の確認を前提に、過度な憶測ではなく、現実的な警戒と備えにつなげることが肝要です。

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

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

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に戻る

2026年1月26日2026年1月28日

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

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年版の中で、特にメモリ領域の安全性に関連する項目としては以下が挙げられます。

CWE-787：範囲外の書き込み
CWE-416：解放したメモリの使用
CWE-125：範囲外の読み取り
CWE-476：NULLポインター逆参照
CWE-121：スタックベースバッファオーバーフロー
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に戻る

2025年11月20日2025年11月20日

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

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

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

ランサムウェアとは

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

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

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

なぜ企業が狙われるのか

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

国際的にも支払いは原則「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に戻る

2025年11月7日2026年1月29日

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

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

米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（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では

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

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

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

2025年11月12日（水）14:00～15:00
「なぜ今“脆弱性診断”が必要なのか?実績データで見る検出傾向とサービス比較」

2025年11月26日（水）13:00～14:00
【好評アンコール配信】「クラウド設定ミスが招く情報漏洩リスク -今こそ取り組むべき「クラウドセキュリティ設定診断」の重要性-」

最新情報はこちら

2025年10月2日2025年10月2日

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

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

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

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

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

社内連携と報告体制

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

被害範囲の特定

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

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

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

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

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

復旧対応

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

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

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

再発防止策の検討

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

BBSecでは

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

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

まとめ

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

―第3回へ続く―

【参考情報】

NIST SP 800-61 Rev. 2（https://csrc.nist.gov/pubs/sp/800/61/r2/final）
経済産業省「サイバー攻撃の被害に遭ってしまったら御活用を！―中小企業のためのセキュリティインシデント対応の手引き―」（https://www.meti.go.jp/policy/netsecurity/sme_incident.html）
独立行政法人情報処理推進機構(IPA)セキュリティセンター「中小企業のためのセキュリティインシデント対応の手引き」2024年7月（https://www.ipa.go.jp/security/sme/f55m8k0000001wpz-att/outline_guidance_incident.pdf）

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
【好評アンコール配信】「フィッシング攻撃の最新脅威と被害事例〜企業を守る多層防御策〜」

最新情報はこちら

CVE-2026-3055が注目される背景（CitrixBleedとの関連）

CVE-2026-3055の概要

影響を受ける製品とバージョン

CVE-2026-3055はKEVカタログ登録済みの脆弱性

CVE-2026-3055が「CitrixBleed 3」と呼ばれる理由

悪用された場合のリスク

企業がまず確認すべきポイント

対応方針：アップデートが最優先

侵害有無の確認方法

なぜ境界装置は狙われるのか

脆弱性管理で求められる実務対応

この脆弱性から学ぶべきポイント

まとめ：CVE-2026-3055への対応ポイント

脆弱性スキャンとは

脆弱性診断との違い

脆弱性スキャンの種類

Webスキャン

ネットワークスキャン

クラウドスキャン

脆弱性スキャナーの比較

脆弱性スキャン導入のポイント

導入目的の明確化

導入後の運用体制の整備

資産管理との連携

脆弱性診断・ペネトレーションテストとの併用

脆弱性管理との関係

まとめ

SQAT®脆弱性診断サービス

アタックサーフェス調査サービス

TLSとは？

TLSの仕組み

暗号化通信

認証（証明書）

完全性の確保

TLSバージョンの違い

TLSの脆弱性リスク

古いTLSのリスク

設定不備によるリスク

攻撃への悪用

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

定期的な設定確認

よくある質問（FAQ）

まとめ

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

TLSとは？（基本の整理）

TLSのバージョン移行の背景

TLSバージョンの確認方法

ブラウザで確認（例：Chrome）

OpenSSLコマンドで確認（Linux／Mac）

オンラインツールで確認

最新のTLSバージョン利用状況

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

古いTLS（TLS1.0 / 1.1）バージョンを使い続けるリスク

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

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

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

設定時のチェックポイント

TLS設定を継続的に管理する重要性

各種ガイドラインの紹介

TLS設定確認を効率化する方法

BBSecでは

ネットワーク脆弱性診断

デイリー自動脆弱性診断

脆弱性診断とは

脆弱性診断の必要性

情報資産を守るため

情報セキュリティ事故を未然に防ぐため

サービス利用者の安心のため

脆弱性診断の種類

脆弱性診断とペネトレーションテストの違い

脆弱性診断のやり方（方法）

ツール診断

脆弱性診断ツールとは

手動診断

脆弱性診断サービスの流れ

継続的なセキュリティ対策の実施を

まとめ

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

漏洩した個人情報

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

SQAT^®脆弱性診断サービス