はじめに

Azure Advent Calendar 2020 23日目の記事ということで、Azure MonitorとKustoの話を書きます。
本記事はクレジットカードを取り扱うサイトにおいて、悪用を試験的に検知した話になります。
悪用対策のベストプラクティスではなく、Azure Monitorでこんなこともできるよ的な内容になりますので、
その旨ご留意いただければと思います。

また本記事はKusto初学者による試行錯誤が含まれていますので、
同じくこれからKustoにチャレンジされる方はぜひご参考ください。
Kustoに改善点があればご指摘いただけますと幸いです。

背景

有効なクレジットカードの当たり判定に悪用されてしまった…

勤め先はWebシステムのパッケージを持ち、カスタマイズして納品するBtoB企業です。
ECサイトの構築事例も多いのですが、EC案件でクレジットカードを機械的に大量に試行され、
有効なカードの判定に使われてしまったことがありました。

カードの有効性の確認はいわゆるXSSやSQLインジェクション等の攻撃とは異なり、
アプリケーションの仕様を悪用したもののため、IPSやWAFでは検知できませんでした。

先手を打ちたい！

後になってカード会社や決済代行会社から顧客を通じて連絡があり、
対応が後手に回ることが多かったため、被害を最小化すべく先手を打ちたいと考えていました。

ちょうどAzureで何ができるのか探していた時に「Azure Monitorで怪しい動きを見つけられないか」という話があり、
アプリケーションを改修せずにクレジットカードの大量試行を検出できるか試すことになりました。

Azure Monitor の設定方法

Azure Monitorとは、ざっくりいうと収集したサーバー上のログやパフォーマンスなどのメトリックデータを監視して、
条件に満たしたときにアクションを起こせるツールです。
今回はWebサーバーログを利用しました。

Log Analytics とは

ログの収集にはLog Analyticsを利用します。
収集したデータに対してKustoというSQLのようなクエリを用いて、分析をすることができます。
収集対象のサーバーはAzure上にある必要はなく、ログエージェントをインストールすれば
他クラウドやオンプレでも収集可能です。WindowsでもLinuxでも可です。

Azure Monitor の概要より引用

Kusto とは

Log AnalyticsがストアしたデータをSQLのようなクエリで可視化することができます。
といってもSQLとは似つかない構造のため、初めて触れたときにはなかなか難儀しました。

Logs
| where Level == "Critical"
| count

はSQLでいうところの以下に相当します。

SELECT COUNT(*)
FROM Logs
WHERE Level = 'Critical';

アラートを起こすには

アラートルールの条件にKustoを書き、最短5分間隔で実行して結果を評価し、条件を満たせばアクションを呼び出します。

アラートロジックの基準

Kustoを実行したときのcountすなわち結果の数か、
変数に格納した値のメトリック測定かどちらかが選択できます。

今回はメトリック測定を使いましたが、これを使うにはAggregatedValueという固定の変数名に
時間ごとに集計した値 bin(TimeGenerated, roundTo) を代入することが必須になっています。

たとえばWebサーバーログ(IIS)で500を応答した行数を10分ごとに分割して集計し、
メトリック測定で判定したい場合は以下のようなKustoになります。

W3CIISLog
| where scStatus == 500
| summarize AggregatedValue = count() by bin(TimeGenerated, 10m)

これをシグナルロジックの構成の検索クエリに設定し、アラートの発火条件を設定します。
余談ですがアラートをトリガーする基準の次の値より大きいは0は動くのですが、
画面のように1以上の値を入れると全く動きませんでした。情報求む…。

アクショングループ

条件を満たしたときの動作です。
アクショングループでは通知とアクションの2種類があります。

通知

メールやSMS、Azureアプリへのプッシュ通知、音声(電話をかけてくる)ということができます。
メールを使ってみましたが、件名のみ変更可能で文面は変更できません。

アクション

Automation Runbook、Azure Function、ITSM、ロジックアプリ、Webhook のセキュリティ保護、Webhook が選べます。
Microsoft Teamsを使っているため、Webhookを使いました。

なお、Webhookを使う場合はアクションをカスタマイズでwebhook 用のカスタム Json ペイロードを含むを使わないとちゃんと通知してくれませんでした。
以下のようなカスタムJsonを設定しておきます。

{"text":"怪しい動きを検出しました: #alertrulename"}

本題: クレジットカードの試行を検出する

Azure Monitorの設定方法を簡単に紹介しました。
ここからは実際にどうKustoクエリを作り、どういう結果が得られたのか紹介します。

今回のECサイトの仕様

