WP WAFおよびRASP:多層防御のベストプラクティス - JP

WAFおよびRASP:多層防御のベストプラクティス

WAFおよびRASP:多層防御のベストプラクティス

WAFの防御レイヤーが非常に強力であるのに、なぜRASPソリューションが必要なのでしょうか?

単一のセキュリティ製品ですべての脅威ベクトルに対し保護する訳ではないため、というのが簡単な回答です。包括的なITセキュリティ戦略には、有効性を最大化できる場所で実装された、リスク
に応じた制御が含まれす。

Imperva WAF(Web Application Firewall)は、アプリケーションを保護するための、階層的な多層防御戦略に不可欠な部分を成しています。正常なトラフィックが背後のアプリケーションに流れるのは許可する一方悪質なトラフィックを排除することにより、不正なデータ引き出しなどOWASP Top 10リストで見られるような脆弱性をターゲットにする重大な脅威を防ぎます。

その一方で、Imperva RASP(Runtime Applications Self-Protection)はWAFに類似していると思うかもしれません。 というのは、これもまた、SQLインジェクションやクロスサイトスクリプティングなどの脆弱性をターゲットにするエクスプロイトペイロードを検出し、阻止するように設計されているためです。

特に、クラウドネイティブの洞察でのプログラム言語に依存しない保護などImperva RASPは最近強化されたため、 WAFとRASPを組み合わせて使用し重要な資産とデータ保護セキュリティアーキテクチャを支援するメリットについてよく考えてみる価値があります。

ウェブアプリケーションファイアウォール

WAFはアプリケーションの前に存在し、HTTPリクエストの着信トラフィックを検査し、既知の攻撃ペイロードと異常な使用パターンを検出します。不審なペイロードや使用パターンが検出されると、リクエストをレポートしたり、レポートしてブロックしたりすることができます。WAFによって、IPアドレスをブロックすることができ、リアルタイムのアラートとレポートに加えて、ルールセットのカスタマイズも可能です。

Imperva WAFは、既知の悪質なトラフィックを正常なトラフィックと切り離し、アプリケーションの意図した機能に関連のない情報やリクエストをアプリケーションが処理しないようにします。このソリューションのその他のメリットには、アプリケーション・インフラストラクチャコストの削減があります。

多くのWAFの欠点は、エクスプロイトをブロックするための調整が必要であることです。保護を適用する前にエクスプロイトペイロードを特定する、リアクティブなアプローチが必要です。これによって、特にテンポの速いアジャイル開発手法を伴うアプリケーション開発において、検出漏れや望ましくない誤判定が取り込まれる場合があります。

Run-Time Application Self-Protection (RASP)

RASPアプローチは、サーバーレベル自体でアプリケーションに接続することで、アプリケーションコードと密接に結合されています。

Imperva RASPは、Language Theoretic Security(LangSec)として知られるコンテキストアウェアネス手法を使って脅威を検出し、特定のペイロードがアプリケーションコードを悪用するのを阻止します。RASPテクノロジーは、アプリケーションがペイロードを使用する方法との関連で、完全な(およびしばしば変形または難読化された)ペイロードを検査します。これが行われるのは、アプリケーションがそのデータの使用を試みる場合のみです。

その結果、誤判定が少なくなり、脆弱性(組織が以前気づかなった弱点も含む)の可視性が高くなります。RASPは、継続的なメンテナンスや大幅な調整を必要としません。そしてWAFと、Application Securityソリューションスイートのその他の要素を補完する、場所に適したセキュリティを提供します。

SDLCのポリシーによって、セキュリティテストツール(DASTなど)で見つかった脆弱性を、アプリケーションの生産に入る前に修正することが義務付けられる場合がありますが、業務多忙により、アプリケーションに既知の問題があるままでリリースされることもよくあります。アプリケーションコードにバグがないことは稀です。また、開発者は通常、十分なセキュリティトレーニングを受けていないため、アプリケーションレベルで対エクスプロイトの既定保護用ソリューションを利用する場合が非常に多くなります。

