機能

Virtual Patching

コード変更なしで数分以内にトラフィック層で脆弱性を閉じます。

TR7 Virtual Patchingを使用すると、新しいCVEが公開されたり本番環境で脆弱性が発見されたりした場合に、アプリケーションコードを変更することなくAAMレベルの保護ルールを追加できます。目的は恒久的なコード修正を置き換えることではなく、パッチが開発・テスト・安全にデプロイされる間に攻撃面を素早く縮小することです。 Log4Shell、Spring4Shell、Shellshockなどの重大な脆弱性に対する事前構築シグネチャはTR7 WAAPデータベースで入手できます。新規または組織固有の脆弱性に対しては、オペレーターが正規表現ベースのカスタムルールを記述し、マッチスコープを選択し、スコアを割り当て、ブロックを有効化する前にモニターモードで実際の本番トラフィックに対してルールをテストできます。 ルールのライフサイクルはmonitor、enabled、disabledの状態で管理されます。ルールはまずログのみで実行され、誤検知の影響を測定し、その後ブロックが有効化されます。ホットリロードアーキテクチャにより、パッチルールの追加がシステム全体の再起動になることはありません。 結果として:TR7は重大な脆弱性が開示された際の唯一の選択肢として「待つ」ことを除外します — アプリケーション修正が準備されている間、制御された方法でトラフィックをパッチする運用セキュリティバッファを提供します。

3+
事前構築された重大CVEシグネチャ — Log4Shell、Spring4Shell、Shellshock(複数バリアント)
3
ルール状態 — enabled / disabled / monitor
5〜10分
ルールの記述・コンパイル・有効化 — ホットリロード経由

アプリケーションパッチの準備が整っていない場合、攻撃者が待ってくれることを期待するのはセキュリティ戦略ではありません。

新しいゼロデイまたは重大なCVEが公開されたとき、組織が直面する実際の問題は脆弱性が不明であることよりも、アプリケーションをどれほど早くパッチできるかです。レガシーアプリケーション、サポート終了バージョン、壊れやすい依存関係、ベンダーロックされたソフトウェアはすべて直接的なコードパッチを困難にします。

公式パッチには数日または数週間かかることがあります。パッチが提供されても、本番環境にデプロイすることは別のプロセスです。回帰テスト、変更ウィンドウ、承認チェーン、ロールバックプラン、サービスダウンタイムリスク。活発な攻撃ウェーブが始まっているとき、これらのプロセスはセキュリティチームにとって十分なスピードではありません。

クラウドベースまたは外部依存のWAAPシグネチャフィードでは、組織は重大なCVEシグネチャがいつ到着するか、どの程度カスタマイズできるかを常に管理できるわけではありません。これはセキュリティ対応を内部で実施する必要があるオンプレミス、エアギャップ、ソブリンクラウドアーキテクチャでは特に重要です。

Virtual Patchingを誤って適用すると新たな問題が発生します。過度に広い正規表現ルールは正当なユーザートラフィックを壊す可能性があり、スコープの誤った選択は関係のないアプリケーションに影響を与える可能性があり、ブロックモードに直接配置されたルールは本番環境で誤検知を生み出すことがあります。したがって迅速な対応には制御されたテストとロールバック能力が必要です — スピードだけではありません。

TR7のVirtual Patchingアプローチは、モニターモード、スコアコントロール、スコープ選択、ホットリロードを通じて運用リスクを導入することなくアプリケーションコードの準備が整うまでトラフィック層で攻撃面を縮小します。

私たちのアプローチ

TR7はVirtual Patchingを一度限りの緊急ルールとしてではなく、テスト可能で管理可能なセキュリティライフサイクルとして扱います。

重大なCVEに対する事前構築シグネチャがセキュリティセットに含まれる

Log4Shell、Spring4Shell、Shellshockなどの重大な脆弱性に対する事前構築シグネチャがWAAPデータベースで入手できます。個別のパターンが複数のバリアントとエンコードされた攻撃形式をカバーします。

カスタムパッチルールをステップごとに構築

オペレーターは正規表現を記述し、マッチフィールドを選択し、スコアを割り当て、ルール状態を設定します。ルールはpath、query、header、form、json、xml、またはrawボディを含む異なるトラフィックフィールドに適用できます。

パッチ日付が記録・追跡可能

すべてのカスタムルールは日付スタンプと共に保存されます。このレコードにより一時パッチがいつ追加されたかを確認し、恒久的なアプリケーション修正が完了した後にクリーンアップすることが容易になります。

モニターモードにより本番での安全な検証が可能

`monitor`状態のルールはトラフィックをブロックせずにログを生成します。セキュリティチームが誤検知の影響を確認した後、同じルールを`enabled`に移動してブロックを有効化できます。

機能一覧

TR7 Virtual Patchingは事前構築CVEシグネチャ、カスタムルール作成、制御された有効化を単一のポリシーパイプラインに組み合わせます。

事前構築CVEシグネチャが重大な攻撃ファミリーを迅速にカバー

