SSQ.AISSQ.AI

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

Vulnerability Assessment & Penetration Testing

脆弱性、悪用条件、実際の影響を確認します。

対象のシステムとサービスを定めて脆弱性を広く探し、そのうち実際に悪用される経路と業務への影響を専門家が直接確認します。「ある顧客の情報が他の顧客に見えてはならない」のように必ず守るべき条件があれば、その条件が破られうる経路を別に設計して検証します。

脆弱性は実際に悪用されうるのか、重要な保護条件は守られているのか?

問題が起きる条件と実際の影響を検証し、改善の方向を示します。

確認済み

OUTSIDE インターネット SERVICE Web・アプリ・API ASSET 顧客データ 権限確認の漏れ 条件:権限なしに見えてはならない 見つけた弱点 実際につながる経路 守られた条件
見つけた弱点のうち実際に顧客データまでつながる経路を確かめ、必ず守るべき条件がほかの経路を止めるかを検証します。

二つのサービス

点検する対象から出発するか、懸念される被害から出発するかで分かれます。

VAPT(脆弱性診断・ペネトレーションテスト)

Vulnerability Assessment & Penetration Testing

このシステムの脆弱性は、実際に悪用されうるのか?

合意したシステムとサービスを広く調べて脆弱性と設定の問題を探し、攻撃者のように弱点をつないで、実際にどこまで入り込めるか、業務にどう影響するかを専門家が直接確認します。

出発点
点検する対象。Web・アプリ、クラウド、社内アカウント基盤、AIサービス、制御システムなど
こんなときに
リリースや大きな変更の前後、定期点検、顧客やパートナーから第三者による診断結果を求められたとき

個別設計型セキュリティ検証

Bespoke Security Validation

懸念している被害は、実際に起こりうるのか?

クーポンやポイントの悪用、アプリの改ざん、個人情報の漏えい、顧客企業間のデータ露出のように懸念される被害や、必ず守るべき条件から出発し、その被害につながる経路を設計して集中的に検証します。

出発点
懸念される被害、または必ず守るべき条件
こんなときに
特定の被害が心配なとき、機微なデータを多く扱うとき、点検基準がまだない新しい技術を導入するとき

二つは組み合わせて使えます。VAPTで対象全体を広く確認したあと、最も懸念される被害を個別設計型の検証で深く確かめる、という進め方です。どこから始めるかは、ご相談の中で一緒に決めます。すべてのサービスは、単独でも、複数を組み合わせてもご契約いただけます。

現実的な攻撃状況で組織の予防・検知・対応を確かめるレッドチームの取り組みは、課題に応じて別途範囲を設定します。レッドチーム・サイバーレジリエンス検証

以前の「脅威別特化セキュリティ検証」をお探しの方へ

何を点検するか

対象ごとに構造も攻撃の手口も違うため、確認する項目と方法、必要な専門性も対象に合わせて決めます。実際の攻撃は対象同士のつながりを伝ってくるので、対象がつながる箇所もあわせて確認します。

ネットワーク境界 外部 重要データ LLM LLMサービス プロンプトインジェクション WEB Web・API・モバイル ログイン・権限・ロジック IOT IoT・組込み機器 機器・ファームウェア・通信 GPU GPU・HPC 分離・共有ストレージ CLOUD サーバー・クラウド 外部公開・IAM・コンテナ OT OT・制御システム 制御機器・ファームウェア AGENT AIエージェント ツール権限・承認の境界 IAM 認証・権限 AD・SSO・権限昇格
八つの対象は一つの組織の中でつながっています。青緑の経路のように、攻撃はWebからサーバーとアカウント基盤を経てデータまで、対象をまたいで進みます。
  • WEBWeb・API・モバイル

    お客様が使うWebサービスとアプリ、その裏のAPIと管理画面までを一つのサービスとして見ます。ログインと権限、注文・決済のような業務の流れが中心です。

  • IAM認証・権限(AD・LDAP・SSO)

    社内のアカウントと権限が集まる場所です。権限昇格の経路、サービスアカウント、入社・異動・退職に伴うアカウント管理を確認します。

  • CLOUDサーバー・ネットワーク・クラウド

    外部に公開されたサービスと管理画面から、ネットワーク分離、クラウドの権限(IAM)と鍵・シークレット、コンテナ・Kubernetesの運用環境まで確認します。

  • AGENTAIエージェント

    メール・予定・社内システム・外部ツールを使うエージェントが持つ権限、人の承認が必要な行動の境界、外部からの入力に左右されないかを確認します。

  • LLMLLMサービス

    チャットボット・検索拡張生成(RAG)・要約などのサービスで、プロンプトインジェクション、システム指示と機微情報の露出、検索対象文書の権限を確認します。

  • OTOT・制御システム

    制御網と業務網の境界、遠隔接続の経路、PLCなどの制御機器とファームウェアそのものの脆弱性まで確認します。稼働中の設備に影響しないよう、方法から決めます。

  • IOTIoT・組み込み・ファームウェア

    店舗・家庭・現場のコネクテッド機器とファームウェア、ハードウェアインターフェース、機器・アプリ・クラウド間の通信と更新の仕組みを確認します。

  • GPUGPU・HPC

    モデルの学習・推論に使うクラスタのスケジューラと管理インターフェース、利用者・チーム間の分離、共有ストレージとモデルファイルの権限を確認します。

