脆弱性診断の基礎と実践!手動診断とツール診断の違いを徹底解説第3回:手動診断とツール診断、どちらを選ぶべきか?最適な診断方法の選び方

Share

手動診断とツール診断、どちらが自社に最適なのか?本記事では、「脆弱性診断の基礎と実践」をテーマに全3回のシリーズのうちの最終回として、手動診断とツール診断の両者の特性や違いを比較し、診断方法を選ぶポイントを解説します。最適な診断方法を見極め、継続的なセキュリティ対策を実現しましょう。

手動診断とツール診断の違い

脆弱性診断には「手動診断」と「ツール診断」の2つの手法があり、それぞれに検出できる脆弱性の範囲、診断の精度、コストや時間といった違いがあります。適切な診断方法を選ぶためには、それぞれの特性を理解することが重要です。

検出可能な脆弱性の範囲

診断手法検出可能な脆弱性の範囲
ツール診断CVE、OWASP Top 10などに基づき脆弱性を自動検出。ただし、システム固有の処理に関連する脆弱性の検出や複雑な攻撃手法には対応が難しい。
手動診断ツール診断では発見が難しいカスタムアプリの脆弱性や認証回避の脆弱性も検出可能。

ツール診断はパターンマッチングに基づく脆弱性スキャンが主であり、定型的なセキュリティホールの発見に優れています。一方、手動診断はシステムごとの特性を考慮した診断が可能で、セキュリティエンジニアによる最新の攻撃手法に基づいたシナリオでの診断にも対応できます。

診断の精度

診断手法精度
ツール診断短時間で広範囲の診断が可能だが、誤検知(False Positive)や見落とし(False Negative)が発生することがある。
手動診断セキュリティエンジニアが攻撃者視点で分析するため、より正確な脆弱性の特定が可能。誤検出を減らし、実際のリスクを精密に評価できる。

ツール診断は効率的に多くのシステムをスキャンできるメリットがありますが、誤検出や見落としのリスクがあるため、結果を精査する必要があります。手動診断は攻撃手法を考慮したテストを実施できるため、リスクの深刻度を正確に判断しやすいのが特長です。

コストと時間の違い

診断手法コスト時間
ツール診断比較的低コストである。短時間で診断可能(数時間~1日程度)。規模が小さいシステムであれば、数時間程度で診断が完了するため、定期的なスキャンが容易。場合によっては24時間いつでも診断が可能
手動診断専門のエンジニアが対応するためコストが高い。診断の範囲や内容によって費用が変動時間がかかる(数日~数か月)。対象システムの複雑さにより診断期間が変動

ツール診断は、コストを抑えて素早く診断ができる点が魅力ですが、ツールの設定や診断結果の解釈には専門知識が必要です。手動診断はコストや時間がかかるものの、外部のセキュリティ専門企業などに委託することによって、より精密な脆弱性評価が可能です。特に重要なシステムや高度なセキュリティ対策が求められる場面では有効です。

診断方法を選ぶ際のポイント

以下のポイントを考慮し、適切な診断方法を選ぶことが重要です。

組織の規模やセキュリティ方針に合わせた選択

組織の特徴推奨される診断方法
スタートアップ・中小企業(コストを抑え、効率的に診断したい場合)コストを抑えつつ効率的な診断を行いたい場合は、ツール診断が適している。自動化により定期的なチェックが可能。
大企業・金融・医療・官公庁高度なセキュリティ対策が求められるため、手動診断+ツール診断の組み合わせが効果的。特に重要システムには手動診断を推奨。
クラウド環境を利用する組織クラウド環境特有のリスクに対応するため、クラウドセキュリティに特化したツール診断と、必要に応じた手動診断の併用が理想的。

どのような診断が必要か

診断対象推奨される診断方法
WEBアプリケーションツール診断で基本的な脆弱性をチェックし、重要な部分に手動診断を実施。特に、認証機能や決済機能の診断には手動診断が有効
ネットワークセキュリティネットワークスキャンツール(例:Nmap、Nessus)を活用し、必要に応じて手動で詳細な分析を実施。ファイアウォールの設定やアクセス制御の確認が重要
クラウド環境(AWS、AZURE、GCPなど)クラウド専用の脆弱性診断ツールを活用し、アクセス制御や設定ミスをチェック。特に、IAM(Identity and Access Management)の監査が必要な場合は手動診断も推奨

ポイント:

  • Webアプリケーションの診断では、ツール診断でOWASP Top 10の脆弱性をスキャンし、カスタムアプリの診断には手動診断を追加するのが理想的
  • ネットワーク脆弱性診断では、ツール診断でポートスキャンを行い、不審な通信や設定の誤りを手動診断で確認する方法が有効
  • クラウド環境は設定ミスが原因の脆弱性が多いため、ツール診断を活用して広範囲をスキャンし、リスクの高い設定には手動診断を組み合わせることが推奨される

手動診断とツール診断の組み合わせ

手動診断とツール診断にはそれぞれメリットと限界があり、両者を適切に組み合わせることで、より高精度なセキュリティ対策が可能になります。ツール単独での診断では見落とされるリスクを補完し、組織のセキュリティレベルを向上させる戦略的なアプローチが求められます。

両者を組み合わせることで得られるメリット

スキャンの自動化と専門家による精査が両立

  • ツール診断で迅速に広範囲をスキャンし、重大なリスクが懸念される部分のみ手動診断を実施
  • 手動診断でツールの誤検出を精査し、実際のリスクを正確に判断

費用対効果の向上

  • 低コストでツール診断を定期的に実施し、大きな問題が発覚した場合のみ手動診断を適用することで、予算を最適化

診断結果の精度向上

  • ツール診断のスキャン結果を専門家が分析し、追加の手動診断を行うことで、より正確な脆弱性評価が可能

効果的なセキュリティ診断戦略の構築

手動診断とツール診断を組み合わせることで、組織ごとのセキュリティ要件に応じた診断戦略を構築できます。

(1) 定期的なスキャン+詳細なリスク分析

  • ツール診断を月次・四半期ごとに実施し、継続的にセキュリティ状況を監視
  • 重大なリスクが検出された場合のみ、対象システムの手動診断を実施して詳細分析

(2) システムの重要度に応じた診断手法の選択

  • 基幹システム・決済システムなどの重要システム
    手動診断を優先し、高精度な診断を実施
  • 一般的なWebアプリ・社内システム
    ツール診断で定期的にチェックし、基本的なリスクを管理

(3) インシデント対応と診断の連携

  • 過去のセキュリティインシデントの発生状況を分析し、手動診断で重点的にチェックすべき領域を特定
  • ツール診断のログを蓄積し、将来の診断方針に反映

適切な脆弱性診断サービスの選び方

診断会社を選ぶ際のポイント

脆弱性診断を外部に委託する場合、診断会社の選定は重要な要素となります。まず、診断の実績を確認し、自社の業界やシステムに適した経験があるかをチェックしましょう。特に、金融・医療・ECなどの高いセキュリティが求められる分野では、業界特有のリスクを理解している診断会社が望ましいでしょう。次に、対応範囲を確認し、Webアプリ、ネットワーク、クラウド環境など、自社のシステム構成に適した診断を提供できるかを見極めます。また、診断後のサポート体制も重要なポイントです。診断結果のレポート提供だけでなく、脆弱性修正のアドバイスや再診断が可能かどうかも確認し、長期的なセキュリティ強化に役立つパートナーを選びましょう。

費用対効果を考慮した最適な診断プランの検討

脆弱性診断のコストは組織にとって大きな課題ですが、単純に安価なサービスを選ぶのではなく、費用対効果を考慮した診断プランの選定が重要です。まず、診断の頻度と範囲を明確にし、必要最低限のコストで最大の効果を得られるプランを検討します。たとえば、定期的な診断が必要な場合はツール診断を活用し、重大なシステムについては手動診断を実施する組み合わせが有効です。また、診断会社ごとに料金体系や提供サービスが異なるため、複数社のプランを比較し、自社に最適なものを選択することが求められます。さらに、初回診断の割引や無料トライアルなどを活用することで、コストを抑えつつ診断の質を確認する方法も有効です。

