ソフトウェア・インテグリティ

 

Q&A:インタラクティブ・アプリケーション・セキュリティ・テスト(IAST)とSeeker

IASTに関するご質問に対する 回答、説明、推奨事項を用意しました。IAST Webセミナーでの視聴者からの質問への回答をご覧ください。

IASTに関する質問、回答、推奨事項

AppSec Hype or Reality? Demystifying IAST」Webセミナーをご視聴いただいた皆様にKimm共々お礼申し上げます。熱心にご参加いただき、優れた質問もありました。時間が足りず、すべての質問に回答できなかったので、このブログの投稿で回答を公開しています。すべての質問をIAST全般に関する質問とSeeker固有の質問の2つに大別しています。内容をご覧になって、その他にもご質問があれば、sig-japan@synopsys.comまでお気軽にお問い合わせください。

Webセミナーを視聴する(英語版)

IASTに関する質問

IASTはDASTに代わることができるか?

IASTはアプリケーション・セキュリティ・テストをDASTより効率的に実行します。そのため、多くの場面でDASTに代えてIASTを利用することができます。以下では、最適なツール選びに役立つよう、IASTとDASTの違いを説明します。

DASTはブラックボックス型のセキュリティ・テストです。要求を送信し、アプリケーションの応答を解析することによって脆弱性を検出します。DASTの長所は、一般に言語やフレームワークに依存しないことです。開発に使用するテクノロジー・スタックを問わず、あらゆる種類のWebアプリケーションに対応します。また、DASTにはアプリケーションをスキャンする機能があり、セキュリティ・テストを実行するためのアプリケーションをユーザーが駆動/テストする必要がありません。

短所は、DASTではセキュリティ・テストの対象となるアプリケーションをスキャンする必要があることです。また、DASTでは、スキャナーがログインやその他のフォームの背後にあるページにアクセスできるように継続的に膨大な設定が必要になります。そのため、DASTの方が設定と使い方が難しくなります。結果として、DASTはセキュリティ・テストを完了するまでに必要な時間とリソースのオーバーヘッドが大きくなります。

一方、IASTは、一般にアプリケーション内部にエージェントをインストールして動作を監視し、脆弱性を報告します。IASTはアプリケーションまたはソースコードのスキャンを必要とせず、セキュリティ・テストと機能テストを同時に実行します。そのため、セキュリティ・テストのための余分な時間がかかりません。代わりに、機能テストをセキュリティ・テストに変換します。IASTソリューションの価値を最大限に引き出すには、アプリケーションのすべての部分を動作させる堅牢な機能テスト・プロセス(自動化が望ましい)が必要です。

QA環境でDASTを実行する場合、優れた機能テスト・プロセスを用意し、IASTツールがサポートする言語でアプリケーションが作成されていれば、DASTをIASTに変更することは容易で、コストとリソースの削減、市場投入までに要する期間の短縮、セキュリティ体制の向上を実現することができます。

IASTはPCIテスト・ガイドラインに適合していますか?

はい。IASTはPCI DSSの6.5項に規定されたアプリケーション・セキュリティ・テストの要件に適合しています。IASTは、アプリケーションのテストに静的解析(SAST)、DAST、IAST、ソフトウェア・コンポジション解析(SCA)などのさまざまなセキュリティ・テスト・ツールおよび手法を用いることを要件として定めた新しいPCIソフトウェア・セキュリティ・フレームワークにも対応しています。

一部のコードのテストにIASTを用いなかった場合、どうなりますか?

アプリケーションの一部をテストしなかった場合、IASTではその部分の脆弱性は検出されません。これは他のソフトウェア・テスト・プロセスの場合でも同じことです。アプリケーション全体をテストしなければ、バグが残っているリスクがあります。同様に、IASTを使用した場合でも、アプリケーション全体をテストしなければ、テストしなかった部分に脆弱性が残るリスクがあります。

IASTツールではSASTツールで検出されるすべての脆弱性が検出されますか?

シノプシスでは、IASTがSASTツールの代用になるとは考えていません。納得していただけましたか?

IASTではOWASP Top 10のすべての脆弱性を検出できますが、ツールは要件に応じて選ぶ必要があります。最適なツールの選択に役立つよう、IASTとSASTの違いをご説明します。

  • 処理。IASTはソースコードやアプリケーションのスキャンが不要なため、処理のオーバーヘッドが生じません。IASTでは(アプリケーションの動作を監視して脆弱性を報告するエージェントを用いて)機能テストをセキュリティ・テストに変換します。SASTではソースコードのスキャンが必要なため、時間がかかります。したがって、処理の面ではIASTの方が優れた選択肢といえます。
  • 実行時テスト。IASTは、実行時セキュリティ・テストにより実行中のアプリケーションのすべての部分の脆弱性を発見します。一方、SASTは、実行時に実行されない部分を含めて、アプリケーションのすべての部分の脆弱性を検出します。このような種類の脆弱性を見つける必要があるかどうかを考慮してください。
  • セキュア・コーディング。開発者がセキュア・コーディング・プラクティスに従ってコードを開発することを目的とする場合にはSASTが適しています。動的セキュリティ・テストにはIASTが適しています。
  • 脆弱性の種類。IASTを利用しなければ検出できない種類の脆弱性もあります。その一例は重要データのリーケージに関連する脆弱性です。IASTは実行時に値を認識し、値のパターンを検索して重要データのリーケージを検出します。SASTでは、重要データのリーケージを検出する場合に静的コードのみに注目し、実行時の値を可視化することはできません。その結果、一部の脆弱性が見落とされる可能性があります。その他にも、HTTPヘッダーによる情報漏えいやSSLで使用されている弱い暗号など、IASTのみで検出可能な脆弱性にはさまざまな種類があります。このように実行時のみに検出可能な脆弱性は多数存在します。

