🚀

Starting Detection Engineering in Ubie

2023/12/02に公開

この記事はUbie Engineering Advent Calendar 2023の2日目の投稿になります。UbieではこれからDetection Engineeringに対して取り組もうとしており、どのような課題があってどのように進めようとしているのか、についてご紹介したいと思います。

背景：セキュリティ監視の課題

サイバー攻撃の対策の一つにサイバー攻撃の検知や検知後調査のためのログ収集をする「セキュリティ監視」があります。セキュリティ監視は未然にインシデントを防ぐのはやや困難ですが、早期検知によるインシデントが発生した場合の被害の極小化、そして調査によって影響範囲の特定ができます。他の防御策と組み合わせて運用することで、ユーザの利便性を損なわずに高い安全性を提供することもできます。

Ubieではいまだに事業や組織が成長の段階にあり、様々な変化が日々起きています。そのような状況の中でセキュリティ監視は重要な役割を果たします。例えばセキュリティを向上させるための手段として従業員の権限を限界まで絞り込んだり、利用できる機能を制限する方法があります。これは事業や組織が固定化し変化がない状況であれば有効ですが、変化が大きい状況ではあまり適切ではありません。ユーザの利便性を損なってしまったり、変化が起きるたびに権限や制限の調整に多大な労力が必要になってしまいます。そのため制限を最低限にとどめ、監視によって問題の発生を即座に検出するというアプローチは変化の大きいスタートアップにとっても相性の良い対策と言えます。

セキュリティ監視は有効なアプローチである一方、丁寧に運用するためのコストが大きいという課題があります。

担当するメンバーに深い脅威分析の専門知識が必要
検知ルールのチューニングが正常に機能するかの検証
手作業による検知ルール適用作業
同じようなアラートに対する対応の繰り返し

実際に運用しようとするとこれらの作業工数は小さくなく、数人程度専任チームで対応する必要があります。しかし現実にはその規模の専任チームを抱えられる規模の組織は限られており、結果として別の役職のメンバーが片手間に運用する体制になりがちです。監視を適切に運用するためには検知 → 対応 → 改善のループを回す必要があり、片手間の運用ではその効果が十分に発揮しにくくなります。

またこれらは同じチーム内であっても、作業の分担によって属人化しやすい側面もあります。担当のメンバーに知識や経験が集中するのは効率的な部分もありますが、逆に人の出入りがしにくくなるという負の側面も常に抱えることになります。

Detection Engineering

このようにこれまで「人」の力で解決してきたセキュリティ監視という領域を、「エンジニアリング」の力で解決しようという取り組みが近年あり、 Detection Engineering という名称で呼ばれ始めています。（参考 Detection Engineering and SOAR at Mercari 、Autonomic Security Operation ）Detection Engineeringは比較的新しい概念のためまだ一般化された定義はありませんが、自分も以前からそうした分野に強い興味があり、試行錯誤してきました。そして、自分の視点からDetection Engineeringでコアとなる発想は「近年のソフトウェア開発のベストプラクティスをセキュリティ監視の世界で活用する」ことだと考えています。これはHashiCorpが過去に提唱したPolicy as Codeの概念に近く、自分は具体的な要素として次の3点があると考えています。

(1) 検知やトリアージ、対応ルールのコード化

ソフトウェア開発でプロダクトのためのソースコードを書くのと同様に、アラートの検知や検出したアラートの深刻度判断、さらにはアラートの内容や深刻度に基づいた対応をコードとして記述します。これには次のような利点があります。

変更内容の明確化：ルールの変更において、口頭や紙面であっても変更内容を伝えるコミュニケーションに齟齬が起こり得ます。コードとして記述された場合、適用される変更が明確になり、確認が容易になります
レビュー：変更内容がコードによって明確化されることで、GitHubのPull Requestのように別のメンバーによる確認が容易になります。また、承認後でなければ変更適用できない、のようなワークフローも明瞭化しやすくなります。
履歴管理：gitのようなバージョンコントロールシステムを使うことで、現在のルールが過去どのような変遷を経てきたのかを追跡できるようになります。これにより、新しく参加したメンバーが変更の経緯を把握するのが容易になります。