注文周りの画面は以下のように構成されています。

クレジットカードの試行エラーの検知条件

サイトの仕様から、③請求額確認(カード入力)の画面で200が応答される場合、以下のどれかの問題であることがわかります。

• Validationの失敗
• 決済代行会社への処理（カードの与信処理含む）の失敗
• 注文データ作成の失敗

Validationについては商品在庫が引き当らないか、コメント欄にたくさん文字を入れてしまった場合なので、そんなに頻度はありません。
注文データ作成の失敗についてもDBでのINSERT処理の失敗なので、こちらもあまり起きません。

決済代行会社が障害により通信できない場合は一定期間POST時に200が出現しますが、
平時と比べて極端に増えるものでなく、また決済代行会社のサポートから連絡があるため、判別が付きます。

したがって③でPOST時に200が平時とは異なり大量に出てくる場合は、
ほぼカードの与信処理に失敗している＝色々なカードを試している状態であるとみなせます。

Kusto(1) 特定URLの200の応答数を数える

まず素直に③の画面でPOSTしたときに200が返ってくる件数で仕掛けてみます。

W3CIISLog
| where csUriStem contains "③のURL"
| where csMethod == "POST"
| where scStatus == 200
| summarize AggregatedValue = count() by bin(TimeGenerated, 10m)

平時

数はそれほど多くありません。概ねアクセス数とリンクした値になっています。

※実際のデータをお見せすることはできないためモザイク処理を入れています。すみません…。

クレジットカードの大量試行をされた時

中央やや右の部分に極端に大きな値が出ていました。
平時と比べて数百倍大きいため、検出は容易そうです。

※こちらもモザイク処理を入れています。

あとはこれを平時と比べて大きな値になったときアラートを発火するようにしました。

課題1

• 平時と比べて十分大きな値が案件により異なるため、
  案件ごとにどういった値が適切なのか調べて設定する必要がありました。
  
  • どの案件でも共通で入れられるように移動平均を取って判定に加えてみます。

Kusto(2) 24時間移動平均の5倍以上であるか

「5倍」の根拠は明確にはありませんが、過去に発生したログを分析したところ、概ねこれくらいなら確実に検知できるだろう値で設定しています。
※もっと統計的に処理してみたく3σや5σ以上としてみたのですが、母集団が少ないためかあまりうまくいきませんでした。

ここから急にKustoの難易度が上がり、この時点でKustoに触り始めて1週間程度の自分にはなかなか理解できないものでした。
2週間程度試行錯誤の上、ようやくKustoを編み出します。

let hour = 24h;
let span = 10m;
let gap_multiple = 5;
let thresold = XX;
let Log = ()
{
    W3CIISLog
    | where csUriStem contains "③のURL"
    | where csMethod == "POST"
    | where scStatus == 200
    | make-series num=count() default=0 on TimeGenerated in range(ago(hour*2), now() , span) 
    | extend ma=series_fir(num, repeat(1, toint(hour/span)))
    | mv-expand TimeGenerated, num, ma
    | project todatetime(TimeGenerated), tolong(num), todouble(ma)
};
Log
| where TimeGenerated >= ago(hour)
| where num >= ma * gap_multiple
| summarize AggregatedValue = sum(num) by bin(TimeGenerated, span)

※thresoldはしきい値を設定します。平時から注文が少ないサイトだと誤検知が多いため最低エラー件数を設定します。

Kustoクエリの解説

• Log変数にクエリの実行結果を格納し、そこからメトリック測定で使うAggregatedValueに値を代入できるようにしています。
• make-seriesで行方向ではなく配列(Dynamic型)としてカウントしたデータを時系列に作りnumに入れます。
  24時間移動平均なので、その2倍の48時間を拾っています。
• series_firで、numの移動平均を作ります。
  引数のrepeat(1, toint(hour/span))は10分間隔の24時間で144個の1だけの配列をフィルタとして入れています。
• mv-expandでDynamic型を行方向に変換します。これを知るまで1週間かかりました…。
• projectで必要な列を用意します。SQLでいうSELECTみたいなものです。
• 取り出したテーブルをLogに格納し| where num >= ma * gap_multipleで移動平均の5倍以上という判定を加えています。

平時

| where num >= ma * gap_multipleを外し、
| render columnchart kind=unstackedでグラフ化すると以下のようになります。
numは先ほどの平時のグラフと同じで、maは24時間移動平均です。
この中で移動平均の5倍以上になるものはありませんでした。

※例によってモザイク処理のためわかりにくくてすみません。

