SIEM on Amazon OpenSearch Serviceの活用によるSIEMの導入

はじめに

ITシステムに対する脅威・攻撃は日々進化しており、画一的なセキュリティ対策でそのすべてを防ぐことは困難です。
このような状況への対応として、システムが出力する多くのログ・データを活用して脅威の予兆を早期検出し、プロアクティブに対応を取ることが求められます。

本記事では、アマゾンウェブサービス（AWS）のサービスを組み合わせてSecurity Information and Event Management（SIEM）を実装し、自社サービス基盤に適用した事例を通してSIEM導入のポイントについて解説いたします。

SIEM導入の目的と効果の概要

TISが提供する決済ソリューションブランド「PAYCIERGE」の基盤である「高セキュリティクラウド基盤サービス」は、クレジットカード業界のセキュリティ基準であるPCI DSSに準拠した高いセキュリティを実現したシステム基盤をご提供するサービスです。

この基盤サービスは、PCI DSSに準拠するだけに留まらず常にセキュリティの向上に向けた取り組みを推進しております。
需要に応じてサービスの拡大を続けた結果、2023年2月現在で数十のAWSアカウントを利用して運営しており、今後更に多くのお客様にご利用頂き拡大していくことが見込まれています。
高セキュリティを担保した上でサービスの拡大を続けることを目指した際に、我々としては近い将来以下のような課題に適切に対応していくことが必要になると考えました。

• 大量のAWSアカウント状況の一元的な管理
• リアルタイムでの各システムのセキュリティ状態把握
• 大量のセキュリティデータの有効活用

これらの課題への対応として、今回AWSがOSSで提供している“SIEM on Amazon OpenSearch Service”を導入しました。
その結果、1つのAWSアカウントに全AWSアカウントのログを集約し可視化することで、AWSアカウント数が増えても一元的に状況を確認することができるようになりました。
また、今回構築したダッシュボードは社内端末から閲覧することが可能であるため、必要時にリアルタイムでセキュリティ状況を確認・ダッシュボード上での分析を行うことができます。

これまで活用できていなかったセキュリティに関係するデータ・ログ類を可視化し分析できるようにしたことで、セキュリティインシデントの早期検知だけでなく、システム全般の異常にも気づきやすい状態を作ることができました。
このように当初課題として設定した3つの事項に対して効果を確認することができております。

SIEM on Amazon OpenSearch Serviceとは

SIEMはSecurity Information and Event Managementの略で、セキュリティ機器、ネットワーク機器、その他のあらゆる機器のデータ収集及び一元管理をして、相関分析によって脅威検出とインシデントレスポンスをサポートするためのソリューションです。

Amazon OpenSearch Serviceは、オープンソースのOpenSearchとOpenSearch Dashboardsまたは、Amazon Elasticsearch ServiceとKibanaを大規模かつ簡単でコスト効率の良い方法を使用してデプロイ、保護、実行する完全マネージド型サービスです。
Amazon OpenSearch Serviceの環境にSIEMとして必要な機能を実装したのがSIEM on Amazon OpenSearch Serviceです。
SIEM on Amazon OpenSearch ServiceはAWSがOSSとして公式にGitHub上で提供しているサービスとなり、2023年2月現在でログの取り込みに対応しているAWSサービスは26種類、ログは45種類です。

下図は、SIEM on Amazon OpenSearch Serviceを使ったAWS CloudTrailのログの可視化の例です。
IPアドレスに地理情報を付与するエンリッチメントを処理することで、送信元IPアドレスを世界地図にマッピングすることもできます。

AWSサービスのログをAmazon S3バケットにエクスポートをすると、自動的にAmazon OpenSearch Serviceに取り込まれてログ分析ができるようになります。
AWS以外のログもAmazon S3に保存をすると同様の仕組みでAmazon OpenSearch Serviceに取り込むことができます。

＜出典＞
「AWS サービスのログの可視化やセキュリティ分析を実現する SIEM on Amazon Elasticsearch Service 公開のお知らせ」
URL：https://aws.amazon.com/jp/blogs/news/siem-on-amazon-elasticsearch-service/
※2021年9月、Amazon Elasticsearch Serviceの名称はAmazon OpenSearch Serviceに変更されました。
「SIEM on Amazon OpenSearch Service」
URL：https://github.com/aws-samples/siem-on-amazon-opensearch-service/blob/main/README_ja.md

SIEMを導入するにあたって、我々はこのSIEM on Amazon OpenSearch Serviceを選択しました。
サービス選定のポイントは以下の3点です。

• 高セキュリティクラウド基盤サービスではAWSを使用しており親和性が高いため
• OSSとして公開されており、短いリードタイムで使用開始できるため
• 多くのAWSアカウントに存在する多種類のログを収集可能であるため

