コンテナ・Kubernetes環境向けセキュリティ・モニタリング プラットフォーム

本文の内容は、2021年1月19日にKaizhe Huangが投稿したブログ(https://sysdig.com/blog/falco-vs-auditd-hids/)を元に日本語に翻訳・再構成した内容となっております。

このブログでは、ホスト侵入検知(HIDS)の観点からFalcoとAuditDを比較対照します。

AuditDは、インシデント調査を容易にするために特定のタイプのシステムアクティビティを収集するLinuxカーネルのネイティブ機能です。

Falcoは、コンテナやKubernetesのランタイム脅威検知のためのCNCFオープンソースプロジェクトです。

技術的な詳細を掘り下げ、インストール、検出、リソース消費、両製品間のインテグレーションについて取り上げます。

Linux Auditing System（別名：AuditD）とは何ですか？

AuditD は Linux Auditing System のユーザスペースコンポーネントであり、監査記録をディスクに書き込む役割を担っています。

Red Hatは、「カーネルとの緊密な統合により、Auditdは、システムコール、ファイルアクセス、変更、およびRHELによって維持されている事前に設定された監査可能なイベントのリストを監視することができます」（Redhat, n.d.）と述べています。(Redhat, n.d.)

また、AuditDには、コンテナのランタイム情報でイベントを充実させる機能がないことにも注意してください。そのため、比較対象をHIDSとして限定しています。

FalcoとAuditDの比較

CNCFのインキュベーションプロジェクトであるFalcoは、豊富ですぐに使えるデフォルトルールで、クラウドネイティブ環境での異常な動作を検出するのに役立ちます。

クラウドネイティブ環境以外にも、FalcoはLinuxの異常動作を検出するHIDSツールとしても使用できます。

私たちがFalcoと他のオープンソースHIDSツールとの比較を考え始めたとき、SANSのレポートに掲載されているAuditDの扱いに目が留まりました。報告書を検討した結果、2つの理由から比較対象としてAuditDを選択することにしました。

• Linuxとネイティブに統合されていること。
• また、検出のためのシステムコールに深く依存していること。

FalcoとAuditDを深く掘り下げてみると、どちらも強力なHIDSツールであることがわかりました。どちらも侵入検知にはシステムコールに依存していますが、ルールの作成やイベントデータの出力方法には大きな違いがあります。

FalcoとAuditDのインストール

Falco と AuditD はどちらもインストールが簡単で、ほとんどのパッケージマネージャで利用できます。debian システムでは、apt-get を使うことができます。

# Trust the falcosecurity GPG key, configure the apt repository, and update the package lis
curl -s https://falco.org/repo/falcosecurity-3672BA8F.asc | sudo apt-key add -
echo "deb https://dl.bintray.com/falcosecurity/deb stable main" | sudo tee -a /etc/apt/sources.list.d/falcosecurity.list
sudo apt-get update -y
# Install kernel headers
sudo apt-get -y install linux-headers-$(uname -r)
# Install falco

sudo apt-get install -y falco 

そして、auditdをインストールします。

sudo apt-get install auditd audispd-plugins

どちらもシステムサービスとして実行され、systemd によって管理されます。

また、システムコールにフックして監視するカーネルコードであるauditdは、2.6の時代からLinuxカーネルの一部であることにも注意してください。Falcoとは対照的に、auditdにはカーネルモジュールのインストールは必要ありません。

FalcoとAuditDにはどのような検出ルールがあるのか？

動作検出機能に注目しているので、FalcoとAuditDがそのような動作をどのように定義しているかを比較していきます。

FalcoもAuditDも、セキュリティではかなり一般的な用語である検出ルールという概念を持っており、独自のフォーマットを使用しています。両者の比較は以下の通りです。

Falcoルール

FalcoのルールはYAML形式で書かれており、マクロとリストオブジェクトをサポートしており、コードを再利用することができます：

• ルール: アラートが生成される条件。ルールは、アラートと一緒に送信される説明的な出力文字列を伴っています。
• マクロ: ルールや他のマクロの中で再利用できるルール条件のスニペット。マクロは、一般的なパターンに名前を付けたり、ルールの冗長性を排除したりする方法を提供します。
• リスト: ルールやマクロ、その他のリストに含めることができる項目の集まり。たとえば、プロセスの名前、ファイルの名前、ポートなど。ルールやマクロとは異なり、リストはフィルタリング式として解析できません。

単純なFalcoルールの例は以下のようになります。

- rule: Nmap Launched
  desc: Detect Nmap is launched
  condition: spawned_process and proc.name = nmap and container.id = host
  output: Nmap launched (user=%user.name parent=%proc.pname cmdline=%proc.cmdline)

  priority: WARNING 

上記のルールは、偵察ツールNmapが起動されたときにトリガされる。

本番システムでこのようなアラートが発動されるとすれば、攻撃者がマシンに侵入し、社内ネットワークで偵察を開始したことを示す良い指標となる。

このルール条件は、3つの部分から構成されています。

• spawed_process: この定義済みマクロは、システムコールの execve が呼び出されたとき（プロセスが起動したときなど）にトリガされます。
• proc.name = nmap: プロセス名 (フルパスを除く) は nmap と等しくなります。
• container.id = host: execve イベントはコンテナではなくホスト内部で発生します。

Falcoルールがどのように作成されるかについての詳細はブログをご覧ください。また、Falcoユーザーガイドでは、Falcoルールの条件を構築するために利用できるすべてのフィルタを確認することができます。

AuditDルール

AuditD ルールは、ファイル中心かシステムコール中心にすることができ、auditctl クライアントツールで作成・管理されます。

ファイル中心のルールの例は以下のようになります。

auditctl -w /etc/ -p aw -k write_below_etc

このルールは、/etc フォルダ以下のファイルに書き込むイベントを監査します。各フラグはルールの異なるプロパティを設定します。

• -w ウォッチのパスを挿入します。私たちのケースの場合は/etc/です。
• -p この例では、watch、append、execute (aw) の権限フィルタを設定しています。
• -k write_below_etc のようなルール名でフィルタキーを設定します。

ファイル中心のルールは、ファイルの改ざん、機密データの読み込み、異常なプロセス実行などを検出するのに適しています。

システムコール中心のルールの例は以下のようになります：

auditctl -a always,exit -F arch=b64 -S socket -F success=1 -F a0=2 -k socket_activity

上記のルールは、IPv4上で成功したすべてのソケットsyscallイベントを監査し、以下のフラグで定義されています。

• -a はルールを最後に追加します。この例では、終了時に常にソケットsyscallを監査します。
• -S この例では、終了時に常にsocketのsyscallを監査します。
• -F 監査レコードが開始されるために、イベントが通過しなければならないフィルタまたは条件。これらはイベントフィールドの値に基づいています。例えば、arch=b64 は 64 ビットマシンを意味し、 success=1 はソケットが成功して終了することを意味し、a0=2 は IPv4 プロトコルを意味します。

なぜsyscallを使うのか?

FalcoもAuditDもLinuxマシンへの侵入を検知するために、syscallに大きく依存していることに気づいたかもしれません。しかし、なぜでしょうか？

システムコールは、ファイル、デバイス、ネットワークなどのリソースにアクセスするために、アプリケーションがオペレーティングシステムのカーネルと対話するためのプログラム的な方法です。

これは、アプリケーションの動作を理解するための究極の統一された方法であり、真理の源です。アプリケーションがC/C++、Java、Python、Golangなどで書かれているかどうかは関係ありません。システムコールイベントから、どのファイルが作成されたのか、読み書きされたのか、アプリケーションがTCP接続を確立したIPアドレスは何なのかを知ることができます。

では、FalcoとAuditDの両方がsyscallイベントに依存しているとしたら、両者の大きな違いは何でしょうか？

次のセクションでこの質問に答えてみましょう。

FalcoとAuditDの検出機能

先ほど、システムコールはアプリケーションの動作の真実の究極のソースであり、Linuxマシンへの侵入を検出するための完璧なツールになると述べました。このことを考えると、十分な計算リソースがあれば、FalcoやAuditDからは何も隠されていないと考えることができるでしょう。これは無制限の検出能力を意味します。

しかし、そうでしょうか？

実際には、セキュリティ製品は、タスクを完了するために非常に限られたリソースしか使用しないはずです。これでは、検出能力はリソースの制限に縛られてしまいます。

また、検出の粒度にも限界があります。

最後になりますが、イベントの冗長性には製品の設計や実装の制限があり、インシデントの調査に必要なすべての情報を得ることができない場合があります。

キャパシティマネジメント

これらの限られた計算リソースで動作するために、Falco と AuditD の両方が実装されており、サービスの品質を確保しています。

適切なキャパシティ管理をしないと、十分なリソースを占有できなくなったときに製品がクラッシュするか、検出中のLinuxマシンのリソースを占有しすぎてしまうかのどちらかです。どちらにしても悪いことです。

このようなケースを避けるために、Falco はカーネルとユーザスペースの間に共有バッファを使用してシステムコール情報を渡しています。共有バッファのサイズは8MBです。バッファが一杯になると、システムコールは落とされ、Falcoはユーザーに警告するためにアラートを投げます。

AuditDのバッファサイズは、auditctlで設定できます。デフォルトのバッファ数は64です（8192に設定することをお勧めします）。監査イベント数がバックログ制限を超えると、エラーメッセージが表示されるはずです。

audit: backlog limit exceeded

FalcoとAuditDはどちらも本番環境に対応しています。FalcoはGitlab、Shopify、Sumo Logicなどの企業で採用されています。

ルールの粒度

留意すべき重要な点の一つは、私たちのルールがどれだけ細かく設定されているかということです。興味のあるイベントだけをフィルタリングできるか？

これがFalcoとAuditDの大きな違いです。

機密性の高いファイルアクセスイベントのフィルタリング

システムの暗号化されたパスワードがすべて含まれている /etc/shadow ファイルを読んでいるプロセスを検出するような単純なルールを考えてみましょう。

Falcoのout-of-the-box-rulesでは、次のようになります：

- rule: Read sensitive file untrusted
  desc: >
    an attempt to read any sensitive file (e.g. files containing user/password/authentication
    information). Exceptions are made for known trusted programs.
  condition: >
    sensitive_files and open_read
    and proc_name_exists
    ...
    and not user_known_read_sensitive_files_activities
  output: >
    Sensitive file opened for reading by non-trusted program (user=%user.name user_loginuid=%user.loginuid program=%proc.name
    command=%proc.cmdline file=%fd.name parent=%proc.pname gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] container_id=%container.id image=%container.image.repository)
  priority: WARNING

  tags: [filesystem, mitre_credential_access, mitre_discovery] 

