📊

Sumo LogicでSophosのログを集計してみた(初級編)

2023/07/10に公開

7月!!!!
ティアキンが終わりません…
来週からディアブロも再開する予定…

仕事はAzure×OpenAIもやる予定なのでクラウドネイティブさんの記事見ながら諸々やります!
https://blog.cloudnative.co.jp/16682/

今回はSumo Logicを使っているのでその記事です!!

目次

  • 1.きっかけ
  • 2.SumoLogicとは
  • 3.ログとクエリ
  • 4.おわりに

1.きっかけ

この間参加したJamfのイベントで、Splunkさんが来て色々SIEMについて会話したんですが、意外とSumoLogic使ってる人がいて下記のような声がありました。

  • 導入したけど何ができるかよくわからない
    →SIEMあるあるでは???
  • ドキュメントがよくわからない
    →一応Google翻訳で日本語変換?できるんですけどまーーーこれが読みにくいのと色々書いてあるんですけどこれどこでどの利用シーンで使うんや!って読むの途中で萎える
  • 設計してクエリ書く時間がない
    →わかる(わかる)

なのでうちでやってる部分を見せつつこうやって書くとこうなるよーっていうのを実際に書いていこうと思います。

2.SumoLogicとは

SIEM製品です。
代理店だとクラスメソッドさんとかかな?
元々直接やり取りしてたんですけどここ最近いつの間にか直接やり取りできなくなってました…
→今朝確認したら日本支社が先月末消滅していたとのこと
クラスメソッドさんがたくさん記事を書かれているようなので気になる方はそちらをご覧ください。
https://dev.classmethod.jp/tags/sumo-logic/

料金体系はSplunkとほとんど変わりません。
Azure AD、AWS、GWS、Slackからcloudflareのログまでテンプレートがあるのであんまり何も考えなくても標準で見える化は可能です。
これもありますか?っていうのを聞きたければ調べますのでコメントなり何なりご連絡ください。
(一部)

もちろんクラウドサービスだけでなくオンプレのサーバやネットワーク機器もログ収集は可能です。
ざっくりですがこんな感じです。

構成図

このオンプレのログサーバをAWS上に構築してそこにコレクターをインストールしてSumoLogicに送るサーバとして置くことも可能です。
注意事項として、ログを送るコレクターはJavaで動作していて、CPUに負荷がかかりまくるのでデータ量に応じてCPUのスペックは上げておいた方が良いです。

できることとしては

  • 各サービスの正常性の確認
  • ログを保持できる(エクスポート可能)
  • メール、Slackにアラート通知可能

他にもおおよそSIEMでできることはほとんどできます。
5000日は保持できるらしいですが、その分ストレージ容量の料金が高くなるのでここは最低限規定などで定めた期間で契約した方が良いです。

色々細かく知りたい方はクラスメソッドさんに聞くのが一番かもです。
今は不明ですがチュートリアル環境もらえてたはずなのでそこで見てみるのもありかも

3. ログとクエリ

まずクエリを説明する前に、取得するログを解析します。
SophosというEDR製品を利用しているのですが、そこでのマルウェア検知のアラートが出た分表示させます。
情報として最低限出したいのはこの5つ

  • いつ
  • 誰が
  • どの端末で
  • どういうマルウェアの種類か
  • どれくらい危険なのか(EDR判定基準)

Sophosとの連携と確認

まずはSophosとSumoLogicを連携させます。
この記事は公式見ながらでもできると思いますのでこちらをご覧ください。
https://help.sumologic.com/docs/send-data/hosted-collectors/cloud-to-cloud-integration-framework/sophos-central-source/#create-asophos-centralsource

連携できるサービスとできないサービスがあるので、そこは事前に調べておきましょう。
今回はsecurity/sophosというディレクトリにログを格納します。
連携させてしばらく経ったらSumoLogicを開き、上部のNewのLog Searchをクリックします。

その後、下記のクエリを書き、右側の見る期間を指定して検索ボタンをクリックします。
※今回は面倒なので30dにしてます。

_sourceCategory=security/sophos


これでログは取り込めるようになりました。
ほぼリアルタイムで取り込んでくれているので現状の状がわかります。

