The Inside Playbook

Ansible によるセキュリティ自動化を始める:調査の強化

2020年4月6日、寄稿者: Roland Wolters (ローランド・ウォルターズ)

昨年 11 月、Red Hat は、IT セキュリティ業界全体での統合の欠如への対策として、Ansible によるセキュリティ自動化をリリースしました。セキュリティ運用者が抱える典型的な課題を Ansible で解決するシナリオの 1 つをご紹介します。

セキュリティ運用者が日々行っているタスクの大部分は、調査です。調査の強化はそのタスクの 1 つで、反復的で時間がかかる場合があり、まさに自動化するべき作業と言えます。これらのプロセスを最適化することで、アナリストはより戦略的なタスクに集中できるようになり、時間的制約のある状況での対応を迅速化し、人的ミスを減らすことができます。しかし、多くの大規模組織では、このようなアクティビティのセキュリティ・ソリューションにおいて、互いに統合されていない側面が複数存在します。そのため、IT セキュリティの側面ごとに担当するチームが異なり、場合によってはプロセスもチームごとに異なっています。

このような状況では、多くの場合、手動による作業が必要になり、チーム間でのやり取りが生じるため、エラーが起こりやすく、なにより時間がかかります。したがって、不審な事象が発生して調査が必要となっても、セキュリティチームは不審なアクティビティにすぐに集中することができず、さまざまなセキュリティ・ソリューションの運用や他のチームとの調整に多くの貴重な時間を費やすことになります。

このブログ記事では、Ansible がどのようにこうした課題の克服を支援し、調査を強化するためのアクティビティをサポートするのかについて詳しく説明します。次に示す例では、Ansible を使用して、SIEM に統合されていないテクノロジーからのログなどの情報に、プログラムでアクセスできるようにする方法を説明します。ここでは、エンタープライズ・ファイアウォールと侵入検知および保護システム (IDPS) を例として使用します。

シンプルなデモ設定

前述のシナリオにあわせて、きわめてシンプルかつ簡素化したデモ設定を作成しました。以後これを使用してやり取りを見ていきます。この設定には、不審なトラフィックに関する情報を提供する 2 つのセキュリティ・ソリューションと SIEM が含まれています。情報を提供するセキュリティ・ソリューションとして、Check Point Next Generation Firewall (NGFW) と Snort IDPS を使用します。それらのデータを収集して分析する SIEM は、IBM QRadar です。

また、「attacker」という名前のマシンから、IDPS が実行されているターゲットマシンでの潜在的な攻撃パターンをシミュレートします。

これは単なる基本的なデモ設定です。Ansible によるセキュリティ自動化統合の実際の設定は異なるものであり、他のベンダーやテクノロジーを搭載することができます。

ログ:重要だが分散されている

ここで、自分がある企業のセキュリティアナリストだと考えてみてください。アプリケーションの異常が通知され、ログに不審なアクティビティが記録されました。たとえば、以下のデモでは、Web サーバー (ここでは「web_attack_simulation」と呼ぶことにします) の特定のエンドポイントに対して curl を実行します。

$ sudo grep web_attack /var/log/httpd/access_log
172.17.78.163 - - [22/Sep/2019:15:56:49 +0000] "GET /web_attack_simulation HTTP/1.1" 200 22 "-" "curl/7.29.0"
...

セキュリティアナリストであるあなたは、異常は潜在的な脅威の兆候である可能性があることを知っています。これが誤検知で単純に無視できるのか、あるいは実際の脅威であり、一連の修復アクティビティを実行して停止させる必要があるのかを判別しなければなりません。そのためには、ファイアウォールや IDS などから、より多くのデータポイントを収集する必要があります。ファイアウォールと IDPS のログを手動で調べるには、かなりの時間がかかります。大規模な組織では、セキュリティアナリストが必要なアクセス権を持っていないこともあり、その場合はエンタープライズ・ファイアウォールと IDPS を担当する各チームに連絡し、各自手動でそれぞれのログを調査して異常を直接確認し、結果を報告してもらえるように依頼しなければなりません。これでは、電話、チケット、長い説明、必要なエクスポートといった作業のために、貴重な時間を消費することにもなりかねません。

