1 AWS事業本部　コンサルティング部 菊池　聡規 GuardDutyとSysdigのランタイムセキュリティ 機能を比較してみる

● 【名前】 菊池 聡規 ● 【所属】 AWS 事業本部 コンサルティング部 ● 【キャリア】 金融機関向けオンプレのインフラエンジニア１０年ほど→ 自社Webサービスをもつ企業で３年ほど→ クラスメソッドにジョイン ● 【Blog】 https://dev.classmethod.jp/author/tooti/ ● 【好きなAWSサービス】 Amazon EventBridge, AWS Step Functions, ECS 2 自己紹介

1. はじめに 2. 通知速度 3. コスト比較 4. 検知ルールとカスタマイズ 5. セットアップの簡便さ 6. まとめ 3 アジェンダ

4 前提 ● 前提 ○ ECS Fargate環境を前提とします ○ ランタイムセキュリティ機能に絞って話します ○ サービスの比較になりますが、どちらかのサービスを貶す意図はないです。どちらも 良いサービスです

5 1. はじめに - ランタイムセキュリティの役割 ● そもそもランタイムセキュリティとは？ ○ 実行中のコンテナを保護すること ○ コンテナ上の怪しい振る舞いを検出する等の方法で実現 ○ 例えば以下のような攻撃を防げる ■ コンテナ内に含まれたマルウェアによる攻撃 ■ コンテナイメージに含まれる脆弱性を利用した攻撃 ○ コンテナに含まれる脆弱性はビルド時にもチェックするがゼロデイ脆弱性等、ビルド 時に洗い出せないものも→いわば最後の防衛線

6 1. はじめに - GuardDutyとSysdigの概要 ● GuardDuty ○ AWS環境に対する脅威検出サービス ○ 2023/11アップデートにてECSに対するRuntime Monitoringが追加 ● Sysdig ○ コンテナ、Kubernetes、クラウド環境向けセキュリティ

7 2. 通知速度 ● GuardDutyでの通知 ○ GuardDutyで発生したイベントは Amazon EventBridgeに送信される ○ 発見から５分以内に通知を送信 ○ 同一ECSタスク内で複数回攻撃が発生 しても最初の５分間に発生したイベント はすべて一つの通知に集約される ○ 異なるECSタスクで発生した場合は別イ ベントとしてカウント

8 2. 通知速度 ● GuardDutyでの通知 ○ 攻撃発生時のタイムライン例　 発生時刻 内容 3:13:34 タスクAで暗号通貨関連のドメイン名に対して nslookup実施 3:13:40 タスクBで暗号通貨関連のドメイン名に対して nslookup実施 3:15:50 GuardDutyにタスクAのイベント作成 3:15:50 GuardDutyにタスクAのイベント作成 3:20:03 Amazon EventBridgeからトリガーされる処理が開始 3:20:07 Amazon EventBridgeからトリガーされる処理が開始

9 2. 通知速度 ● Sysdigでの通知 ○ Notification ChannelsとEvent Forwardingの２種類のイベント送信方 法が存在 ○ Notification Channelsはポリシーに対して設定し、指定したポリシー違反 があった際にSlack,Email,Amazon SNSなどにイベント送信 ■ Notification Channelsは何かが起きていることを把握する目的のもの であるため同時タイミングのイベント等はミュートされる ○ Event ForwardingはAWS等のクラウドアカウントやコンテナで発生したポ リシー違反等のセキュリティイベントをElasticsearchやAmazon SQS, Splunk等に転送する機能 ■ こちらは発生した全イベントを送信

10 2. 通知速度 ● Event Forwardingの送信イメージ

11 2. 通知速度 ● Sysdigでの通知 ○ 攻撃発生時のタイムライン例（Event Forwarding） 発生時刻 内容 19:53:18 タスクAで不審なネットワークツール (ncat)実行(※1) 19:53:23 タスクAで不審なネットワークツール (ncat)実行(※2) 19:53:42 SQSからLambdaが起動(※1) 19:54:08 SQSからLambdaが起動(※2)