状態の重要な部分がいくつかあります：

• sensitive_files： 機密ファイルとディレクトリを定義するマクロです。
• open_read：読み込み関連のsyscallイベントを定義するマクロです(例: evt.type=openat)。
• user_known_read_sensitive_files_activitiesのような例外を含めています。

AuditDでは、次のような新しいルールを作成することができます：

auditctl -a always,exit -F arch=b64 -S openat -F path=/etc/shadow -F perm=r -F key=read_etc_shadow

Falco と AuditD の両方とも、機密性の高い /etc/shadow ファイルを読んでいるプロセスを検出するための適切なフィルタを持っています。

悪意のあるIPへのネットワーク接続のフィルタリング

しかし、他のシナリオではそうはいきません。ここでは、FalcoルールがAuditDよりも細かい粒度を持つ1つの例を取り上げてみましょう。

次のシナリオでは、既知のC2（コマンドアンドコントロール）サーバへのネットワークトラフィックを検出するルールを記述します。

Falcoのout-of-the-box-rulesには、以下のようなものがあります：

# the list is subject to be updated
- list: c2_server_ip_list
  items: [...]
- rule: Outbound Connection to C2 Servers
  desc: Detect outbound connection to command & control servers
  condition: outbound and fd.sip in (c2_server_ip_list)
  output: Outbound connection to C2 server (command=%proc.cmdline connection=%fd.name user=%user.name user_loginuid=%user.loginuid container_id=%container.id image=%container.image.repository)
  priority: WARNING

  tags: [network] 