TR7 WAAPデータベースにはLog4Shell、Spring4Shell、Shellshockなどの重大な脆弱性に対する事前構築シグネチャが含まれています。Log4Shell側では、基本的なJNDIパターン、エンコードされたバリアント、難読化の試みをそれぞれ個別のパターンで対処できます。この構造により既知の高リスク攻撃に対してゼロからルールを記述する必要が低減されます。組織は事前構築シグネチャをモニターまたはブロックモードで有効化して迅速に対応できます。

新しい脆弱性に対して正規表現ベースのVirtual Patchesをカスタムで記述可能

組織固有の脆弱性、CMSプラグインの欠陥、ペネトレーションテストの発見事項に対してカスタム正規表現ルールを定義できます。ルールはpath、query、header、form、json、xml、またはrawボディを含む異なるマッチフィールドに適用できます。これによりセキュリティチームはアプリケーションコードを変更することなくトラフィック層で攻撃パターンを傍受できます。このアプローチは恒久的なパッチが入手可能になるまでの素早い保護層を作ります。

モニターモードによりブロックを有効化する前に実際のトラフィック影響を測定

`monitor`状態の新しく追加されたルールはログのみを生成し、ユーザートラフィックをブロックしません。セキュリティチームはルールがどのリクエストにマッチするか、誤検知を生み出すか、スコアへの影響はどうかを確認できます。結果が安全と判断されたら、ルールは`enabled`状態に移動されます。このフローは緊急対応スピードと本番の安全性のバランスを取ります。

スコアベースの判定モデルが異なるリスクレベルを管理

カスタムルールには2、4、6、8などのスコアを割り当てられます。高スコアは直接ブロックシナリオに使用され、低スコアは組み合わされたリスクしきい値判定に貢献します。この構造により各Virtual Patchをすべてのルールに同じ深刻度を適用するのではなく、攻撃の確実性とビジネスへの影響に合わせて調整できます。オペレーターは精密なポリシーと積極的なポリシーの両方を構築できます。

グローバルおよびプールレベルで異なるパッチスコープを定義可能

Virtual Patchはすべてのサービスプールにグローバルに適用することも、特定のプールのみにバインドすることもできます。グローバル層は広範なCVE攻撃に対する迅速なカバレッジを提供し、プールレベルは特定のアプリケーション脆弱性に対してより管理されたスコープを提供します。これにより単一のCMS脆弱性がプラットフォームポリシー全体を不必要にハードニングしないことを保証します。ルールスコープはアプリケーションリスクに合わせて絞り込めます。

既存ルールの状態とスコアを上書き可能

既存ルールの状態を`enabled`、`disabled`、`monitor`に変更できます。同様に、スコア値を増減して判定プロセスにおけるルールの重みを調整できます。この機能は既知のシグネチャを一時的にモニターモードに置いたり、緊急時により積極的に適用したりするために使用されます。組織ポリシーを実際のトラフィック動作に対して細かく調整できます。

ホットリロードによりパッチのデプロイを再起動操作にしない

新しいVirtual Patchが追加されると、変更された正規表現コンテンツが処理され、関連するハッシュ構造が更新され、影響を受けたセグメントのみが再コンパイルされます。このプロセスはプロキシ層全体を再起動せずにルールの有効化を目指します。コンパイル操作は管理されたリソース制限内で実行されます。セキュリティチームはメンテナンスウィンドウに依存させることなく緊急パッチを適用できます。

テスト攻撃辞書によりパッチの動作を検証可能

事前構築された攻撃辞書からの特定の攻撃例をTR7テストフレームワーク内で再生できます。`Attack.js`ツールによりターゲットホストとポートを選択して特定の攻撃IDを実行できます。この方法によりVirtual Patchが期待される攻撃パターンを捕捉するかどうかを実用的に検証します。運用チームはルールを本番環境に投入する前に具体的な動作を確認できます。

運用上の深み

Virtual Patchingは迅速な緊急対応と同様に、ルールの追跡可能性、ロールバック、スコープ制御、テストの規律を必要とします。

01

ルールID範囲

グローバルカスタムルールとプールレベルのカスタムルールは別個のID範囲に保持されます。グローバルルールは1M〜5Mの範囲に、プールルールは5M〜10Mの範囲にあります。この分離によりルールが影響するスコープが運用上より可視化されます。

02

パッチ日付の追跡

カスタムルールは`DD.MM.YYYY`形式の日付スタンプと共に保存されます。このフィールドは一時パッチが忘れられることを防ぐために重要です。恒久的なアプリケーション修正が完了したら、関連するVirtual Patchesを一括でクリーンアップできます。

03

ホットリロードのコンパイルプロセス

新しい正規表現コンテンツが処理されると、関連するハッシュ値が再計算され、変更されたセグメントが再コンパイルされます。プロセスはリソース制限内で実行され、影響を受けたセキュリティパイプラインが更新されることを保証します。緊急ルールの追加は広範なサービス中断を必要としません。

04

本番前の攻撃テスト

事前構築された攻撃辞書は既知の攻撃例を使用したルール検証を支援します。オペレーターは特定の攻撃IDを実行してルールがログに記録するかブロックするかを確認できます。このテストは特に新しい正規表現ルールに対する誤検知と見逃しのリスクを低減します。