大規模な組織では、イベント管理を SIEM で一元化し、それを調査のプライマリダッシュボードとして使用するのが一般的です。このデモでは SIEM の例として QRadar を使用していますが、ここに示す手順はどの SIEM にも当てはまります。セキュリティ関連のイベントを適切に分析するには複数の手順が必要で、まず対象のセキュリティ・テクノロジー (ここではファイアウォールと IDPS) を構成してログを SIEM にストリーミングする必要があります。さらに、これらのログを正しい方法で解析し、意味のあるイベントを生成するように SIEM を構成する必要もあります。これを手動で行うには時間がかかり、ドメインに関する深い知識が必要です。さらに、セキュリティアナリストにはない権限が必要になる場合があります。

しかし、Ansible を使用すれば、セキュリティ組織は事前に承認された自動化ワークフローを Playbook の形式で作成できます。それらを一元的に維持し、異なるチーム間で共有して、ボタンを押すだけでセキュリティ・ワークフローを有効にすることもできます。


これらのログを QRadar に永続的に追加しないのはなぜかというと、アラートが多くなりすぎる可能性があるからです。システムに過剰なデータが送り込まれると大量のイベントが生成され、重要なイベントが埋もれてアナリストに見逃されてしまう可能性があります。さらに、すべてのシステムからすべてのログを送信すると、クラウドリソースやネットワーク帯域幅がいくらあっても足りません。


そこで最初に、ログソースを構成する Playbook を作成して、ログを SIEM に送信させます。Snort で Playbook を開始し、すべてのログを SIEM インスタンスの IP アドレスに送信するように構成します。

---
- name: Configure snort for external logging
  hosts: snort
  become: true
  vars:
    ids_provider: "snort"
    ids_config_provider: "snort"
    ids_config_remote_log: true
    ids_config_remote_log_destination: "192.168.3.4"
    ids_config_remote_log_procotol: udp
    ids_install_normalize_logs: false

  tasks:
    - name: import ids_config role
      include_role:
        name: "ansible_security.ids_config"
        

この Playbook のタスクは、既存ロールのインポートだけです。ロールは Ansible の重要な部分であり、自動化コンテンツの構造化に役立ちます。ロールは通常、明確に定義された目的に必要なタスクとその他のデータをカプセル化します。上記の Playbook の場合は、さまざまな IDPS の構成を管理するロール ids_config を使用します。このロールは、一例として Ansible セキュリティチームから提供されています。このロールは、このブログ記事で言及している他のロールと同様に、Ansible に不慣れな顧客であっても、より迅速に生産性を向上できるようになるためのガイダンスとして提供されているものであり、必ずしもベストプラクティスやリファレンス実装として意図されたものではありません。

このロールを使用すると、いくつかのパラメーターに注意するだけで済みます。Snort 自体の構成方法に関するドメインの知識は不要です。次に、Check Point ファイアウォールでもまったく同じことを行います。log_manager という既存のロールが再利用されます。

- name: Configure Check Point to send logs to QRadar
  hosts: checkpoint

  tasks:
    - include_role:
        name: ansible_security.log_manager
        tasks_from: forward_logs_to_syslog
      vars:
        syslog_server: "192.168.3.4"
        checkpoint_server_name: "gw-2d3c54"
        firewall_provider: checkpoint
        

これらの 2 つのスニペットを使用すると、自動化された方法で 2 つのセキュリティ・ソリューションに到達し、ログを中央の SIEM に送信するために再構成できるようになっています。

これらのログを受け入れるように SIEM を自動的に構成し、QRadar で対応するストリームにソートすることもできます。

- name: Add Snort log source to QRadar
  hosts: qradar
  collections:
    - ibm.qradar

  tasks:
    - name: Add snort remote logging to QRadar
      qradar_log_source_management:
        name: "Snort rsyslog source - 192.168.14.15"
        type_name: "Snort Open Source IDS"
        state: present
        description: "Snort rsyslog source"
        identifier: "ip-192-168-14-15"

- name: Add Check Point log source to QRadar
  hosts: qradar
  collections:
    - ibm.qradar

  tasks:
    - name: Add Check Point remote logging to QRadar
      qradar_log_source_management:
        name: "Check Point source - 192.168.23.24"
        type_name: "Check Point FireWall-1"
        state: present
        description: "Check Point log source"
        identifier: "192.168.23.24"
        

ここでは、Ansible Content Collections を使用します。これは、自動化コンテンツを配信、維持、消費する新しい手法です。コレクションにはロールを含めることができますが、特定の環境の自動化を有効にするために必要なモジュールやその他のコードを含めることもできます。この例の場合、たとえばコレクションにはロールが含まれていますが、QRadar と対話するために必要なモジュールと接続プラグインも含まれています。

