インタラクティブアプリケーションセキュリティテストの有効性
Acunetix Web Vulnerability Scanner や HP WebInspect Real-Time など、多くのIASTツールが市場で入手できます。
これらは脆弱性の発見にどの程度効果的ですか？これらがブラックボックスアプリケーションペンテスト（DAST）またはソースコードレビュー（SAST）よりも多いか少ないかを検出できるという証拠はありますか？
私は この論文 を見つけましたが、それはIASTベンダーによってブランド化されているように見えるので、独立した比較があるかどうか疑問に思いました。
私も興味を持ってこの投稿を読みました： ブラックボックスペンテストで検出される脆弱性の割合は何ですか？
各方法（DASTとSAST）には長所と短所があります。
たとえば、DASTメソッドは、実際に（クライアント側で）実行して、実行が実際に可能であるかどうかを検証できる（良性のリフレクションではない）ため、XSSタイプの脆弱性の評価にはるかに適しています。この場合のSASTは、ほとんどの場合、入力がソースからシンクに到達した（または可能なパスを持っている）ことを証明することに限定されており、出力に反映することができますが、通常、反映が実行できることを確認できませんXSSペイロードを配信します。この場合、DASTにはSASTよりもいくつかの利点があります。
OTOH、パスワード入力がクリアテキストでバックエンドログファイルに書き込まれるなどの脆弱性を検出すると、DASTスキャナーではほとんど不可能であることが証明されますが、SAST分析では扱いやすいジョブです。
したがって、IAST（またはハイブリッドと呼ばれることもあります）は、両方の方法の長所を利用して、他の方法の固有の弱点を管理/軽減するのに役立ちます。また、1つの方法で他の方法を確認することで、誤検知率を削減することもできます（たとえば、SQLIの動的テストで、攻撃が実際にDBに到達したことを確認した場合）。攻撃面を狭めることでテストをスピードアップし（たとえば、ページがSQLを実行しない場合は、SQLIのページをテストする必要がありません）、非表示になっている可能性のある攻撃面（つまり、サブアプリケーションまたはリンクされていないページや視覚障害者には簡単に見つけられない）など.
免責事項：私は以前はそのようなスキャナーの1つで働いて開発していました。
IASTツールは脆弱性の発見にどの程度効果的ですか？
HP WIRT、Acusensorを搭載したAcunetix、コントラストセキュリティ、Quotium、Appscan Enterpriseは、最適なシナリオでより多くの脆弱性を見つけることができます。はい、コントラストセキュリティとWIRTを使用して、SAST側の機能がない場合よりも速く脆弱性を検出しました（WIRTはSecurityScopeフックを介して両方のWebInspectツールにフィードバックを提供し、FortifyをSecurityScopeログ出力とマージ可能にすることに注意してください） 、しかし私はJEEアプリを対象とする場合にのみそれらの機能を利用する（そして持っている） Acusensorの場合、得られる結果はさらに少なく、PHPアプリに対してのみです。QuotiumとAppscan Enterpriseは、.NET、JEE、または私が遭遇したその他の言語に必ずしもより多くの価値を加えるわけではありません- -しかし、彼らは確かにニッチを正しい設定と設定の下に持っています。
HP WIRT/SecScope vs. JEE: 9/10
Contrast Security vs. JEE: 9.5/10
Acusensor vs. PHP: 6/10
Quotium or Appscan benefits: 7 or 8 out of 10
HP WIRT vs. ASP.NET: 8.5 out of 10
これらがブラックボックスアプリケーションペンテスト（DAST）またはソースコードレビュー（SAST）よりも多いか少ないかを検出できるという証拠はありますか？
特に、特定のDAST評価に時間とリソースの制約が課せられていることを考えると、これの絶対的な決定的な証拠があります。このトピックに関しては、私をボーカルジャイアントにしてみましょう：厳密な（コントラスト、クォーティウム）またはゆるく定義された（WIRT/SecScopeなど）IASTは、ハイブリッドブレインツールの後にフォールトインジェクションテストケースを構成する際に非常に役立ちますコードの理解（通常、少なくともアプリの実行フローのウォークおよびクロールが含まれます）。
WIRT/SecScopeの場合、いくつかのシナリオで明らかに見逃していたであろう脆弱性を構成して見つけることができました-特にJEEおよび.NETアプリ、特に20を超えるMLOCで複雑さが非常に大きいアプリに対して、特にSOAPおよび/またはRESTインターフェースであるWebサービスが含まれていました。
個人的には、JAST、.NET、またはPHPビルドされたアプリに対する評価に触れずに、IASTを主要な初回実行アプローチと見なすことはありません。時間を大幅に節約し、フォーカス。
SASTとIASTの比較：IASTはSASTよりも高速で、リスク管理に重点を置いています。 SASTが将来的に検出する場合としない場合があるというIASTの結果が1つしかない場合でも、制御セットのギャップ分析または同様のリスク管理の問題を調べる場合、これは非常に価値があります。 IASTでセキュリティのバグが発見されたという事実は、ソフトウェアの弱点をより高い優先順位に独自に位置付けます。さらに、IAST調査結果をSAST調査結果（特にカスタムルールベース）と組み合わせると、ビューのさらなるカスタマイズ、コードの理解、コードの設計、およびリソースの組み合わせに関して、時間を大幅に節約できます
DASTとIASTの比較：IASTは私の手の中で、単により多くを見つけ、脆弱性をより深く理解します。これにより、より簡単に/より迅速に悪用または悪用チェーンにつながる可能性があります。
要約：可能な限り早く、可能な限りIASTを使用し、将来のSAST（およびカスタマイズされたSAST）評価にIASTアーティファクトを提供します。
どちらが良いですか？ハンマーまたはドライバー？それはすべて問題に依存します。事前に弱点を知らない場合、 IARPA 'STONESOUPが推奨するアプローチ は、複数のアプローチで複数のツールを使用することです。
NISTのポールブラックは、静的分析の利点と欠点を CrossTalk 2009年3月/ 4月の記事 で強調しています。 「新しい攻撃または障害モードが発見された場合、新しいテストを開発する必要があります。この場合、スタティックアナライザーにはいくつかの利点があります...」最も重要なのは、スタティックアナライザーがまれな発生や隠れたバックドアを見つける可能性があることです。特定の実行とは独立してコードを検討するため、可能なすべての相互作用を列挙できます。相互作用の数は指数関数的に増加する傾向があり、包括的な静的分析やテストの実行に対抗できません。静的分析では、初期状態を再確立したり、システムを人為的に制約して必要な相互作用を生成したりする必要なく、相互作用に焦点を当てることができます。さらに悪いことに、ブラックボックステストでは、ユーザーIDが「JoshuaCaleb」の場合、テストする任意の文字列がほぼ無限にあるため、実際にはバックドアにアクセスできるとは予想できません。」
「テストと静的分析は互いに補完し合う。テストには完全に予期しない障害を明らかにする可能性があるという利点がある。コンポーネントに隠れている可能性のあるソフトウェアを分析することがまったく非現実的である場合でも、組み込みシステムをテストできる。」
「静的分析は万能薬ではありません。複雑で微妙な脆弱性は、静的アナライザーの推論を常に無効にする可能性があります。監査や暗号化などの重要な要件の完全な欠如は、ポストプロダクションアーティファクトの調査だけから合理的に推定することはできません。ソフトウェア復元力や自己監視機能がないと、インストールや操作でエラーが発生する可能性がありますが、静的分析は脆弱性に対する防御の最後の行の1つになる可能性があります。」 ... 2008年6月の静的分析ツール博覧会の作業 [3] 、 [4] は、現在のアナライザーが大きく異なることを示しています。アナライザーは、一部の弱点については少数の誤報を生成しますが、他の弱点については多くの誤報を生成します。同様に、見逃された弱点の割合は大きく異なります。アナライザーはまた、文書化された弱点 [5] のサブセットのみをカバーします。したがって、最も包括的な静的分析は、慎重に使用されたアナライザーの組み合わせから生じます。
ブラック博士はNISTの SAMATE-ソフトウェアアシュアランスメトリックとツール評価 プロジェクトをリードしています。 Webアプリケーションスキャナーの価格と機能の比較 については、SAMATEの ツール調査 およびShay ChenのSecToolページを参照してください。
私はケーススタディQuotium（ http://www.quotium.com ）を書いた会社で働いていますが、私の回答では客観的になるように努めます！
重要なのは、脆弱性を見つけることではなく、開発者がビジネス、特にデータ（ハッカーの主な範囲）に本当のリスクをもたらすものを迅速に修正できるようにすることです。
どうして ？
リリースサイクルが短いアジャイル環境で開発している場合。 SAST + DASTを実行し、レポートを分析し、結果をトリアージし、未使用の関数の問題を修正し、コードを分析して（場合によってはサードパーティにある）、ソースを特定し、誤検知のeccを理解するプロセスを停止することはできません...時間はありません！
SASTとDASTの主な問題は、時間と専門知識です。どちらの場合も、影響分析とコード修正分析が必要です。 SAST + DASTはアジャイルではありません。
SASTとDASTはシステムの片側のみを認識し、全体的な脅威コンテキストとデータコンテキストの脆弱性を調べません。 IASTは、フロントエンドからバックエンドまでデータを追跡するため、そうします。
本当のIASTは、ハッカーの観点からコードに作用するために特別にゼロから構築された1つのツールです。
IASTを使用すると、開発プロセスとの統合を強化できます。
たとえば、ビルドサーバーのある場所にIASTツールを接続します。一方の側では、バグ追跡ツールのもう一方の側で自動テストスクリプト（Selenium for ex。）を接続します。夜間に実行される自動セキュリティテストプロセスがあります。
午前中に、開発者は、適用する修正、テストされたアプリケーションに対する攻撃のリプレイビデオ、ソースコンポーネントの場合にサードパーティのインターフェイスにパッチを適用できるようにするためのさまざまなコンポーネントの脆弱なコードへのパスを含む脆弱なコードリストを見つけます利用できません。
- 開発者は証明された脆弱性のみに焦点を当てます
- テスターは、OWASPトップ10、SANS/CWE、PCI ecc ...で調整されたGO/NO GOの脆弱性リスクを明確に把握できます。
その過程で時間を大幅に増やすことができます。
まあここでは私は客観的ではありませんが、それはそれがどのように機能するかです:)
客観的であるために：
IASTとして作成されたツールは、QuotiumのSeekerとAspect from Contrastの2つだけです。
他のすべてのベンダーは、marketingの目的で別々のツールをマージしようとしましたが、それらはIASTではなくDAST + SASTです！
IASTを継続的なプロセスとして実装し、引き続き監査用のSASTツールを提供しているクライアントがいます。
SASTは、より安全なコーディングを実践するのに役立ちます。 IASTはSAST後も脆弱性を検出しますが、コードの一部が脆弱なプロセスに影響されない場合、IASTは安全でないコーディングの実践を強調しません。
したがって、DAST + SASTよりもIAST + SASTを実行する方がよい場合があります。