上記のルール条件では：

• outboundマクロは、evt.type(例: connect, sendto)、fd.typechar(例: IPv4)などのフィルタを使用して、発信ネットワーク接続syscallイベントがあることを検出するために使用されます。詳細はマクロの定義を確認してください。
• fd.sipフィルタは、connectやsendtoのようなsyscallイベントからサーバのIPアドレスを取得します。
• そして、Falcoルールは、そのIPアドレスをc2_server_ip_listで定義されているものと比較します。
• 一致するものがあれば、Falcoはアラートを送信します。

このようにして、フィルターは細かい検出ルールを作成するために機能します。ファイルの読み書きやネットワーク接続のようなすべてのシステムアクティビティだけではありません。Falcoのフィルタは、C2サーバへの特定のIPv4接続を検出することを可能にします。

コンテナイメージリポジトリやKubernetesのネームスペースなど、クラウドネイティブのコンテキストを理解しているフィルタを含むFalcoルールを作成するために使用できるフィルタの完全なリストを確認してください。

AuditDでは、残念ながら同様のルールを作成することはできません。できることは、あらゆる種類のネットワーク関連のsyscallイベント（ソケット、接続など）を検出するルールを作成することです。

auditctl -a always,exit -F arch=b64 -S socket -F success=1 -F a0=2 -k socket_activity

