アプリケーション・セキュリティにおける誤検知を理解する

Pulisher : Enterprise Managed Service Group イ・ヒェイン
Description：誤検知に関するケースとトラブルシューティング方法、およびAWS Firewall Manager、AWS WAFを誤検知現象にどのように適用できるかについての紹介セッション

はじめに

運用業務をしていると、誤検知に関する経験をほとんど必然的にすることになると思います。 その中で、セキュリティアプリケーションやサービスに関してどのような事例があり、どのように解決できるのか、事例を参考にしたいと思い、セッションを申し込みました。

セッションの概要紹介

誤検知に関するケースとトラブルシューティング方法、そしてAWS Firewall Manager、AWS WAFの概要とこのサービスを誤検知現象にどのように適用できるかという内容を中心にセッションが行われました。

朝、お気に入りのウェブサイトを起動してクリックするだけで、写真画面が表示されるのを見たことがあるでしょう。

例えば、あるユーザーがラスベガスからニューヨークへのフライトを予約するためにいくつかの情報を入力した後、予約ボタンを押した瞬間、403エラーが表示されます。

基本的に誤検知は、ユーザーが正当な操作を行ったのにエラーが返される現象です。

では、1人のユーザーが同じことをされたとき、複数のユーザーが同じことをされたらどうなるでしょうか？ この問題が発生すると、おそらく航空券を探していたユーザーが競合他社のページに移動するでしょう。 つまり、彼がウェブサイトで過ごそうとした1,000ドルが競合他社の売上につながるということです。一人のユーザーなら大丈夫かもしれませんが、何百、何千人ものユーザーにこのようなことが起こったら、

その後、すべてのユーザーがインターネット上でウェブサイトがダウンしているかどうかを確認することになり、間違った理由で検索ワードに載り始めると、ブランドと評判が競合他社に移ることになります。

2つの主な課題は、適切なツールが必要であるということです。

まず、適切なアプリケーションで保護するためには、セキュリティチームが適切な技術力を持ち、セキュリティと警備方法を理解する必要があります。

セキュリティのために、AWSはエッジで提供される次のようなセキュリティサービスを提供しています。

世界中にコンテンツセキュリティを提供するのに役立つコンテンツ配信ネットワークであるAmazon CloudFrontがあります。

また、基本的に監視だけでなく、レイヤ7攻撃を防ぐのに役立つAWS WAFまたはWebアプリケーションファイアウォールがあります。

次に、Layer 3とLayer 7に対するDDoS防御サービスであるAWS Shieldがあります。

最後に、セキュリティガードレールを展開し、拡張する機能を提供するAWS Firewall Managerがあります。

一般的なウェブアプリケーションの様子は次のようになります。

このアーキテクチャを例に挙げると、Application LoadBalancerにAWS WAFを接続し、パブリックインターネットトラフィックが入る場合、AWS CloudFrontを使うことができます。しかし、多くの顧客は複数のAWSアカウントと複数の組織にリソースが分散しているため、このアーキテクチャは完璧なアーキテクチャとは言えません。

また、AWS WAFはAWS Athenaと組み合わせてログに対するクエリが可能です。これにより、特定のログに対するモニタリングが可能で、誤検知や問題が発生した場合、特定のイベントをクエリして探す作業も容易です。

次に、誤検知に関する2つのシナリオを説明します。 最初のシナリオは一緒に進行し、2つ目は観客の意見を聞いて分析する方法で進行しました。

状況1.正常なユーザーが403エラーを返しており、開発チームでは前日にコードを修正しました。 また、セキュリティチームでは403エラーと関連した複数のアラームを受信しました。

AWS WAFを使用している場合、Blockが発生すると警告するCloudwatchアラームの修正が必要です。

例えば、この場合、900秒または15分以内に5回の閾値が違反されたため、ブロックされたという通知が届きます。*実際のシナリオでは、もちろんもっと高くなる可能性があります。

そして、アラーム詳細情報を見ると、どのアカウントでアラームが発生したかを知ることができます。

二番目に見る情報はAWS WAFにどのようなルールが実行されているかであり、この情報を見ると、このような誤検知がAWSManagedRulesSQLiRuleSetで発生していることを確認することができます。

これを解決するために、まず、アラームを再設定した後、AthenaでCount Actionのクエリを生成します。このクエリを実行すると、最初の列にブロックされたリクエストの数が表示されます。

そして、ブロックされた原因である特定のルール項目が表示され、これにより、なぜ発生したのか、どこで発生したのか、この場合、発生した正確な場所を知ることができます。 これで、これらのログに基づいて誤検知を識別することができます。

この場合の最初の方法は、該当RuleSetを選択した後、RuleSet内のサブグループを識別して共通グループを変更することです。 この例の場合、ExceptionSQLiCookieルールをBlockからCountに変更して例外処理を適用します。その後、AWSManagedSQLiRuleSetルールの後に例外となる他のルールを追加し、WAF SQLi labelを使用してsessionID Cookieを除くすべてのSQLiリクエストをブロックします。

次は2番目のシナリオです。

現在、Cookie関連の問題があったアプリケーションの1つを修正しました。 開発チームは、アプリケーションに複数の変更が行われるため、複数のアプリケーションで再発する可能性があると言っています。

そのため、これを視覚的に素早く分析できる方法を要求してきました。

この要件を満たすことができる方法は、Amazon QuickSightです。

Quicksightはクラウドベースであり、他の可視化ツールと比較してはるかに使いやすいです。

データの流れは、AWS WAFログをS3に送った後、これをAmazon Athenaに送り、AthenaをWebサイトやAmazon QuickSightに接続します。

また、これを解決するための方法は最初のシナリオで使用した方法と同じで、他にもいくつかの方法があります。

セッションを終えて

運営中に発生する可能性がある様々な誤検知事例について知ることができました。 また、AWSが提供する様々なセキュリティサービスを通じて補完が可能であり、セキュリティサービスを活用した解決策及び可視化ダッシュボードを通じた持続的なモニタリング案も確認することができました。 運営間アプリケーション団のコード問題で誤検知が発生したことがしばしばありましたが、今後、同様の問題が継続的に発生する場合、QuickSightを使用して開発チームに提供すると、迅速な原因把握と問題解決に役立つと思います。