AST - アプリケーションセキュリティテストの疑問: 「誰が」「何を」「なぜ」「どこで」？

2020/10/30 - 読み終える時間: 3 分

?AST - The Who, What, Why and Where of Application Security Testing の翻訳版です。

AST - アプリケーションセキュリティテストの疑問: 「誰が」「何を」「なぜ」「どこで」？

2020年10月28日

著者: Shahar Sperling / Chief Architect at HCL AppScan

アプリケーションのセキュリティテスト技術を選ぶことは、単純な作業ではありません。直感的に、あなたは自分自身に尋ねるでしょう、 "最高の技術は何ですか？" その答えを見つけたら、あとは自分が一番気に入った製品を選ぶだけの簡単な作業です。

私は直感の大ファンなのですが、この場合、検討範囲を完全に理解していないと直感が誤解を招くことになります。上の質問は基本的に "DAST vs. SAST vs. IAST" という考え方をしていますが、本来は "DAST & SAST & IAST" であるべきなのです。AppScan の世界では、DAST から SAST、そして IAST へと拡大していく中で、私たちは10年以上前にこの結論に達しました。この拡大は、単にお客様に多くのオプションを提供するだけの問題ではないということに気付いたからです。スキャン範囲を改善してリスクを低減し、DevOps ライフサイクルのより多くの場所でセキュリティテストを適用し、適切な仕事に適切な技術を使用し、適切な人に適切なツールを提供することが重要なのです。テクノロジーは互いに置き換えられるものではなく、互いに補完し合い、隣り合わせに存在します。

なぜ、みなさまは単一のテクノロジーを求めているのでしょうか

技術には長所と短所があり、対象者も違えば、さまざまな種類の結果をもたらし、さまざまな条件のもとで活躍する技術もあります。開発とリリースのライフサイクルには、多くの段階があり、様々なスキルや専門分野を持つ多くの参加者がいます。可能な限り最も効果的なセキュリティテストを実施するために、ライフサイクルの異なるポイントで技術を導入することができますし、導入すべきです。

単一の技術の探索は、通常、次の3つの理由に起因します。

• 予算の制約: 支出は常に組織の関心事であり、制約があるかもしれません。
• プロファイルと政治性: 組織で働く人々のタイプ、誰の話を聞いているか、どのブログを読んでいるかなど。組織の一部がセキュリティプログラムに参加する意思があるかどうか、また、その結果として生じる腕ひねり（いわゆる、政治）は、すべて技術の選択に影響を与える。
• 誤情報: あるいは、過剰な情報。知っていることが多すぎても、十分でなくても、同じように混乱することがある。

それぞれの技術の使用状況をフレーム化するために、さらにいくつかの質問をしてみましょう。これらの質問はプログラムを設計するのに役立ちますが、それでも一つの技術を選択することが目的であるならば、決定するのに役立つはずです。

誰がスキャンを実行するのですか

この質問は、厳密には誰がスキャンの設定や設定を行うかということではありません。誰が実行するかという質問でもあります。特別な制限があるわけではありませんが、技術には、他の技術よりもはるかに適した特定のユーザータイプが存在することがよくあります。

開発者: 開発者は SAST スキャンを実行することで最も恩恵を受けることができますが、IAST も活用することができます。

QA エンジニア: QA エンジニアは、特別な相互作用がないため、IAST スキャンの実行に最も適している可能性が高いです。スキャンは、彼らが通常のQA作業（手動または自動化されたテスト）を行っているときに起こります。QAエンジニアは、DASTスキャンを実行することはほとんどなく、通常、SASTの開発環境にアクセスすることはありません。

セキュリティの専門家とペンテスター: セキュリティの専門家とペンテスターは、SAST と DAST が相性が良いと考えていますが、ほとんどの場合、IAST を使用することはありません。

結果を誰が受け止めるのか

これは、アウトプットが可能な限り実行可能なものになるようにしたいので、重要です。最終的には、開発者がすべてのスキャン結果を受け取り、それに基づいて行動する必要があります（つまり、修正する必要があります）。しかし、追加のキャッチャー(オペレーションやITなど)や中間処理者がいるかもしれません。

SAST と IAST の結果は、開発者にとって最も直接的に消費可能なものです。これらの結果は、開発者にとって最も直接的な情報（特定のコードの位置など）を保持しています。しかし、コードロケーションよりもレクリエーションシナリオを好む開発者は、DAST の方がより多くの利益を得られるかもしれません（これは、ユーザーが何に慣れるかの問題です）。

DAST の結果は、専門家やペンテスター、あるいは運用/IT (インフラストラクチャーの問題を修正するための) にとって、より意味があります。コードは、ほとんどの場合、彼らにとってはアクセスできないか、無関係なものです。

スキャンはいつ実行すべきでしょうか

スキャンには時間がかかります。コードレビュー、ユニットテスト、自動化された機能テストなど、開発ライフサイクルに別のタスクを導入する場合は、注意して行わなければなりません。セキュリティテストはそのようなタスクの一つに過ぎませんが、通常は無視されています。何が最も重要なのかを考える必要があります。