12 3. コスト比較 ● GuardDuty ランタイムモニタリングの価格モデル※ ○ エージェントが保護するタスクのvCPU数に応じて課金 ■ 月最初の500vCPUまで：1vCPUあたり2.00USD/月 ■ 500vCPU以上、4500vCPUまで：1vCPUあたり1.00USD/月 ■ GuardDutyのVPCエンドポイントが作成されるがこちらは無料 ■ 2vCPU使うタスクが10個の条件で試算すると ➢ 2vCPU * 10台 * 2USD = 40USD/月 ※最新の情報や詳細についてはAWS公式ページをご参照ください https://aws.amazon.com/jp/guardduty/pricing/

13 3. コスト比較 ● Sysdigの価格モデル※ ○ ECS Fargateでランタイムセキュリティを使いたいときは「Secure Workload Sec CaaS」ライセンスを購入すればOK ○ ECS Fargateの1タスク毎に月額12USD ○ １タスク毎に１ヶ月あたり720時間を超えて使用すると追加で料金がかかる ■ Additional usage fee for Secure Workload Security CaaS：0.03USD/h ○ その他、オーケストレータ（ECS,NLB）の料金がかかる ■ おおよそ、月200USD~250USD程度 ■ 2vCPU使うタスクが10個の条件で試算すると ➢ 10タスク * 12USD + 250USD = 370USD ※最新の情報や詳細については 以下ページをご参照ください https://aws.amazon.com/marketplace/pp/prodview-p4hagtkrkpgbw?sr=0-1&ref_=beagle&applicationId=AWSMPContes sa

14 4. 検知ルールとカスタマイズ ● GuardDutyランタイムモニタリングの検知ルール ○ ルール数は2/16時点で31 ■ 暗号通貨関連や既知のC&Cサーバへの通信 ■ Torネットワークへの接続 ■ 既知の悪用ドメインへの通信 ■ リバースシェルなどなど ○ カスタマイズは不可 ○ 不要なルールは基本的には抑制ルール（属性名と値の組み 合わせでフィルタ）で制御 ○ 詳細な検知条件はブラックボックス（例えば既知の悪用ドメイ ンが何かまでは分からない）

15 4. 検知ルールとカスタマイズ ● Sysdigの検知ルール ○ ルール数は2/16時点でWorkloadカテゴリだけでも100以上 ■ 各ルールには種別を示すタグが複数ついている ➢ 例えばCISベンチマークやMITRE ATT&CKになどのセキュリティ標準に準 拠したルールにはそれを示すタグがつく ➢ その他のタグとしてはnetwork, fileなど挙動を表すタグ等 ○ カスタマイズが柔軟 ■ 複数ルールを束ねたものがポリシーとして存在、ポリシー内の各ルール毎に有 効無効を設定可能 ■ ３種類のポリシー種別がありカスタムポリシーという種別ではルールの組み合 わせを自由に設定、マネージドポリシーでは自動でルールがupdate ■ 各ルールはFalcoルールという書式で書かれており、ユーザが独自のルールを 作ることも可能 ○ 詳細な検知条件までわかる

16 4. 検知ルールとカスタマイズ ● Sysdigの検知ルール

17 4. 検知ルールとカスタマイズ ● Sysdigの検知ルール

18 5. セットアップの簡便さ ● GuardDutyのセットアップ ○ めちゃくちゃ簡単

19 5. セットアップの簡便さ ● GuardDutyのセットアップ

20 5. セットアップの簡便さ ● Sysdigのセットアップ ○ オーケストレータエージェントとワークロードエージェントを作る 必要あり ○ それぞれTerraformとCloudFormationが用意されている

21 簡単、簡単☆ミ

22 5. セットアップの簡便さ

23 6. まとめ ● まとめ ○ それぞれに特徴があるので要件に合ったものを使おう！ 項目 GuardDuty Sysdig 検知速度 △ ◯ コスト ◎ ◯ ルール数とカスタマイズ ◯ ◎ セットアップの容易さ ◎ ◯

24