このルールでは、成功したすべての IPv4 接続をフィルタリングしています (フィルタ a0=2 と success=1 を介して)。DNSのような正当な接続も含めて、すべてのネットワークトラフィックが記録されます。(特定のIPアドレスへの)正確なイベントをフィルタリングしたり検出したりするには、ausearchのようなツールを使用する必要があります。

クラウドネイティブコンテキスト

コンテナとして実行され、Kubernetes クラスターにデプロイされるアプリケーションが増えています。HIDSツールにとって重要なのは、クラウドネイティブのコンテキストを理解し、それに基づいて検出ルールを構築できるようにすることです。

これは、AuditDがFalcoと比較して不足している点です。

例えば、crypto-worm攻撃であるgraboidでは、重要なIOCの1つはコンテナ内でdockerクライアントを実行していますが、これは本番システムでは珍しいことです。しかし、ホストレベルでdockerクライアントを実行することは、正当な操作である可能性があります。

ここに、そのような IOC を検出するために特別に書かれた Falco のルールがあります：

- rule: The docker client is executed in a container
  desc: Detect a k8s client tool executed inside a container
  condition: spawned_process and container and not user_known_k8s_client_container_parens and proc.name in (k8s_client_binaries)
  output: "Docker or kubernetes client executed in container (user=%user.name user_loginuid=%user.loginuid %container.info parent=%proc.pname cmdline=%proc.cmdline image=%container.image.repository:%container.image.tag)"
  priority: WARNING

  tags: [container, mitre_execution] 

このルールの条件では：

• コンテナフィルタは、コンテナ内でイベントが発生した場合にのみルールがトリガーされることを決定します。
• 次に、dockerを含むk8s_client_binariesリストとproc.nameを比較します。

クラウドネイティブのコンテキストを理解しているコンテナのようなフィルタを使用することで、クラウドネイティブ環境のセキュリティを確保するために必要な細かいルールを構築することができます。

全体では、Falcoが150以上のフィルター（Kubernetesやコンテナなどのクラウドネイティブ環境に関連するものが多い）をサポートしているのに対し、AuditDは約40をサポートしています。それでも、有効なUID/GID、ファイルシステムのUID/GID、SELinux User/Role/TypeなどのAuditDのフィルターは、Falcoではまだ利用できないことは言及しておく価値があります。

イベントの冗長性におけるFalco vs. AuditD

セキュリティイベントが冗長であればあるほど、セキュリティチームはそれに迅速に対応することができます。関連する情報としては、検出ルールの作成に使用したフィルタや、ホスト名、ログインユーザなどの補助属性があります。このような理由から、冗長性は、どのHIDS製品の検出能力においても重要な要素となります。

Falcoでは、イベントの出力もユーザーによって定義され、Falcoでサポートされているほとんどのフィルタを利用することができます。ルールの出力のほとんどは、コマンドライン、親プロセス名、ファイル名、ユーザー名、ログインユーザー名などのフィルタを含んでいます。この out-of-the-box ruleの出力フィールドを見てみましょう：

- rule: Write below etc
  desc: an attempt to write to any file below /etc
  condition: write_etc_common
  output: "File below /etc opened for writing (user=%user.name user_loginuid=%user.loginuid command=%proc.cmdline parent=%proc.pname pcmdline=%proc.pcmdline file=%fd.name program=%proc.name gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] container_id=%container.id image=%container.image.repository)"
  priority: ERROR

  tags: [filesystem, mitre_persistence] 

このルールを、例えばtouch /etc/hello_falcoを実行することで発動させれば、このような情報が全て得られることになります。

23:36:25.600378940: Error File below /etc opened for writing (user=root command=touch_link /etc/hello_falco parent=bash pcmdline=bash file=/etc/hello_falco program=touch gparent=sudo ggparent=bash gggparent=sshd container_id=host image=<NA>)23:36:25.600378940: Error File below /etc opened for writing (user=root command=touch /etc/hello_falco parent=bash pcmdline=bash file=/etc/hello_falco program=touch gparent=sudo ggparent=bash gggparent=sshd container_id=host image=<NA>)

