OPA/Regoの応用（SOAR: Security Orchestration, Automation and Response）

この記事はOPA/Regoアドベントカレンダーの24日目です。

本日は前回に引き続き、OPA/Regoによる応用がテーマです。今回はセキュリティ監視・対応の運用を自動化する Security Orchestration, Automation and Response (SOAR) にOPA/Regoを組み込む可能性について議論します。こちらも実装を形にしつつはあるのですがまだ不十分なこともあり、今回は構想について紹介するにとどめたいと思います。

SOARとは

単語としてはGartnerが2017年くらいから言い始めた単語で、セキュリティ監視によって得られたアラートを自動的に評価・対応するためのフレームワークや製品を指しています。筆者が以前に登壇で使った資料にも説明を記載していますので、興味ある方はご参照ください。

https://speakerdeck.com/mizutani/soar-and-secops?slide=8

セキュリティのアラートとは、例えばエンドポイントセキュリティやネットワーク監視装置、あるいは近年だとクラウドプロバイダが提供する監視サービス（AWS：GuardDuty、GCP：Security Command Center）などが「セキュリティ侵害に関連しそうなイベント」として報告してくるもの^[1]を指します。SOARはこのアラート（の一部）を自動的に対応し、セキュリティ監視業務を効率化するのが目的です。GoogleのSecurity Operation Center（SOC）のチームが発行しているドキュメントにも「SOARのようなツールを使ってプロセスを自動化することで、対処のスピードが上がるだけではなく対応の一貫性の向上やトレーサビリティの向上、監査可能性の向上が見込まれる」として、自動化の重要性が説明されています。

SOARには大きく分けて3つの役割があると考えています。

• 情報の補完（Enrich）: セキュリティアラートは装置やサービスが監視できている範囲の情報を元に検知、発報します。そのためアラートによって伝えられる情報は限定的であり、組織内の別の装置・サービスから得られた情報をもとに関連情報を補完する必要があります^[2]。また組織外から必要に応じてOpen-source intelligence (OSINT) 情報を得る場合もあります。
• 評価（Evaluation）: 情報の補完されたアラートを見てリスクを評価します。そのアラートは誤検知ではなく本当に発生したインシデントを示しているのか、インシデントだとして影響度や影響範囲はどこかを判断します。
• 対応（Remediation）: 影響があると判断した場合はIncident Response (IR) が必要となります。実際のIRは非常に複雑かつケースごとにやるべきことが大きく異なるため、全てを自動化するのはさすがに困難です。しかし初動対応として必要な暫定的な復旧や対処（例えば侵入されたと考えられるサーバを一時的に外部から遮断するなど）はおおよそやるべきことが決まっており、手順化しやすく自動化と相性が良いと考えられます。

これらのステップの全体、あるいは一部だけでも必要に応じて自動化するための仕組みがSOARになります。

SOARにおける課題：自由度が高く運用しやすいポリシー

SOARの自動化による恩恵を受けるためには、いくつか乗り越えないといけない壁があります。そのうちの一つがワークフローやルールをどのように管理・運用するかという点です。

• ワークフロー: 受け付けたセキュリティアラートをどのように補完、評価、対応するかという順序を表したものです
• ルール: 評価において、受け付けた（そして補完された）セキュリティアラートは影響があったのか、あったとしてどのくらいの影響範囲なのか、ということを判断するためのポリシーです

便宜上、この2つをまとめて「ポリシー」と呼びます。このポリシーは組織によって異なるため、ほぼカスタマイズが必要です。例えば組織ごとに運用しているシステムやサービスが違うと補完において収集すべき情報も異なります。また対応もどのような環境を持っているのかによってGCPのインスタンスとAWSのインスタンス、どちらを遮断するのか？のような違いが生まれます。これによってワークフローも使う・使わない、使うならどう使うか、というようなポイントを組織ごとに考えなければなりません。

ルールはさらに組織ごとの違いがでます。事業体制、目標、会社としてのフェイズ、リスクに対するスタンス、設備の差異など、完全に同一の環境というのは存在し得ず、ポリシーは組織ごとにカスタマイズする必要があります。

このポリシーのカスタマイズは既存のSOARだと大きく分けて 1) GUIによるポリシーのカスタマイズ（例：swimlane, splunk）、2) 一般的なプログラミング言語によるポリシー記述（例：Microsoft sentinel）の2つのアプローチがあると認識しています。それぞれにメリットがある一方、課題も抱えていると考えています^[3]。

GUIによるポリシーのカスタマイズ

