BBSecの脆弱性診断

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

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

2023年上半期診断結果

Webアプリ/NW診断実績数

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

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

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

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

2023年12月22日2023年12月27日

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

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

前回までの内容

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

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

SQLインジェクションとは

SQLインジェクションは、Webアプリケーションの脆弱性の一つであり、多くの企業や中小企業がこの攻撃の影響を受ける可能性があります。具体的には、攻撃者が不正な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インジェクションの脆弱性があるかどうかを調べる方法としては、入力フィールドに本来許可してはいけない文字列を設定した場合にWebアプリケーションがどう反応するか、といったことを観察し、SQLインジェクションの脆弱性の有無を診断するというやり方があります。この文字列を「診断文字列」と呼ぶことがあります。

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

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

まとめ

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

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

2023年12月20日2023年12月25日

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

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

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

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

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

クロスサイトスクリプティング（XSS）とは

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

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

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

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

反射型XSS…攻撃者がリクエストに混入させたスクリプトなどが、Webサーバからのレスポンスに含まれる形で実行されるもの
蓄積型XSS…攻撃者がWebサーバ上に何らかの方法でスクリプトを格納したうえで、被害者がアクセスすることでスクリプトが実行されるもの
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-更新情報に戻る

2023年11月10日2024年2月1日

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

今、インターネット上に公開される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で具体的にどのようなことを実施するかというと、前述の経済産業省によるガイダンスでは、次のようなプロセスが紹介されています。「攻撃面」とは、「アタックサーフェス」のことです。

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

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

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

プロセス（2）攻撃面の情報収集：

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

