はじめに

クラウドセキュリティ最前線！SASE、SSEなどのトレンドを語ろう by Netskope Advent Calendar 2024に参加してみることにしました。

ゼロトラストセキュリティを実現するためには、IdPやSSE, EDRなど複数カテゴリのセキュリティ製品を導入し、組み合わせることが前提になります。
一方、複数カテゴリのセキュリティ製品を組み合わせた結果、ログをどう管理するのか、どう分析していくのかという観点は後々の課題になりやすいポイントです。

ゼロトラストセキュリティを単一ベンダーの製品で実現できてログを一元管理できるばよいのですが、複数ベンダーの製品を組み合わせて実現するのが一般的だと思います。
インシデントレスポンスのタイミングではそれぞれの製品に蓄積されたログを個別に分析する必要があり、関連のあるログを特定するだけでも一苦労です。

この問題を解消するソリューションとしてSIEMというカテゴリの製品があります。
この記事では、SIEM製品の選定時に考えたことと、その際に抱いたセキュリティログ標準化プロジェクトへの葛藤をお伝えできればと思います。

SIEM製品におけるログの正規化

SIEM製品では複数製品のログをまとめて扱うことになりますが、当然、製品ごとにログフォーマットは異なっています。
例えばIPアドレスひとつをとってもログのコンテキストによって、Source(送信元)・Destination(送信先)といった意味の異なる値を示す場合があります。
こうした製品ごとに異なるログフォーマットを正規化して取り込むために、多くのSIEM製品にはログパーサーと呼ばれる機能が存在しています。

ログパーサーは一般にSIEMベンダーが作成したもので、セキュリティ製品側のベンダーが作成したものではありません。
セキュリティ製品のベンダーが意図したログ仕様とSIEMベンダーが解釈したログ仕様に齟齬があると、セキュリティインシデントの分析結果にも誤った結果が生まれかねないという懸念がありました。
また、ログパーサーのカスタマイズをベンダー側でしか行えないという製品もあり、セキュリティ製品のログ仕様が変更された場合に追従できるのか？といった懸念もありました。

実際、導入を決めたSIEM製品のPoC中に、ログパーサーの解釈が誤っている箇所を見つけました。
私が見つけたケースでは、セキュリティ製品では通信を許可していると記録しているにもかかわらず、SIEM上で確認すると通信をブロックしたことになっていて、本運用で発生した場合、かなり致命的だった可能性があります。なお、SIEMベンダーへのフィードバックにより、現在、この問題は解消されています。

ログパーサーの解釈違いをなくすためには？

SIEMの導入検討を開始した2022年の夏、偶然、OCSF(Open Cybersecurity Schema Framework)というプロジェクトに出会いました。
このプロジェクトは、セキュリティ製品のログに関するフレームワークを定義することで、製品間のログの仕様差を埋めてしまうことで、ログの正規化を簡素にすることを目的としています。
セキュリティ製品のベンダーがフレームワークに沿ったログを設計すれば解釈違いは起きないよね？という考え方です。

当時、OCSFは発足したばかりでほとんど情報はありませんでしたが、AWS, Splunk, IBMといった業界をリードする企業がSteering Committeeを担っていることから、当時は一定の期待値を寄せていました。
実際にAWSではSecurity Lakeを中心として、OCSFに準拠してログ基盤を整える動きがみられましたし、現在もこの動きは継続しているようで対応している製品も増えています。¹

余談ですが、本アドベントカレンダーのスポンサーであるNetskope様の製品もNetskope Cloud Exchangeという製品を使うことでOCSFに対応したログを出力できる²ようなので、Netskopeをお使いの方でOCSFが気になる方は一度調べてみるとよいかもしれません。

OCSFを前提に据えたSIEM導入

思想に筋が通っているし、参画している企業の規模からうまく行きそうなプロジェクトだと思っていたので、OCSF前提でSIEM導入を進めることにしました。

すべてのSIEM製品を検討したわけではありませんが、多くの製品は取り込むログの容量に応じた課金体型となっています。
当時はSIEMの価値を示せる材料がなかったので、安価に始められてOCSFにも対応していたSIEM on Amazon OpenSearch Serviceを試してみることにしました。

SIEM on Amazon OpenSearh Service自体はログパーサーを持たないので、ログソース側からSIEMへログを転送するパイプライン上に、自前でログパーサーを実装する必要がありました。OCSFを利用する場合、セキュリティ製品のメーカーが用意したログパーサーを利用する前提になるのでメーカー側のマニュアルを見ながらSIEMへのパイプラインを構築していきます。
最終的に出来上がったSIEMでログを確認していくと、一部の製品でログの構造がおかしいことに気づきます。

OCSFの現状に対する評価

ログ構造がおかしいのには大きく以下2つの問題がありました。

セキュリティ製品のメーカーがOCSFの仕様を誤認しているパターン
- OCSF SchemaにはRequirementというフラグが定義されています³がRequiredなのに存在しなかったり、階層構造が崩れているなどの問題がありました
セキュリティ製品のログ出力仕様がOCSFに向いてないパターン
- イベントのログとインベントリ情報が分離して記録されている製品で、OCSF変換した際にDeviceなど、インベントリ情報に相当する内容がすべて空になるという問題がありました

前者は不具合なのでいずれ直ると思いますが、後者は製品仕様なのでログパーサーの実装をいじって解消するしかなさそうでした。
後者が結構致命的なので、運用工数の観点からOCSFへの移行は断念しましたが、前者についてもセキュリティ製品のメーカーがOCSFの仕様を正しく理解していないとSIEMベンダーがパーサーを作ったときと同じ問題が生じるという学びにつながりました。
OCSF自体はAWSが積極的に導入を進めているので、将来的に成熟するフェーズを迎える気もしますが、それ以外のメーカーがOCSFの仕様を理解するためのプロセスがないと、業界標準の規格とするには難しいというのが今の私のOCSFに対する評価です。

導入を決めたSIEM製品について

最終的にSIEM on Amazon OpenSearh Serviceではなく、OCSFに準拠していない別のSIEM製品を導入することに決めました。
導入を決めたSIEM製品はSIEMメーカー製のログパーサーを内包している製品でしたが、ログ分析を正しく行えるという観点では現状大きく困っていません。
とはいえ、前半に述べたようにログの解釈違いによる問題は起こりうるので、当面はSIEM製品とセキュリティ製品それぞれでアラートを受け取るようにして、SIEMの分析結果に違和感があった場合にログを見比べながらチェックしていくという運用になりそうです。

おわりに

OCSFは現状まだまだ育ちざかりということで、見切りをつけた形にはなりますが、思想に筋は通っているので、業界標準のログ規格になってくれたらセキュリティ製品のログに限らず、もっと広い分野でログ解析が楽になると思うので、今後の成長には大いに期待しています。

クリスマス当日まであと1日！
素敵な一日になりますように

https://docs.aws.amazon.com/ja_jp/security-lake/latest/userguide/open-cybersecurity-schema-framework.html ↩
https://docs.netskope.com/en/mappings-used/ ↩
https://github.com/ocsf/ocsf-docs/blob/main/Understanding%20OCSF.md#attribute-requirement-flags ↩