まとめ:企業にとって最適な診断方法を選択する

脆弱性診断を効果的に活用するためには、自社のシステムやセキュリティ方針に適した診断方法を見極めることが重要です。コストを抑えながら広範囲をスキャンできるツール診断、高度な攻撃手法にも対応可能な手動診断、それぞれの特性を理解し、適切に使い分けることが求められます。また、企業の業種やシステムの重要度によって、手動診断とツール診断の組み合わせを検討することが望ましいです。

さらに、脆弱性診断は一度実施すれば終わりではなく、継続的なセキュリティ対策が必要です。サイバー攻撃の手法は日々進化しており、新たな脆弱性が発見される可能性があるため、定期的な診断と適切なセキュリティ対策の実施が欠かせません。企業のセキュリティレベルを維持・向上させるために、継続的な診断計画を立て、適切な対策を講じることが重要です。

BBSecでは

当社では様々なご支援が可能です。お客様のご状況に合わせて最適なご提案をいたします。

<SQAT診断サービスの特長>

Webアプリケーション脆弱性診断バナー

<デイリー自動脆弱性診断 -Cracker Probing-Eyes®->

CPEサービスリンクバナー

Security Report TOPに戻る
TOP-更新情報に戻る

―第1回「手動診断のメリットとは?」はこちら―
―第2回「ツール診断のメリットとは?」はこちら―


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

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

脆弱性診断の基礎と実践!
手動診断とツール診断の違いを徹底解説
第2回:ツール診断のメリットとは?

Share

ツール診断は、短時間で広範囲をスキャンし、コストを抑えながら効率的にセキュリティ対策を実施できる手法です。本記事は「脆弱性診断の基礎と実践」をテーマに全3回のシリーズのうちの第2回として、脆弱性診断の手法の一つであるツール診断のメリットや適しているケースについて解説します。

第1回「手動診断のメリットとは?」はこちら

ツール診断とは?

ツール診断とは、セキュリティベンダーが商用または自社開発した脆弱性診断ツールを使用し、システムやアプリケーションのセキュリティ上の脆弱性を自動的に検出する手法です。自動診断とも呼ばれ、比較的手軽に実施できるため、開発段階での利用や定期的な簡易診断としても活用されています。ただし、機械的な検査であるため、過検知や誤検知が含まれることが多く、その結果は技術者が補正することで正確な情報が得られます。ツール診断は、コストを低減しつつ最新のセキュリティ状態を保つ手段として有効です。

ツール診断の一般的な実施プロセス

ツール診断は、一般的に以下の流れで実施されます。

1.スキャンの対象設定

  • 診断対象のIPアドレス、ドメイン、アプリケーションURLなどを指定
  • 必要に応じて認証情報を設定し、ログイン後の動作も診断

2.脆弱性スキャンの実行

  • 診断ツールが自動で対象システムをスキャンし、脆弱性を検出
  • 既知の攻撃パターン(シグネチャ)を照合し、不正アクセスのリスクを評価

3.診断結果の解析

  • スキャン結果をもとに、発見された脆弱性の種類や影響範囲を整理
  • 誤検知が含まれていないかチェック(必要に応じて手動で確認)

4.結果レポートによる対策検討

  • 検出された脆弱性のリスクレベルを分類(例:高・中・低)し、結果を出力
  • 修正が必要な項目をリストアップし、対応策を検討

ツール診断のメリット

ツール診断を実施するメリットは、特に以下の3つの点があります。

1.短時間での診断が可能(大量のシステムやWebサイトを効率的にチェック)

ツール診断の最大の強みは、短時間で一括チェックが可能な点です。

  • 手動診断では膨大な時間がかかる大規模システムでも、診断対象を絞ることにより迅速にスキャンが可能。
  • 企業が運営する複数のWebサイトやサーバを一度に診断できる。

2.コストを抑えやすい(手動診断より低コストで運用可能)

ツール診断は自動化によって効率的になり、手動診断より低コストでの運用が可能です。

  • エンジニアの人的コストを削減
    ・手動診断は専門のセキュリティエンジニアが時間をかけて実施するため、コストが高くなりがち。
    ・ツール診断は自動で診断を行うため、人的リソースを節約できる。
  • 継続的な診断でも費用負担が少ない
    ・手動診断は1回ごとの費用が高く、頻繁に実施するのが難しい。
    ・ツール診断ならライセンス契約やサブスクリプション型などのツールを利用するため、低コストで定期的に診断することが可能。
  • 導入・運用の負担が少ない
    ・クラウド型の診断ツールも多く、専用機材の導入不要でスムーズに利用開始ができる。

3.定期的な診断が容易(スケジュールを自動化できる)

セキュリティ対策は一度行えば終わりではなく、継続的な監視と対策が不可欠です。ツール診断を活用すれば、コストを抑えつつ、定期的なスキャンを自動で実施し、最新の脆弱性を常にチェックできます。

  • スケジュール設定で定期スキャンが可能
    ・ツールを活用すれば、毎週・毎月・四半期ごとの定期スキャンを自動化できる。
    システムの更新後(パッチ適用後など)の検証にも活用できる。
  • 継続的なセキュリティ監視ができる
    ・手動診断では頻繁に実施するのが難しいが、ツールなら日常的なセキュリティ監視が可能。
    ・システム改修のたびに手動診断を依頼するより、ツールを活用して迅速に問題を検出できる。

ツール診断が適しているケース

ツール診断は特に以下のケースで実施が推奨されます。

1.定期的にスキャンしてセキュリティリスクを管理したい企業

ツール診断を導入することで、定期的なスキャンを自動化し、常に最新のセキュリティ状態を維持できます。

  • システムのアップデート後に迅速なリスクチェックが可能
    ・OS、アプリケーション、ミドルウェアのアップデート後に、脆弱性が新たに発生していないか即時に確認ができる。
    ・システム改修や機能追加時の影響を即座に確認できる。
  • 運用中のシステムに影響を与えない
    日常業務に影響を与えず、バックグラウンドで実施できる。

2.コストを抑えながらセキュリティ対策を進めたい場合

セキュリティ診断を実施したいものの、手動診断の高コストがネックとなる組織にとって、ツール診断は費用対効果の高い選択肢です。

  • 人件費が抑えられるため、低コストで運用可能
  • 大規模なシステムでもコストを抑えやすい
    特に、中小企業や予算が限られた組織にとって、手軽にセキュリティ対策を実施できる手法となる。
  • 社内での脆弱性診断の内製化が可能
    手動診断は外部のセキュリティ専門企業へ依頼するケースが多いが、ツール診断は自社で運用可能なため、外部委託のコストを抑えられる。

3.基本的な脆弱性を素早く把握したい場合

ツール診断なら、開発段階や運用中のシステムに対して、迅速にリスクを把握し、適切な対応が可能になります。

  • 即時スキャンで迅速な脆弱性検出
  • 開発段階での脆弱性検出に活用
    ・開発中のWebアプリやシステムに対して、リリース前に簡易スキャンを実施できる。
    ・これにより、本番環境でのリスクを最小限に抑えられる

ツール診断の限界

ツール診断はコストを抑えて効率的に運用できる点がメリットですが、場合によってツール診断だけでは限界があります。

1.誤検出や見落としの可能性がある

ツール診断は、自動でシステムの脆弱性をチェックする仕組みですが、その診断結果には誤検知(False Positive)や見落とし(False Negative)が含まれる可能性があります。

  • 誤検知(False Positive)
    ・実際には問題のないコードや設定を「脆弱性あり」と誤って検出するケース。
    ・例:「このページの入力欄にSQLインジェクションのリスクがある」とツールが指摘するものの、実際には適切なエスケープ処理が施されている場合。
  • 見落とし(False Negative)
    ・実際には脆弱性が存在するのに「問題なし」と判定してしまうケース。
    ・例:カスタム開発された認証フローに不備があっても、一般的な攻撃パターンにマッチしないため検出されない。
  • 誤検知や見落としの原因
    ツールの設定ミス:適切なスキャン設定を行わないと、正しい診断結果が得られない。
    検出ロジックの限界:ツールは既知の脆弱性パターンをもとに診断を行うため、未知の脆弱性やゼロデイ攻撃の検出には弱い。
    環境依存の問題:特定のアプリケーションやネットワーク環境では正しく診断できないことがある。

