こんにちは、freee Developers Advent Calendar 2022 8日目の記事です。 PSIRTでblue teamとして活動している eiji です。
サービスやシステムのsecurityを確保したいとき、まず、最初にやらなければならないことはなんでしょう？ FirewallやIPSのようなsecurity sensorを配置することが頭に浮かぶかもしれませんが、それよりも先にやっておかなければならないことがあります。
それは、logを取ることです。
logがなければ、攻撃や異常を検知できませんし、検知できなければ、サービスやシステムを守るための行動をとることができません。
では、全部のlogを取るのか？ といわれると、答えは乱暴に言うとYesなのです。でも、全てのlogを単純に保存したとして、多くの人はそこからsecurityを確保したと言える状況に至る道筋を思い浮かべると、途方に暮れてしまうのではないかと思います。
Raw Data → Information → Intelligence
でも、最近読んだ「脅威インテリジェンスの教科書」の第1章では、
雑多なlogをかき集めて、securityの確保の役に立つIntelligenceを作成する手順を以下のような図で示していました。
この図は、米国統合参謀本部でのIntelligenceの概念の図を簡略化したものなのですが、これを利用するとログ分析を運用で回していく道筋を整理できそうです。
- Collection : logの収集
- まず、運用環境のservice、security sensor、3rd party SaaSなどから、logを集めてきます。
- ここで蓄積されるのは、Raw Data 生logです。
- formatに揺れがあって、timestampの形式が異なっていたり、送信元のIP addressを示す名前がclient_ipだったり、SrcAddrだったりと、field nameが異なる状況です。
- Processing : logの加工 = 正規化、補完
- logのfileld nameや、timestampなどのformatを統一し、相関分析が可能な形式となっています。
- ここで保持されるデータを Information と呼びます。
- Analysis : logの分析
- logの相関分析を行い、適切な時点で、攻撃の状況を整理し、攻撃への対処であるactionを定義し、まとめておきます。これをIntelligenceと呼びます。
FirewallやIDSのようなsecurity sensorの検知 log を起点にintelligenceを作成した場合、sensorが検知してBLOCKしているのだから、それでaction終了で良いのでは？思われるかもしれません。
しかし、攻撃者が他に怪しい行動を行っていないか log から抽出し、受けた攻撃の検知漏れが起きていないか確認する、他に良く似た攻撃が行われていないか水平展開する、といったactionを定義し、securityを向上するfeedback loopを回したいところです。
つまり、雑多な log から、脅威Intelligence = 「攻撃の内容や対処方法であるactionをまとめたもの」を作成し、日々蓄積していくことで、よりsecureなserviceを実現できるのでは？ と考えました。
ここからは、最近のfreeeのlog運用の移り変わりを脅威 Intellegenceの視点で振り返ってみます。
人力運用
SIEMの運用を開始した当初は、職人芸で分析が行われていました。
まず、最初に運用を開始したのは、S3 bucketに保存されたsecurity sensorの検知eventを一つずつLambdaで拾って、Slackにalertとして投稿する。Reactiveな対処です。
以下の図で言うと、上半分に記載されています。
Slackに飛んでくる多数のalert messageの中から個別で対処が必要なものを経験と勘で見分けて、message threadで対処を行っていきます。ほぼ、real timeで対処できますが、常に人を貼り付ける必要がありますし、triageだけでなく対処にも言語化が難しい職人芸の領域が多いため、誰でも簡単にできると言うものではありません。
一方、上の図の下半分に記載されているのは、定期的に行われる対処です。
freee PSIRTでは、週一回、security sensor もくもく会で、sensor logをtriageしていました。例えば、以下のような検知が多い場所があると、そこに着目して、
「時間帯を限定してから、IP addressやSignatureをTop10を参照して、Top10を上から目立つものを除外しつつ、見慣れないものを探す。」
といったことをteamで画面共有しながら行っていました。もちろん、探し方のコツは時と場合によっていろいろありますし、怪しい動きの概要をまとめた後、BLOCKするのか、泳がせるのか、当事者に問い合わせるのかといった判断に至るまでに、1件あたり20分ほどの時間がかかってしまいます。log分析に追われてしまって、logの運用自体を改善するようなfeedback loopを回すのは難しい状況でした。
この段階だと、分析できるのは一人当たり週に数件程度で、すべての怪しい log の分析が行えず、漏れがあることは明らかでした。
半自動 Triage
分析できる範囲を広げ、漏れをなくすため、徐々に自動化を進めることにしました。まず、手につけたのは、triageに関係する処理の自動化です。
Slackで行っていたReactiveな対処は、こちらが有効な場合もあるため、そのまま残しておきました。
一方でweeklyで行っていた定期的な対処をdailyで行うために、SIEMからdailyで前日の検知状況をfilterした結果をSlackに通知してくれるSlackBotを作成してもらいました。
毎日決まった時刻にSlackBotが前日の検知状況を整理して知らせてくれます。 例えば、Signatureごとの検知状況は以下のように通知されます。
このmessageのlinkからSIEMを参照すると、以下のように検知状況の詳細を確認できます。
グラフから攻撃の時間帯にこれといった傾向がないことがわかります。また、検知logの詳細からsource ipやuser-agentもさまざまで、存在しないpathへのrequestが行われていることから、単純な脆弱性探索を行なっていると推測できます。
ここからさらに分析を進める場合は、「Create Jira issue」のbuttonを押して、以下の情報を含むJira issueを作成し、自動的にassignされた担当者に任せます。
- SIEMへのlink
- 検知したsensor logでfilterしたもの
- すべてのsensor logを串刺ししたもの
- Service固有の情報
- user id
- OSINT
- whois
担当者は、これらissueに記載されている情報を参照し、次のactionを検討します。例えば、こんな感じです。
- ログイン前の攻撃で、すべてBLOCKされていて、誤検知、検知漏れがない
- 攻撃の頻度が高ければ、IP blacklistに登録するなど、コストをかけずに止める方法を考える
- ログイン前の攻撃で、検知漏れがあることが判明したが、実害はない
- お客様としての利用が記録されていない場合、攻撃を自動でBLOCKすることを考える
- ログイン後に異常な操作を行い攻撃として検知
- 意図的なものであれば、攻撃者として対処、BLOCKするかRateLimitするか泳がせるかを考える
- 攻撃の意図を感じられない場合、それ以外の可能性、例えば、applicationやserviceのbugを考える
- ログイン後の正常な操作を攻撃として検知
- 誤検知のため、signatureの修正、条件の変更を考える
triageの判断は人が行いますが、triageに必要な情報を整理してdailyで渡されるため、triage作業がとても楽になりました。 また、分析作業も、dailyで局所化した情報をもとにして、SIEMでいくつかのparameterですべてのlogを串刺し検索することで、水平展開や過去の検知状況を簡単に洗えるようになりました。
こうした半自動triageによって、人力運用の頃と比べて分析できるlogの種類や範囲を10倍以上に広げることができました。
自動的な対処 / Work In Progress
logの運用が回るようになり、漏れなく対処も行えるようになってめでたし！、と言いたいところですが、この運用を1ヶ月ほど続けると、Jira issueで解析する作業がroutine workになってきました。
それは、いつか見た攻撃や、定期的に現れる攻撃者が思っていた以上に多いことが判ってしまったからです。また、そうした攻撃は最初から完全に遮断したとしても、副作用がないことも明らかでした。
つまり、人が判断を下すまでもなく特定の条件でアクセスをBLOCKしてよいものが多数存在していたのです。
で、一次的な検知結果からsignatureを変化させて自動的にBLOCKした結果どうなったのかをここで報告したかったのですが、すみません。時間切れです。 12/25までには、ここに喜びの報告が加筆されると思います。
freeeの脅威Intelligence
freeeのlog運用に脅威Intelligenceの考え方を当てはめると, 以下のような図で表せます。
- Collection : logの収集
- logはS3 bucketに保持しています。
- application logやsecurity sensorのlogの収集から始めて、flow logを用いてtrafficの点と線を結ぶ、packet logを用いてAPIへのaccess patternを機械学習で解析するといったことも行っています。
- logの変更や消去を不可能にするため、S3 bucketでversioningを有効にし、アクセス権限を絞っています。上書きや消去ができてしまうdatabaseのtableに保存しているデータはlogとは呼べないですからね。
- Processing : logの加工 = 正規化、補完
- Elastic Common Schemaを用いてfield nameやformatを統一したOpenSearch上のSIEMにInformationを保持しています。
- freeeで運用しているSIEMについては、以下を参照してください。
- Analysis : logの分析
- dailyで行うtriageを半自動化しました。
- triageしたのち、個人ではなくteamで分析を行い、actionを定義した脅威intelligenceを作成しています。
- weeklyで全てのissueをreviewしています。
freeeでは、生logをS3 bucketに収集し、串刺し検索できるようなInformationをSIEMに保持し、攻撃状況とactionをまとめたIntelligenceを作成し、対処をissueとしてtrackingするlog運用をteamで回しています。
実際の脅威Intelligenceを扱う運用を続ける中で、memberの間で攻撃の手法や最近の傾向について共有され、それに対しての適切な対処を全員で議論できるようになりました。alertの海に溺れて何もできなかった頃からは格段に進歩です。
目に見える範囲で、ほぼ全てのalertを適切に対処できる体制を実現できたと思っていますが、攻撃は終わることなく続いています。気づけていない攻撃も多数あるに違いありません。
これからも、自動化できる部分は積極的に自動化し、人でしかできない探索に集中して取り組める環境を構築することで、今は気づけていない脅威をproactiveに検知できる運用に発展させていきたいと考えています。
そして、明日、2022-12-09に、WafCharm DAYS 2022に登壇します。
WAFを中心としたPSIRTの運用周りについて、株式会社ココナラの川崎さんと語り合う予定ですので、興味がありましたら、参加登録をお願いします。
明日のfreee Developers Advent Calendar 2022は、PSIRT red teamのkaworuさんが、joinしてからの激動の1年間を優しく振り返ってくれます！