そこで、セキュリティ体制を万全にするためには、SASTとIASTの両方を利用することをお勧めします。

IASTはマイクロサービスに対応していますか?

アプリケーションが20の独立したマイクロサービスを搭載し、それぞれが独自のJava仮想マシンで動作している場合、IASTはどの入力妥当性検証が行われたかをどのようにして認識するのでしょうか?

Seekerは、各JVM/マイクロサービスに関する脆弱性を発見および検証します。

Seekerに関する質問

Seekerがサポートする言語を教えてください。

Seekerがサポートする言語の詳細については、Seekerのデータシートをご覧ください。 シノプシスでは常に新しい言語の追加に取り組んでいるので、定期的に新しい言語が追加されることを期待できます。

Seekerツールを使用する場合、ソースコードをコンパイルする必要がありますか?

いいえ。SeekerのインストルメンテーションではSeekerツールを使用する場合にソースコードのコンパイルは不要です。Seekerは実行時インストルメンテーションを用いてセキュリティ・テストを実行します。

「ソースコード・プラン」という言葉が出てきましたが、どういう意味ですか?

Seekerはソースコード情報をアプリケーションのバイナリから取得し、通常、この情報をデフォルトで含んでいます。そのため、Seekerでインストルメンテーションまたはテストを行う場合には、アプリケーションのバイナリに対しては特に何もする必要はありません。

ソースコードに存在しない脆弱性をSeekerエージェントが発見するしくみを教えてください。

ソースコードを実行時にコンパイルする場合(つまり脆弱性が読み取り可能なコードではない場合)、脆弱性を検出できますか?

Seekerは、アプリケーションの動作を監視することにより実行時の脆弱性を検出します。脆弱性の検証は実行時に自動検証エンジンを用いて行われます。Seekerでは脆弱性の検証にソースコードが不要なため、アプリケーション・セキュリティ・テストの際にソースコードをスキャンする必要がありません。

SeekerはIDEと統合されていますか?

現時点では、Seekerは標準ではIDEと統合されていませんが、今後SeekerのIDEプラグインを開発する予定があります。

Seekerはセキュリティ・チームだけではなく、開発チームにも適していますか?

Seekerは開発チームとセキュリティ・チームの両方のニーズに対応しています。

セキュリティ・チームはSeekerのコンプライアンス・レポート(OWASP Top 10、PCI DSS、CWE/SANS Top 25、GDPRなどの規格に対応)、重大度別に集計された脆弱性レポート、またはCAPEC(Common Attack Pattern Enumeration and Classification)の分類を使用してアプリケーション・セキュリティ・テストの結果を監視し、セキュリティ体制の総合的な概要を把握することができます。

開発チームは、Seekerを利用して脆弱性の詳細なコンテキスト(ソースコード、行番号、URL、実行時パラメータ)を取得することができるため、脆弱性の再現と修正が容易になります。また、Seekerは開発ツール(Jira、Jenkins、Slack、Eメールなど)と統合されているため、開発ワークフローにも適合します。

さらに、Seekerは結果を検証して誤検知を削減するための自動検証エンジンを備えています。そのため、開発チームは誤検知の追跡に追われることなく開発に専念できます。また、セキュリティ・チームはアプリケーションのセキュリティ体制の実態を可視化できます。

「検証済みの脆弱性」とは何ですか?

検証済みの脆弱性とは、Seekerで検証された実在の脆弱性です。Seekerは検証ステップで、改ざんされた入力を用いて要求を再現し、脆弱性を検証または無効化します。「検証済み」とは「確認済み」の意味です。

Seekerで他のツールからの結果を検証することはできますか?

所属する開発チームではFortifyからノイズが生成される問題があります。Seekerでこのような結果を検証または少なくとも一部の誤検知の除去に役立てることはできますか?

はい。Seekerは脆弱性をリアルタイムに自動検証する独自の検証エンジンを備えているため、確実に役立ちます。自動検証により誤検知率はほぼゼロにまで削減されます。

Seekerに統合されたeラーニングは動画ベースですか? それともテキストのみですか?

シノプシスのeラーニング・プラットフォームはテキスト、音声、動画を併用し、学習者の知識と理解をテストする評価も用意されています。Seekerとeラーニングの統合により、この没入型の直感的な学習プラットフォームにオンデマンドでアクセスできます。

  • 実例に基づくケース・スタディ
  • 知識のチェックと評価
  • インタラクティブな演習
  • 技術的な詳細分析
  • その他

Seekerを他のベンダーのSCAツールと統合することはできますか?

たとえば、SeekerをBlack DuckではなくSonatype Nexus Lifecycle(IQサーバー)と統合することは可能でしょうか?

Seekerは、オープンソースおよびサードパーティーのコンポーネントの脆弱性を特定するベスト・オブ・ブリードのBlack Duck Binary Analysisエンジンと既に統合されています。さらに、Seekerの結果(SCAを含む)をお好きなツールにインポートできる包括的なAPIも用意されています。標準では、SeekerはBlack Duck Binary Analysis以外のSCAツールとは統合されていません。

インタラクティブ・アプリケーション・セキュリティ・テストの詳細はこちら