これらは詳細なルールの容易とチーム内での徹底により、コード化しないでも同じような効果を得られます。しかしコード化することで大幅に工数を削減したり、メンバーの負荷を減らせることが期待されます。

(2) ルールの自動テスト

ルールを変更した際、そのルールが意図したとおりに機能するかを確認する必要があります。従来ではセキュリティ監視装置などに実際に新しいルールを適用し、検証のためのイベントや通信を実際に発生させるという方法しかありませんでした。また、監視装置の種類によっては複数のルールが互いに干渉しあうような設計（例えばルールのビルディングブロック化）になっており、変更が他のルールへの影響を及ぼさないかを確認する回帰テストも必要となります。これをすべて実機で実施するのは著しい工数になります。

検知や対応のルールをコード化し、その検知ロジックをソフトウェアとして実行できれば自動的にルールの変更をテストできるようになります。発生したイベントと期待される動作をテストケースとして定義しておけば、それを何度も再利用できるようになります。これによって変更したルールのテストが容易になるだけでなく、回帰テストも人間がやるのにくらべれば劇的に小さいコストで実施できるようになります。

(3) CI/CD の活用

変更したルールの適用もCI（Continuous Integration）やCD（Continuous Delivery）を利用します。Detection Engineeringの文脈では自動テストなど含めて変更が正しく適用できる状態にして、ボタンひとつで即座に適用可能な状況までにする、というようなものとイメージしてもらえれば良さそうです。

ポリシーの適用も手作業だと作業ミスに気をつけなければいけなかったり、作業自体の慣れが属人化を引き起こす場合があります。変更に対する心理的負荷を下げつつ、誰でも同じように変更適用ができるようにすることで、より運用を容易にしていくことができます。

“積極的なルール変更” の実現

コード化、自動テスト、CI/CDによる恩恵は「コストの削減」という側面ももちろんありますが、最も大きのは「積極的なルール変更」をしやすくなるということだと考えています。監視という領域にとどまらず、セキュリティを取り巻く状況は絶えず変化します。それは外敵の状況変化、内部の組織的な変化、そして利用しているサービスやプロダクトの変化など、様々な要素の変化がセキュリティおよび監視に影響します。

このように変化に伴ってルールを更新し常に最新の状況に保つ必要があります。コード化によって変化に伴うチーム内での知識の共有を容易にし、自動テストによって自信を持った変更ができるようになり、CI/CDによって変更の適用に対する心理的負荷を下げることができます。これらによってより効率的な監視が期待できるようになることこそが、Detection Engineeringの真髄ではないかと考えています。

UbieにおけるDetection Engineeringの構想

ではこのようなDetection EngineeringがUbieで実現できているのかというと、偉そうにいろいろ話しておきながらまさに今から取り組む状況、というのが正直なところです。もともとこれは私が2年ほど前にUbieに入社したあとすぐ取り掛かるつもりだったのですが、他に優先すべき課題が多くありそちらに時間を使っていました。しかし現状事業の方向性がある程度定まり、規模を拡大させていくなかでより堅牢なセキュリティ体制を作る機運がでてきました。セキュリティ監視体制もこの中に含まれており、Detection Engineeringを軸としてその体制を作ろうとしています。

もちろんこれまで監視に対して何もしていなかったわけではなく、従業員利用端末のEDRやクラウド上の監視サービス（Google CloudのSecurity Command Center）からのアラートを対応したり、社内利用している各種SaaSおよびクラウドインフラの監査ログなどを保存してインシデントが起きた際の調査ができるようにはしていました。しかしそれらはバラバラに運用されており、そららを連携して分析したり、監視体制を継続的に改善したりというような取り組みがあまりできていませんでした。

このような状況から、改めて脅威分析をしたうえで、必要なセキュリティ監視基盤を構築していこうとしています。

セキュリティ監視基盤の構成

実際の構築はこれからなのですが、上記のような構成を考えています。これはセキュリティ監視基盤の構成としては一般的なもので、大きく分けて次のような構成になっています。