上記の中でも特にポイントとなったのは2点目のリードタイムの短さです。
商用のSIEM製品・サービスを利用する場合、製品選定から契約・利用開始までに数か月を要する場合もあり、更に利用を開始してから想定通りの効果が得られない場合の解約手続き等でも時間と体力を要するケースがあるということを危惧していました。
それに対しSIEM on Amazon OpenSearch Serviceでは、サービス自体は無料で利用することができ、作成されたAWSリソースに対してAWS利用料が課金される仕組みとなっています。
利用を開始するにあたり、手続きが不要ですぐに始められるという点は我々にとって非常に魅力的なポイントでした。

システム構成とそのポイント

今回のシステムの全体構成として、各業務システムが稼働するAWSアカウント（ソリューション用アカウント）と、ログを集約しAmazon OpenSearch Serviceが稼働するAWSアカウント（集約用アカウント）の二者が存在します。
集約用アカウントに対して、クロスアカウントで多数のソリューション用アカウントのログを集約し、一元管理を行っています。

下図は、全体構成図です。

SIEM on Amazon OpenSearch Serviceのデプロイは、AWS CloudFormationを利用する方法とAWS CDKを利用する方法の2種類がありますが、今回はAWS CDKを利用する方法を採用しました。
この理由は、セキュリティ面を考慮してAmazon OpenSearch ServiceをVPCのプライベートサブネット内に配置したいという目的があったためです。

OpenSearchをVPCのプライベートサブネットに配置する場合や、マルチアカウント環境下でログを集約分析する場合など、いくつかのケースについてはAWS CloudFormationではなくAWS CDKを利用することが求められています。
具体的な手順などは全てGitHub上で公開されていますので、CDKを初めて利用するという方でもAWSの経験があれば実施可能なレベルとなっています。

今回の構成で意識したポイントとしては、「独自の作り込みを極力排除する」という点です。
その意図としては、まずはSIEMをスピーディにスモールスタートして、SIEMの有用性を早期に確認したいということと、SIEM on Amazon OpenSearch ServiceはAWSが公式に提供しているものであり、その中に含まれているAWSのプラクティスをそのまま活用することがSIEMの有効な使い方につながるのではないかと考えたということがあります。
この方針の結果、デフォルト構成からの変更点としては「Amazon OpenSearch ServiceをVPCのプライベートサブネット内に配置する」という一点のみに抑えています。
これに伴い、Amazon OpenSearch Serviceダッシュボードへのアクセス制御はAWS WAF等も利用してセキュリティを担保した状態にすることができています。
また、今後のSIEMの展開を見据えた方針としても「スモールスタート」を掲げています。
初めから完全な状態で運用することを前提とせず、段階的に収集対象のログや運用内容を充実させることを方針としています。

2023年2月現在、第1段階で集約しているログは以下の6種類に絞っています。
その結果、約1人月でSIEM環境の実装とログ取り込み、ダッシュボード上での可視化という第1段階のSIEM導入を完了することが出来ました。

6種類のログを最優先として選定した理由は、調査が負担になるログをリアルタイムで分析できるようにするためです。
これらのログを集約・可視化した結果、ユーザーアクティビティやAPIの使用状況、セキュリティ基準が守られているかなどを迅速に確認することができ、インシデント発生の場合の相関分析が可能となりました。

SIEMを導入してからセキュリティインシデントと考えられる事象はこれまでに発生しておりませんが、ログの可視化・分析が容易になったことで、開発中のシステムにおいて一部不要な通信が発生していることを一目で検知することができた実績もあり、既にSIEMを入れたことによる効果を感じることができるようになっています。

今後SIEM導入の第2段階では、Amazon OpenSearch Serviceに取り込んだデータを使用して、セキュリティ関連の監視通知やレポーティングを充実させることで効率的な運用を可能にしていく想定です。
更に第3段階では、収集するデータ・ログの幅を拡大し、セキュリティ関連のデータ・ログだけでなく業務系のデータ・ログやAWSサービス以外のログを取り込むことで更にSIEMの価値を向上させていく考えです。

SIEMの運用

SIEMはあくまでログの相関分析を可能にするソリューションであり、それを適切に運用することで初めて脅威の早期検知、分析の迅速化、セキュリティインシデント対応の高度化を実現することが可能になります。
その結果、組織全体でインシデントの防止や被害の最小化が実現できます。

SIEM運用の代表的な項目としては以下表の様なものがあります。