クレジットカードの大量試行をされた時

平時の数百倍のため左側が真っ白に見えますが、実際には僅かに表示されています。
もちろん移動平均の数百倍でもあるため、ちゃんと検知可能です。

※例によって(略

移動平均を取ることで、普段からものすごいPVをたたき出してバンバン注文が入るサイトでも
常にアラートが出っ放しということは無くなりました。

課題2

• マーケティング施策（限定商品セールのプッシュ通知など）による正常なアクセス集中・注文集中で誤検知してしまう。
  
  • セールの場合はカード大量試行と違ってエラー率が異なる点に着目して、見分けられるようにしてみます。

Kusto(3) エラー率は70%以上か

この70%という値も過去のデータから大体の値で決めました。

一般客の正常な決済も混ざっている状態で、エラー率は概ね以下でした。

• クレジットカードの大量試行が起きている場合のエラー率は85～99%程度。
• 正常なアクセス集中時のエラー率は20～40%程度。

すでにKustoに慣れてきていたため、そんなに時間もかからず編み出しました。
ついでにデータ集計期間を移動平均の2倍ではなく任意にできるようperiodに定義しました。(グラフの可視化などで便利なため)

let period = 48h;
let ng_rate = 0.7;
let hour = 24h;
let span = 10m;
let gap_multiple = 5;
let thresold = XX;
let Log = () 
{
    W3CIISLog
    | where csUriStem contains "③のURL"
    | where csMethod == "POST"
    | make-series num=count() default=0,
         numok=countif(scStatus=='302') default=0,
         numng=countif(scStatus=='200') default=0 
         on TimeGenerated in range(ago(period), now() , span) 
    | extend ma=series_fir(numng, repeat(1, toint(hour/span)))
    | mv-expand TimeGenerated, num, numok, numng, ma
    | project todatetime(TimeGenerated), tolong(num), tolong(numok), tolong(numng), numrate=iif(num>0, todouble(numng)/todouble(num), 0.0), todouble(ma)
};
Log
| where TimeGenerated >= ago(period)
| where numng >= thresold
| where numng >= ma * gap_multiple
| where numrate >= ng_rate 
| summarize AggregatedValue = sum(numng) by bin(TimeGenerated, span)

Kustoクエリの解説

• make-seriesでHTTPレスポンスコードが302の場合と200の場合をcountifを使って別々に集計し、Dynamicの配列を作成しています。
• projectにてnumrate変数にNGを全体数で割った値を入れています。
• numokはアラート条件としては何も使っていないですが可視化用に取っています。

平時

• 青がエラーでほとんど20%程度ですが、10分間隔のため件数が少ないと100%みたいな場合もあります。
• 件数の少なさは(2)のときのthresoldや移動平均でカバーしています。 ※例によって(略

クレジットカードの大量試行をされた時

• 当該時間だけ圧倒的に青（エラー）です。 ※例によって(略

セールによるアクセス集中の時

• クレジットカードの大量試行とは異なり、エラー率は最大で45%ほどでした。
• エラー率70%を境としてアクセス集中と大量試行を区別できています。 ※例によって(略

課題3 (余談)

• Webサーバーログが30日で数十GBたまってしまった場合の月額費用が、
  アプリケーション改修して検知できるようにした場合と比べて割に合うものか…。

まとめ

• Webサイトの仕様によっては、アプリケーションを改修せずとも
  Webサーバーログだけで高い精度でクレジットカードの大量試行を検知できました。
  改修難易度が高い案件、古くて調査に時間がかかる保守案件など、手が出しにくい環境下でも導入しやすいです。
• 既にWebサーバーログを収集しているのであれば、追加コストはアラートルール程度で1件につき月額0.5～1.5ドル程度ですが、
  これだけのためにWebサーバーログ収集をした場合はログの保持の月額がやや高額のため、割に合わない可能性があります。
  今回はMonitorの可能性を検証するために実施しましたが、実際に導入される場合は十分に試算してからがおすすめです。

Azure Monitor、Kusto、完全に理解した

mv-expandを使えるようになったあたりから完全に理解したと思っていましたが、
ダニング＝クルーガー効果が示す通り、ここからがスタートだと考えて来年も精進していきたいと思います。

range x from 0 to 130 step 0.2
| extend experience=datetime_add('hour',toint(round(x*120)),make_datetime('2020/11/1'))
| extend confidence=iif(x<10, toreal(x*10), pow(x-77,2)*0.02+10)
| project experience, confidence
| render timechart with(title='ダニング＝クルーガー効果', ymax=100 )