比較すると、同じAuditDルールでも以下のように記述することができます。

auditctl -w /etc/ -p aw -k write_below_etc

Falcoと違って、ユーザーが出力フィールドを定義する方法はありません。また、touch_link /etc/hello を実行してこのルールをトリガーすると、監査イベントは以下のようになります。

node=172.31.91.221 type=SYSCALL msg=audit(1607709712.085:1465620): arch=c000003e syscall=257 success=yes exit=3 a0=ffffff9c a1=7ffc3a4647cc a2=941 a3=1b6 items=2 ppid=21183 pid=21409 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=24151 comm="touch_link" exe="/bin/touch" key="write_below_etc"^]ARCH=x86_64 SYSCALL=openat AUID="ubuntu" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root"
node=172.31.91.221 type=CWD msg=audit(1607709712.085:1465620): cwd="/home/ubuntu/auditd"
node=172.31.91.221 type=PATH msg=audit(1607709712.085:1465620): item=0 name="/etc/" inode=206 dev=103:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0^]OUID="root" OGID="root"
node=172.31.91.221 type=PATH msg=audit(1607709712.085:1465620): item=1 name="/etc/hello" inode=90 dev=103:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0^]OUID="root" OGID="root"

node=172.31.91.221 type=PROCTITLE msg=audit(1607709712.085:1465620): proctitle=2E2F746F7563685F6C696E6B002F6574632F68656C6C6F 

この出力には、3 種類のメッセージ (type=) が含まれています：

• SYSCALL：システムコールレコードを記録するためにトリガされたイベント。
• CWD：現在の作業ディレクトリを記録するためにトリガされたイベント。
• PATH: パス情報を記録するためにトリガされたイベント。
• PROCTITLE: この Audit イベントをトリガした完全なコマンドラインを与え、カーネルへのシステムコールによってトリガされます。

どのような情報が含まれているか、どのように配布されているかについて、いくつかのハイライトがあります：

• AuditD の SYSCALL タイプイベントには作成されたファイル名は含まれませんが、PATH タイプイベントには含まれます。
• PATH型イベントには、オブジェクトのGID（OGID）や機能など、Falcoにはない有用な情報も含まれています。
• 同様に、SYSCALL型イベントはコマンドライン全体を記録しませんが、PROCTITLE型イベントは記録します。
• AuditDの利点の1つは、シンボリックリンクが実行されたときに、実際のファイルとシンボリックリンクファイルの両方を提供することです。上の出力では、comm フィールドにはシンボリックリンク名の touch_link が、exe フィールドには実際のバイナリファイル名 /bin/touch が含まれています。

PROCTITLE型イベントの情報はエンコードされており、以下のようにausearchでデコードする必要があることに注意してください。

node=172.31.91.221 type=PROCTITLE msg=audit(12/11/20 17:42:56.734:1465459) : proctitle=./touch_link /etc/hello
...

node=172.31.91.221 type=SYSCALL msg=audit(12/11/20 17:42:56.734:1465459) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7fff9a49c7cc a2=O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK a3=0x1b6 items=2 ppid=18991 pid=20989 auid=ubuntu uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=24148 comm=touch_link exe=/bin/touch key=write_below_etc 

プロクトタイトル値 2E2F746F7563685F6C696E6B002F6574632F68656C6C6C6F は、./touch_link /etc/hello としてデコードされています。

(出力としての)イベントフィールドの完全なリストは、RHELのドキュメントに記載されています。

全体的に、FalcoとAuditDはどちらも冗長な出力をしています：

• Falcoは、ユーザーがルールがトリガーされたときに何を出力するかを定義することができ、各ルールは1つの単一のイベントのみを生成します。
• AuditDはカスタマイズされた出力をサポートしておらず、1つのシステムコールイベントに対して複数のレコード(異なるタイプの)を生成します。AuditDの出力には、オブジェクトに関する豊富な情報（例えば、inode、GID）が含まれています。しかし、完全なコマンドライン（およびIPアドレス）のようないくつかの重要な情報は、ausearchを介してデコードする必要があります。

リソース消費量におけるFalco vs. AuditD

