EKSにおけるGuardDutyとFalcoの比較

By 清水 孝郎 - DECEMBER 7, 2022
Topics: オープンソース, クラウド セキュリティ, コンテナ、Kubernetes、ホストのセキュリティ

SHARE:

本文の内容は、2022年12月6日に NIGEL DOUGLAS が投稿したブログ（https://sysdig.com/blog/guardduty-falco-eks-detection/)を元に日本語に翻訳・再構成した内容となっております。

AWSのようなクラウドプロバイダーでは、通常、セキュリティが最優先されます。EKSでは、bring-your-ownのバニラKubernetesインスタンスとは異なり、最もセキュリティに敏感な組織の要件を満たすように構築されたデータセンターとネットワークアーキテクチャーの恩恵を受けることができます。これを実現するためには、私たちが持つことのできるすべてのセキュリティレイヤーを使用することが最良の方法の1つです。今回は、GuardDutyとFalcoを使用して脅威の検知を高速化する方法を説明します。ただし、セキュリティはお客様とAWSの間で責任を共有するものです。責任共有モデルでは、これを「クラウドのセキュリティ」と「クラウド内のセキュリティ」と表現しています。AWSは、EKSのようなAWSクラウド内で運用されるAWSサービスを動かすインフラストラクチャーを保護する責任がある。一方、お客様の責任には以下のような領域があります。

  • ノードやコンテナ自体の構成
  • ファイアウォールルールなどのネットワーク制御の設定と管理
  • プラットフォームレベルのアイデンティティとアクセス管理の管理（IAMを使用するか、IAMに加えて使用する）

データの機密性、企業の要件、適用される法律や規制は、責任共有モデルの一環としてエンドユーザーによって管理されます。GuardDutyのようなAWS上のマネージドサービス、またはFalcoのようなオープンソースのセキュリティソリューションのいずれかを通じてこれを実現することができます。このブログでは、Amazon EKS上のGuardDutyとFalcoの違いを詳しく説明し、それぞれのツールが何をしてくれるのか、どんな脅威が検出され、さらなるフォレンジック分析のためにどんなメタデータが返されるのかをより理解できるようにします。

クラウドの中にランタイムセキュリティを追加するFalcoプラグイン

クラウドネイティブのランタイムセキュリティプロジェクトであるFalcoは、デファクトのKubernetes脅威検出エンジンです。Falcoは、お客様のアプリケーションやコンテナの挙動を観察することで、ランタイムに脅威を検知します。Falcoは、Falco Pluginsにより、クラウド環境（AWSなど）にまたがる脅威検知へ拡張することができます。Falcoがクラスター内で動作するコンテナからシステムコールを取り込む（コンテナ自体に対する悪意のある活動を検知する）機能とは異なり、GuardDutyは現在、クラスターのKubernetes Control Planeに対する活動に対してのみアラートを発しています。コントロールプレーンと言っても、その能力は誇張されすぎています。GuardDutyは、コントロールプレーンノード（複数可）における脅威の総合的な検知や、コントロールプレーンに対する特別な機能を提供しているわけではありません。今回は、GuardDutyがコンテナ固有のイベントを可視化できないシナリオとして、以下の2つのコンテナ固有のFalcoのルールに焦点を当てます。

コンテナドリフト検知

Amazon EKSは、Elastic Container Registry（ECR）のようなサービスを提供し、イメージがランタイムにデプロイされる前に安全にスキャンされ、吟味されることを保証しています。しかし、本番環境で実行中のコンテナに変更が加えられないようにするには、どうすればよいでしょうか？GuardDutyは実行中のコンテナからすべてのシステムコールを収集するわけではなく、Kubernetesコントロールプレーンのアクティビティに焦点を当てるため、コンテナ内で新しい実行ファイルを生成するためにchmodが使用された以下のようなケースを検出するための助けが必要になるでしょう。