ログの収集：各種サービスやプロダクトから提供される監査ログを収集します。サービスごとにログの提供方法は異なり、それぞれにあった収集方法を用意する必要があります。
ログ管理基盤：収集したログを利活用するための基盤となります。ログの保存や検索、分析などを行うための機能を提供します。ここからセキュリティ上の問題を検出し、アラートを発報します。
アラート対応基盤：発報されたアラートを対応するための基盤です。アラートの深刻度を判断したり、対応のためのワークフローを実行したりします。

これらは利用するサービス、プロダクトの選定や内製で構築する部分の組み合わせによって、実際の構成は異なります。そしてこれらを構成するに当たっていくつかの論点・課題があり、これを組織の状況や方針に合わせて解決していく必要があります。

セキュリティ監視基盤における課題

(1) セキュリティログの集約と保全

近年はクラウドインフラだけでなく、各種SaaSなどでも監査ログを提供してくれるようになりました。監査ログはセキュリティ監視にも有用で、これを集約して保全、利活用することには価値があります。

ログの集約：ログ自体を提供してくれるサービスは多いのですが、提供方法はサービスによって様々です。既に用意されている機能で分析＆検索基盤へ投入できるものもありますが、場合によっては収集のための仕組みを自作する必要があります。自作する仕組みが増えたり集約の方法が様々だと管理上のコストが上がってしまうため、うまく取りまとめるための仕組みを考えなければなりません。
ログの保全：セキュリティ関連のログは短期間のうちに分析や調査に利用されるのが主ですが、それとは別に過去に遡って保存しておきたいというユースケースもあります。これは長期に渡るインシデントが発覚した場合にいつから影響していたのかを調査したり、法令関連の対応したりするケースを想定したものです。基本的にログはデータ量が多く線形に保存する量が増えるため、長期間の保存が必要な場合はどのようにストレージへ保存するかなどを工夫・検討する必要があります。

(2) セキュリティログ分析＆検索基盤の構築

これは主に(1)とあわせてSIEM（Security Information Event Manager）の機能構築にあたります。集めた複数種類のログを組み合わせたり集計したりすることで、不審な事象を検出することを目的としています。さらに検索機能をもたせることで、探索的に脅威を探し出すThreat Huntingやインシデント発生時の影響範囲および原因調査にも利用できます。

SIEM自体は2010年以前にも相当するプロダクトがあり、それなりに成熟した分野ですでに多くのプロダクトやサービスが存在します。そのため既存のプロダクトやサービスを導入するのも良いのですが、いくつかの点で課題となるポイントがあります。

ログ流量の問題：ほとんどの既存SIEMプロダクト・サービスでは取り込むログの流量が金額に影響します。分析に利用するような監査ログ、ネットワークなどの低レベルなログ、端末ログなどは、多くの場合で大容量となります。これをすべて取り込もうとすると料金が爆発してしまい、すべてのログを入力するのは非現実的となるケースが多いです。これをいかにコストを抑えて効果を発揮するか、あるいは既存プロダクトを利用せずに基盤を構築するかで、技術的論点があります。
ログスキーマの問題：複数種類のログをあつかう上で避けられないのがログの種類ごとのスキーマの違いです。スキーマが異なると検索する際に指定するフィールドが統一されておらず煩わしくなりますが、一方で統一されたフォーマットに変換されると元のログのデータが失われてしまう場合もあります。検索だけでなくアラートの検出機能を考えた際、どのような形式でログを保管し活用できるようにするのかは検討すべき課題です。

(3) 検出したアラートの自動対応とポリシー管理