この記事の紹介でも触れましたが、検出ツールのリソース消費は、検出されたホスト上で実行されているワークロードのパフォーマンスに影響を与える可能性があります。

システムでの影響を適切に把握するには、具体的なユースケースごとにリソース消費量を評価する必要があることを覚えておいてください。検出ルールの定義方法にもよりますが、検出ルールがあまりにも多くの誤検出イベントを発生させてしまう可能性があり、その副作用として計算リソースの消費量が増加する可能性があります。慎重に検出ルールを書けば、誤検出イベントはほとんど発生せず、リソース消費は安定して低くなるはずです。

Falcoはかなりの量の検知ルールを提供していますが、同等の検知能力を持つAuditDルールを見つけるのは難しいです（コンテナ用のFalcoの検知ルールはかなりの数があります）。そこで、比較テストでは、少し極端なことをしてみました。FalcoルールとAuditDルールの両方をトリガーとする単一の操作でシステムにストレスを与えます（これは本番環境ではめったに起こりません）。

以下は、AuditDルールとFalcoルールの両方をトリガーするために使用したテストスクリプトです:

#!/bin/bash
# infinite loop
while [ 0 -eq 0 ]
do
        touch /etc/hello

done 

このようなプレッシャーを考えると、AuditDとFalcoはどちらもまともなパフォーマンスを発揮します。

AuditDは8コアノードのCPUの約15%を占めています：

そして、FalcoのCPU使用率は約9%です：

全体的に、FalcoとAuditDの両方が極端なストレステスト内でOKを実行し、syscallイベントがドロップされることはありませんでした。この特定のテストでは、Falcoの方がAuditDよりもCPUの消費量が少ないですが、これは包括的なベンチマークではないことに注意してください。

イベント転送におけるFalco vs. AuditD

セキュリティイベントを生成するのと同じくらい重要なのは、プロセスを自動的に終了させたり、適切なチームに通知したりするかどうかに関わらず、それらのイベントに対してアクションを起こすことです。

このセクションでは、トリガーされたイベントを消費またはエクスポートする方法について説明します。これは、セキュリティチームがセキュリティイベントを分析するために使用できるツールに影響を与えます。彼らは、これらのツールに対して異なる好みを持っている可能性があるため、これは検出製品で評価すべきユーザビリティの要因と考えます。

Falco イベントをリモートで転送する方法は複数あります：

• プログラム出力：サードパーティのプログラムを起動してFalcoイベントを送信します（例：curlを使用してFalcoイベントをSlackチャンネルに送信するなど）。
• HTTP出力：HTTPエンドポイントにFalcoイベントを送信します。
• Grpcサーバー：Grpcサーバを設定します。Unixソケットまたはネットワークのいずれかをリッスンし、Falcoイベントをプログラムで消費できるようにします。
• Falco Sidekick：ElasticSearch、Kafa、GCP PubSub、Influxdb、NATSなど、最も人気のあるイベントハブやメッセージバスにFalcoイベントを転送するためのツールです。

同様に、AuditDは監査イベントを転送するいくつかの方法をサポートしています。

• Remote syslog： audispdのプラグインであるaudisp-remoteは、監査イベントをリモートsyslogサーバに転送するように設定することができます。
• Elasticsearch：Filebeatは、監査イベントをElasticsearchに転送するためのAuditDモジュールを提供しています。

生の監査イベントのみが転送されることに注意してください。エンコードされたフィールドは、イベントハブで消費される前に意味のあるものになるようにデコードする必要があります。

全体的に、FalcoとAuditDの両方がイベント転送をサポートしています。Sidekick（Thomas Labarussias氏が作成したツール）の助けを借りて、Falcoのイベントを消費するのがかなり簡単になりました。

まとめ

FalcoとAuditDは強力なHIDSツールです。どちらも侵入を検知するためにシステムコールに依存していますが、ルールの作成とイベントデータの出力のアプローチには大きな違いがあります。

HIDSツールを選択する際には、生の機能以外にも、チームのスキルセットや長期的なセキュリティロードマップなど、他の要素を考慮することも忘れないでください。

このHIDS分析フレームワークが、正しいHIDSツールの選択に役立つことを願っています。

Falcoについて詳しく知りたい方は、FalcoのrepoとFalcoのウェブサイトをご覧ください。または、CNCFのFalco slackチャンネルに参加してください。また、Falcoプロジェクトにコントリビュートしたい方は、コントリビューターのページをご覧ください。