できるだけ早期に問題を発見することが最重要であるならば、SAST を使ってセキュリティテストを開発者に導入することは素晴らしい選択です。また、開発者は、特定の DAST テストアプローチが非常に有用であることに気づくことができます。

主な目的が既存のワークフローへの混乱を最小限に抑え、その影響を気づかれないようにすることであるならば、IASTはおそらくあなたの選択するテクノロジーです。アプリケーションと一緒にデプロイするために IAST を設定することは、一度だけの操作であり、一度それが行われると、アプリケーションは常に監視されます。アプリケーションとのインタラクション（自動機能テスト、手動テスト、統合テスト）があるたびに、アプリケーションはセキュリティの問題がないか監視されます。

あなたは、既存のチームの外部にテスト専門の新しいチームを作りたいと考えているかもしれません。そのような場合、DAST のテクノロジーは、彼らが選択するツールとなるでしょう。DAST は、テスターに、基礎となるコードや実行中のアプリケーションから最大限の分離を提供します。

スキャンの期待される結果は何ですか? 何を達成しようとしているのでしょうか?

これらは愚かな質問のように聞こえます。これらの質問は愚かな質問のように聞こえますが、その答えは、「アプリケーションをより安全にしたい！」ということです。しかし、使用する技術の種類を制限することは、ある種の節約を達成することを意味します。あなたは、金銭的にも、時間的にも、あるいは他のどんな条件でも、費用対効果を得ようとしています。そのためには、これらの質問に正直に答える必要があります。

例えば、サーバサイドのコードの安全性をより重視したり、優先順位を高くしたりしているかもしれませんし、開発者に開発ライフサイクルの可能な限り早い段階で問題に対処してもらいたいのであれば、SAST は正しい判断かもしれません。

もう一つの例としては、開発者の気が散るのを避け、時間の節約を促すことを優先することが挙げられます。これらの優先順位を満たすためには、IAST が適切でしょう。この技術は、あなたが何か他のことをしている間に欠陥を特定します。問題点を特定するのに必要な労力はほとんどありません。その「他のこと」をしている間に実行されているコードに限定されますが、基準セットの中では非常に安価です。

オーバーレイと外挿

これを読むと、誰がいつ何を使うべきかという明確な線引きがあると思うかもしれません。現実はもちろんもっと複雑で、重要なのは、それぞれの技術の長所と適合性を見極め、そのラインに沿って最適化することです。

そのラインを表すパラメータには、スキャニングの強さ、限界、リスク、想定ターゲットユーザー（ベンダーが想定）の 4つがあります。

SAST SAST は、サーバサイドの脆弱性（Webアプリケーションでは、モバイルとデスクトップアプリケーションのすべての側面をカバーしています）を特定するのに適しています。クライアント側の脆弱性も、特定の状況下では検出することができますが、SAST が得意とするところではありません。SAST の結果は、かなりの量のトリアージとクリーンアップを必要とする可能性があります。このプロセスは些細なものではなく、数回のサイクルを必要とすることもありますが、コード指向の結果は開発者にとって理想的であり、迅速な修正のターンアラウンドを得るために非常に効果的です。

DAST DAST はサーバサイドの脆弱性に対しても非常に良い仕事をしますが、3つの技術の中ではクライアントサイドの脆弱性に対して最も良い仕事をします。また、その能動的な性質により、はるかに正確な検証が可能となり、誤報告を減らすことができます。コードの位置がわからない一方で、テストペイロードはデバッグに役立ち、これは実行可能な代替手段として役立つかもしれません。DAST には、ある種の盲点があります。DAST が依存している、外部から見える副作用を発生させない問題を特定することはできません。DAST は、アプリケーションの入手困難な部分を見逃してしまう可能性があるため、カバレッジも問題となります。ユーザーがコードや実行中のアプリケーションと対話する必要がないため、DAST は、ペンテスターや帯域外のテストサイクルに最も適したツールです。

IAST IAST の強みは、サーバサイドの脆弱性検出にもあります。多くの点で SAST と多くの特長を共有していますが、結果の質がアプリケーションの機能のカバレッジの質に直接依存するという重大な制限があります。SAST の利点の一つは、内部コードの表現とともにリクエストデータを提示することです。これは、そうでなければ SAST にはない再現性とデバッグ機能を可能にします。第二の利点は、提案されたサニテーションとバリデーションコードの実行時検証です。サニテーションとバリデーションコードの信頼は、（よく知られたライブラリー関数が使用されていない限り）ヒューリスティックに行われるか、設定によって行われます。これはIASTでは要求されない。意図されたユーザーは、組織内で機能テストに従事している人なら誰でもよい。これにより、テストへの投資の可能性が大幅に高まり、以前は不可能であった、ビジネス的に意味をなさなかった開発フェーズでのテストが可能になります。

では、ギャップについてどう思いますか？また、そのギャップに耐えられるものなのでしょうか？

HCL AppScan では、どのような技術もあきらめるべきではない、というのが私たちの当たり前の結論です。諦めてはいけないというのが私たちの結論です。

詳細はこちら

ご自身でアプリケーションセキュリティテスト技術をテストするには、今すぐ AppScan の 30日間の無料トライアルをお申し込みください。