- rule: Container Drift Detected (chmod)
  desc: New executable created in a container due to chmod
  condition: >
    chmod and consider_all_chmods and container and not
    runc_writing_var_lib_docker and not user_known_container_drift_activities
    and evt.rawres>=0 and ((evt.arg.mode contains "S_IXUSR") or (evt.arg.mode
    contains "S_IXGRP") or (evt.arg.mode contains "S_IXOTH"))
  output: >-
    Drift detected (chmod), new executable created in a container
    (user.name=%user.name user.loginuid=%user.loginuid
    proc.cmdline=%proc.cmdline filename=%evt.arg.filename name=%evt.arg.name
    mode=%evt.arg.mode evt.res=%evt.res proc.pid=%proc.pid proc.cwd=%proc.cwd
    proc.ppid=%proc.ppid proc.pcmdline=%proc.pcmdline proc.sid=%proc.sid
    proc.exepath=%proc.exepath user.uid=%user.uid user.loginname=%user.loginname
    group.gid=%group.gid group.name=%group.name container.id=%container.id
    container.name=%container.name evt.type=%evt.type
  priority: error
  source: syscall
...

コンテナからEC2インスタンスのメタデータサービスに問い合わせる

syscallアクティビティのもう1つの強固なユースケースは、実行中のコンテナが潜在的にデータ漏洩を実行しているかどうかを確認する能力です。実行中のコンテナからのsyscallを監視することで、コンテナがEKSクラスター内のコンテナが実行されているEC2インスタンスに到達しているかどうかを確認することができます。EC2メタデータサービスに対して、EC2インスタンスに関する詳細な情報（ホストに割り当てられているタグ、ホストのIPアドレス、そのインスタンス/ホストのVPC（仮想プライベートクラウド）トラフィックを制御するためのセキュリティグループなど）を問い合わせることができます。

- rule: Contact EC2 Instance Metadata Service From Container
  desc: >-
    Detect attempts to contact the EC2 Instance Metadata Service from a
    Container
  condition: >-
    outbound and fd.sip="169.254.169.254" and container and not
    Ec2_metadata_containers
  output: >-
    Outbound connection to EC2 instance metadata service
    (proc.cmdline=%proc.cmdline connection=%fd.name %container.info
    evt.type=%evt.type evt.res=%evt.res proc.pid=%proc.pid proc.cwd=%proc.cwd
    proc.ppid=%proc.ppid proc.pcmdline=%proc.pcmdline proc.sid=%proc.sid
    proc.exepath=%proc.exepath user.uid=%user.uid user.loginuid=%user.loginuid
    user.loginname=%user.loginname user.name=%user.name group.gid=%group.gid
    group.name=%group.name container.id=%container.id
    container.name=%container.name
    image=%container.image.repository:%container.image.tag)
  priority: notice
  source: syscall
...

Falcoでサポートされているsyscallの完全なリストについては、公式Falcoドキュメントをチェックしてください。

Kubernetes Auditイベント

Falco v0.13.0は、サポートされるイベントソースのリストにKubernetes Audit Eventsを追加しました。これは、既存のシステムコールイベントのサポートに追加されたものです。Auditイベントの改良された実装は、Kubernetes v1.11で導入され、kube-apiserverへのリクエストとレスポンスのログを提供するものです。クラスター管理タスクのほぼすべてがAPIサーバーを介して実行されるため、監査ログはクラスターに加えられた変更を効果的に追跡することができます。FalcoとGuardDutyはどちらもKubernetes Audit Loggingを利用しており、だからこそ、その実装を比較することが重要です。これらのシナリオをカバーするために、以下のような注目すべきまたは疑わしい活動を監視するFalcoのルールのセットが追加されました。

  • cluster-admin のような過度に広い権限をユーザーに付与すること
  • 特権的なポッドの作成、機密性の高いホストパスのマウント、またはホストネットワーキングの使用
  • 機密情報を含む ConfigMap を作成する

いったんクラスターに監査ログが設定され、イベントが Falco に送信されるように選択されると、 これらのイベントを読み取ることができる Falco のルールを書き、疑わしい活動やその他の注目すべき活動 に対して通知を送信することができます。

K8sの完全な管理者アクセス（Falco）

ユーザ名にフル管理者権限が付与されているが、承認されたフル管理者ユーザではないK8s操作を検出する場合、Falcoは Allowed_full_admin_usersのような個々のマクロにユーザを分類することができます。例として以下のようなFalcoのYAMLマニフェストを用意しました：

- rule: Full K8s Administrative Access
  desc: >-
    Detect any k8s operation by a user name that may be an administrator with
    full access.
  condition: >
    kevt and non_system_user and ka.user.name in (full_admin_k8s_users) and not
    Allowed_full_admin_users
  output: >-
    K8s Operation performed by full admin user (user=%ka.user.name
    target=%ka.target.name/%ka.target.resource verb=%ka.verb uri=%ka.uri
    resp=%ka.response.code)
  priority: warning
  source: k8s_audit
...

Falcoがユーザーに独自の検出ルールセットを構築する柔軟性を与えているのに対し、AWS GuardDutyは ‘Finding Types‘ と呼ばれるシステムを設けています。GuardDutyでカスタム検出を書くことはできますか？残念ながら、できません。GuardDutyは、独自のカスタムルールセットを開発・維持するための重い作業や複雑さを取り除いています。とはいえ、Kubernetes Audit Logsのための’Finding Types’の長いリストがあります。GuardDutyでは、潜在的な管理者アクセス行為について警告したい場合、特権昇格のためのビルド済みFindingに依存することになります。

PrivilegeEscalation:Kubernetes/PrivilegedContainer (GuardDuty)

この所見は、Kubernetesクラスターで特権付きコンテナを起動するために、これまで一度も使用されたことのないイメージを使用して特権付きコンテナが起動されたことを通知するものです。”特権昇格” に特化して事前に設定されたFalcoのルールはありませんが、このMITRE ATT&CKの手法を検出するルールを構築するためにFalcoを絶対的に使用することができます。特権付きコンテナは、ホストに対するルートレベルのアクセス権を有しています。攻撃者は特権付きコンテナを起動し、コンテナからエスケープすることでホストにアクセスし、ホストを侵害する特権昇格戦術をとることができます。Kubernetesの監査ログだけでなく、すべてのシステムコールを検出できるようにすることで、特権コンテナがどのように作成されたかを明確に把握することができます：

- rule: Create Privileged Pod
  desc: |
    Detect an attempt to start a pod with a privileged container
  condition: >-
    kevt and pod and kcreate and ka.req.pod.containers.privileged intersects
    (true)
  output: >-
    Pod started with privileged container (user=%ka.user.name pod=%ka.resp.name
    ns=%ka.target.namespace images=%ka.req.pod.containers.image)
  priority: warning
  source: k8s_audit
...

ノード/ホストレベルで追加のパーミッションを取得するための一般的な方法の1つは、SetUID/SetGUIDを経由することです。以下のFalcoのルールは、SUIDとGUIDのビット上の変更を検出します。ファイルの所有権は、作成者の uid (ユーザー ID) と gid (グループ ID) にも依存します。もっと知りたければ、カーネルパラメータの記事を深く掘り下げてみてください。syscallの洞察がなければ、攻撃者がEKSのワークロードで特権昇格を実行するためのパーミッションを自分に与えたケースを観察することはできないでしょう。

- rule: Set Setuid or Setgid bit
  desc: >
    setuid or setgid bits are set for an application,
  condition: >
    consider_all_chmods and chmod and (evt.arg.mode contains "S_ISUID" or evt.arg.mode contains "S_ISGID")
    and not proc.name in (user_known_chmod_applications)
    and not exe_running_docker_save
    and not user_known_set_setuid_or_setgid_bit_conditions
  output: >
    Setuid or setgid bit is set via chmod (fd=%evt.arg.fd filename=%evt.arg.filename mode=%evt.arg.mode user=%user.name user_loginuid=%user.loginuid process=%proc.name
    command=%proc.cmdline container_id=%container.id container_name=%container.name image=%container.image.repository:%container.image.tag)
   Priority:
     NOTICE
  tags: [process, mitre_persistence]
  source: syscall
...

Falcoは、syscallやKubernetes Audit Logsだけにとどまりません。FalcoのライブラリやFalco自身はPluginを使用することで拡張することができます。この機能により、FalcoはAWS CloudTrail Pluginのような追加のイベントソースを消費するために拡張されることができます。

alt_text

AWS CloudTrailデータイベント

Falco cloudtrailプラグインは、AWS CloudTrailログを読み、各CloudTrailログエントリに対してイベントを発することができます。このプラグインには、CloudTrailログ内の興味深い/疑わしい/注目すべきイベントを識別するために使用できる、以下のようなアウトオブボックスのルールも含まれています。

  • S3バケットの暗号化の無効化
  • ユーザーに対する多要素認証の無効化
  • 多要素認証を使用しないコンソールログイン

ここでもGuardDutyは同じAWS CloudTrailのイベントにアクセスし、これらのIAMアクティビティを把握することができます。以下のGuardDuty findingは、同じIAMユーザーの複数の成功したコンソールログインが、様々な地理的な場所で同じ時間帯に観測されたことを知らせてくれています。クラウドのログ管理に関する記事で、サービスによるセキュリティイベントの管理方法について詳しく説明しています。

UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B (GuardDuty)

このような異常で危険なアクセス場所のパターンは、AWSリソースへの不正アクセスの可能性を示しています。FalcoのルールのようにMFAにフォーカスしているわけではありませんが、このYAML定義は確かに上記のFalcoのアラート定義を補完することができるでしょう。

MFAを使用しないコンソールログイン（Falco）

多要素認証（MFA）を必要としないコンソールログインの場合、Falcoのルールはこのようになります。データは aws_cloudtrailから供給されます。Falcoはイベントアクティビティを集約して、ConsoleLogin=”Success” and MFAUsed=”No”の例を示します。

- rule: Console Login Without MFA
  desc: Detects a console login without MFA.
  condition: >-
    aws.eventName="ConsoleLogin" and not aws.errorCode exists and
    jevt.value[/userIdentity/type]!="AssumedRole" and
    jevt.value[/responseElements/ConsoleLogin]="Success" and
    jevt.value[/additionalEventData/MFAUsed]="No"
  output: >-
    Detected a console login without MFA (requesting user=%aws.user, requesting
    IP=%aws.sourceIP, AWS region=%aws.region)
  priority: critical
  source: aws_cloudtrail
...

さらに、MFA fatigue or spamming attacksを検出することができます。

Policy:S3/AccountBlockPublicAccessDisabled (GuardDuty)

このfindingは、Amazon S3 Block Public Accessがアカウントレベルで無効化されたことを通知します。S3 Block Public Accessの設定が有効な場合、データの不用意な公開を防ぐためのセキュリティ対策として、バケット上のポリシーまたはアクセス制御リスト（ACL）をフィルタリングするために使用されます。

AWS S3のバージョニングを無効にする（Falco)

