AppScan: ダイナミック・テスト・ポリシーの活用を最大化する方法

2020/7/14 - 読み終える時間: ~1 分

AppScan の動的分析 (DAST) においてはポリシーが大きな役割を果たしています。ポリシーの調整が効果を高める結果となります。どのようにそれを実現すべきかについて英語版ブログに How to Maximize the Effectiveness of Your Dynamic Testing Policies がポストされました。この翻訳版を掲載します。

ダイナミック・テスト・ポリシーの活用を最大化する方法

2020年7月13日

著者: Shahar Sperling / Chief Architect at HCL AppScan

さまざまな種類のポリシーが企業のセキュリティ管理とセキュリティ評価を統制しています。これらのポリシーは、スキャンの結果をどう処理するか、またはどのように処理するかを定義しています。

しかし、何をスキャンするか、いつスキャンするか、どのようにスキャンするかを定義する他のポリシーもあります。What がすべてであるべきです。When はリリース要件によって管理されており、スケジュールを立てることができます。How はもっと複雑です。

How は通常、速度、完了、最適化などの異なる目標を達成するための設定や設定のセットです。静的分析 (SAST) を実行するとき、設定は、スキャナがアプリケーションコードをよりよく「理解」するのを助けることができます。例えば、カスタムサニタイザーや特定の関数の汚れの伝播状態を定義することで、ノイズが少なく、より正確な結果が得られます。動的解析 (DAST) では、ナビゲーション パラメータや冗長性チューニングを定義することで、スキャナがアプリケーションでの役割を「理解」し、それらを正しく処理できるようにします。

スキャンの設定は継続的に改善され、手動でポリシーを設定する必要性が減ります。SAST では、インテリジェントコードアナリティクス (ICA) を導入し、特定の関数や API の役割をほとんど自動的に識別できるようにしました。動的解析 (DAST) では、DOM 比較メカニズムを使用して、ハードリミットや複雑な冗長性チューニングなしでスキャンを最適化します。

静的ではなく動的に

もう一つのポリシーがありますが、それは How の一部ですが、少し違います。それは、アプリケーションをテストするときにどのルールを使うかを定義するものです。ここでは特に DAST ルールについて説明します。

HCL AppScan では、これらをテスト・ポリシーと呼んでいます。テストポリシーは、アプリケーションをテストするときに使用するルールのセットです。

カテゴリのリストを選択して、そのカテゴリ内の問題をスキャンすることもできますし、深刻度の高い問題のみを選択して、重大な欠陥をテストすることもできます。

動的テストルールには、アプリケーション、サードパーティ、またはインフラストラクチャのタイプがあります。

• アプリケーションルールは、アプリケーションコード自体に見られる論理的な問題をテストします。これらは、開発プロセスの一部として導入された脆弱性であり、組織の開発グループのコードベースの中で発見されます。解決策は、通常、コードの修正や変更です。
• サードパーティのルールは、サードパーティのコンポーネントを使用して導入された問題をテストします。サードパーティのルールは、サードパーティのコンポーネントに CVE を割り当てることで指定され、解決策は通常、関連するコンポーネントをアップグレードすることです。
• インフラストラクチャのルールは、Web アプリケーションやサービスを実行するプラットフォームの脆弱性をテストします。これらのルールは、Web やアプリケーションサーバ、通信中に使用される証明書などに関連しています。これらは、設定の問題や、サーバの一部であるサービスアプリケーションの問題である可能性もあります。解決策は、通常、構成の変更であり、多くの場合、DevOps または Ops の IT チームによって実行されます。

決定、決定

開発ライフサイクルのさまざまな段階でスキャンを実行する場合、異なるテストのセットを実行することは意味があるかもしれませんし、意味がないかもしれません。

例えば、サーバが開発サーバの場合、インフラストラクチャのテストを実行することは意味がありません。サーバーが正しく設定されている可能性が低くなり、それを修正したいと思う可能性が低くなります。しかし、ステージングサーバや本番サーバをスキャンしている場合は、これらのテストを実行することが重要です。インフラストラクチャのテストのみを含むテストポリシーでスキャンを実行することもできます。

アプリケーションテストは、確かに継続的な統合スキャンに使用されるでしょう。このようなテストでは、アプリケーションにコード化されている脆弱性を識別するように設計されています。前述したように、インフラストラクチャのテストは、ほとんどがノイズを発生させるので、この段階では除外されるべきです。

サードパーティのコンポーネントは、それほど頻繁には変更されませんし、これらのコンポーネントの導入は、通常、明確に定義されたプロセスの一部として行われます。すべてのテストを常に実行する必要は本当にありません。開発段階ではオープンソース解析 (OSA) を使用した方が良いのですが、AppScan Source では、何か抜け落ちた場合に備えて動的にキャッチすることができます。

サードパーティのルールテストは、新しい脆弱性が公開される可能性があるため、定期的に実行する必要があります。さらに、サードパーティの問題は、必要のない特定の機能をオフにすることで緩和できる場合もあります。その場合は、ダイナミックスキャンを実行することで、その機能が正常に無効化されているかどうかを確認することができます。

より効果的に

セキュリティテストの重要な目標の 1 つは（アプリケーションの安全性を確保し、顧客とデータを保護することは別として）効率性と明快さです。可能な限り徹底したいと考えていますが、間違ったタイミングで間違ったテストを実行してしまうと、得られるのはノイズだけになってしまいます。ほとんどの無関係な情報に圧倒されていると、集中力を失い、場合によっては興味を失ってしまいがちです。

関連する状況に必要な結果を適切なタイミングで得ることに集中することで、スキャン時間と課題のトリアージの両方の効率が向上します。これらの目標を達成するためには、スキャンの目的とする結果に対して正しいテストポリシーを設計することが重要です。時間をかけて、ポリシーを定義するためのオプションを調査し、スキャンの意図とその結果について考えてみてください。

詳細は

AppScan の技術力の詳細をお知りになりたい場合は、是非デモの要望など、お問い合わせ下さい。