“導入にあたってのポイント”でも記載した通り、今回はスモールスタートでスピーディにSIEMを導入することを重視しており、運用設計・構築に関しても同様の考え方で進めております。
具体的には、上表の各運用項目に対して須く詳細な運用内容を定義し、仕組みの実装・手順化を完了してから運用を開始するのではなく、まずはNo2の調査分析に限定してSIEMの利用を開始しています。

調査分析を最初の運用項目に選定した狙いは、これまで馴染みのなかったSIEMを実際に触る機会を多く持つことで、担当者がSIEMの価値を認識し、組織としてSIEMを活用したセキュリティ対策を行うことが当たり前の状態を作ることです。

調査分析に当たっては収集したデータの可視化が必要になりますが、この点に関して今回採用したSIEM on Amazon OpenSearch Serviceでは、2023年2月時点で17のダッシュボードが事前定義されており、データを取り込めばすぐに利用可能な状態となっています。

AWS Security HubやAmazon GuardDuty、AWS CloudTrailなど今回取り込み対象としたログ類のためのダッシュボードも存在したため、データの取り込み直後から可視化して運用を開始することができております。

現時点ではダッシュボードを通してアドホックな分析を担当者が行う運用となっていますが、SIEMの活用が定着した段階で、特定条件に基づいた監視通知及びレポーティング等に結び付けて効率化を図っていくことを想定しています。

SIEM導入のポイントまとめ

これまでご紹介してきたSIEM導入について、重要なポイントは2点挙げられます。
1点目は、SIEMをスピーディに導入するために「スモールスタート」をするという点です。
最初から完全に運用できるように作りこみに注力するのではなく、まずはSIEMを使い始めることを目標とすることが重要だと考えています。
今回我々はスモールスタートしたことによってスムーズにSIEMを始めることができ、現在次の目標の効率的な運用に向けて対応ができております。

2点目はSIEMの構築に留まらず、「SIEMを活用する」という点です。
今回はスモールスタートでスピーディにSIEMの利用を開始しつつ、“SIEMの運用”でも記載した通り、まずは調査分析に限定して活用し、当たり前にセキュリティ対策を行う状態を実現しております。

ここからは、我々が初めてSIEM on Amazon OpenSearch Serviceを導入してみた感想になりますが、CDKのデプロイで手順通りに実施すれば1時間ほどで完了できる点や、Amazon OpenSearch Serviceダッシュボードが見やすいため状況の把握が容易で、更に使いこなせば活用の幅が広がることが期待できる点から、構築のしやすさと共に活用のしやすさに気づくことができました。

導入に費用や時間のかかるイメージのあったSIEMでしたが、今回の経験を通して、SIEM on Amazon OpenSearch Serviceを導入することで比較的安価かつ短期間に導入できることがわかりました。
また、データ活用のためのシステム特有の注意すべき点としては、ストレージ管理の難しさにあると感じました。
具体的には、今回EBSボリュームサイズとして100GiBの設定をしていましたが、運用開始からわずか2週間程で不足する事態となってしまいました。
この原因としては普段我々が主に管理しているようなWeb系システムのストレージ等と異なり、今回のようなデータ活用のシステムでは毎日大量（今回は数十GB）にデータが増加していくということに対する意識が低かったことが挙げられます。
この対策として、データをEBSボリュームのみに格納するのではなく、検索可能で且つ大容量であるUltraWarmストレージや、長期的なデータ保管としてコールドストレージを活用して、データのライフサイクル管理を行うことにより解決に至っております。

＜参考＞
「Amazon OpenSearch Service の UltraWarm ストレージ」
URL：https://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/ultrawarm.html
「Amazon OpenSearch Service 用コールドストレージ」
URL：https://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/cold-storage.html

今後の展開

今回の記事では、PAYCIERGEの高セキュリティクラウド基盤サービスが運用を開始したSIEMについての概要と導入のポイントを解説しました。

高セキュリティクラウド基盤サービスは、PCI DSSやISO27017への準拠をはじめとした取り組みにより、サービス名称の通り高いセキュリティを実現しております。
その中で今回、更に高いレベルのセキュリティを追求すべくSIEMを導入いたしました。
今回の対応においては、AWSが提供するSIEM on Amazon OpenSearch Serviceを利用することにより、個別に製品を購入して導入する場合と比較して安価かつスピーディに実現することができたと考えております。

今後SIEMに取り込むログ種別を順次拡大し、SIEMをセキュリティ対策の中軸として活用していくことに加え、将来的にはセキュリティプロセスの連携及び自動レスポンスであるSOAR(Security Orchestration, Automation, and Response)など、より高度な運用を実現することによって、全てのお客様がPAYCIERGEを安心してご利用頂けるよう活動を進めてまいります。

著：TIS株式会社
DXビジネスユニット ペイメントサービスユニット
ペイメントプラットフォームサービス部
主査　二出川 弘