セキュリティ監視装置から発報されたアラートや、自分たちがログ分析をした結果として検出したアラートを対応するためのフレームワークの構築が必要です。このようなセキュリティ監視におけるワークフロー制御の機能は、一般的にはSOAR (Security Orchestration, Automation and Response）と呼ばれています。

柔軟なワークフローが組める：実行したいワークフローは組織ごとに異なること、さらに本番環境になんらかの影響を及ぼすワークフローについては実行・非実行についても精緻に制御できなければなりません。
入力できるデータに柔軟性がある：セキュリティ関連のアラートは、デファクトスタンダートとなる共通フォーマットが実質的にありません。そのため各製品から発報サれるアラートは独自のフォーマットとなっています。また、直接セキュリティと関係しないサービス・プロダクト（例えばIaaS）からのログを利用することもあります。そのため、それらを自由に取り込めるのが望ましいでしょう
ポリシーの履歴管理ができる：Gitなどで管理できる形式になっているのが望ましいですが、そうでなくてもどのポリシーがいつどのような理由で変更されたかを管理できることは、長期運用においてかなり重要です
ポリシーの回帰テストができる：当然ですが、ポリシーを変更したときに意図した通りに動くかを検証する必要があります。これを都度人手でやると工数が増えたり、変更に対する心理的障壁が高くなってしまいます。そのため回帰的にテストができ、CIでそのテストをパスした変更だけを本番に適用するようにすることで、積極的にポリシーを更新できます

SOARは2020年前後からプロダクトが現れ始めた、まだ比較的新しい領域です。現状だと自分は上記をみたす適切なプロダクトを見つけられなかったため、現状では内製したAlertChainというツールを運用しています。

詳細を説明するとあまりにも長くなってしまうので今回は割愛しますが、AlertChainは汎用ポリシー言語であるRegoによってワークフローを定義できます。アラート処理だけではなく、ワークフロー制御についてもテストができるようになっており、自動的にCIで回帰テストして異常があればデプロイできないようにしています。ポリシーもGitHub上で履歴管理しており、相互レビューができる状態になっています。AlertChainについても詳しく解説したいのですが、かなりの長編になってしまうため、これはまた改めて別の記事などを用意したいと思っています。

現状では

ポリシーに基づいたアラートの深刻度評価
ChatGPTを利用した要約の作成
GitHubの課題管理用リポジトリにIssueとして起票と通知

といったことに利用しています。なかでもChatGPTの要約作成は地味に便利で、多様なアラートがあるなかで調査する人の認知負荷をいくらか下げてくれています。

JSONで受け取ったGoogle CloudのSecurity Command CenterからのfindingをChatGPTに要約してもらった例

今後は以下のような、より高度な対応を組み込んでいきたいと考えています。

関係者の自動的な招集や対応開始のガイド
関連するプロダクトや社内サービスログの自動的な収集および分析
問題が発生した疑いのあるインスタンス等の自動バックアップ作成や切断

(4) 継続的な運用と検知・対応ポリシーの改善や民主化

最後に、検出したアラートを最終的にメンバーが対応する際のフローや体制、そしてそれを改善していくプロセスを作っていく必要があります。目先のアラートの対応も重要ですが、検知のルールなどを改善していかないと再現なく似た作業が必要になってしまいます。これはいわゆるSRE（Site Reliability Engineering）でいうところのtoilに近いと考えており、適切に削減していくことでさらなる改善や、別の施策に対して時間を使うことができるようになります。

またアラートの対応も、インフラや社内システムに関するものは専任のチームが担当する必要がありますが、プロダクトに直接関係するものや特定のビジネス領域に関連するものを扱う場合もあります。そういった場合はセキュリティチームが仲介になるだけではなく、それらを担当するチームが直接対応してもらえる体制に移行していくのが適切かと思います。そのためには様々な壁があると思いますが、それを乗り越えてスケーラブルなセキュリティ監視基盤にしていけると良いのではと考えています。

おわりに

先述した通りこの取り組みは今まさに始めた段階です。まだまだ課題は多く、これから様々なことを試行錯誤していく必要がありますが、技術的にも運用的にもチャレンジしがいのあるものだと考えています。

ちょうど先日、この課題に一緒に取り組んでいけるメンバーの募集も始めました。私のX（former Twitter）アカウント @m_mizutani でDMもオープンしていますので、興味のある方や、ちょっと話を聞いてみたいという方がいらっしゃいましたらぜひご連絡ください！

Enterprise Security Engineer - Ubie株式会社