GUIの画面を見てワークフローやルールをカスタマイズする方法です。グラフィカルにワークフローなどを操作することができるため、ロジックなども直感的に理解できます。コード的に入力する箇所もまれにありますが、必要最低限になっています。これによってプログラミングに馴染みがないメンバーでも小規模なポリシーであれば少ない学習コストで操作できるというメリットがあります。

一方で大規模に運用する場合は様々な弊害があります。

まずPolicy as Codeが持つ以下のようなメリットをほとんど受けることができません。

• テストの自動化
• バージョン管理やレビュー
• デプロイ自動化

そのため規模が大きくなるとどのルール同士が相互作用しているのかがわかりづらくなり、ポリシーの追加や変更が難しくなっていきます。さらにバージョン管理の機能や変更差分確認などの機能がほとんど実装されていないので、誰がどのような意図でその変更を残したのかわからず、「よくわからないけど残っている」ようなロジックが各所に現れます^[4]。そして本番環境へのデプロイも手動で実施しなければいけない場合が多く、ミスが発生しがちになります。

このように規模に応じて運用負荷が指数関数的に上がっていく傾向があり、徐々にSOARの利用が鈍化していく恐れがあります。

また Policy as Code の問題とは別に、表現力に制限があるという課題もあります。判定の条件に使える評価方法がイコールとノットイコールしかない、というような実装だと「配列に含まれている」、「キーと値が同時に一致する」というような条件を記述できない、ということが起こりがちです。そういった点から個人的にGUIによるポリシーの運用は消耗が大きいと考えています。

一般的なプログラミング言語によるポリシー記述

このようなGUIでのポリシー管理に対抗する手法として、一般的なプログラミング言語を用いてポリシーを記述するという方法が近年出現してきたと感じています。代表的なのがMicrosoft Sentinelかと思っていて、こちらはJupyter Notebookでアラートへの対応をplaybookとして記述することができ、実質ワークフローとルールを両方表現できる形になっています。コードの実行環境も選べる（ローカル環境でも再現できる）ようなので、Policy as Codeの恩恵を十全に受けることができます。また自由にアルゴリズムを記述できるため、表現力の点からも問題はありません。

筆者も以前はこのような考えに基づき、主にGo言語で記述するサーバーレス型のSOARを作って運用していました。

https://github.com/cookpad/deepalert

しかしこれも実用の観点からはいくらか問題があると感じていました。主な問題は ポリシーとデータ処理の境目が分かりづらい という点です。コーディング上の整理で一定分離するようにしているものの、やはりデータ処理および関連する処理とポリシー（特に評価のためのルール）が混ざってしまいがちになっていました。特に途中でデータ加工を混ぜると境が曖昧になってしまい、どこからがポリシーでどこからが手続き的な処理なのか分かりにくくなってしまいます。

これはコード整理の上で問題になるのと同時に、コーディングなどの経験は浅いがポリシーの記述にだけ集中したいメンバーの参加を阻む、という問題にもつながっていると感じていました。そのプログラミング言語に馴染みがあれば境界を判断できたり、コーディング制約（例えば階層型アーキテクチャのような概念）を工夫できていればうまくできたのかもしれませんが、何かべつのアプローチがあると良いかなと考えていました。

OPA + SOARの可能性

そこで思い至ったのがSOARのポリシーと実装をOPAを使って分離する、というアプローチです。

ここまでOPA/Regoについて調べてきた結果、以下のようなデータはOPA/Regoで判定するのに相性がよいと言えます。

• 状態を持たないで判定できるデータ: OPA自体は1回の入力に対して1つの出力をするため、過去の状態と照らし合わせながら判定をする、というような性質のデータとは相性がよくありません。しかしセキュリティアラートは基本的に単体で出力されてくる^[5]ものであるため、OPAでの判定はやりやすいと考えられます。
• 一度にまとめて送られてくるデータ: 細切れで入力されたデータをまとめるというのはOPAが苦手とするところです。例えばdata（basic document）を更新しつつ最終的にinputを投げ込む、ということで理屈上は細切れにデータを入力できますが、同期をとるのが難しく現実的ではありません。しかしSOARはAlertとして一定固められたデータとして取り扱えるので、これについても相性が良いと言えます。

という観点からOPAとSOARをどのように統合するか、というアーキテクチャを考えてみたのが以下の図になります。

基本的な動作は前述したとおりで、SOARが受け取ったセキュリティアラートを補完（Enrich）、評価（Evaluation）、対応（Remediation）の順番で処理していきます。それぞれのフェーズでOPAがどのような判断をできそうかについて説明したいと思います。