2.システム固有の脆弱性や複雑な攻撃パターンには対応できない

ツール診断は、主に既知の脆弱性をパターンマッチングによって検出するため、システム固有の処理に関わる脆弱性や、複雑な攻撃パターンには対応できません。

  • システム固有の処理に関連する脆弱性の例
    決済システムの不正操作:カートに入れた商品の価格を改ざんする攻撃。
    アクセス制御の不備:本来は管理者のみアクセス可能な機能を一般ユーザが利用できてしまう。
    認証バイパス:特定のリクエストを送ることで、パスワードなしでログインできてしまう。
  • 複雑な攻撃パターンの例
    API連携を悪用した攻撃:ツール診断ではAPI間の不正な連携による情報漏えいを検出しづらい。
    ・多段階の攻撃手法(チェーン攻撃):攻撃者が複数の脆弱性を組み合わせて攻撃する手法は、ツール単独では検出が難しい。

ツール診断は、効率的でコストパフォーマンスに優れたセキュリティ診断の手法ですが、その限界も理解し、必要に応じて手作業による診断と組み合わせることで、より信頼性の高いセキュリティ対策が可能となります。

まとめ

ツール診断は、自動化された脆弱性診断ツールを活用し、短時間で広範囲をスキャンできる効率的なセキュリティ対策です。手動診断と比べてコストを抑えながら、定期的な診断が容易に実施できるため、継続的なセキュリティリスク管理に適しています。また、基本的な脆弱性を素早く把握できるため、初期段階のリスク検出や、手動診断の補助としても活用可能です。しかし、ツール診断には誤検知や見落としといったリスクのほか、ビジネスロジックの脆弱性や複雑な攻撃手法の検出が難しいというデメリットが存在するため、単独では限界があります。そのため、より高度なセキュリティ対策を実現するには、手動診断との組み合わせが重要となります。

Webアプリケーション脆弱性診断バナー
CPEサービスリンクバナー

Security Report TOPに戻る
TOP-更新情報に戻る

―第1回「手動診断のメリットとは?」はこちら―
―第3回「手動診断とツール診断、どちらを選ぶべきか?最適な診断方法の選び方」はこちら―


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

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

テレワーク環境に求められるセキュリティ強化

Share
テレワークセキュリティ2.26更新版サムネイル

テレワークの普及に伴い、セキュリティ対策の重要性が一層高まっています。特に、在宅勤務やモバイルワークなど、多様な働き方が浸透する中で、情報漏えいや不正アクセスといったリスクへの対応が求められます。本記事では、最新のガイドラインや具体的な対策を踏まえ、テレワーク環境におけるセキュリティ強化のポイントを解説します。

テレワークの現状とセキュリティの重要性

総務省によれば、テレワークは「ICT(情報通信技術)を利用し、時間や場所を有効に活用できる柔軟な働き方」と定義されています。

テレワークを推進する総務省が刊行する「テレワークセキュリティガイドライン(第5版)」では、テレワークの形態を自宅を勤務場所とする「在宅勤務」、出先や移動中に作業する「モバイル勤務」、本社から離れた営業所やシェアオフィスなどを利用する「サテライトオフィス勤務」の3つに分類しています。

これらの働き方は柔軟性を提供する一方で、情報セキュリティの観点から新たな課題も浮上しています。特に、家庭内ネットワークの脆弱性や公共のWi-Fiを利用する際のリスクなど、従来のオフィス環境とは異なる脅威が存在します。

テレワークのセキュリティの基本的考え方

ガイドラインでは、クラウドサービスの活用やゼロトラストセキュリティの概念など、最新のセキュリティ動向を踏まえた対策が示されています。また、中小企業向けには「テレワークセキュリティに関する手引き(チェックリスト)」が提供されており、具体的な対策項目が整理されています。

図:テレワークにおける脅威と脆弱性について

(画像出典:総務省:「テレワークセキュリティガイドライン(第5版)」より一部抜粋)

テレワークにおけるセキュリティ対策の基本方針

テレワーク環境のセキュリティ対策は、「ルール」「人」「技術」の3つの要素のバランスが重要です。総務省のガイドラインでは、以下のポイントが強調されています。

  • ルールの整備:情報セキュリティポリシーの策定や、テレワーク時のデバイス使用に関する規定を明確にする
  • 人への教育:従業員に対する定期的なセキュリティ教育や訓練を実施し、フィッシング詐欺やマルウェアへの対処方法を周知する
  • 技術的対策:VPNの導入や多要素認証の活用、最新のセキュリティパッチの適用など、技術的な防御策を講じる

テレワーク環境下の人を狙ったサイバー攻撃

総務省ガイドラインが示す「ルール」「人」「技術」の中でも、特に忘れてはならない重要ポイントは人の問題です。令和元年度の情報通信白書においても、「ソーシャルエンジニアリング」が再び攻撃の中心になるという予測を紹介しています。

ソーシャルエンジニアリング対策としては、警視庁が「そのテレワーク、犯罪者が狙ってる!」と題する動画や、短編アニメ「テレワーク勤務時のセキュリティ基本篇」、啓発チラシ「ちょっと待って! そのテレワーク、セキュリティは大丈夫?」などを公開配布しています。

オフィスでみんなが席を並べて仕事していたら、いつもと違うメールが着信しても「こんなメールが届いた」と、隣席の同僚や情報システム部門に気軽に相談することができます。しかしテレワークではそれが簡単ではなくなります。人間心理の隙間を衝くような標的型攻撃メールなどに今まで以上に警戒が必要です。

また、政府のセキュリティ機関である内閣サイバーセキュリティセンター(NISC)は2020年4月、「テレワークを実施する際にセキュリティ上留意すべき点について」と題したテレワークに関する注意喚起を行っています。

NISCの注意喚起では、「政府機関」「重要インフラ事業者」「国民一般」の3つのカテゴリー毎に、セキュリティポリシーやルール整備、ICT環境の準備、安全な接続方法であるVPNやリモートデスクトップなどの技術活用にあたっての留意事項、遠隔会議システムの安全な利活用、機器のアップデートやパスワードの複雑化など、必要なセキュリティ対策がリストアップされています。

さらに、ノートPCの支給が間に合わずに個人端末の使用を許す場合もあり、これまでのような情報システム・IT部門による一括管理は難しくなりました。情報システム部門が個人端末に対してどこまで管理できるかの法的な問題もあります。また、一般社員に向けて、テレワークのセキュリティの留意点を告知したとしても、すべての社員がその内容を理解できているとは限りません。従業員向けの通達の意味が分からない場合、そのまま放置される可能性はどの程度あるでしょうか。それがリスクにつながるのであれば、通達の方法を変更するべきです。全従業員による確実な実施を徹底するため、情報システム部門からの通達内容において、使用されているIT用語は読み手のスキルレベルに対して適切か、耳慣れないと想定される言葉やプロセスは図を使用するなどして誰にでも等しくわかるような説明がなされているか、といった観点の校閲を設けるくらいの心構えが必要です。

テレワーク環境下でのセキュリティ対策

テレワーク環境の安全性を確保するためには、以下のようなポイントでセキュリティ対策を実施することを推奨いたします。

  • デバイスの管理:業務用デバイスと私用デバイスを明確に区別し、業務データの漏えいを防止する
  • ネットワークの安全性確保:自宅のWi-Fiには強固なパスワードを設定し、公共のWi-Fi利用は避ける
  • データの暗号化:重要なデータは暗号化し、万が一の情報漏えいに備える
  • アクセス権限の管理:必要最小限のアクセス権限を設定し、不正アクセスを防ぐ
  • 定期的なセキュリティ診断:専門機関によるセキュリティ診断やペネトレーションテストを実施し、システムの安全性を確認する