マルウェアを検知したときのログ

Sophos側でマルウェアのログを検知したときは下記のようなログになります。

{
source:"ユーザー名",
type:"イベントタイプ",
severity:"リスクの重大度",
core_remedy_items:{...},
endpoint_type:"エンドポイントのタイプ(computerなど)",
endpoint_id:"エンドポイントのID",
created_at:"いつこのログが作成されたかの時間",
source_info:{...},
customer_id:"カスタマーのID",
user_id:"ユーザーのID",
threat:"マルウェアの種類",
when:"いつ検知されたかの時間",
name:"具体的にどこで起こったかなどのパスなど",
location:"Host名",
id:"id名",
group:"グループ名"
}

表示させるために新しいダッシュボードで新しくパネルを作成していきます。
まずは先程と同様に_sourceCategory=security/sophosを書いた後に、| で区切ります。
ログの形式はjsonで、かつ上記ログのthreat:"マルウェアの種類",があるログを検索したいので下記のようにします。

_sourceCategory=security/sophos
| json "threat"

その次に、さらに | で区切ってcount byで何をカウントさせるか条件を書いていきます。
テーブルに表示させたいのはsource、severity、threat、when、locationです。
テーブルで表示させたい場合は左から順番に書いていけば順番通りに表示されます。

_sourceCategory=security/sophos
| json "threat"
| count by source, severity, when, location, threat

whenだと細かく時間が分かれてしまうのでcount byではなくてもいいのですが、時間以外で一番多く検知している人を見たい時にwhenをここから消せばいいのであえてcount byにしてます。

そしたら再度 | で区切って時間で並べ替えするようにします。
sort by、order byどちらも使用可能です。
descだと降順、ascだと昇順です。
今回はsort byで並べ替えます。

_sourceCategory=security/sophos
| json "threat"
| count by source, severity, when, location, threat
| sort by when desc

結果はこのようになります。

ちなみにSophosはMTRサービスに入っているのでこのマルウェアなどの検知をした際にSophosのセキュリティ担当の人?が調べてくれて対処してくれるので出てはいますけど大丈夫です。

テーブルはこちらからテーブルを選択すればテーブル表示になります。
グラフにしたければグラフも選択可能です。

その他円グラフで表示させて月一報告書などに記載しているのですが、
どれくらいのマルウェア、Web系マルウェアを検知をしたか、Sophosが危ないと判断しているWebのカテゴリがどれくらいあったかなどを表示させているのでそのクエリも載せておきますので参考にしてください。
parse regexは正規表現を利用して細かくデータを抽出できますが、ここは次回説明します。

Sophos URL Category Count
_sourceCategory=security/sophos "warned due to category"
| parse regex field=name ".*?warned due to category\s*'(?<category>[^']*)'"
| count by category
| sort by _count
Sophos WebMalwere Count
_sourceCategory=security/sophos "Access was blocked"
| parse regex field=name "Access was blocked to.*because of \"(?<malware_code>[^\"]+)\""
| count by malware_code
| sort by _count
Sophos Malwere Count
_sourceCategory=security/sophos
| json "threat" 
| count by threat
| sort by _count

4.おわりに

結構簡単なクエリでざっくりと説明しましたが、何でもできてしまう反面なにやったらいいかわからないってなるかと思います。
こちらのクラスメソッドさんの記事を読むのもまず最初かなとは思いますが、SIEMを選定するタイミングでどのログを取得して分析したいかはおおよそ明確にしていた方が損はしないかと思います。
https://dev.classmethod.jp/articles/sumo-logic_predefined-design/

単純にやらなきゃいけないから導入したというところも多いと思いますが、まずは最低限IDPやセキュリティ製品のログなどは見れておいて損はないかと思います。

自分のところが正常なのか、異常であるかの判断やグラフや数値にすることによって経営側にセキュリティ製品導入の予算取りのためのアプローチやその他CASBの導入が必要であることなどの提案もしやすくなると思うので守りながら攻めることができる情シスに一歩近づけるのではないでしょうか。

今回はAPIでjsonのログ取得時の話でしたが、次回はCSVでログを取得した場合の話をします。

Discussion