RASPアプローチはアプリケーションを意識した、コンテキスト依存の保護を提供できるため、そのメリットは多数あります。このレベルでソフトウェア開発ライフサイクル(SDLC)に統合され、ゼロデイ攻撃を防ぎ、レガシーアプリケーションを保護することができます。

WAFおよびRASPの事例

攻撃の検出

WAFのような、アプリケーションの前にあるセキュリティは、既知の攻撃に対する優れた保護です。WAF シグネチャにより、以前から既知のエクスプロイトペイロードの対処に優れています。しかし、頻繁なアプリケーションコードの変更やサードパーティーライブラリにより環境は絶え間なく変化し、エッジ保護はリアクティブにする必要があります。さもないと検出漏れや望ましくない誤判定の危険にさらされます。

この場合、これまで知られていなかったエクスプロイトペイロードに対処する時にRASP LangSecが役立ちます。Imperva RASPソリューションはシグネチャが不要で、アプリケーションとその関連コンポーネントがエクスプロイトの試みを特定するのと同じ方法で各ペイロードを評価し、既定でアプリケーションセキュリティを提供します。このソリューションは適所で利用されるため、誤判定を最小限に抑えられます。

適切なセキュリティアーキテクチャを実現するには、多層防御戦略において様々な地点に様々な制御を実装する必要があります。攻撃がレイヤー1 の制御を通過した場合、レイヤー2で同じ種類の制御を使用しても意味がありません。

より多くの攻撃トラフィックをブロックする

組織がクラウドインフラストラクチャに移行するにつれ、従来のネットワークの境界が本質的に消去されると、接続の始点に基づいて敵と味方を区別するのがますます困難になります。ほとんどのWAF導入の検査では、「南北」または「アウトサイドイン」トラフィックを重視します。一方RASPは、「東西」または「内部-内部」トラフィックの向きになります。

WAFは、信頼できないアウトサイダーを排除することに主眼を置きます。RASPは、信頼できるインサイダーまたは自律型マイクロサービスによって危害をもたらされるのを防ぐことができます。

セキュリティをDevOpsの一部にする

多くの組織では、WAFは専用の特殊化したチームによって管理されています。このチームは外部(例えば、Impervaまたはマネージドセキュリティサービスプロバイダー)でも内部(例えば、セキュリティ運用部門のWAF管理チーム)でもありえます。

ただし、業界は「クラウド」に進化し続けており、急速に運用部門と開発部門を統合しています。DevOpsは継続的インテグレーションを意味し、継続的デリバリーパイプラインは、セキュリティ管理をセットアップおよび実施するための既定のメカニズムです。RASPはアプリケーションの一部にすぎず、必然的にこのモデルに適合します。

ITと攻撃者の状況は共に絶え間なく進化しているため、多層防御戦略は動的である必要があります。セキュリティはDevOpsの会話の話題に上る必要があり…加えて言えば、トレーニングを十分に受けた人材が十分であるということはありません。開発のベストプラクティス、テクノロジーおよびスタッフを活用してみませんか?

RASPとWAFのメリットを評価し、優れている方を判断する場合、RASP とWAF はお互いを補完するというのが事実です。WAFは既知の悪質なトラフィックから保護し、RASPはアプリケーションの観点から場所に適したセキュリティを実施します。

2種類のセキュリティアプローチは、強固なセキュリティ戦略の一環として多層防御ソリューションを提供し、今日の様々な形態の攻撃に対抗します。

Imperva Application Securityなどの多層アプローチは、Web Application Firewall(WAF)、DDoS Protection、Advanced Bot Panagement、およびRASPにおいて、保護とマルチセンサー分析を提供し、アプリケーションアクセスを保護および監視するための完全なソリューションスタックになります。

当社のプレスリリースで、Impervaの RASP、最近拡大されたサポート、およびクラウドネイティブのワークロードの保護機能の詳細をご覧ください。

* 一部のハイパーリンクは英語のみです。