技術的な対策だけでなく、従業員のセキュリティ意識の向上や定期的なルールの見直しを行い、組織全体で継続的にセキュリティ対策を強化していくことが重要です。

セキュリティ診断もリモートで実施可能

情報システム部門が安全のためにできることがもうひとつあります。それは、リモートワーク環境を構成するVPN機器や認証サーバ、クラウド環境の接続拠点といったアクセスの出入り口における設定不備や、不正アクセスの原因となりうるセキュリティ上の欠陥の有無について、ハードやソフト面のセキュリティ診断を行うことです。

Webアプリケーションの脆弱性診断や、脆弱性が悪用された場合のインパクトを事前に調べるペネトレーションテストといったセキュリティ診断の多くは、インターネットを介して行うことができます。新型コロナ感染症対策でテレワークを経験した企業では、今後もテレワークを希望する人が少なくありません。今後もこうした働き方を継続するのであれば、一度は脆弱性の有無を確認し、安全な環境で業務を行えるよう環境を整備することをお勧めします。

まとめ

・新型コロナウイルス感染対策にともない、多くの組織が拙速にテレワークに移行したためセキュリティの課題がある。
・まずは警視庁や内閣サイバーセキュリティセンターの注意喚起を参照。
・総務省の出している詳しいガイドラインに沿って「ルール」「人」「技術」を見直そう。
・VPN機器やクラウド環境などテレワーク環境全体のセキュリティ診断を受けよう。

【関連情報】

●<インタビュー>上野 宣 氏 / ScanNetSecurity 編集長

●<コラム>「ゼロトラストアーキテクチャ」とは?

