知らないと損する「RASP」とは？ 「Webアプリの脆弱性対策＝WAF」はもう古い：これで分かる「DevSecOps」の課題と解決【第4回】
Webアプリケーションの脆弱性対策として、広く利用されている「WAF」。実はWAFは、幾つかの問題を抱えている。それらの課題を解消した新たな手段である「RASP」の特徴とは。
「DevOps」（開発と運用の融合）にセキュリティを取り入れた「DevSecOps」をWebアプリケーション開発で実現するには、どうすればよいのでしょうか。そのためには、Webアプリケーションの開発段階から本番運用までの全ての過程でセキュリティ対策を実施することが必要です。
Webアプリケーションの開発およびテストの段階では、脆弱（ぜいじゃく）性検出を効率化する「IAST」（インタラクティブアプリケーションセキュリティテスト）や「SCA」（ソフトウェア構成分析）といったツールが活用できます。Webアプリケーションの本番運用段階では、どのようなツールがDevSecOpsの実現に役立つのでしょうか。本稿は、その代表例である「RASP」（ランタイムアプリケーションセルフプロテクション）について解説します。
Webアプリケーションの脆弱性対策「WAF」が抱える“あの問題”
「WAF」（Webアプリケーションファイアウォール）は、Webアプリケーションを稼働させているサーバ（ホスト）と、インターネットなど外部のネットワークの間で動作する境界型セキュリティツールです。WAFは、大きく分けて3つの種類があります（図）。いずれのタイプも、シグネチャのパターンマッチングにより攻撃（マルウェアの実行やデータ流出など）をブロックするかどうかを判断する仕組みをベースにしています。
- ホスト内に配置する「ホスト型」
- ホストが属する内部ネットワークに設置する「アプライアンス型」
- クラウドサービスとして利用する「クラウド型」
WAFをWebアプリケーションの脆弱性対策として利用する上で、特に問題になるのは以下の点です。
WAFの問題1．パターンマッチングの限界
一般的なWAFは、攻撃ごとの通信手法や行動パターンをまとめた「シグネチャ」を使い、パターンマッチングによって攻撃を検出します。パターンマッチングは既知の攻撃の検出には有効ですが、シグネチャに合致しない攻撃を見つけることが困難です。そのためデータの内部構造を悪用するといった比較的複雑な攻撃の場合、見逃してしまう可能性があります。WAFでの検出が難しい攻撃の例は、以下の通りです。
- 「CSRF」（クロスサイトリクエストフォージェリ）悪用攻撃
- CSRFは、攻撃者がCookieなどのセッション情報を悪用し、まるで正規のユーザーが意図したもののように不正なリクエストをWebサイトに送り、処理させることができる脆弱性。
- Webサイトが不正なリクエストを正規リクエストとして処理するため、パターンマッチングでは検出が難しい。
- Deserialization of Untrusted Data悪用攻撃
- 「Deserialization of Untrusted Data」は、単一形式のデータに変換したデータを元の形式に戻す「Deserialize」（デシリアライズ）を、変換先のデータの安全性を確認せずに実施できる脆弱性。
- デシリアライズはWebサイトのソースコードやライブラリによって処理方法が異なる場合があり、WAFの一般的なシグネチャではデシリアライズ処理の内容を完全に把握することは困難。
- Padding Oracle Attack（パディングオラクル攻撃）
- 不正な暗号化時に発生するエラーを悪用してデータが暗号文として適切かどうかを調べ、暗号化されたデータを読み取る攻撃手法。
- 暗号化のエラー情報を利用して暗号文の正当性を推測するため、WAFが正規の暗号化処理と攻撃を区別するのが難しい。
- WAFが全ての暗号化アルゴリズムを理解して対策することが困難な点も問題。
WAFの問題2．シグネチャの継続的な追加
基本的にWAFは、該当するシグネチャがない攻撃は検出できません。そのため新しい脆弱性に対処し続けるには、WAFのシグネチャを継続的に更新する必要があります。新しいCVE（共通脆弱性識別子）が出れば、それに対応したシグネチャが必要になるのです。OSS（オープンソースソフトウェア）の新しいCVEは、毎年約1万5000件報告されています。そのたびに新しいシグネチャを用意し、追加し続けなければなりません。
こうした問題による影響を緩和するためには、セキュリティエンジニアがWAFを定期的にチューニングしたり、シグネチャを定期的に更新したりする必要があります。これはセキュリティエンジニアの業務負荷を増大させ、コストの増加を招きます。WAFの大規模な全社展開に二の足を踏む企業が少なくない背景には、こうした事情があるのです。
「RASP」とは？ WAFとは何が違う？
併せて読みたいお薦め記事
連載：これで分かる「DevSecOps」の課題と解決
- 第1回：「SAST」「DAST」「SCA」がDevSecOpsに向かない“なるほどの理由”
- 第2回：脆弱性検出ツール「IAST」が「DevSecOps」に欠かせないのはなぜか？
- 第3回：Webアプリの“危険なOSSライブラリ”を見抜く「SCA」とは？
DevSecOpsについて知る
Webアプリケーションの外部から攻撃を検出するWAFに対して、RASPは内部から攻撃を検出します。Webアプリケーションに組み込んだエージェントソフトウェアを使ってデータの流れを確認し、そこから得られたコンテキスト（複数の兆候）を基にして発生した攻撃を検出し、食い止める仕組みです。RASPは、Webアプリケーションの内部関数や、外部ライブラリのAPI（アプリケーションプログラミングインタフェース）の呼び出し内容を追跡し、関数やAPIの呼び出し時点で攻撃を特定可能です。こうした仕組みにより、RASPは比較的複雑な攻撃でも検出しやすいという特徴があります。
脆弱性の種類を識別するための共通基準であるCWE（共通脆弱性タイプ一覧）単位で攻撃を検出、ブロックすることも、RASPの特徴です。この仕組みによって、RASPが認識していない脆弱性を悪用した攻撃が発生しても、その攻撃が悪用する脆弱性のいずれかが既存のCWEと合致すれば、検出、ブロックできます。CWEの例には、正規のSQLクエリに悪意ある操作を挿入し、標的のサーバで実行させる「SQLインジェクション」があります。
RASPはWebアプリケーション自体と、Webアプリケーションが利用するOSSライブラリの、双方の脆弱性に対処できます。Webアプリケーションのソースコードに脆弱性が存在する場合、その脆弱性への一時的な対処にRASPが役立ちます。OSSライブラリの脆弱性が新たに見つかり、そのOSSライブラリをアップグレードするまでの一時的な対処としてもRASPを利用できます。
繰り返しになりますが、Webアプリケーションが扱うデータの流れを追跡し、解析することで脆弱性を検出するのが、RASPの特徴です。世界的に被害を広げている、Javaのログ出力ライブラリ「Apache Log4j」の脆弱性は、脆弱性を突いて最終的に悪意のあるプログラムを実行させる「コマンドインジェクション攻撃」に悪用されています。RASPは追跡、解析したデータに基づいて「悪意のあるプログラムの実行につながっている」と判断しますので、そうしたコマンドインジェクション攻撃もゼロデイ（ベンダーが脆弱性情報を公開していない状態）で検出してブロックできている実績があります。
企業が継続的に成長するためには、デジタルトランスフォーメーション（DX）の推進が不可欠です。DXを推進する上で、Webアプリケーションの開発と運用の効率化だけでなく、セキュリティ対処も効率化するDevSecOpsが重要になっています。
本連載をお読みいただいた方は、DevSecOpsの実現を支援する手段として、IAST、SCA、RASPが有効なツールであることをご理解いただけたのではないでしょうか。これらのツール群を適切に活用することで、開発プロセスのより早い段階でセキュリティ対策を実施する「シフトレフト」や安全な本番運用環境の実現など、セキュリティ対策の自動化、プロジェクト全体の効率化を図りやすくなると考えています。
著者紹介
田中一成（たなか・かずなり） Contrast Security Japan
国内システムインテグレーターや外資系企業で営業を経験した後、ArcSight（現Micro Focus）、41st Parameter（現Experian）など、主に米国スタートアップのカントリーマネジャーとして6社の日本オフィスを立ち上げ、成長させた。IT業界で約30年以上の経験があり、ハードウェア、ソフトウェア、クラウド、セキュリティ、データベース、デジタルマーケティングなどさまざまな分野に精通している。現在、安全なWebアプリケーション環境を構築して運用管理するContrast Securityのランタイムセキュリティ製品の拡販およびサポートに尽力している。
Copyright © ITmedia, Inc. All Rights Reserved.