対象ごとの点検領域を詳しく見る

どんな被害を検証するか

懸念される被害から出発するときは、分野ごとに個別に設計した検証項目を使います。複数の分野を組み合わせることができ、ここにない懸念も一緒に設計します。

  • ビジネスロジック悪用の検証

    クーポン・ポイント・返金・予約のような業務ルールを、正規の手順の外で利用して利益を得られないか?

  • アプリ・クライアントのロジック保護構造の検証

    自社のアプリを解析されたとき、中核のロジックとセキュリティ機能はどれほど容易に見え、改ざん・回避されうるか?

  • 個人情報・機微情報の露出可能性の検証

    個人情報と重要な情報はどこに残り、どこから漏れうるか?

  • ネットワーク分離・情報持ち出し統制の検証

    分離したはずのネットワークと資料が実際に隔離されているか、重要な資料が外へ出ていく道はないか?

  • テナント・システム分離の検証

    複数の顧客企業が共同で使うサービスで、ある顧客企業のデータや機能が他社へ渡ってしまわないか?

  • AI・新技術の保護条件の検証

    AIエージェントや新しく導入した構成が、自社で定めた線を実際に越えないか?

分野ごとの検証範囲を詳しく見る

進め方

どちらのサービスも、始める前に目標・範囲・安全条件を書面で合意します。

  1. 目標・範囲の合意

    点検する対象または守るべき条件、提供いただく情報の水準(ブラック・グレー・ホワイトボックス)、許可・禁止する行為と中断条件を決めます。

  2. 準備

    権限ごとのテストアカウントと環境、点検期間中の連絡担当者、本番環境であれば点検できる時間帯を合わせます。

  3. 点検・検証

    ツールとAIエージェントで広く調べ、専門家が直接分析して、実際に悪用できるかを安全に確認します。

  4. 結果の説明

    発見事項と実際の影響、証跡、改善の方向を、意思決定者と技術担当者それぞれに説明します。

  5. 対処後の再確認

    合意した場合、直した結果を同じ方法で再確認します。

安全に進めるためにサービスに影響しうる試験は事前に合意した場合にのみ行い、異常の兆候があれば合意した基準に沿って止め、担当者に知らせます。点検中に扱うデータと証跡の保管・廃棄方法も、始める前に決めます。

お客様に残る成果

何をどんな条件で確認したかから、発見事項の実際の影響と根拠、直す順番までを整理します。

確認した範囲

点検した対象・条件・アカウント権限と、今回確認できなかった部分を明記します。

発見事項と実際の影響

実際に悪用できるか、業務にどう影響するかを説明します。確認した事実と、追加確認が必要な兆候は分けて記します。

再現可能な証跡

各結果を再確認できる手順と条件、根拠を残します。

改善の方向と順序

悪用の可能性と業務への影響に沿って、何からどう直すかを整理します。

個別設計型の検証では、これに加えてシナリオごとに防がれたか突破されたかと、その条件を残します。結果は認証審査や法的判断に代わるものではなく、対処後の再確認は別途決めます。

関連する研究:オフェンシブエンジニアリング(EXPLOIT)—攻撃者の視点から、脆弱性と実際の影響を分析・検証する技術を研究します。