05

ルールロールバック管理

Virtual Patchesは一時的なセキュリティコントロールとして扱うべきです。アプリケーションが恒久的に修正された場合、関連するカスタムルールを一括で無効化または削除できます。この規律がなければ古い緊急ルールが蓄積し、ポリシーの混乱と不要なブロックリスクが生じます。

06

監査と証拠生成

ルール名、説明、日付、状態、スコア、マッチフィールドは監査の観点から意味のあるレコードを生成します。セキュリティチームは特定のCVEまたはペネトレーションテストの発見事項に対してどの一時的なコントロールが追加されいつ適用されたかを示せます。これは脆弱性検出、コントロール適用、恒久的パッチ保留というチェーンを実証するコンプライアンスプロセスで特に有用です。

利用シナリオ

Log4Shell緊急対応

すぐにパッチできないレガシーJavaアプリケーションでLog4Shellのリスクが検出された場合、TR7で事前構築シグネチャを有効化してトラフィック層でJNDIバリアントをブロックし、アプリケーション修正の時間を確保できます。

レガシーアプリケーションの一時的なSpring4Shell保護

レガシーアプリケーションフレームワークにクラスローダー操作リスクがある場合、まずルールをモニターモードで実行できます。一日間トラフィックへの影響を測定した後、ルールをブロックモードに移動して脆弱性を管理下に置きます。

CMSプラグインの脆弱性に対するカスタムパラメーターブロック

CMSプラグインのベンダーパッチが利用可能になる前に、攻撃パターンが特定のパラメーターに表れることがあります。TR7で関連するパスまたはクエリフィールドのみを対象にしたカスタム正規表現ルールを記述します。これによりアプリケーション全体を停止させることなくリスクのあるリクエストをブロックします。

ペネトレーションテストの発見後の一時的なセキュリティコントロール

ペネトレーションテストチームが本番環境の悪用可能な脆弱性を報告した場合、開発チームには恒久的な修正の時間が必要です。TR7のVirtual Patchingは、その期間中に発見事項が攻撃トラフィックに変わることを防ぐ暫定コントロールを提供します。

よくある質問

TR7のVirtual Patchingはアプリケーションコードを変更せずに実際に保護しますか?
はい。ルールが有効化されると、TR7はトラフィック層で関連する攻撃パターンを傍受し、バックエンドサービスに到達する前にブロックします。アプリケーションコードは変更されません。保護はAAMレベルで適用されます。このアプローチは恒久的なコード修正が完了している間の攻撃面を縮小するよう設計されています。
TR7は新しいCVEを自動的にブロックしますか?
いいえ。TR7には自動CVEシグネチャ配布メカニズムはありません。Log4Shell、Spring4Shell、Shellshockなどの既知の重大な脆弱性に対する事前構築シグネチャがWAAPデータベースで入手できます。新しい脆弱性に対しては、オペレーターがカスタム正規表現ルールを記述して数分でVirtual Patchをデプロイできます。これにより組織が独自のセキュリティ対応を直接管理できます。
モニターモードとは何ですか?なぜ使用すべきですか?
モニター状態のルールはログのみを生成し、トラフィックをブロックしません。セキュリティチームはリスクなしに、どのリクエストにルールがマッチするか、本番環境で誤検知を生み出すかどうかを確認できます。ルールの動作が安全と判断されたら`enabled`状態に移動され、ブロックが有効化されます。モニターモードは緊急対応スピードと本番の安全性のバランスを取ります。
Virtual Patchルールの追加にはサービスの再起動が必要ですか?
いいえ。ホットリロードアーキテクチャにより、新しいルールが追加されると影響を受けたセグメントのみが再コンパイルされます。このプロセスはプロキシ層全体を再起動せずに動作し、管理されたリソース制限内で実行されます。セキュリティチームはメンテナンスウィンドウに依存させることなく緊急パッチを適用できます。
グローバルレベルとプールレベルのVirtual Patchingの違いは何ですか?
グローバルルールはすべてのサービスプールに適用され、広範なCVE攻撃に対して広範なカバレッジを提供します。プールレベルのルールは特定のプールのみにバインドされ、単一のアプリケーション脆弱性に対してより管理されたスコープを提供します。この分離により単一の脆弱性がプラットフォームポリシー全体を不必要にハードニングすることを防ぎます。
アプリケーションが恒久的に修正されたらVirtual Patchesはどのように管理しますか?
恒久的なアプリケーション修正が本番環境にデプロイされたら、関連するカスタムルールを一括で無効化または削除できます。ルール名、説明、日付スタンプによりこのクリーンアッププロセスが簡単になります。古い緊急ルールをクリーンアップすることで、時間とともに蓄積するポリシーの混乱と不要なブロックリスクを防ぎます。

コード変更なしで脆弱性を閉じる

Log4Shellからペネトレーションテストの発見事項まで、TR7のVirtual Patchingはすべての緊急シナリオでトラフィック層に対応します。お客様自身の環境でのライブセットアップをご案内します。