事業会社でWebサービスを展開していると、WAF（Web Application Firewall）を導入する必要に迫られます。そんなとき、どのように全体を進めていけばよいのか、リアルなケースを考えていきたいと思います。
ケース説明
プロジェクトの背景
A社は日本企業向けにB2BのWebサービスを開発、運営している。そしてB社はA社のWebサービスの導入を検討している。現在はまだ導入検討フェーズで、B社からA社へセキュリティチェック（クラウドサービス選定のセキュリティ基準）が行われている。
セキュリティチェックの結果としてA社はB社から追加のセキュリティ対策としてWAFを導入することが求められた。このセキュリティ要件を満たさないと失注になる。（B社はセキュリティを理由に導入を見送る）
方針
A社の経営方針として無理な受注はしない方針。機能開発のスケージュールや今回の顧客から得られる利益など、総合して検討した結果、今回のセキュリティチェックではWAFは導入していない、また現状、WAFを導入する計画がないことも正直に伝えた。結果として、失注となった。
その後、プロダクト開発のチームは機能開発が落ち着く6か月後に、WAFの導入検討をすることにした。
WAFの導入方針をまとめる
今回は具体的な課題が明確になっていないため、目的を深掘りし、導入するかどうかを検討するところから始めることになった。
WAF導入の目的を深掘りする
なんのためにWAFを導入をするのか？を少し深ぼっていきます。
一般的にはWebアプリケーションの防御と言われていますが、自社にとっての目的を考えています。
まず、現状を考えてみると、大きく２つの事実、可能性が浮かび上がります。
- Webアプリケーションへの攻撃が見えていないこと
- もし攻撃されていると仮定すると、それはWebアプリケーションまでリクエストが飛んでいるはず、ということ
1に関してはまず本当に攻撃されているか、されていないか、がデータとしてわかってないです。もし攻撃されているのであれば、どんな攻撃がされているのかというデータが取れれば、そこから新たな防御策を検討するサイクルを回すことができます。
次に2について。攻撃されているのであれば、現在その攻撃はWebアプリケーションまで届いてしまっているはずです。脆弱性がないため、その攻撃は有効ではないという状況でしょう。ということはWebアプリケーションの手前で攻撃を防御することができれば、今後、Webアプリケーションの脆弱性が出たとしてもそれを修正することの時間を稼げるし、多層防御にもなる。また攻撃によるWebアプリケーションのリソースを消費することもなくなります。
ここまでをまとめると
- Webアプリケーションへの攻撃可視化ができたら攻撃データに基づいた対策が打てそう
- Webアプリケーションの手前で攻撃を防御できれば、多層防御として防御力向上、脆弱性修正の時間稼ぎ、そしてシステムリソースの消費を抑えることができそう。
これらを目的とする導入であれば、ある程度意味がある導入になることがわかりました。
WAF製品の傾向を把握する
まずはWAF製品の傾向を把握するため、Google検索を行うことから始めます。
調べていくとWAF製品の検知ロジックにはいくつかの種類が存在します。
通常はこのうちの1つ、もしくは複数の検知ロジックが組み合わせて使用されます。WAFは検知が命です。該当製品がどの検知ロジックなのか理解して選定する必要があります。
シグネチャベースの検知
既知の攻撃パターンや脆弱性に基づいたシグネチャ（特定の文字列やパターン）を用いて攻撃を検知します。シグネチャは定期的に更新され、新たな脆弱性や攻撃方法に対応します。
異常検知
正常なトラフィックのプロファイルを学習し、異常なアクセスパターンや行動を検知します。ユーザーの行動、セッションのパターン、アプリケーションの使用状況などを分析します。
ヒューリスティックベースの検知
定義されたルールやアルゴリズムに基づいて、攻撃を推測し検知します。既知の攻撃パターンに完全に一致しない新しいまたは変種の攻撃を識別するのに有効です。
IPレピュテーションと地理的ロケーションに基づく検知
信用できないとされるIPアドレスや特定の地域からのアクセスを識別します。不正アクセスの試みやブルートフォース攻撃を検知するのに役立ちます。
レートリミットと行動分析
特定の時間内に許容されるリクエスト数を制限し、それを超えると攻撃と見なします。DoS攻撃やブルートフォース攻撃など、異常なトラフィックパターンを検知します。
機械学習に基づく検知
大量のデータから学習し、通常のトラフィックパターンと異なる行動を自動で識別します。進化する脅威や未知の攻撃パターンに対応する能力を持ちます。
導入方針をまとめる
目的の深掘り、製品の傾向を把握した上で、導入方針をまとめていきます。
まずは目的と制約を確認します。
目的
- 攻撃の可視化
- 多層防御による防御力向上、脆弱性修正の時間稼ぎ、システムリソースの消費
制約
- WAFを運用できるセキュリティエンジニアがいない
- コスト（事前に取っている予算内）
導入方針
そして製品の傾向から導入方針を下記とします。
- 既知の脆弱性を防御できること
- 攻撃を可視化できる
- 運用が楽なこと
- シグネチャ型であればルールを自動追加できるサービスがよい
- もしくはAI（機械学習）型
WAFの選定、導入
選定
導入方針を選定軸として比較して、製品選定をしていきます。実際にはコストを加味することになります。
※ここでは仮の選定表を作成しています。それぞれの製品サイトから拾える情報（マーケティング的な情報）を記載しているだけですので、情報は正確ではありません。また特定製品を推す意図はありません。
今回は簡単に試せるハンズオンワークショップが用意されているWafCharmを選んだと仮定して以降を記載していきます。
- Scutum : https://www.scutum.jp/
- WafCharm : https://www.wafcharm.com/jp/
- Cloudbric : https://www.cloudbric.jp/cloudbric-waf/
- PrimeWAF : https://security.valtes.co.jp/primewaf/
- Imperva : https://www.imperva.com/ja/web-application-firewall-waf/
| 候補 | 検知方法 | 可視化 | 自動運用 | 備考 |
|---|---|---|---|---|
| Scutum | AI | ? | ◯ | ---- |
| WafCharm | シグネチャ | ◯ | ◯ | シグネチャ自動運用 |
| Cloudbric | ロジック | ? | ◯? | 運用マネージド・サービス付き？ |
| PrimeWAF | シグネチャ？ | ◯ | ? | ---- |
| Imperva | シグネチャ? | ◯ | ◯? | シグネチャ自動運用？ |
導入
今回は導入を仮定して、下記ハンズオンを利用しました。
WafCharm自体は、WAFそのものではなく、AWS WAFを自動運用するためのサービスです。よって、AWS WAFの導入 + WafCharmの設定が必要になります。
ここにWafCharmの設定手順を入れようと思いましたが、あまり手順がないため、公式のドキュメントを貼って終わりにしたいと思います。
WAFの運用
通常、シグネチャ型のWAF場合、シグネチャルールを自分たちで追加していく運用が必要になります。しかしこれには専門知識や時間がかかります。WafCharmの場合、この部分を自動化してくれます。
シグネチャ自動運用の仕組みを紐解いていくと、AWS WAFのログを解析して、シグネチャルールを自動追加するという仕組みになっているようです。
まとめ
今回は、本質的なセキュリティ対策を行うというケースを説明してきました。
ケース1とケース2でそれぞれ異なった結果になったのではないかと思います。
セキュリティの施策はわりとケース1のような場合が多い気がしています。外部起因で発生したプロジェクトは、実際のプロジェクト実行者のモチベーションは低く、また目的が短期的となります。そして、解決の施策は本質的な課題を解決しないかわりに、のちに課題を増やすことも多いです。
マネジメントはこのあたりのコントロールを行っていくと、セキュリティチームは本質的な課題に注力できると個人的に考えています。今回のケース1の例でいうと、低コスト短納期で導入だけのプロジェクトにならないように適切な予算やスケジュール、ゴール設定になるようにコントロールする、そもそも1顧客のセキュリティチェック（セキュリティ要件)に振り回されないような方針を握っておくなどになるでしょう。
Discussion