セキュリティアナリストがさらに介入しなくても、Check Point ログが QRadar ログの概要に表示されるようになります。これまでのところ、Snort から QRadar に送信されるログはありません。Snort は、このトラフィックが注目に値することをまだ認識していないのです。これについては、後ほど説明します。

セキュリティアナリストの視点で考えてみると、これで、より多くのデータを自由に利用できるようになりました。これにより、アプリケーションの動作に生じている異常の原因を探るための手がかりが増えました。ファイアウォールからのログが表示され、誰から誰にトラフィックが送信されているのかもわかります。しかし、これはまだ、何が起こっているのかを完全に把握するのに十分なデータではありません。

調査の微調整

自由に利用できるデータを活用するため、あなたは特定のパターンが検出された場合にアラートログを取得するために、IDPS にカスタムシグネチャを実装することを決定します。

典型的な状況では、新しいルールを実装するには、複数のインスタンスを手動で構成することになるであろう Snort 担当のセキュリティ運用者とのやり取りがさらに必要になります。しかし幸いにも、Ansible Playbook を再び使用して、時間のかかる手動の手順や他のチームメンバーとのやり取りを行わなくても、同じ目標を達成できます。


顧客固有の状況に対応する一連の Playbook を事前に作成するオプションもあります。Ansible の言語は YAML なので、知識の少ないチームメンバーでも Playbook に貢献することができ、アナリストがすぐに使用できる Playbook を事前に決めておくことができます。


ここでも、ids_rule というロールを再利用します。今度は、Playbook を機能させるために Snort ルールをある程度理解する必要があります。それでも、ロールのおかげで、さまざまなターゲットシステムにわたり Snort をサービスとして管理する方法についての実際の知識は不要になっています。

---
- name: Add Snort rule
  hosts: snort
  become: yes

  vars:
    ids_provider: snort

  tasks:
    - name: Add snort web attack rule
      include_role:
        name: "ansible_security.ids_rule"
      vars:
        ids_rule: 'alert tcp any any -> any any (msg:"Attempted Web Attack"; uricontent:"/web_attack_simulation"; classtype:web-application-attack; sid:99000020; priority:1; rev:1;)'
        ids_rules_file: '/etc/snort/rules/local.rules'
        ids_rule_state: present
        

攻撃を終わらせる

Playbook が実行された後、アラートが表示されているかどうかを QRadar で確認できます。実際、このデモ設定では以下のようになります。

この情報を入手したら、最終的に同じタイプの攻撃をすべてチェックし、すべてが単一のホスト (ここでは「attacker」) からのみ送信されていることを確認できます。

ここから、調査を続行できます。このデモでは、その動作が意図的なものだと想定しているため、攻撃を偽陽性としてクローズします。

ロールバック

最後に重要なことが 1 つあります。見過ごされがちですが重要なのが、すべての変更をロールバックすることです。すでに説明した通り、すべてのログを常に SIEM に送信すると、リソースを大量に消費します。

Ansible を使用すれば、ロールバックは非常に簡単です。基本的に、上述の Playbook は再利用することができ、ログストリームを作成しないように少々変更する必要はあるものの、再び削除できます。こうすることで、プロセス全体を完全に自動化すると同時に、リソースをできるだけ使いやすくすることができます。

まとめと次のステップ

必要なツールがすべて揃っていたとしても、CISO とそのチームの仕事は困難です。それらのツールが互いに統合されていないためです。セキュリティ上の脅威が存在する場合、アナリストは調査を実行し、インフラストラクチャ全体にわたって関連するすべての情報を追跡するとともに、何が起こっているのかを理解し、最終的にはあらゆる種類の修正を実行するために貴重な時間を費やす必要があります。

Ansible によるセキュリティ自動化は、セキュリティ・テクノロジーの統合と相互運用を可能にし、セキュリティアナリストによるセキュリティ・インシデントのより迅速な調査および修正を支援するように設計されています。

次のステップとして、このトピックについてさらに理解を深めるための多くのリソースを以下にご紹介します。



お問い合わせ・製品のご紹介

Red Hat Ansible Automationについてのお問い合わせは

ansible-jp@redhat.com

Red Hat Ansible Automation製品について

詳細はこちら