GuardDutyがS3 Block Public Accessが無効になったことを検知する方法と同様に、FalcoはS3バケットのバージョニングが無効になった場合などのS3バケットルールを作成することができます。

- rule: AWS S3 Versioning Disabled
  desc: Detect disabling of S3 bucket versioning.
  condition: >-
    aws.eventSource = "s3.amazonaws.com" and aws.eventName =
    "PutBucketVersioning" and
    jevt.value[/requestParameters/VersioningConfiguration/Status] = "Suspended"
    and not aws.errorCode exists
  output: >-
    The file versioning for a bucket has been disabled. (requesting
    user=%aws.user, requesting IP=%aws.sourceIP, AWS region=%aws.region,
    arn=%jevt.value[/userIdentity/arn], bucket
    name=%jevt.value[/requestParameters/bucketName])
  priority: warning
  source: aws_cloudtrail
...

通常、バケットやバケット内のオブジェクトへのパブリックアクセスを許可するために、S3 Block Public Accessはアカウントでオフにされます。アカウントでS3 Block Public Accessが無効になっている場合、バケットへのアクセスは、個々のバケットに適用されるポリシー、ACL、またはバケットレベルのBlock Public Access設定によって制御されます。これは、必ずしもバケットが公に共有されることを意味するものではありませんが、バケットに適用されたパーミッションを監査して、適切なレベルのアクセスを提供していることを確認する必要があります。同じことが、S3バケットのバージョニングにも言えます。S3バージョニングは、ユーザーが1つのバケットにオブジェクトの複数のバージョンを保持することができます。不正なユーザーは、ランサムウェア攻撃の場合にS3データの潜在的なバックアップを削除するために、この操作を実行するかもしれません。これは、クラウドテナントにとって、もう1つの明確なIoC（Indicator of Compromise）となるでしょう。