補完（Enrich）

別のデータソースに対して関連する情報を問い合わせる際に考えなければいけないことは「どの情報をどこに問い合わせるか」になります。闇雲にすべての情報を問い合わせると流量過多になってしまいます。特にOSINTなどで使うようなデータソースは問い合わせ回数の制限が厳しかったりするため、問い合わせ対象をある程度選ぶ必要があります。また、内部情報に関連するようなものを無闇に外部に問い合わせると、情報流出につながってしまう恐れもあります（例：VirusTotalのようなサイトに内部向けのファイルを送信してしまう、など）

ある対象（例：IPアドレス、ドメイン名、ハッシュ値、メールアドレス、などなど）について問い合わせるかどうかをOPA/Regoで判断させるのは役割として適していると考えられます。例えばこのサービスからのアラートには内部情報が含まれる可能性があるので問い合わせない、このアラートについては外部関連の情報しか乗らないのでひとまず問い合わせる、この項目は問い合わせてもあまり意味がないので抑制する、などの判断ができます。

また、Enrichの際には再帰的な問い合わせをしたい場合もあります。問い合わせ先から入手した情報を元に、さらに別のデータソースへ問い合わせるといったケースです。しかしすべてを再帰的に処理すると何度再帰処理すればいいのかわからないですし、問い合わせ数も指数関数的に増えてしまいます。これを抑制するためにOPA/Regoで判定をして必要最低限だけ再帰的な問い合わせをするといった制御も可能ではないかと考えられます。

評価（Evaluation）

評価はOPA/Regoによる判定処理の本懐です。元のセキュリティアラートにあった情報、および補完（Enrich）された情報を元にそのアラートによる影響があったのか否かを判定するポリシーはRegoによって記述できます。

もちろん、すべてのアラートについて判定できるわけではなく、未知のアラートについては「判定不能」とするしかありません。しかしこの段階で大部分のFalse positiveの処理を中断できれば、セキュリティチームのメンバーが無駄に呼び出される回数は必ず減ると考えられます。また、明らかに影響があったと判定された場合に直ちにセキュリティチームを（どんな手段を使っても）呼び出したり、この後の対応フェイズで急ぎの処理をする、という判断もできるようになります。

対応（Remediation）

評価ではあくまで影響の有無を判定しているため、どのような対応をとるべきかもまたOPA/Regoで表されるとよいのでは、と考えています。例えば影響ありなアラートにEC2インスタンスのID情報が含まれていたとしても、それをシャットダウンすればいいのか、バックアップを取得すればいいのか、ネットワークから遮断すればいいのか、あるいはそのインスタンスは直接的には関係ない監視元のインスタンスを表していたのか、などがわからないと対応のしようがありません。

このような判断は評価とともに出力されるというのも一つのアプローチなので、評価と対応で分離する必要があるかについては議論が必要だと考えています。しかし、対応の指定をOPA側に任せることで何をするべきかということもポリシーとして記述できるようになります。対応は特に影響が大きいため、「このようなアラートがきたらこう対応する」というテストを自動でできるようになることで、積極的に対応を追加・変更していけるようになり、セキュリティ監視が捗ることが期待されます。

まとめ

今回はまだ実装ができていない、SOAR + OPAの構想に関する紹介でした。抽象的な話になってしまいセキュリティ監視に馴染みにない方には掴みどころがない話になってしまったかもしれません。ただ、このフレームワーク、ないしソフトウェアについてはこれからぜひ実装していきたいと考えています。

まだ構想も考えている途中なので、もし興味を持った方や同じような課題感を持っている方からのご意見などあれば聞いてみたいと考えています。あるいは一緒にやっていきたいというような機運がある方がいれば、ぜひお声がけください。

脚注

1. これらの装置・サービスから直接ではなくSIEM（Security Information and Event Manager) を経由する場合もあります

2. これについてはSIEMを使っている場合、組織内の全ログなどが集約できていると仮定すると

3. 公開されている範囲の資料を自分なりに見た範囲での判断なので、もし実態と異なるなどをご存じの方がいたらぜひ教えて下さい

4. もちろんこういった変更管理は古の現場だとスプレッドシートなどを使って手動で取り組まれてきましたが、運用の負荷が高く、また記載ミスも起こりがちです

5. 検知においては状態を保持するような手法は多く存在します。（例：パスワード総当たり攻撃の検知）逆に言うと状態はSOARに入る前の段階までしか持たないため、SOAR内部で状態を管理する必要はあまりありません