Security Report TOPに戻る
TOP-更新情報に戻る


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

  • 2025年3月5日(水)13:00~14:00
    ランサムウェア対策の要!ペネトレーションテストとは?-ペネトレーションテストの効果、脆弱性診断との違い-
  • 2025年3月12日(水)14:00~15:00
    サイバー攻撃に備えるために定期的な脆弱性診断の実施を!-ツール診断と手動診断の比較-
  • 2025年3月13日(木)11:00~12:00
    脆弱性診断、やりっぱなしになっていませんか?高精度診断と充実サポートでリスクを最小化〜サイバー保険で安心 診断から守るまでを徹底解説〜
  • 最新情報はこちら


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

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

    サイバー攻撃の脅威と新しい脆弱性診断サービス「SQAT® with Swift Delivery」のご提案

    Share

    第1章:深刻化するサイバー脅威の現状

    サイバー攻撃の進化と企業が直面するリスク

    デジタルトランスフォーメーション(DX)が加速する中で、企業を取り巻くサイバー脅威は急速に高度化しています。2023年には以下のような深刻なサイバー攻撃が顕在化しました。

    企業における脆弱性管理の課題

    多くの企業が抱える脆弱性管理の課題は、次の3点に集約されます。

    1. 脆弱性の発見遅延:新規脆弱性の平均発見所要時間は205日(出典:Ponemon Institute 2023 Vulnerability Report)、重大な脆弱性の見落とし率は約27%(出典:Cybersecurity Ventures
    2. 対応の遅延:脆弱性の発見から修正までの平均所要時間は67日(出典:Verizon Data Breach Investigations Report 2023)、クリティカルな脆弱性の放置率は約21%(出典:Gartner Security Trends 2023
    3. リソースの不足:セキュリティ人材不足率は約64%(出典:ISC2「Cybersecurity Workforce Study 2023」)、予算不足を報告する企業は68%に上る(出典:Deloitte Cyber Risk Report 2023

    事例から見る被害の実態

    事例1: 大手小売業A社
    被害額:約8.5億円。原因は既知の脆弱性の放置で、顧客情報320万件が流出。

    事例2: 製造業B社
    被害額:約12億円。新規サービス展開時の脆弱性を突かれ、生産ラインが14日間停止。

    第2章:脆弱性診断の重要性

    なぜ今、脆弱性診断が重要なのか

    1. 攻撃手法の高度化:AIを活用した自動攻撃やサプライチェーン攻撃の増加、ゼロデイ攻撃の脅威が拡大している
    2. 法規制の強化:個人情報保護法の改正やGDPR、CCPAなどの規制が強化されており、企業に高いセキュリティ対策が求められている。
    3. ビジネスリスクの増大:セキュリティインシデントによる信用失墜、損害賠償リスク、事業継続への影響が深刻化している

     脆弱性診断がもたらす価値

    • 予防的価値:攻撃を事前に防ぎ、リスクを早期に発見することで、セキュリティ体制を強化
    • コンプライアンス価値:法規制に適合し、監査対応を効率化することで、企業の説明責任を果たす
    • ビジネス価値:顧客の信頼を維持し、競争優位性を確保。事業継続性を向上させる

    新サービス「SQAT® with Swift Delivery」の特長

    当社が提供する「SQAT® with Swift Delivery」は、迅速かつ効果的な脆弱性診断を実現し、企業の安全性向上に貢献します

    主な特長

    1. 最短7営業日での報告書提出
      スピードを重視した診断を行い、ビジネスの迅速な意思決定をサポート
    2. 明確な料金体系
      診断日数に応じた料金を設定し、予算の見通しが立てやすい
    3. セキュリティ保険の付帯
      万が一のリスクに備え、保険による保証を提供いたします
    4. 60,280システム以上の診断実績
      幅広い業界での豊富な経験により、高い信頼性を確保
    5. わかりやすい報告書
      専門用語をなるべく避け、分かりやすく整理された報告書を提供し、改修のための情報を的確に伝える

    サービスご提供の流れ

    1. 初期相談:要件をヒアリングし、基点URLを基に診断の準備を開始。スケジュール確定が重視される
    2. 診断の実施:優先順位をつけて重要な部分から診断を行い、全体を効率よくカバー
    3. 報告書の提出:診断終了から2営業日以内に提出
    4. フォローアップ:報告書の内容についての質問対応を行い、次の対策につなげるサポートを実施

    まとめ

    サイバー攻撃の脅威が増す中、迅速かつ効果的な脆弱性診断は企業の存続に不可欠です。「SQAT® with Swift Delivery」は、スピーディーな診断と的確な情報提供により、企業のセキュリティ強化をサポートし、事業継続の安全性を確保するための理想的なサービスです。


    Security Report TOPに戻る
    TOP-更新情報に戻る

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

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

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

  • 2024年11月27日(水)12:50~14:00
    【好評アンコール配信】
    Webアプリケーションの脆弱性対策-攻撃者はどのように攻撃するのか-
  • 最新情報はこちら


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

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

    脆弱性診断は受けたけれど~脆弱性管理入門

    Share

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

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

    参考情報:

    Security Report TOPに戻る
    TOP-更新情報に戻る

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

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

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

  • 2024年9月18日(水)13:00~14:00
    【好評アンコール配信】
    ランサムウェアの脅威を知る-脅威に備えるためのランサムウェア対策-
  • 2024年9月25日(水)13:00~14:00
    【好評アンコール配信】
    ランサムウェア対策の要~ペネトレーションテストの効果、脆弱性診断との違いを解説~
  • 2024年10月2日(水)13:00~14:00
    【好評アンコール配信】
    サイバー攻撃に備えるために定期的な脆弱性診断の実施を!
     - ツール診断と手動診断の比較 –
  • 2024年10月9日(水)13:00~14:00
    【好評アンコール配信】
    システム開発のセキュリティ強化の鍵とは?
     -ソースコード診断で手戻りリスクとサイバー攻撃を未然に防ぐ-
  • 最新情報はこちら

    Youtubeチャンネルのご案内

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


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

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

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

    Share

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

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

    脆弱性診断とは

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

    脆弱性のリスクについてはこちらの関連記事もあわせてご参照ください。
    BBSec脆弱性診断結果からみる― 脆弱性を悪用したサイバー攻撃への備えとは ―
    定期的な脆弱性診断でシステムを守ろう!-放置された脆弱性のリスクと対処方法-
    既知の脆弱性こそ十分なセキュリティ対策を!
    今、危険な脆弱性とその対策―2021年上半期の診断データや攻撃事例より―

    脆弱性診断の必要性

    情報資産を守るため

    CIA説明画像

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

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

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

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

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

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

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

    脆弱性診断の種類

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

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

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

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

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

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

    脆弱性診断画像

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

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

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

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

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

    脆弱性診断のやり方(方法)

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

    ツール診断

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

    CPEサービスリンクバナー

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

    脆弱性診断ツールとは

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

    手動診断

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

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

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

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

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

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

    チームによる診断・分析・保守画像

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

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

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

    まとめ

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

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

    まずは無料で資料をダウンロード

    サービス内容が記載されている資料がダウンロードできるURLをお送りいたします。
    見積もりについてのご相談は、お問い合わせよりご連絡ください。

    Security Report TOPに戻る
    TOP-更新情報に戻る


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

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


    診断結果にみる情報セキュリティの現状 ~2023年上半期 診断結果分析~

    Share

    SQAT® Security Report 2023-2024年秋冬号

    2023年上半期診断結果分析サムネ画像(PCの画面イメージ)

    BBSecの脆弱性診断

    システム脆弱性診断で用いるリスクレベル基準

    BBSecのシステム脆弱性診断は、独自開発ツールによる効率的な自動診断と、セキュリティエンジニアによる高精度の手動診断を組み合わせて実施しており、高い網羅性とセキュリティ情勢を反映した診断を実現するため、セキュリティエンジニアおよびセキュリティアナリストが高頻度で診断パターンを更新し、診断品質の維持・向上に努めている。検出された脆弱性に対するリスク評価のレベル付けは、右表のとおり。

    脆弱性診断サービスの基本メニューである「Webアプリケーション脆弱性診断」・「ネットワーク脆弱性診断」の2023年上半期(1月~6月)実施結果より、セキュリティ対策の実情についてお伝えする。

    2023年上半期診断結果

    Webアプリ/NW診断実績数

    2023年上半期、当社では12業種延べ553企業・団体、3,396システムに対して、脆弱性診断を行った(Webアプリケーション/ネットワーク診断のみの総数)。

    2023年上半期システム脆弱性診断 脆弱性検出率の棒・円グラフ

    9割のシステムに脆弱性

    「Webアプリケーション診断結果」の棒グラフのとおり、Webアプリケーションに
    おいて、なんらかの脆弱性が存在するシステムは9割前後で推移を続けている。検出された脆弱性のうち危険度レベル「高」以上(緊急・重大・高)の割合は17.5%で、6件に1件近い割合で危険な脆弱性が検出されたことになる。

    一方、ネットワーク診断では、なんらかの脆弱性があるとされたシステムは約半数だったが、そのうちの危険度「高」レベル以上の割合は23.8%で、5件に1件以上の割合であった。

    以上のとおり、全体的な脆弱性検出率については、前期と比較して大きな変化はない。当サイトでは、「2023年上半期カテゴリ別脆弱性検出状況」とし、検出された脆弱性を各カテゴリに応じて分類しグラフ化している。

    Webアプリケーション診断結果

    高リスク以上の脆弱性ワースト10

    リスクレベル高以上の脆弱性で検出数が多かったものを順に10項目挙げてみると、下表のような結果となった。

    長年知られた脆弱性での攻撃

    「Webアプリ編」について、1位、2位は前期同様「クロスサイトスクリプティング(以降:XSS)」と「HTMLタグインジェクション」となった。3位以下は、脆弱性項目は前期からあまり変化はないものの、「SQLインジェクション」が順位を上げた。

    3位の「サポートが終了したバージョンのPHP使用の可能性」など、サポートが終了したバージョンのコンポーネント(プログラム言語、ライブラリ等)の使用がワースト10の4項目を占めている。サポート終了とはすなわち、新たに脆弱性が発見された場合でもコンポーネントの提供元は基本的に対処しないということであり、危殆化に対する利用者側での対策が困難となるため、継続利用は危険である。例えば、サポートが終了した製品についての脆弱性情報の公開が契機になり、攻撃コードが公開され、攻撃が活発化することも考えられる。最新バージョンへのアップデートを迅速に、定期的に実施すべきである。

    ネットワーク診断結果

    高リスク以上の脆弱性ワースト10

    ネットワーク診断結果に関しても、リスクレベル高以上の脆弱性で検出数が多かったものを順に10項目挙げてみると、下表のような結果となった。

    高リスク以上の脆弱性ワースト10(2023年上半期)NW編の表

    アクセス制御が不適切な認証機構の検出がランクイン

    「ネットワーク編」のワースト10については、ワースト4までが前期と変わらず、5位、6位は順入れ替えという結果で、あまり大きな変動は見られなかったが、8位の「アクセス制御が不適切な認証機構の検出」が前期圏外からランクインした。「アクセス制御が不適切な認証機構」には、特権アカウントやデフォルトアカウント等を使用してログインできる脆弱性も含まれる。特権アカウントがデフォルトのまま、もしくは推測されやすい認証情報で設定されていた場合はさらに危険である。デフォルトアカウントやデフォルトパスワードを使用せず、推測されにくい複雑なパスワードを設定することや、ログイン画面に対するアクセスを強固に制御すること、特権アカウントは必要最小限のユーザにのみ付与することなどが推奨される。

    カテゴリ別の検出結果詳細についてはこちら

    Security Report TOPに戻る
    TOP-更新情報に戻る


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

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


    Security Serviceのサムネ

    BBsecサムネ

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

    セキュリティトピックス告知のサムネ

    SQLインジェクションの脆弱性
    -Webアプリケーションの脆弱性入門 2-

    Share

    SQLインジェクション攻撃は多くの企業やシステムにとって大きな課題となっています。本記事では、SQLインジェクションの基本的な仕組みから、その主な原因とリスクについて解説します。また、企業での対策方法についても紹介します。SQLインジェクションの脆弱性のリスクを認識し、その対策方法を学びましょう。

    前回までの内容

    クロスサイトスクリプティング(XSS)とは、動的にHTMLを生成するWebアプリケーションで、ユーザの操作を介して不正なスクリプトを実行させる(できる)事象を指します。このクロスサイトスクリプティングの脆弱性を悪用した攻撃手法をクロスサイトスクリプティング攻撃と呼び、これは、ユーザのブラウザ上で不正なスクリプトを実行させ、個人情報等を漏えいさせるという仕組みです。XSSには「反射型」「蓄積型」「DOMベース」の3種類があり、それぞれ異なる方法で攻撃が行われます。XSSの主な原因は、出力の検証や処理が不十分であることです。攻撃者は、例えば、コメント欄や検索ボックスなどユーザからの入力を受け付ける部分にスクリプトを挿入することで、他のユーザのCookie情報等を搾取することが可能となります。対策としては、スクリプト言語における特別な意味を持つ文字や記号を置き換える「エスケープ処理」の実施や、Webアプリケーションファイアウォール(WAF)の活用等があります。また、セキュリティ診断を定期的に行い、リスクを可視化して適切なセキュリティ対策を実施することが重要です。

    前回記事「クロスサイトスクリプティング(XSS)の脆弱性 -Webアプリケーションの脆弱性入門 1-」より

    SQLインジェクションとは

    SQLインジェクションは、Webアプリケーションの脆弱性の一つであり、多くの企業や中小企業がこの攻撃の影響を受ける可能性があります。具体的には、攻撃者が不正なSQL文を挿入することで、データベースを不正に操作することを指します。例えば、攻撃者は不正な文字列や記号を入力値として使用し、データベースの内容を改竄したり、顧客の情報を不正に取得したりすることができます。

    SQLインジェクション攻撃の基本的な仕組み

    SQLインジェクション攻撃は、不正な文字列や特殊文字を入力値として使用し、データベースの処理や検索を操作する脅威の一つで、悪意のある第三者が、通常の入力欄に異常な構文や文字を注入することで、情報の取得や変更が可能です。

    SQLインジェクションの脆弱性が発生する主な原因とリスク

    SQLインジェクションの脆弱性(南京錠のアイコンマーク)イメージ

    SQLインジェクションは、WebアプリケーションでのSQL文の組み立て方法に問題がある場合に、攻撃者が挿入した不正なSQL文を誤った命令文として認識してしまうことで発生します。SQLインジェクション攻撃により、インシデントが発生した場合、企業の顧客情報や決済履歴などの機密情報が第三者に漏えいする恐れがあります。その結果、企業のセキュリティ対策姿勢が疑われ、インシデントによる直接的な被害だけでは済まない、信用の失墜やブランドイメージの低下といった大きな痛手を受ける恐れがあります。

    SQLインジェクション攻撃の事例

    2022年に報告されたSQLインジェクションによる情報漏えい事例を紹介します。

    国内オンラインショッピングサイトではSQLインジェクションによる攻撃を受け、サービス登録ユーザの氏名、生年月日、メールアドレス、住所などの詳細な個人情報等、275万件以上の情報が漏えいしました*1。その結果、被害の対象となった顧客へのお詫び状の送付、専用のお問い合わせ窓口の設置、個人情報保護委員会や警察への報告、再発防止策の検討を含めたセキュリティ強化、事故に関する継続的な調査対応等に追われました。

    データベースの不正操作を許せば、事業活動に必要なデータをすべて消去されるといった最悪の事態も発生しうるため、SQLインジェクションの脆弱性を放置することは非常に危険です。

    効果的なSQLインジェクション対策とその実践方法

    SQLインジェクションの対策

    重要な情報が集まるデータベースは、守るべき優先度がきわめて高く、SQLインジェクション対策としてさまざまな取り組みが行われています。

    基本的な対策

    • プレースホルダを使用したSQL文の構成:プレースホルダは、SQL文における変数の位置を示すために使用され、実際の値は後から安全にバインドされます。特に、バインド処理を実装するライブラリの実装状況によってSQL構文が変化する「動的プレースホルダ」ではなく、SQLの準備段階からSQL構文が変化しない「静的プレースホルダ」の方が、より有効性の高い対策を実現できます。
    • 特殊文字に対するエスケープ処理:運用上の制約等によりプレースホルダを使用したバインド処理が使用できない場合は、特殊文字に対するエスケープ処理を実施することで対策が可能です。なお、エスケープ処理では対策漏れが生じる可能性もあるため、可能な限りプレースホルダを使用することが推奨されます。

    保険的な対策

    • SQLエラー情報の非表示化:エラーメッセージの内容にエラーを起こしたSQL文の情報、使用データベース、テーブル名、カラム名等が含まれる場合、攻撃者に対してSQLインジェクション攻撃を実行するための有益な情報を与えることになります。そのため、エラー情報はクライアントへ出力せずログファイル等で管理することが推奨されます。
    • アカウントへの適切な権限付与:アプリケーションがデータベースにアクセスする際には、命令文の実行に必要な必要最小限の権限を付与します。これにより、万が一SQLインジェクションが発生しても、被害を最小限に抑えることができます。

    SQL文の組み立ては、データベースのセキュリティを維持する上で非常に重要です。セキュアなプラクティスを適用することで、データベースへの攻撃を防ぎつつ、アプリケーションのデータ操作を効率的かつ安全に行うことができます。

    SQLインジェクションのテスト方法

    SQLインジェクションの脆弱性(マルとバツのアイコンマーク)イメージ

    システムにSQLインジェクションの脆弱性があるかどうかを調べる方法としては、入力フィールドに本来許可してはいけない文字列を設定した場合にWebアプリケーションがどう反応するか、といったことを観察し、SQLインジェクションの脆弱性の有無を診断するというやり方があります。この文字列を「診断文字列」と呼ぶことがあります。

    企業のセキュリティ担当者をはじめ、SQLインジェクションの脆弱性に対する問題を理解し、社内で情報を共有し、適切な対策とることで、自組織がSQLインジェクション攻撃を受ける前に被害を未然に防ぐことが可能になるでしょう。

    開発やリリース時点では脆弱性が存在しなかったとしても、Webサイトの機能追加や新しい攻撃手法の発見等によって、脆弱性は日々新たに生み出されていきます。こうした実情に対して有効なのは、Webアプリケーションの定期的なセキュリティ診断です。SQLインジェクションによるリスクを考えると、Webサイト運営者はぜひとも実施すべき対策といえるでしょう。

    まとめ

    SQLインジェクション攻撃は多くの企業やシステムのセキュリティ上の課題として存在しています。SQLインジェクションは、Webアプリケーションの脆弱性を突いて、不正なSQL文を挿入しデータベースを操作する技術です。主にSQL文の組み立て方法に問題があることで、情報の漏えいやデータの改ざんが可能となります。実際に、国内企業でも情報漏えい事例が発生しており、その影響は甚大です。対策として、プレースホルダの使用、エスケープ処理などが推奨されています。またSQLインジェクションの脆弱性を検出する方法として、定期的にセキュリティ診断を実施し、適切な対策を実施することで、Webアプリケーションのセキュリティを向上できます。

    Security Report TOPに戻る
    TOP-更新情報に戻る


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

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


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

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

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

    セキュリティトピックス動画申し込みページリンクへのバナー画像

    クロスサイトスクリプティング(XSS)の脆弱性
    -Webアプリケーションの脆弱性入門 1-

    Share

    クロスサイトスクリプティングはWebアプリケーションの脆弱性の1つです。この記事では、クロスサイトスクリプティングとは何か、その仕組みや種類、そしてそれに関連する脆弱性や攻撃手法について詳しく解説します。さらに、クロスサイトスクリプティングとクロスサイトリクエストフォージェリとの違いや、クロスサイトスクリプティング攻撃を防ぐための対策方法も紹介します。

    Webアプリケーションの脆弱性入門

    Webアプリケーションの脆弱性入門(3つのブロックにアイコンマーク)イメージ

    脆弱性は、プログラムの不具合や設計ミスによって発生するセキュリティ上の欠陥です。Webアプリケーションに脆弱性が存在する場合、攻撃者がシステムに侵入し、機密情報を盗み出したり、サービスを乗っ取ったりするリスクがあります。Webアプリケーションの主な脆弱性にはSQLインジェクション、クロスサイトスクリプティング(XSS)、クロスサイトリクエストフォージェリ(CSRF)、セッション管理の不備、アクセス制御の不備があります。脆弱性が悪用されると、機密情報の漏洩、データの改ざん、サービスの停止や遅延、金銭的損失、企業の信頼喪失などの深刻な影響をもたらす可能性があります。対策方法としては、正しい権限管理の実施、定期的なセキュリティチェックの実施、最新のセキュリティパッチの適用などが挙げられます。これらの対策により、脆弱性の早期発見と修正が可能になり、攻撃のリスクを減らすことができます。企業のセキュリティ部門担当者は、社内の機密データや取引先の顧客情報等を守るためにも、脆弱性対策に取り組むことが重要です。

    前回記事「Webアプリケーションの脆弱性入門」より

    クロスサイトスクリプティング(XSS)とは

    クロスサイトスクリプティングとは、動的にHTMLを生成するWebアプリケーションで、ユーザの操作を介して不正なスクリプトを実行させる(できる)事象を指します。

    このクロスサイトスクリプティングの脆弱性を悪用した攻撃手法をクロスサイトスクリプティング攻撃と呼びます。まず悪意のある第三者が事前にターゲットのWebサイトに特定の文字列のスクリプトを入力値として挿入すると、そのWebサイトにアクセスしたユーザのブラウザ上で挿入したスクリプトが実行されます。これにより、第三者によってブラウザを不正に操作され、ユーザの個人情報が漏えいする、という仕組みになっています。

    クロスサイトスクリプティング(XSS)の種類

    クロスサイトスクリプティングの脆弱性には主に3つの種類があります。

    1. 反射型XSS…攻撃者がリクエストに混入させたスクリプトなどが、Webサーバからのレスポンスに含まれる形で実行されるもの
    2. 蓄積型XSS…攻撃者がWebサーバ上に何らかの方法でスクリプトを格納したうえで、被害者がアクセスすることでスクリプトが実行されるもの
    3. DOMベースXSS…Webサーバ側がスクリプトで動的にHTMLを生成する場合にスクリプトタグを生成してしまうことに起因し、ブラウザ側での処理の際に不正なスクリプトが実行されるもの

    クロスサイトスクリプティング(XSS)とクロスサイトリクエストフォージェリ(CSRF)の違い

    クロスサイトスクリプティング(XSS)とクロスサイトリクエストフォージェリ(CSRF)は、Webアプリケーションのセキュリティ脅威として知られていますが、その仕組みや対策には明確な違いがあります。クロスサイトスクリプティング攻撃の基本的な手法は、攻撃者がWebアプリケーションの脆弱性を悪用し、ターゲットのWebサイトに悪意のあるスクリプトを挿入し、ユーザがブラウザを閲覧する際にスクリプトが実行されるという仕組みです。主に出力の検証が不十分な場合に発生します。一方、クロスサイトリクエストフォージェリ(CSRF)は、ユーザがログインしている状態で、攻撃者が仕掛けた誘導URLをクリックさせることで、ユーザの意図しない操作を実行させる攻撃です。この攻撃は、セッション管理やトークンの処理が不適切な場合に主に発生します。

    クロスサイトスクリプティングの脆弱性が発生する原因

    クロスサイトスクリプティング(XSS)の脆弱性の主な原因は、出力の検証や処理が不十分であることです。悪意のある攻撃者が特定の文字列やスクリプトを入力し、その内容が未検証のままWebページに表示される場合、クロスサイトスクリプティング攻撃が実行されるリスクが高まります。特に、公開されている企業のWebサイトやアプリケーションで、ユーザからの入力値が適切に処理されず、そのままWebページへの出力処理される場合、情報の漏洩や不正な操作が可能となります。

    クロスサイトスクリプティングの脆弱性による影響

    脆弱性を放置した場合の影響は、情報の漏洩から不正な操作まで多岐にわたります。攻撃者が悪意のあるスクリプトを挿入することで、顧客の情報を搾取したり、企業の内部情報にアクセスしたりする可能性があります。

    クロスサイトスクリプティング攻撃の手法と例

    クロスサイトスクリプティング攻撃の手法は、攻撃者が悪意のあるスクリプトを入力し、その内容がそのままWebページへの出力処理に使用されることで、ユーザのブラウザ上でスクリプトが実行されるというものです。例えば、コメント欄や検索ボックスなど、ユーザからの入力を受け付ける部分にスクリプトを挿入することで、他のユーザのCookie情報等を搾取することが可能となります。

    クロスサイトスクリプティングの脆弱性への対策

    根本的な対策とその重要性

    根本的な対策とその重要性(ブロックと紙飛行機)イメージ

    クロスサイトスクリプティングの対策は、リクエストに不正な文字列が含まれていても、それをスクリプトとして機能させないことです。Webページに出力する要素に対して、スクリプト言語等において、その言語にとって特別な意味を持つ文字や記号を別の文字列に置き換える「エスケープ処理」を行います。

    対策の重要性は、企業の信頼性や顧客情報の保護に直結しています。特に、自社のWebアプリケーションが公開されている場合、定期的なセキュリティ調査や対策の更新が不可欠です。最後に、社内での知識共有や外部の専門家との相談を通じて、最新の脅威や対策についての知識を更新し続けることが求められます。

    WAFを活用したクロスサイトスクリプティングの防御方法

    WAF(Webアプリケーションファイアウォール)は、Webアプリケーションへの様々な攻撃を検知し、防御する機能を持っています。通信をリアルタイムで監視し、攻撃と判断された通信を遮断することで、Webサイトの脆弱性が悪用されるのを防ぎます。クロスサイトスクリプティング攻撃やSQLインジェクション攻撃などには、Webアプリケーションへの入力値のチェックなどを行うWAFを用いた防御も考えられます。WAFの導入により、Webサイトのセキュリティレベルを向上させ、ユーザ情報の漏洩やサービスの停止を防げる可能性も高まります。ただしWAFを使った防御では、そもそもの脆弱性を解消するという本質的問題解決とはならない点に注意が必要です。

    まとめ

    クロスサイトスクリプティング攻撃の基本的な手法は、攻撃者がWebアプリケーションの脆弱性を悪用し、ターゲットのWebサイトに悪意のあるスクリプトを挿入し、ユーザがブラウザを閲覧する際にスクリプトが実行されるという仕組みです。クロスサイトスクリプティングの脆弱性の主な種類には「反射型」「蓄積型」「DOMベース」があり、それぞれ異なる攻撃方法が特徴です。また、XSSとクロスサイトリクエストフォージェリ(CSRF)は両方ともWebアプリケーションの脅威として知られていますが、攻撃の仕組みや対策が異なります。クロスサイトスクリプティングの脆弱性は、出力の検証が不十分な場合に発生し、情報の漏洩や不正な操作が可能となるリスクがあります。対策としては、出力の検証、エスケープ処理などが求められます。

    基本的な対策は、Webサイトにおいて、セキュリティ診断によるチェックを定期的に実施してリスクを可視化し、適切なセキュリティ対策を実施することにより、脅威から自社や顧客の情報を保護することとなります。また、企業や組織は、セキュリティ対策の実施や知識の更新をする必要があります。Webアプリケーションのセキュリティを向上させるための知識として、また、日々の開発や運用の中での参考として、本記事を活用してください。

    Security Report TOPに戻る
    TOP-更新情報に戻る


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

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


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

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

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

    セキュリティトピックス動画申し込みページリンクへのバナー画像

    ASM(Attack Surface Management)と脆弱性診断
    ― セキュリティ対策への活用法 ―

    Share

    今、インターネット上に公開されるIT資産がサイバー攻撃者に狙われ、被害が拡大しています。サイバー攻撃者は事前に偵察行為をし、攻撃の的を探し、特定します。特に、脆弱性が存在しているWebシステムやネットワーク機器などは攻撃者にとっても悪用しやすく、侵入するための入口となってしまいます。では、自組織が狙われないようにするために、私たちはどのような対策をとればよいのでしょうか?本記事では、ASM(Attack Surface Management)と脆弱性診断を併用した、それぞれの実施の活用方法について解説いたします。

    アタックサーフェス(攻撃対象領域)とは

    サイバー攻撃に対する防御について語られる際に出てくる言葉の1つに、「アタックサーフェス」があります。

    アタックサーフェスは、直訳すると”攻撃面”となりますが、サイバーセキュリティの文脈では、「攻撃対象領域」といった意味合いで使用され、サイバー攻撃の対象となり得る様々なIT資産、攻撃のポイントや経路等を指します。

    組織が事業活動を行う上で使用するIT資産には、ハードウェアもソフトウェアも含まれます。IT資産にサイバー攻撃の足掛かりとなる攻撃ポイント・経路が存在すると、サイバー攻撃者は容赦なくそこを狙ってきます。

    【アサックサーフェスの例】

    攻撃事例とアタックサーフェス

    実際のサイバー攻撃やインシデントの事例とそのアタックサーフェスを確認してみましょう。

    事 例 アタックサーフェス
    2020年 国内上場企業のドメイン名を含むサブドメインテイクオーバー(使用が終了したドメイン名の乗っ取り)の被害事例が2020年7月までに100件以上発生*1 ドメイン管理の不備
    2023年 2022年5月以降、特定のセキュア・アクセス・ゲートウェイ製品の脆弱性を狙ったものと見られる標的型サイバー攻撃が断続的に発生*2 ネットワーク機器の
    既知の脆弱性
    2023年 国内自動車メーカーの関連会社で保有する顧客約215万人分の車両等の情報が10年近く公開状態になっていたことが判明*3 クラウド設定の不備

    拡大するアタックサーフェス

    クラウド利用、DXの推進、テレワークの一般化……ITインフラ環境の柔軟性は高まる一方です。これに伴い、Webシステムやネットワーク機器といった外部との境界にあるアタックサーフェスは、拡大し続けています。つまり、外部にいるサイバー攻撃者が組織のシステムを侵害するチャンスが広がっていると考えられます。

    サイバー攻撃者によるアタックサーフェスへのアプローチ

    サイバー攻撃者が攻撃のため、最初に行う活動の典型が、「偵察」です。攻撃に利用可能な様々な情報を探索し、どの組織を標的とするか、どのような攻撃手法をとるか、といったことを定めるのに役立てます。

    偵察活動で駆使される技術として、合法的に入手可能な公開情報を収集して調査・分析する手法—OSINT(「オシント」Open Source Intelligence:オープンソースインテリジェンス)が注目されています。

    サイバー空間における脆弱性探索行為

    前述のサイバー攻撃者による偵察活動が行われていることの裏付けとして、日本の各機関からも以下のような観測が定期的に報告されています。

    【観測報告の例】

    発表元 観測内容
    国⽴研究開発法⼈
    情報通信研究機構(NICT)
    2022年1~12月 調査⽬的と判定されるスキャンの数は12,752のIPアドレスから約2,871億パケットあり、これにサイバー攻撃のための偵察活動が含まれていると考えられる*4
    JPCERT/CC 2022年10月~2023年6月 IoT機器を主な標的とするマルウェアMirai型パケットについて、海外および日本からの探索活動が継続して報告されている。探索元IPアドレスの一部について、動作している機種の特定に成功したことも*5
      2023年4~6月 Laravel(Webアプリケーションフレームワーク)の設定情報窃取を試みる通信を確認*6
    警察庁 2023年1~6月 脆弱性のあるIoT機器の探索を目的としたものと見られるアクセスの増加を確認
      2023年1~6月 脆弱性のあるVPN機器の探索を目的としたものと見られるアクセスを断続的に確認

    ASM(アタックサーフェスマネジメント)で自組織を守る

    サイバー攻撃者の偵察行為で、自組織が攻撃対象として選定されないようにするにはどうすればよいでしょうか。

    サイバー攻撃から⾃組織を守るために、インターネット上で意図せず公開してしまっているアタックサーフェスとなり得るIT資産を特定し、セキュリティ対策に活用する手法が、「ASM(Attack Surface Management:アタックサーフェスマネジメント)」です。

    ASM導入ガイダンス

    経済産業省は、ASMを「組織の外部(インターネット)からアクセス可能なIT資産を発見し、それらに存在する脆弱性などのリスクを継続的に検出・評価する一連のプロセス」と定義しており、2023年5月29日に「ASM(Attack Surface Management)導入ガイダンス~外部から把握出来る情報を用いて自組織のIT資産を発見し管理する~」を発行しています。

    企業のセキュリティ担当者や情報セキュリティを管掌する経営層(CIO、CISO等)に向けて、企業・組織に対してサイバー攻撃の起点となり得るIT資産を適切な方法で管理できるよう促すため、ASMの解説、ASMを実施するためのツールや必要なスキル、体制、留意点等がまとめられています。また、国内企業のASM取り組み事例も掲載されています。

    ASMにより得られる効果

    ASMにより以下のようなことが確認できます。

    ASMのプロセス

    ASMで具体的にどのようなことを実施するかというと、前述の経済産業省によるガイダンスでは、次のようなプロセスが紹介されています。「攻撃面」とは、「アタックサーフェス」のことです。

    ASMのプロセス画像
    出典:経済産業省「 ASM(Attack Surface Management)導入ガイダンス~外部から把握出来る情報を用いて自組織のIT資産を発見し管理する~」(令和5年5⽉29⽇)P.8 図 2-1 ASM のプロセス

    プロセス(1) 攻撃面の発見:

    インターネットからアクセス可能なIT資産として、IPアドレスやホスト名を発見。

    ・組織名(法人名等)より、オフィシャルWebサイトや検索プロトコルであるWHOISを利用して当該組織のドメイン名を特定・ドメイン名を特定したら、DNS検索や専用ツールの使用によりIPアドレス・ホスト名の一覧を取得

    プロセス(2) 攻撃面の情報収集:

    前プロセスの結果より通常のインターネットアクセスで取得可能な方法でOS、ソフトウェア、ソフトウェアのバージョン、開放されているポート番号といったIT資産の情報を収集。

    プロセス(3) 攻撃面のリスク評価

    前プロセスで収集した情報を既知の脆弱性情報と突合せするなどして、脆弱性が存在する可能性を識別。

    ASMのプロセスとしてはここまでですが、セキュリティ対策としては、ASMを実施して自組織のセキュリティリスクを把握した後の工程として、リスクの深刻度に応じた対応要否や優先度、具体的な対応内容等を決め、セキュリティリスクの低減に努める必要があります。

    ASMと脆弱性診断の違い

    さて、「IT資産の脆弱性検出やリスク評価を行う」となると、脆弱性診断と重なるイメージがあるのではないでしょうか。

    ASMと脆弱性診断の関係性を表す、次のような図があります。脆弱性管理において、それぞれに役割があることが伺えます。

    ASMと脆弱性診断の違い画像
    出典:経済産業省「 ASM(Attack Surface Management)導入ガイダンス~外部から把握出来る情報を用いて自組織のIT資産を発見し管理する~」(令和5年5⽉29⽇)P.11 図 2-2 ASM と脆弱性診断の違い

    両者の違いをまとめると以下のようになります。いずれもセキュリティ対策における取り組みですが、非常にざっくりと、ASMは“管理対象でないものも含めて広く浅く”、脆弱性診断は“特定した対象に対して深く詳細に”という印象で捉えられるのではないでしょうか。

    ASMと脆弱性診断の併用・使い分けを

    脆弱性管理において、ASMと脆弱性診断のどちらかを行っていればOK、ということではありません。脆弱性診断では、自組織が特定したシステムや機器に対して脆弱性を洗い出しますが、脆弱性診断の対象となるということは、組織自身が当該IT資産を管理下にあるものと認識していることになります。一方、ASMでは、そもそも管理外であるにもかかわらず当該組織のIT資産としてインターネット上に公開されてしまっているもの、つまり気づかぬまま管理から漏れてしまっているものを発見することができます。

    そのため、両者の特長を理解した上でその目的に応じて、例えば、ASMによって脆弱性が存在する可能性があると発見したら、対象となる機器やシステムに対して脆弱性診断を実施して脆弱性の特定を行う、といった両者の併用・使い分けが推奨されます。

    ASM・脆弱性診断ともに有効な実施方法の検討を

    ASMも脆弱性診断も、ただ実施すればよいというものではなく、効果的に、かつ継続して行うことが重要です。そのためにはノウハウやスキルが必要となります。

    ASMや脆弱性診断を自組織で実施しようとなると、以下のような注意点が挙げられます。

    例えば、自組織ではASMや脆弱性診断をどう活用したいか検討することの方に労力を割き、ASMや脆弱性診断の実施や結果の分析については、その活用目的に合致した対応が望める外部のセキュリティサービスを探して依頼するなど、定期的に見直しをすることが重要です。

    日々進化していくITインフラ環境において便利になる反面、攻撃者にもそのチャンスが広がっています。攻撃者から自組織を守るためにも、ASMと脆弱性診断の実施を組み合わせることは有効な選択肢の1つといえるでしょう。

    BBSecでは

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

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

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

    詳細・お見積りについてのご相談は、お問い合わせフォームからお気軽にお問い合わせください。お問い合わせはこちら。後ほど、担当者よりご連絡いたします。

    SQAT脆弱性診断サービス

    システムに存在する脆弱性は、時として深刻な被害につながる看過できない脅威で、事業継続性に影響を与えかねません。BBSecの脆弱性診断は、精度の高い手動診断と独自開発による自動診断を組み合わせ、悪意ある攻撃を受ける前にリスクを発見し、防御するための問題を特定します。

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

    最新情報はこちら

    Security Report TOPに戻る
    TOP-更新情報に戻る


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

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


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

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

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

    セキュリティトピックス動画申し込みページリンクへのバナー画像