DNSログ

ドメインネームサービス（DNS）は、より有用なIndicator of Compromise（IoC）の1つです。期待される/期待されない/望まないドメイン名へ送信された接続を判断することで、既知の悪質なC2サーバーへのデータ漏洩の可能性を即座に検出することができます。このような理由から、DNSを保護することが重要なのです。Falcoは、この種の活動を検知するために、同じ方法で使用することができます。

- rule: Malicious IPs or domains detected on command line
   desc: >-
    Malicious commands detected in pod/host. The rule was triggered by an IP.
    or domains in proc_cmdline
  condition: >
    evt.type = execve and evt.dir = < and (proc.name="curl" or proc.name="wget")
    and proc_args_with_malicious_domain_ip
  output: >-
    Malicious connections to IP or domains detected in pod or host.
    proc.cmdline=%proc.cmdline evt.type=%evt.type evt.res=%evt.res
    proc.pid=%proc.pid proc.cwd=%proc.cwd proc.ppid=%proc.ppid
    proc.pcmdline=%proc.pcmdline proc.sid=%proc.sid proc.exepath=%proc.exepath
    user.uid=%user.uid user.loginuid=%user.loginuid
    user.loginname=%user.loginname user.name=%user.name group.gid=%group.gid
    group.name=%group.name container.id=%container.id
    container.name=%container.name %evt.args
 . riority: warning
  Tags:
  - ioc
  source: syscall
  exceptions: []
