前文
Detonateシリーズ の最初の投稿 では、Detonateシステムと、Elasticで使用しているものを紹介しました。 また、セキュリティ成果物のパフォーマンスを評価する際にチームにもたらす利点についても説明しました。
この出版物では、Detonateがどのように機能するかを分解し、技術的な実装について詳しく説明します。 これには、このサンドボックス環境を実際に作成する方法、パイプライン全体をサポートするテクノロジ、パイプラインに情報を送信したりパイプラインから情報を読み取ったりする方法が含まれます。
Detonateの他の投稿に興味がありますか? パート 1 をチェック - クリック、クリック...ブーム！ Detonateを紹介し、なぜそれを作ったのか、Detonateがどのように機能するかを探り、ケーススタディを説明し、有効性テストについて話し合います。
アーキテクチャー
以下は、Detonate のエンドツーエンド アーキテクチャの概要です。
システム全体は、一連のメッセージキューとPythonワーカーで構成されています。 デトネーションタスクは、サンプルファイルのハッシュと同じくらい少ない情報でリクエストを受け入れると、APIサーバーによって作成されます。 その後、タスクはキューからキューへと移動し、途中でさまざまな操作を実行するワーカーによって選択されます。
サーバーとワーカーは 、Amazon ECS のコンテナで実行されます。 パイプラインは、 Docker Compose を使用してローカルで起動し、早期の開発と機能テストを行うこともできます。
API サーバ
Detonate APIサーバーは、サンプルのハッシュ、ネイティブコマンド(bashまたはPowershellで、引数の有無にかかわらず)、アップロードされたファイルなど、さまざまな実行ターゲットリクエストを受け入れる FastAPI Pythonアプリケーションです。 また、このサーバーは、Elastic クラスターからアラートと raw エージェント テレメトリをフェッチするためのエンドポイントも公開します。
APIドキュメンテーションはFastAPIによって 自動的に 生成され、グローバルAPIスキーマに組み込まれます。
API サーバーとの対話 - CLI
Detonateサーバーと対話するためのカスタムPython CLI(コマンドラインインターフェイス)ツールを構築しました。 CLIツールは、Pythonライブラリを使用して構築されており、ターミナルウィンドウで美しいフォーマットエクスペリエンスを実現するために 、リッチ と一緒に クリック します。このツールは、ローカル パイプライン設定に対しても実行できるため、パイプラインのデバッグに特に役立ちます。 このツールは、依存関係の管理とスクリプトの実行に最適なツールである Poetryを使用してインストールおよび実行されます。
❯ DETONATE_CLI_API_ROOT_URL="${API_ENDPOINT_URL}" \
DETONATE_CLI_API_AUTH_HEADER="${API_KEY}" \
poetry run cli \
--hash "${MY_FILE_HASH}"API サーバーとの対話 - Web UI
社内では、Protections Portalというサイト( Elastic UI コンポーネントを使用して作成)をホストし、チームの研究を支援しています。 Detonate API をよりインタラクティブに体験するために、ポータルに操作用のページを作成しました。 タスクの送信に加えて、Web UIを使用すると、ユーザーはすべての爆発のフィードと各タスクの詳細を確認できます。
各タスクを展開して、その完全な詳細を表示できます。 爆発中に収集されたデータとテレメトリへのリンクを提供します。
API サーバーとの対話 - HTTP クライアント
ユーザーがDetonate APIとの対話方法をカスタマイズしたい場合は、選択したHTTPクライアント( curl 、 httpie など)を使用してコマンドを実行することもできます。 これにより、スクリプトにデトネーションを追加したり、自分のワークフローの最後に最終ステップとして追加したりできます。
Queues
パイプラインは、一連のキューとワーカーに基づいて構築されています。 メッセージキューエンジンの非常に基本的な要件があるため、 Amazon SQSを使用することにしました。 SQSのような人気のあるサービスを利用する多くの利点の1つは、オープンソースのリソースとライブラリを利用できることです。 たとえば、パイプラインをローカルで実行するときに、 softwaremill/elasticmq Dockerイメージをキューエンジンとして使用します。
キューは、すべての運用インフラストラクチャとステージング インフラストラクチャをカバーする Terraform コードを使用して構成およびデプロイされます。
勤務者
各ワーカーは、キュー コンシューマとキュー プロデューサの両方として機能する Python スクリプトです。 ワーカーはカスタムミニフレームワークに実装され、エラー処理、再試行、監視の定型コードが組み込まれています。 当社のベースワーカーは簡単に拡張できるため、追加の要件が発生した場合に新しいワーカーを追加したり、既存のワーカーを進化させたりすることができます。
監視には、 Elastic APM オブザーバビリティソリューションを使用しています。 これは非常に強力で、実行フローのビューを提供し、パイプラインの問題のデバッグを簡単にします。 以下に、APM UIのワーカー間でのDetonateタスクの移動を示します。
これらのソフトウェアとインフラストラクチャコンポーネントは、デトネーションを構成するサブミッション、実行、データ収集を実行するために必要なすべてを提供します。
デトネーション
パイプラインは、Windows、Linux、macOS の仮想マシン (VM) でコマンドとサンプルを実行できます。 Windows および Linux 環境では、 Google Compute Engine の VM インスタンスを使用します。 パブリックイメージの選択肢が豊富なため、Windows、Debian、Ubuntu、CentOS、RHELの異なるバージョンでサンドボックス環境をプロビジョニングできます。
macOS環境では、 AWSのmac1.metalインスタンス と、 VeertuのオンデマンドmacOS仮想マシンプロビジョニングソリューションであるAnkaを使用します。 Ankaを使用すると、同じmacOSベアメタルインスタンスで実行されている複数のmacOSVMをすばやくローテーションできます。
Detonate は現在、OS のカバレッジの幅広さ、スケーラビリティ、パイプラインからのコンテキスト関連データの収集に重点を置いています。 Detonateへの高度な分析防止対策の搭載については、現在研究・開発が進められています。
VM のプロビジョニング
VM のフットプリントを最小限に抑えるために、プロビジョニングにスタートアップ スクリプトを使用します。 VM 内のアクティビティは収集するイベントに含まれ、実行後の分析がより複雑になるため、フットプリントを最小限に抑えることが重要です。 Windows VM と Linux VM の場合、Powershell と bash で記述された GCP スタートアップ スクリプト を使用してシステムを構成します。macOS VM の場合、カスタムの bash スクリプトと AppleScript スクリプトを記述しました。
スタートアップ スクリプトは、次の手順を実行します。
- システムを設定します。 たとえば、MS Defenderを無効にする、MS Officeでマクロの実行を有効にする、システムの自動更新を無効にするなどです。
- Elastic エージェントをダウンロードしてインストールします。 このスクリプトは、エージェントが フリートサーバーに適切に登録されている こと、およびポリシーが適用されていることを確認します。
- サンプルをダウンロードして爆発させるか、一連のコマンドを実行します。 実行はバックグラウンドプロセスで行われ、メインスクリプトはSTDOUT / STDERRデータストリームを収集し、N秒間スリープします。
- ファイルシステムからファイルを収集し(必要な場合)、ストレージにアップロードします。 これにより、爆発が完了した後に追加の検証やデバッグを行うことができます。
VM のライフサイクルは、 start_vm ワーカーと stop_vm ワーカーによって管理されます。 ランサムウェアの場合など、スタートアップスクリプトの実行フローを壊すような爆発が発生することが予想されるため、すべてのVMにはTTLが設定されており、 これによりstop_vm ワーカーは使用されていないVMを削除することができます。
この白紙の状態からのアプローチと、デトネーションに必要なすべての構成に使用されるスタートアップ スクリプトにより、Google Cloud の公開イメージ カタログのベンダーの VM イメージを変更せずに使用できます。
ネットワーク構成
デトネントするサンプルの中には悪意のあるものもあり、ネットワークスキャンやC2コールアウトなど、悪意のあるトラフィックを生成する可能性があります。 クラウドリソースとベンダーのインフラストラクチャを安全に保つために、VMからの送信トラフィックをすべて制限しています。 インスタンスはロックダウンされた VPC に配置され、事前定義されたターゲットのリストへの送信接続のみが許可されます。 VPC 内のトラフィックフローは、Google Cloud の ルート と ファイアウォールルール、および AWS のセキュリティグループを使用して制限します。
また、GCEの VPCフローログ も利用しています。 これらのログにより、VPC 内のサンドボックス VM によって開始されたプライベートネットワークトラフィックを確認できます。
テレメトリ コレクション
爆発を観察するために、 Elastic Agent と Elastic Defence の統合が、すべての保護が「Protect」モード(「Protect」ではなく)でインストールされています。 これにより、VMからできるだけ多くの情報を収集できると同時に、 Elasticセキュリティ ソリューションでアラートと検出を生成できます。
このアーキテクチャでは、保護の検証(異なるOSバージョン、エージェントのバージョン、デプロイされたセキュリティアーティファクトなどに対して生成されたイベントとアラートの比較)と、分析のためのテレメトリの収集(新しいサンプルまたは新しいマルウェア)の2つのユースケースをカバーしています。 収集されたすべてのデータは永続的なElasticクラスターに保存され、Elasticの研究者が利用できます。
本番環境での実行
最近、私たちは、複数のデータ統合の負荷の下で、本番環境でDetonateパイプラインを丸1か月実行し、UIを通じて内部ユーザーに同時にサービスを提供しました。 これまでの記録は1日で 1034 回の爆発であり、これまでのところ、スケーラビリティや信頼性の問題は見られません。
現時点では、提出物の大部分は Windows 固有のサンプルです。 私たちはLinuxとmacOSのカバレッジを拡大することにも取り組んでいますので、近日公開予定の研究ブログ投稿にご期待ください。
さまざまなファイルタイプのサポートを常に改善しており、デトネーションが意図したトリガー動作にできるだけ近づくようにしています。
先月の爆発を見ると、ほとんどのタスクが 13 分以内に完了していることがわかります(中央値は 515 秒)。 この時間には、タスク データの準備、VM のプロビジョニングとクリーンアップ、サンプルの実行、および爆発後の処理が含まれます。
これらはまだサービスの初期段階であるため、外れ値が表示されるのは正常です。 タスクのほとんどの時間は VM のプロビジョニングを待つのに費やされるため、カスタム VM イメージを使用し、VM インスタンスを事前に開始し、スタートアップ スクリプトを最適化することで、全体的な実行時間を改善できます。
次のステップ
Detonateがどのように機能するかがわかったところで、次の投稿ではDetonateのより詳細な使用例について詳しく説明します。 これらの爆発が、Elasticを含むより多くのユーザーを保護する方法に変わる方法について、さらに詳しく説明します。