プロセス(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や脆弱性診断をどう活用したいか検討することの方に労力を割き、ＡＳＭや脆弱性診断の実施や結果の分析については、その活用目的に合致した対応が望める外部のセキュリティサービスを探して依頼するなど、定期的に見直しをすることが重要です。

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

BBSecでは

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

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

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

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

SQAT脆弱性診断サービス

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

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

2023年11月22日（水）13:00～14:00「今さら聞けない！PCI DSSで求められる脆弱性診断あれこれ」
2023年12月6日（水）13:00～14:00「今さら聞けない！ペネトレーションテストあれこれ」
2023年12月13日（水）14:00～15:00「今さら聞けない！スマホアプリのセキュリティあれこれ」

最新情報はこちら

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

2023年10月4日2024年4月9日

ウェビナー抜粋動画

サービス紹介デモ動画

BBSecで提供しているサービスをご紹介するデモ動画を公開しています。

過去ウェビナー抜粋動画

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

自動車産業・製造業におけるセキュリティ対策のポイント-サプライチェーン攻撃の手口と対策方法-サムネ

DevSecOpsを実現！-ソースコード診断によるセキュリティ対策のすすめサムネ

TOP-更新情報に戻る

2023年9月29日2023年10月4日

PCI DSS v4.0で変わるセキュリティ対策のポイント

PCI DSS v3.2.1の引退まで1年を切っていますが、対応状況はいかがでしょうか。2022年3月31日にリリースされたPCI DSS v4.0の準拠運用は、即時要件に対しては遅くとも2024年4月に開始される時期となり、システム系の大きな変更点が伴う未来日付要件を含めたv4.0完全対応完了までは、残り1年半となっています。この記事では、PCI DSS v4.0で変わるセキュリティ対策のポイントについて、脆弱性診断に関する要件に着目し、今後どのように対応すべきかについて解説します。

PCI DSS v4.0：新たなセキュリティスタンダードへの移行

PCI DSSとは、Payment Card Industry Data Security Standardの頭文字をとったもので、クレジットカード会員データを安全に取り扱うことを目的として策定された、クレジットカード業界のセキュリティ基準です。American Express、Discover、JCB、MasterCard、VISAの5つのカードブランドによって設立された組織、PCI SSC（PCI Security Standards Council）によって管理されており、クレジットカードを取り扱うすべての事業者に対して、カード情報の保護とセキュリティの実施を求めるものです。この基準に準拠することで、クレジットカードを取り扱う事業者の信頼性と顧客の安心感を高め、ブランド価値の保護、そして業界全体のセキュリティレベルの向上に寄与します。

2022年3月31日には最新版PCI DSS v4.0が発表されました、以前のメジャーバージョンであるPCI DSS v3.0は2013年11月に発表されたもので、今回8年4か月ぶりのメジャーアップデートとなります。今後2024年3月31日には2年間の移行期間が終了したv3.2.1が引退し、以降v4.0のみが有効な基準となることが決まっています。

未来日付要件は、現在はベストプラクティス要件の位置づけのため、2025年3月31日までは対応必須ではありません。しかし、残り1年半程度の対応期間の中で、システム改修や新規ソリューション導入等を行わなければならない場合、予算化や製品選定、対応ベンダ選定、運用に向けた検証作業、手順書見直しなど、対応すべき事項は決して少なくありません。

少なくとも今年度中には、要件の要求ポイントと自組織に不足する要素を洗い出し、対応スケジュールの立案が済んでいることが望ましい時期です。

PCI DSS v4.0改定のポイント

PCI DSS v4.0は、従来のv3.2.1に比べて、以下のようなポイントで改定されています。

●　決済業界のセキュリティニーズに対応
●　継続的なプロセスとしてセキュリティを促進
●　さまざまな方法論に柔軟性を追加
●　検証方法を強化

出典：https://www.pcisecuritystandards.org/document_library/
PCI-DSS-v4-0-At-a-Glance-r1-JA.pdf

PCI DSS v3.2.1からの主な変更点

PCI DSS v4.0では、いくつかの重要な変更点があります。事業者がPCI DSS準拠の対応を検討する際には、これらの変更点に注意を払う必要があります。

要件タイトル変更

まず、大きな変更の一つ目が、要件タイトルの変更です。要件9以外すべてが変更となりました。加えて、要件の理解を高めるために、詳細要件と用語の定義、文章の修正が行われました。

進化した要件

次に、新たな脅威や技術、決済業界の変化に対応するため追加された新規要件や、既存要件が一部変更／削除されたものがあります。該当する要件は67件ありますが、その中でも大きなものとしては、以下のようなものがあげられます。

多要素認証について

PCI DSS v4.0では、要件8.5.1にて、多要素認証(MFA)について、実装方法が明確に要件化されました。

また、要件8.4.2では「カード会員データ環境(CDE)へのすべてのアクセス」にMFA（多要素認証）が要求されることになりました。8.4.3では「カード会員データ環境(CDE)にアクセスまたは影響を与える可能性のある、事業体のネットワーク外から発信されるすべてのリモートネットワークアクセス」に対してもMFAが求められており、それぞれでMFAが必要となります。

これは例えば、ある担当者が最初にリモートアクセスによって事業者のネットワークに接続し、その後ネットワーク内からカード情報データ環境(CDE)への接続を開始した場合、その担当者は「事業者のネットワークにリモートで接続するとき」と「事業体のネットワークからカード会員データ環境(CDE)へアクセスするとき」の2回、MFAを使用して認証する必要があるということです。なお、CDEへのアクセスに対するMFAはネットワークまたはシステム／アプリケーションのレベルで実装することができます。CDEネットワークに接続する際にMFAを使用した場合、その後のCDE内の各システムコンポーネントにログインする際には追加のMFAを使用する必要はありません。

脆弱性診断に関する主な変更点

PCI DSS v3.2.1からv4.0への変更点のうち、脆弱性診断に関わるポイントとしては以下の3点が挙げられます。

脆弱性スキャンの頻度は「四半期に一度」だったところが「3カ月に1回」へと変更されました。PCI DSSの時間枠要件の意図は「その時間枠を超えない範囲で、できるだけ近い感覚で実行されること」であるところを、「四半期に一度」では最大半年ほど間隔があいてしまうことも許容することになってしまうため、厳格化されたものと思われます。

認証スキャンの実施については、十分な特権ユーザのID/パスワードのアカウント、もしくはクライアント証明書を保持した状態であることが必要になります。十分な権限による脆弱性スキャンができない事情がある場合は、当該システムについて文書化することが求められます。

ペネトレーションテストに求められる内容については、PCI DSS v3.2.1では、業界承認のテスト方法（NIST SP800-155など）であればよいと規定されていましたが、結果としてペンテスターへの依存度が高くなり、さまざまな形態のペネトレーションテスト結果の提出が許容される形となっていました。こうした状況を是正し、準拠レベルを標準化するため改定されたのではないかと考えられます。

脆弱性診断実施にあたって求められる対応

PCI DSS v4.0では脆弱性診断実施にあたって求められる対応にも変更があります。高リスクの脆弱性（CriticalやHigh）以外の脆弱性、すなわち中・低リスクの脆弱性（MediumやLow）についても、ターゲットリスク分析の上で対応をすることが要求されています。また、脆弱性は日々新しいものが発見・更新されていますので、各種のスキャン等で検出された高リスクの脆弱性対応だけでも大きな負担であるところを、さらに中低のリスクとされる脆弱性についても対処が必要となると、脆弱性管理は非常に負担の大きな作業になることが予想されます。

PCI DSS v4.0に求められる脆弱性診断のポイント（診断実施機関の長期化・診断実施時のリスクの考慮）

QSA(Qualified Security Assessors:認定審査機関)の見解次第ではありますが、ターゲットリスク分析の結果、『対処の必要なし』と判断した事業者側の意見が通った場合は別として、中低リスクの脆弱性についても対処が基本的に必要になると考えますと、今まで通りのやり方（PCI DSS v3.2.1手法の脆弱性管理）では指摘を受ける可能性もあります。この規定の”目的”部分を見ると、機械的に中小リスクだから対応は一律不要と判断するのではなく、ターゲットリスク分析において、きちんとした根拠を持って”対処が不要”とした事業者が結論を出す必要があると読み取れます。

脆弱性診断に関する主な変更点については、SQAT® Security Report 2023年春夏号
「PCI DSS v4.0で変わる脆弱性診断～2024年4月1日完全移行で慌てないために～」でも取り上げています。
以下より資料（PDF）ダウンロードいただけますので、ぜひご参考ください。
https://www.sqat.jp/sqat-securityreport/

PCI DSS v4.0への移行に向けて

PCI DSSの準拠対応を検討する事業者にとって、PCI DSS v4.0への移行は重要な課題です。新たな要件や変更点に対応するためには、準備が必要となります。

PCI DSS v4.0準拠までのステップ

●　PCI DSS v4.0の精査
●　現状の環境での差異を把握
●　詳細化・明確化要件の対応を開始
●　新規要件およびシステム化対応の予算を確保
●　新規要件およびシステム化対応の実施
●　全体の対応状況の確認

PCI DSS v4.0では、ここで取り上げたほかにも、クラウド環境でのセキュリティ要件の明確化、セキュリティ管理の強化といった変更点もあります。事業者はv4.0に準拠対応しようとした場合、従来よりも高いレベルのセキュリティを実現することが求められます。専門家の助言や適切なソリューションを活用することが、スムーズな準拠対応の一助となるでしょう。当社ブロードバンドセキュリティがその助けとなれば幸いです。

BBSecでは

BBSecは、PCI SSC認定QSA（PCI DSS準拠の訪問審査を行う審査機関）です。準拠基準についての疑問や対応困難な状況があるといったような懸念・不安などは曖昧なままにせず、QSAにご相談いただくことをおすすめいたします。準拠に向けた適切な対応を検討するためのアドバイスや、事情に応じた柔軟な対応も可能です。

お問い合わせはこちら
※外部サイトにリンクします。

PCI DSS v4.0対応脆弱性診断サービス随時対応受付中！

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

・2023年10月18日（水）13:50～15:00
「自動車産業・製造業におけるセキュリティ対策のポイント -サプライチェーン攻撃の手口と対策方法-」
・2023年11月15日（水）13:50～15:00
「Webアプリケーションの脆弱性対策 -攻撃者はどのように攻撃するのか-」

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

Webアプリケーションは私たちの日常生活に欠かせない存在となっています。しかし、それらのWebアプリケーションが攻撃者からの脅威にさらされていることをご存知でしょうか？Webアプリケーションに脆弱性が存在すると、悪意のある第三者によって個人情報や企業の機密情報が漏洩するリスクが生じます。この記事では、Webアプリケーションの脆弱性の種類について解説します。

脆弱性とは

脆弱性とは、プログラムの不具合や設計上のミス等によるバグが原因となって発生したセキュリティ上の欠陥や弱点のことを指します。Webアプリケーションに脆弱性が存在する場合、攻撃者がシステムに侵入し、機密情報を盗み出したり、サービスを乗っ取ったりするリスクが生じます。企業はWebアプリケーションの脆弱性を理解し、それに対処するための適切な対策を講じる必要があります。

脆弱性の種類

脆弱性にはさまざまな種類があります。以下に代表的な例を挙げます。

1. SQLインジェクション

データベースを使って情報を処理するWebアプリケーションは、その多くがユーザからの入力値をもとにデータベースへの命令文を構成しています。SQLインジェクションは、攻撃者がWebフォームなどの入力欄に特定のコードを入れることで不正な命令文を構成し、データベースを不正利用できてしまう脆弱性です。これを悪用することで、例えば、データベースの情報を盗んだり、改ざんしたり、消去したりできる可能性があります。

2. クロスサイトスクリプティング（XSS）

クロスサイトスクリプティング（XSS）は、ネットバンキングや掲示板のように、ユーザから入力された値を処理して出力するWebページに攻撃者が悪意のあるスクリプトを埋め込むことで、Webページを閲覧したユーザのWebブラウザ上でスクリプトを実行させることができる脆弱性です。これを悪用されると、ユーザが意図しない情報の送信や表示ページの改ざんなどのリスクが発生します。

3. クロスサイトリクエストフォージェリ（CSRF）

クロスサイトリクエストフォージェリ（CSRF）は、攻撃者が罠として用意した偽サイトを用いてリンクや画像をクリックさせることで、ユーザが意図していないリクエストを強制的に行わせることができる脆弱性です。例えば、SNSで「いいね！」をする、銀行の振込操作など、被害者がログインしているWebサービスの操作を攻撃者が悪用することが可能です。

4. セッション管理の不備

Webアプリケーションの中には、セッションID（ユーザを識別するための情報）を発行し、セッション管理を行うものがあります。このセッション管理に不備があることで、セッションIDを固定化できたり、有効なセッションIDが推測可能だったりすると、セッションハイジャックと呼ばれる攻撃が成立する危険性があります。これにより、攻撃者が本来のユーザになりすまして権利を行使することで、プライベートな情報の閲覧や、設定の変更などが行われる可能性があります。

5. アクセス制御の不備

Webアプリケーションにおいて、本来付与されている権限の範囲内でのみ動作するような制御が実装されていない問題を指します。例えば、一般ユーザとしてログインした際に管理者としての権利を行使できてしまう権限昇格、パラメータを操作することで、本来制限された領域外のファイルやディレクトリにアクセスすることが可能となるパストラバーサルなどです。不正アクセスや意図しない情報の公開をはじめとした、様々なリスクが生じます。

脆弱性を悪用した攻撃による影響

脆弱性が悪用されると、企業に深刻な影響が及ぶ恐れがあります。脆弱性が引き起こす可能性のある影響の例を、以下に示します。

機密情報の漏洩

攻撃者は、脆弱性を利用して機密情報を盗み出すことができます。クレジットカード情報や個人情報など、大切な情報が漏洩することで、企業の信頼性に係る問題や法的な問題が発生する可能性があります。

データの改ざん

脆弱なWebアプリケーションは、攻撃者によってデータの改ざんが行われる可能性があります。データの改ざんによって、Webアプリケーションの正確性が損なわれたり、信頼性が低下したりする可能性があります。

サービスの停止または遅延

脆弱性を悪用されると、サービスの停止、遅延、またはデータベースの消去といった、システム全体に影響が及ぶ被害を受ける恐れがあり、企業のビジネス活動に重大な影響が生じる可能性があります。

金銭的な損失

脆弱性のあるWebアプリケーションは、企業にとって金銭的な損失をもたらす可能性があります。攻撃者による不正アクセスでデータが盗難された結果、企業に損害賠償責任が生じる場合があります。

企業の信頼喪失

セキュリティに関する問題が公になると、企業の評判に悪影響を与える可能性があります。顧客やパートナーからの信頼を失うことは、企業にとって非常に重大な損失です。

脆弱性対策の方法

脆弱性の悪用を防ぐためには、以下のような対策が考えられます。

正しい権限管理の実施

ユーザには場面に応じた必要最小限の権限のみ付与することが推奨されます。また、不要な機能やリソースへのアクセスを制限することも脆弱性を軽減させるポイントとなります。

定期的なセキュリティチェックの実施

Webアプリケーションに対しては、機能追加などのシステム改修時はもちろんのこと、定期的なセキュリティチェックを行うことが重要です。脆弱性スキャンやペネトレーションテストなどの手法を活用し、問題を早期に発見して修正することが大切です。

まとめ

脆弱性のあるWebアプリケーションは、攻撃の潜在的なターゲットになります。セキュリティ対策を徹底し、脆弱性の早期発見と修正を行うことが重要です。また、さまざまな対策手法やセキュリティツールを活用し、脆弱性を作り込まないセキュアな開発環境作りに取り組んでください。企業のデータや顧客の個人情報を守るためにも、脆弱性対策は欠かせません。今回の記事がお役に立てれば幸いです。

2023年6月16日2024年4月12日

ChatGPTとセキュリティ
-サイバーセキュリティの観点からみた生成AIの活用と課題-

2022年11月にOpenAIによって公開された生成AI「ChatGPT」の利用者は、リリース後わずか2か月で1億人を突破しました。2023年になってからもその勢いは止まらず、連日のようにニュースで取り上げられ、人々の注目を集め続けています。ChatGPTを含めた生成AIは、今後のビジネスにおいて重要な役割を果たし、企業の競争力にも関わってくると考えられます。本記事では改めてChatGPTとはいったい何なのか？そしてサイバーセキュリティの観点からみたインパクトとリスクについて解説します。

ChatGPTとは？

ChatGPTとは、端的に言えば「人間が作った質問に自然な文章で回答を返してくれる、OpenAIが開発した人工知能システム」のことです。ChatGPTの主要機能は「人間同士の対話を模範すること」であり、その得意とするところは、「人間が自然と感じる回答の生成」です。

応答してくれる言語については、主要なものに対応しており、日本語で問いかけた場合は日本語で回答が返ってきます。

ChatGPTの返答イメージ

なぜそのようなことが可能かというと、人間の脳の神経回路の構造を模倣した「ニューラルネットワーク」を利用*7しており、大量のウェブページ、ニュース記事、書籍、社交メディアの投稿など、多様なテキストを学習しているからです。つまり膨大なデータで学習し、人間の脳を模倣した処理によって、人間が使う自然な言葉で、入力した言葉に対して回答を返してくれるのです。

多種多様な生成AI

生成AI（ジェネレーティブAI）とは
生成AIとは、学習したデータをもとに、画像・文章・音楽・デザイン、プログラムコード、構造化データなどを作成することができる人工知能（AI）の総称です。近年は様々な組織から多種多様な生成AIが開発、リリースされており、日進月歩の進歩を遂げています。なお、ChatGPTの「GPT」は「Generative Pre-trained Transformer」を意味しており、Gは生成を意味するGenerativeです。

ChatGPTは2023年6月現在、2つのバージョンが存在しています。2022年の11月に公開された無料で利用できるChatGPT3.5というバージョンと、2023年3月に公開された有償での利用が可能なChatGPT4というバージョンです。ChatGPT4は3.5に比べて事実にもとづく回答の精度が40％向上しているとされている他、いくつかの機能が追加されています。

また、人工知能チャットボットとしてはChatGPTの他にも「Google Bard」、「Microsoft Bing AI」「Baidu ERNIE」その他様々なモデルが登場しています。他にも文章や画像から生成する画像生成AIとして「Midjourney」や「Stable Diffusion」、音声から文字起こしを行うChatGPTと同じOpenAIの「Whisper」といったものもあります。最近では、MicrosoftがWindows11へ「Windows Copilot for Windows 11」というChatGPTを利用した対話型のアシスタンスの導入を発表しています。

こうした生成AIにはカスタマーサービスでの利用、ソフトウェアの作成やメール文章の作成から、ちょっとした日常生活の疑問の解決、様々なビジネス上のシナリオ作成からテストまで、幅広い活用の幅があります。


種類	提供元	サービス名	URL
文章生成AI	OpenAI	ChatGPT	https://openai.com/blog/chatgpt
文章生成AI	Google	Bard	https://bard.google.com/
文章生成AI	Microsoft	Bing AI	https://www.microsoft.com/ja-jp/bing?form=MA13FJ
文章生成AI	Baidu	ERNIE	https://yiyan.baidu.com/welcome
画像生成AI	Midjourney	Midjourney	https://www.midjourney.com/home/?callbackUrl=%2Fapp%2F
画像生成AI	Stability AI	Stable Diffusion	https://ja.stability.ai/stable-diffusion
画像生成AI	OpenAI	DALL·E	https://openai.com/dall-e-2
文章生成AI （文字起こし）	OpenAI	Whisper	https://openai.com/research/whisper
音声生成AI	ElevenLabs	Prime Voice AI	https://beta.elevenlabs.io/

無数に存在するAIの画像 — 無数に存在するAI
出典：Harnessing the Power of LLMs in Practice: A Survey on ChatGPT and Beyondより引用

ChatGPTとサイバー攻撃

このような幅広い活用を期待されているChatGPTですが、一方でサイバー攻撃においても悪用が注目されてしまっているという側面もあります。

ChatGPTのサイバー攻撃での悪用を考えるときに、まず考えられるのはフィッシング攻撃における悪用です。ある調査では「見慣れたブランドであれば安全なメールだと思っている」という人が44％いると報告されています。そのような人が被害にあいやすい、「もっともらしく見える、文面に不自然なところのない一見して信ぴょう性の高い文面」を、攻撃者はChatGPTを利用して簡単に作り出すことができます。加えて、攻撃者が標的の普段利用している言語を解さず、そこに言語の壁が存在したとしても、これもやはりChatGPTを利用することで容易に乗り越えることが可能となります。このような精巧なフィッシングメールを、攻撃者はこれまで以上に少ない労力で大量に生成可能となります。

また、ChatGPTにマルウェアで利用できるような悪意のあるコードを生成させようと検証する動きがあり、ダークウェブ上では前述のフィッシングでの悪用を含めて、活発な調査、研究が進められているという報告もあります。このような言語的、技術的なハードルの低下は、ノウハウのない人間でも攻撃の動機さえあれば、ChatGPTを利用することで簡単にサイバー攻撃が実行できてしまうという脅威につながります。

ChatGPTの活用におけるその他のセキュリティ課題

ChatGPTに対するセキュリティの観点からの懸念点は、他にもあります。

情報漏洩リスク

業務上知りえた機密情報や、個人情報をChatGPTに入力してしまうリスクです。ChatGPTに送信された情報は、OpenAIの開発者に見られてしまったり、学習データとして使われたりして、情報漏洩につながってしまう可能性があります。2023年3月末には、海外の電子機器製造企業において、ソースコードのデバッグや最適化のためにChatGPTにソースコードを送信してしまったり、議事録を作ろうとして会議の録音データを送信してしまったりという、情報漏洩が報道*2されています。

正しくない情報の拡散リスク

ChatGPTは過去に学習した情報を利用して回答しているため、間違った情報や意図的に歪められた汚染情報、セキュアではない情報にもとづいた返答をしてしまう可能性があります。また、蓄積情報についても大部分が2021年までの情報とされており、回答が最新情報とは限らない点にも注意が必要です。例えば最新の脆弱性情報について質問しても、間違っていたり、古い情報で回答をしてしまったりする可能性もあります。

ChatGPTのセキュリティ課題

ChatGPTのセキュリティでの活用

ここまでセキュリティの観点からChatGPTのリスクに注目してきましたが、ChatGPTは応答学習型のセキュリティ教育や、セキュリティの疑問に答えてくれるセキュリティボットの開発、インシデント発生時のセキュリティアシストや、脅威動向の把握など、セキュアな社会構築への貢献も期待されています。また、OpenAIからもAIを活用したセキュリティに関する「OpenAI cybersecurity grant program」という最大100万ドルの助成金プログラムを開始すると発表がされています。このことからも、AIを用いたサイバーセキュリティの強化や議論促進が今後進展していくものと考えられます。

基本的な対策こそが重要

AIとサイバー攻撃について述べてきましたが、気を付けないといけないのは、ChatGPTがなくても、攻撃者もマルウェアも既に存在しており、脆弱性があればそこを突いて攻撃が行われるのだということです。ChatGPTはあくまでサイバー攻撃の補助として悪用されているだけであり、ChatGPT自体が脅威なのではありません。危険なのはChatGPTではなく、サイバー攻撃を行う者や、脆弱性を放置するなど対策を怠ることです。

今後、ハードルが下がったことで、技術力の低い攻撃者が参入しやすくなり、攻撃の数は増えるかもしれませんが、過去からある基本的なセキュリティ対策を講じていれば、多くの攻撃は未然に防げることに変わりはありません。個人情報の漏洩や正しくない情報の拡散といったリスクについても、セキュリティポリシーの遵守や、きちんと情報の裏付けを取る（ファクトチェック）といった基本的な行動規範がリスクを緩和してくれます。基本的なセキュリティ対策こそが効果的であるという前提に立って、今一度自組織のセキュリティを見直すことが重要です。いたずらに怖がるのではなく、基本的なセキュリティ対策を踏まえたうえで、上手にAIと付き合っていくことが必要ではないでしょうか。

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

2023年6月8日2024年3月26日

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

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

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

これに伴い、情報システムやそれを取り巻く環境・体制が堅牢であるかどうかを検査、評価する方法がいくつも存在します。この記事では、その中の 「脆弱性診断」を取り上げて、その定義、特徴、メリット、実際の利用方法などを紹介します。

脆弱性とは

脆弱性とは、不正アクセスやコンピュータウイルスなどの攻撃により、その機能や性能を損なう原因となり得るセキュリティ上の問題箇所のことです。

悪意のある第三者（サイバー攻撃者）によって脆弱性を悪用されると、コンピュータ内部データ（情報）の盗取・改竄・削除、また他のコンピュータへの同様の悪事が可能になり、自組織のシステムに脆弱性が存在した場合、サイバー攻撃者に狙われやすくなる可能性が高まります。

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

脆弱性診断とは

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

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

重要なのは、システムライフサイクルの各フェーズで、適切な診断を実施し、洗い出されたセキュリティ上の問題に優先順位をつけて、ひとつひとつ対処することです。

脆弱性診断の必要性

情報資産を守るため

情報のセキュリティの3要素、「機密性」「完全性」「可用性」を守るためにも、脆弱性診断は必要な理由の一つです。
「機密性」…限られた人だけが情報に接触できるように制限をかけること。
「完全性」…不正な改ざんなどから保護すること。
「可用性」…利用者が必要なときに安全にアクセスできる環境であること。
これらの要素を適切に満たすことが、情報セキュリティを担保する上では欠かせないものとなります。

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

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

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

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

脆弱性診断の種類

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

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

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

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

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

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

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

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

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

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

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

脆弱性診断の方法（ツール診断・手動診断）

ツール診断とは、脆弱性診断ツールと呼ばれるコンピュータプログラムを実行して、その応答から脆弱性を検知していくもので、自動診断とも呼ばれます。脆弱性診断ツールには、たとえばWebアプリケーション診断の場合に、検査コードと呼ばれる不正なHTTPリクエストを送信し 擬似攻撃するプログラムがあります。

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

「ツール診断」による脆弱性診断

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

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

「手動診断」による脆弱性診断

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

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

脆弱性診断の進め方

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

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

脆弱性診断のまとめ

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

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

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

2023年4月21日2023年10月4日

BBSec脆弱性診断結果からみる
― 脆弱性を悪用したサイバー攻撃への備えとは ―

Webサイトは、重要なデータの宝庫であり、サイバー攻撃者にとっては宝の山です。攻撃者はWebアプリケーションやシステムに存在する脆弱性を突いた攻撃を仕掛けます。では、自組織のシステムに脆弱性が存在した場合、攻撃者に悪用されづらくするためには何ができるでしょうか。本記事では、多くの企業・組織への診断実績がある弊社の視点で、サイバー攻撃への備えの一つとして、脆弱性診断を活用した予防的措置をご紹介いたします。

脆弱性を悪用したサイバー攻撃

事業活動に欠かせないIT環境では、様々な個人情報や機密情報等が保管・やりとりされており、サイバー攻撃者にとってそれらは宝の山です。そのため、今この瞬間もあらゆる企業・組織がサイバー攻撃の脅威にさらされています。

そして残念ながら、多くのWebアプリケーションやシステムには脆弱性が存在している可能性があります。宝の山に、宝を盗める抜け穴、つまり脆弱性があるとなれば、悪意ある者に狙われてしまうのは当然といえます。

サイバー攻撃者はどのような脆弱性を狙うのか

では、サイバー攻撃者が狙う脆弱性とは、どのような脆弱性でしょうか。
それは攻撃者にとって「悪用がしやすい」、そして「うまみがある」脆弱性です。そのような脆弱性があるWebアプリケーションやシステムは、攻撃対象になりやすく、攻撃者にとって魅力的な標的です。

そして、攻撃者にとって「悪用がしやすい」「うまみがある」脆弱性とは、簡単に攻撃ツールやエクスプロイトコードが入手できる「蔓延度」、どれだけ甚大な被害をもたらすことができるのかという「危険度」、そしてどれだけ他の機能やシステム、あるいは世間にインパクトを与えることができるのかという「影響度」の3つを軸にして捉えることができます。

また、そうした攻撃者にとって魅力的な脆弱性が多数ある場合、一度の攻撃のみならず、何度も複数の脆弱性を突いて攻撃を行われる可能性があります。

脆弱性を突いた攻撃が成功した攻撃者のイメージ画像（自販機から飲み物が出てくる＝攻撃成功）

別の側面から見れば、攻撃者にとって魅力的な脆弱性がないWebアプリケーション・システムであれば、標的にされる可能性が少なくなるということです。

自販機に魅力的な脆弱性（攻撃してもうまみがない脆弱性）がないのをみて攻撃をあきらめる攻撃者のイメージ画像

サイバー攻撃者にとって攻撃対象にしづらいシステムとは？

ここまでみてきたように、攻撃者は「蔓延度」「危険度」「影響度」を軸に魅力的な脆弱性を判断することがあります。つまり裏を返せば、Webアプリケーションやシステムの脆弱性の「蔓延を防ぐ」「危険度を下げる」「影響度を下げる」ことで、攻撃者に脆弱性を悪用されにくくすることができます。そのためには各組織で脆弱性対策を行うことが必須となります。システムの欠陥をつぶし、脆弱性をなくすことが最も重要です。

古くから「無知は罪なり」という言葉もあります。情報セキュリティにおいては“まず知ること”が必要不可欠となります。脆弱性に対処するためには、「自組織のセキュリティ状況を見直し、リスク状況を把握して攻撃に備える」ことが重要です。

脆弱性の放置はサイバー攻撃を誘発し、事業活動に甚大な影響を及ぼしかねません。サイバー攻撃によるインシデントは、組織にビジネスの機会の喪失、信用の失墜といった損失につながる可能性があるため、脆弱性の放置はそういった損失の潜在的な原因となります。

システムに存在する脆弱性の有無を確認するために有効な手段の一つが、脆弱性診断です。脆弱性診断により、日々変化する脅威に対する自組織のシステムのセキュリティ状態を確認できるため、適時・適切の対策が可能です。

BBSecの脆弱性診断サービス

BBSecのシステム脆弱性診断は、独自開発ツールによる効率的な自動診断と、セキュリティエンジニアによる高精度の手動診断を組み合わせて実施しています。検出された脆弱性に対するリスク評価は5段階にレベル付けしてご報告しており、リスクレベルによって脆弱性対策の優先順位を判断しやすいものとなっています（右表参照）。

2022年下半期診断結果（多く検出された脆弱性ワースト10）

2022年下半期、BBSecでは12業種延べ510企業・団体、3,964システムに対して、脆弱性診断を行いました。結果として、なんらかの脆弱性が検出されたシステムのうち、5件に1件ほどはリスクレベル「高」以上の脆弱性が含まれているのが現状です。そのリスクレベル「高」以上の脆弱性を検出数順に10項目挙げると、下表のとおりになります。

2022年下半期におけるWebアプリ編ワースト10の上位3項目は、上半期同様、攻撃者にとって悪用しやすくうまみのあるインジェクション系の脆弱性がランクインしています。いずれもよく知られた脆弱性ばかりなため、悪用された場合、世間に基本的なセキュリティ対策を怠っている組織と認識され、信用失墜につながります。

また、アプリケーション等のバージョンアップを行わず、古い脆弱なバージョンを使用し続けているWebアプリケーションも多く存在し、ワースト10のうちの4項目がそういった脆弱性でランクインしています。すでに他組織で悪用された実績のある脆弱性を放置した状態となっている等、攻撃者にとっては同様の攻撃を複数の組織に対して行うだけで成果が出るので、こちらも悪用しやすくうまみのある脆弱性といえます。

ネットワーク編のワースト10でも過去と同じような脆弱性がランクインしていますが、9位の「SNMPにおけるデフォルトのコミュニティ名の検出」は初のランクインとなりました。SNMPは、システム内部のステータスや使用ソフトウェア等の各種情報取得に利用されるプロトコルで、管理するネットワークの範囲をグルーピングして「コミュニティ」としています。コミュニティ名には、ネットワーク機器のメーカーごとに「public」等のデフォルト値がありますが、SNMPにおけるコミュニティ名はパスワードのようなものであるため、デフォルトのままだと、これを利用して攻撃者に接続され、攻撃に有用なネットワークの内部情報を取得される恐れがあります。

脆弱性診断を活用した予防措置

ここまでお伝えしたように、攻撃者はより悪用しやすくうまみのある脆弱性を狙ってくる中で、自組織のWebアプリケーション・システムに脆弱性が存在するのか、また存在した場合どういったリスクのある脆弱性なのかを知り、脆弱性対策を行うことは組織として重要なことです。

脆弱性を悪用したサイバー攻撃への備えとして、BBSecとしては、脆弱性診断を推奨します。下図の攻撃方法は一例となりますが、影響範囲として機会損失から業務停止まで引き起こされる可能性がある、という実態はどの攻撃方法でも同じです。脆弱性を悪用された場合、どの攻撃方法であってもそういった被害が出る可能性があるため、悪用されやすい脆弱性は早急に対応しなければなりません。

早急に対応するポイントは「自組織のシステム状態を知り、優先順位をつけながら必要な対策をする」こととなるのですが、自組織におけるセキュリティ対策の有効性確認には、専門家の目線をいれることをおすすめしています。

脆弱性を悪用したサイバー攻撃に対して、予防的にコントロールするといった観点も含め、よりシステムを堅牢化していくために脆弱性診断の実施をぜひご検討ください。

半期（6か月）毎にBBsec脆弱性診断の結果を集計・分析。その傾向を探るとともに、セキュリティに関する国内外の動向を分かりやすくお伝えしています。
最新号のダウンロードはこちら。

SQAT脆弱性診断サービス

Webアプリケーション脆弱性診断-SQAT^® for Web-

Webサイトを攻撃するハッカーの手法を用いて、外部から動的に脆弱性を診断することで、攻撃の入口となる可能性のある箇所を検出します。診断は最新のセキュリティ情報に基づき実施されますので、開発時やリリース前ばかりでなく、既存システムに対する定期的な実施といった、現状の脆弱性対策の有効性を確認するために活用することをおすすめしています。
以下より、サービス内容が記載されている資料のダウンロードもいただけます。

ネットワーク脆弱性診断-SQAT^® for Network

悪意ある第三者の視点で、ネットワークをインターネット経由またはオンサイトにて診断し、攻撃の入口となる可能性のある箇所を検出します。ネットワークを標的とした攻撃のリスクを低減するため、脆弱性を徹底的に洗い出し、システムの堅牢化をご支援します。システムの導入・変更・アップグレード時のほか、運用中のシステムに対する定期チェックにご活用いただけます。
以下より、サービス内容が記載されている資料のダウンロードもいただけます。

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

	自動車産業・製造業におけるセキュリティ対策のポイント -サプライチェーン攻撃の手口と対策方法- 再生時間：04:56
	DevSecOpsを実現！ -ソースコード診断によるセキュリティ対策のすすめ- 再生時間：05:29
	Webアプリケーションの脆弱性対策 -攻撃者はどのように攻撃するのか- 再生時間：05:42
	今さら聞けない！ペネトレーションテストあれこれ再生時間：05:20
	予防で差がつく！脆弱性診断の話再生時間：04:57
	今さら聞けない！PCI DSSで求められる脆弱性診断あれこれ再生時間：05:00
	知っておきたいIPA『情報セキュリティ10大脅威 2023』～セキュリティ診断による予防的コントロール～再生時間：05:00
	今さら聞けない！ソースコード診断あれこれ再生時間：05:00
	今さら聞けない！クラウドセキュリティあれこれ再生時間：05:00
	リスクを可視化するランサムウェア対策総点検再生時間：02:04 ※2021年度ウェビナー資料【資料ダウンロード】
	“他山の石”の拾い方－セキュリティのトレンドをキャッチアップ－再生時間：06:26 ※2019年度セミナー資料【資料ダウンロード】
	クラウド環境におけるセキュリティの重要性再生時間：05:00 ※2019年度セミナー資料【資料ダウンロード】

BBSecの脆弱性診断

2023年上半期診断結果

Webアプリ/NW診断実績数

9割のシステムに脆弱性

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

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

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

ネットワーク診断結果

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

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

前回までの内容

SQLインジェクションとは

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

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

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

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

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

基本的な対策

保険的な対策

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

まとめ

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

クロスサイトスクリプティング（XSS）とは

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

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

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

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

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

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

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

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

まとめ

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

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

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

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

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

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

ASM導入ガイダンス

ASMにより得られる効果

ASMのプロセス

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

プロセス（2） 攻撃面の情報収集：

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

ASMと脆弱性診断の違い

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

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

BBSecでは

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

SQAT脆弱性診断サービス

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

サービス紹介デモ動画

過去ウェビナー抜粋動画

PCI DSS v4.0：新たなセキュリティスタンダードへの移行

PCI DSS v4.0改定のポイント

PCI DSS v3.2.1からの主な変更点

要件タイトル変更

進化した要件

多要素認証について

脆弱性診断に関する主な変更点

脆弱性診断実施にあたって求められる対応

PCI DSS v4.0への移行に向けて

PCI DSS v4.0準拠までのステップ

関連情報

BBSecでは

PCI DSS v4.0対応脆弱性診断サービス随時対応受付中！

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

脆弱性とは

脆弱性の種類

1. SQLインジェクション

2. クロスサイトスクリプティング（XSS）

3. クロスサイトリクエストフォージェリ（CSRF）

4. セッション管理の不備

5. アクセス制御の不備

脆弱性を悪用した攻撃による影響

機密情報の漏洩

データの改ざん

サービスの停止または遅延

金銭的な損失

企業の信頼喪失

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

プロセス（2）攻撃面の情報収集：

Webアプリケーション脆弱性診断-SQAT^® for Web-

ネットワーク脆弱性診断-SQAT^® for Network