...

上記のルールは、マクロ – proc_args_with_malicious_domain_ip で、IP アドレスまたはドメイン名に対してイベントを実行するプロセス ‘cURL’ または ‘wget’ を探しています。上記のマクロを開いてみてください。IPアドレスとドメインがリストアップされている短いスニペットを見ることができます。

macro: proc_args_with_malicious_domain_ip
condition: (proc.args contains "pool.minexmr.com" or proc.args contains "pool.supportxmr.com" or 
  proc.args contains "us1.ethermine.org" or proc.args contains "xmr-us-east1.nanopool.org" or 
  proc.args contains "xmr-us-west1.nanopool.org" or proc.args contains "xmr.pool.minergate.com" or 
  proc.args contains "51.15.67.17" or proc.args contains "142.44.242.100" or 
  proc.args contains "104.140.244.186" or 
  proc.args contains "46.105.31.147" or 
  proc.args contains "us-west.minexmr.com" or 
  proc.args contains "xmr.hashcity.org" or 
  proc.args contains "pool.hashvault.pro" or 
  proc.args contains "fastpool.xyz" or 
  proc.args contains

前述のように、GuardDutyはネットワーク関連の活動に対する‘findings’ の束をビルドします。これらのフィードは、コマンド＆コントロール（C2 / C&C）サーバー接続、サービス拒否（DoS）、またはビットコインマイニングツールなどの特定の脅威パターンに結びつけられています。以下に例を示します。

Backdoor:EC2/C&CActivity.B!DNS

このfindingは、AWS環境内のリストされたインスタンスが、既知のコマンド＆コントロール（C&C）サーバーに関連するドメイン名をクエリーしていることを通知します。リストされたインスタンスは危険にさらされている可能性があります。コマンド＆コントロールサーバーは、ボットネットのメンバーにコマンドを発行するコンピュータです。Falcoでは、同様に既知のC2サーバーのIPアドレスまたはドメイン名を検出することができます。CLIからの一般的な悪意のあるIP/DNS接続に対する上記のFalcoの例を取り、C2サーバーのリストに特に行く任意の接続（CLIまたはそれ以外）にこのロジックを適用します。

- rule: Outbound Connection to C2 Servers
  desc: Detect outbound connection to command & control servers
  condition: outbound and (fd.sip in (c2_server_ip_list) or fd.sip in (ti_c2_ip_list))
  output: >-
    Outbound connection to C2 server (dest=%fd.sip dport=%fd.sport
    dproto=%fd.sproto proc.cmdline=%proc.cmdline connection=%fd.name
    user.name=%user.name user.loginuid=%user.loginuid container.id=%container.id
    evt.type=%evt.type evt.res=%evt.res proc.pid=%proc.pid proc.cwd=%proc.cwd
    proc.ppid=%proc.ppid proc.pcmdline=%proc.pcmdline proc.sid=%proc.sid
    proc.exepath=%proc.exepath user.uid=%user.uid user.loginname=%user.loginname
    group.gid=%group.gid group.name=%group.name container.name=%container.name
    image=%container.image.repository)
  priority: warning
  source: syscall
  append: false
...

Falcoのアプローチは、いくつかの明確な利点を追加します。上記のシナリオでは、私たちはシステムコールに依存しているため、これらのC2接続がコンテナレベルで行われているかどうかを判断することができます。GuardDuty は確かに不要な C2 アウトバウンド接続について警告することができますが、 Falco は、どのコンテナがトラフィックを生成し、それがどのネットワークネームスペースから存在するかを教えてくれるきめ細かさを提供します。私たちは、syscallイベントからすべての関連するメタデータを抽出することができます。

Backdoor:EC2/DenialOfService.Dns

このfindingは、AWS環境内のリストされたEC2インスタンスが大量のアウトバウンドDNSトラフィックを生成していることを通知します。これは、リストアップされたインスタンスが侵害され、DNSプロトコルを使用したDoS攻撃を実行するために使用されていることを示す可能性があります。Falco YAMLスニペットでブログ記事を埋め尽くすことなく、オープンソースツールFalcoとCalicoを使用したKubernetesにおけるDoS攻撃の検出と防御に関するブログ記事を公開しました。私たちは、ほとんどのDoSインシデントでは、攻撃者が何らかの形で匿名性を維持しようとすることを述べました。これを実現する素晴らしい方法は、Tor VPN Exitノードを使用することです。同様のFalcoのルールは、Tor Exit NodeのIPアドレスにプラグインするMacroで構築することができます。


CryptoCurrency:EC2/BitcoinTool.B!DNS

このfindingは、AWS環境でリストされたEC2インスタンスが、ビットコインやその他の暗号通貨関連の活動に関連するドメイン名をクエリーしていることを通知するものです。ビットコインは世界的な暗号通貨であり、他の通貨、製品、サービスと交換可能なデジタル決済システムです。ビットコインは、ビットコインマイニングの報酬であり、脅威行為者が非常に求めているものです。繰り返しになりますが、暗号通貨の検出については、Falco で詳しく説明しています。マイナーは通常、3333、4444、8333のような共通ポートでマイナープールに接続します。

- rule: Detect outbound connections to common miner pool ports
  desc: >-
    Miners typically connect to miner pools on common ports
  condition: net_miner_pool and not trusted_images_query_miner_domain_dns
  output: >-
    Outbound connection to IP/Port flagged as mining activity (dest=%fd.sip
    proc.cmdline=%proc.cmdline port=%fd.sport domain=%fd.sip.name
    container=%container.info evt.type=%evt.type evt.res=%evt.res
    proc.pid=%proc.pid proc.cwd=%proc.cwd proc.ppid=%proc.ppid
    proc.pcmdline=%proc.pcmdline proc.sid=%proc.sid proc.exepath=%proc.exepath
    user.uid=%user.uid user.loginuid=%user.loginuid
    user.loginname=%user.loginname user.name=%user.name group.gid=%group.gid
    group.name=%group.name container.id=%container.id
    container.name=%container.name image=%container.image.repository)
  priority: critical
  source: syscall
  append: false
...

 net_miner_pool マクロの内部には、さらに2つのマクロがあります。
  1. miner_ports は、これらのビットコイン/暗号化プールに関連する IP アドレスをリストアップします。
  2. miners_ip は、ビットコインのマイニングによく使われるポート番号のリストです。

list: miner_ports
items: [25, 80, 443, 3333, 3334, 3335, 3336, 3357, 4444, 
  5555, 5556, 5588, 5730, 6099, 6666, 7777, 7778, 
  8000, 8001, 8008, 8080, 8118, 8333, 8888, 8899, 
  9332, 9999, 14433, 14444, 45560, 45700]

list: miners_ip
items: ["51.15.39.52", "163.172.162.51", "51.15.89.69", "213.32.74.230", 
  "213.32.74.219", "151.80.59.84", "51.15.39.186", "144.217.14.109", 
  "192.99.69.170", "142.44.242.100", "142.44.243.6", "144.217.14.139", 
  "128.199.55.158", "46.101.236.153", "18.184.127.10", "188.166.16.158", 
  "18.184.174.79", "18.184.182.16", "3.68.113.29", "46.101.145.131" etc]

他のGuardDutyの‘findings’とは異なり、これらのフィードに自分の良い/悪いIPアドレスを追加することができます – それ以上ではありません。これにより、ユーザーは検出を受けたくないドメインやIPをホワイトリストに登録することができます。GuardDutyはこれを “Feature “と称しています。Falcoでは、ユーザーが独自の脅威フィードを持ち込んで、それをYAML形式のルールファイルに単純に差し込むことができます。

オーダーメイドの運用

もしあなたのセキュリティチームが、独自のアプリケーションや使用しているサードパーティアプリケーションからセキュリティイベントを生成する必要がある場合、GuardDutyは執筆時点では解決策を提供しないでしょう。現在、Kubernetesクラスターで稼働している何十ものオープンソースツールから、どのようにアラートを生成しているのでしょうか？多くの組織では、ログ集約とさらなるフォレンジックのために、イベントをSIEMツールに送信しています。Falcoでは、お客様独自のFalcoプラグインをビルドするためのプラグイン開発者ガイドを提供しています。もし、あなたやあなたの開発者がビルドすることに興味があるなら、HashiCorpとのFalcoコミュニティセッションをチェックしてみてください。

お金はどうなる？

Falcoとは異なり、AWS GuardDutyは無料ではありません。例えば、GuardDutyはCloudTrailの管理イベントを継続的に解析しています。執筆時点では、CloudTrailの管理イベント分析は月100万イベントごとに課金され、日割り計算されます。Falcoは、コミュニティが支援する無償のオープンソースプロジェクトです。Falcoは、ローカルマシン、クラウド、マネージドKubernetesクラスター、IoTやEdgeコンピューティングで稼働するK3sなどのKubernetesクラスターにデプロイすることが可能です。Linuxシステムで作業しているのであれば、Falcoを実行できる場所にはほとんど制限がありません。とはいえ、どんなオープンソースのルールエンジンでも、オンスケールで管理すると時間がかかり、盲点を特定するのが難しくなることがあります。そのため、Sysdig Secureは既存のFalcoのルールエンジンを拡張し、セキュリティとコンプライアンスチーム向けにアウトオブボックスのワークフローを追加して拡張しているのです。GuardDutyは取り込まれたログやイベントの数に応じて課金されますが、Sysdig Secureはノード単位のシンプルなライセンスモデルを提供しています。AWS環境で発生する大量のセキュリティイベントによって多額の請求が発生するようであれば、Sysdig Secureを検討する価値があるかもしれません。

まとめ

AWSとEKSのようなAWS上で動作するサービスのみを対象としてセキュリティを管理している場合、FalcoとGuardDutyのどちらを選択するかは妥当な判断材料となります。他のインフラストラクチャー、非クラスター、マルチクラウド戦略へのサポートを拡張する必要がある場合は、Falcoが明らかに勝者となるでしょう。Falcoはオンプレミス、スタンドアロンVMで動作し、Google Cloud Platform、Microsoft Azure、IBM Cloudなどのクラウド監査データを収集することができます。管理の観点からは、GuardDutyはセキュリティ・インシデントとその対応を管理するための簡素化されたアプローチを提供します。3回クリックするだけで、GuardDutyを起動させることができます。しかし、これには制限があります。例えば、GuardDutyが持っているものを利用しなければなりませんし、これは一般的なケースです。つまり、S3かもしれないし、EC2かもしれないし、EKSかもしれませんが、GuardDutyがアウトオブボックスで提供するものに対してアクションを起こさなければならないのです。彼らの「知見」は、実はカスタマイズできないのです。ポリシー言語や、ユーザーとしてイベントを違反または違反でないとマークする他の方法はありません。GuardDutyの意見に従うしかないのです。一方、Falcoのカスタマイズ可能なYAMLルール言語は、ユーザーがイベントから任意のデータを取り出し、関連するアラートをビルドすることを可能にします。Falcoがアラートできる内容は、システムコール、kubernetesの監査ログ、前述したCloudTrailのログの制約の範囲内であれば、特に制限はありません。FalcoとGuardDutyのセットアップは、どちらも割とシンプルでした。おそらく、単一のスタンドアローンクラウド環境上で以下のワークロードに従うGuardDutyでは、よりシンプルになります。
  1. https://console.aws.amazon.com/guarduty/ でGuardDutyのコンソールを開きます。
  2. Get Startedを選択します。
  3. GuardDutyの有効化を選択します。

このブログ記事に基づいて、GuardDutyと並行してFalcoを使用するか、GuardDutyの代わりにFalcoを使用するかを決定することができるはずです。もし、フルカスタマイズ可能なポリシーエンジンが必要であれば、Falcoがより強力な選択肢となることでしょう。しかし、セキュリティインシデントやイベント管理チームの負担を軽減するために、フルマネージドセキュリティを提供したい場合は、一見するとGuardDutyの方が安全なオプションに見えるかもしれません。第三の選択肢として、Falcoにフルマネージドポリシーを導入してもらうという手もあります。Sysdig Secureは、Falco、Sysdig、OPA、Prometheusといったスケーラブルなオープンソースソリューションをベースにしたマネージド型のエンタープライズソリューションを提供しています。Sysdig Secureは、Falco、Sysdig、OPA、Prometheusなどのスケーラブルなオープンソースソリューションをベースに、マネージドなエンタープライズソリューションを提供します。ユーザーは、Falcoインスタンスの管理について心配する必要はありません。グラフィカルなユーザインタフェースは、これらのアラートの重要度を表示し、UI内の直感的なポリシービルダーも表示します。SysdigのCDRプラットフォームについてもっと知りたい方は、今すぐ無料で試用できます。