インフラストラクチャー部セキュリティグループの水谷 (@m_mizutani) です。

現在、クックパッドのセキュリティグループではセキュリティ監視を高度化に対して取り組んでいます。サービスに関連する部分の監視は以前からやってきたのですが、ここしばらくはそれ以外のインフラやオフィスで発生するセキュリティ侵害を検知することを目的とした監視基盤の構築に力を入れています。

昔は一般的にオフィス、インフラのセキュリティ監視と言えば、イントラネット内に閉じた環境でのログ収集から分析まで完結していたケースも少なくなったと考えられます。しかし現在だとインフラとしてクラウドサービスを多用したり、業務で使うツールをSaaSによって提供するという場面も増えているかと思います。このような状況だとセキュリティ監視のために見るべき箇所がばらけてしまうといったことが起こります。クックパッドでも積極的にSaaSやAWSを利用しており、個別のサービス毎にログは蓄えられているものの、それぞれを活用しきれていない状況が続いていました。この状況を改善するため、下記の図のように各所から必要なログをかき集めて利活用できる状態にすることが、「監視の強化」になります。

f:id:mztnex:20180529104148p:plain

必要なログを一箇所に集めてセキュリティ監視に利用できる状態を作ることで、以下のようなメリットがあります。

アラートの通知・対応フローを一本化できる: 監視している機器・サービスにおいて危険度の高いイベントが発生した場合にはセキュリティの担当にアラートとして通知してほしいですが、通知の方法が機器・サービス毎に異なると設定変更の漏れや、通知の受け取りをミスしてまう可能性もあります。例えば通知方法で言えば、メール通知のみ、syslogへの出力のみ、APIに問い合わせないとわからない、というようにバラバラなことはよくあります。また、通知するメンバーをローテーションしたりするといった管理もとても煩雑になってしまいます。これを一本化することで、どのような機器・サービスで発生したアラートでもスムーズに対応できるようになります。
ログの検索や分析が統一されたコンソールから実施できる: インシデントと疑わしい事象が発生したらそれが本当に影響があったのかをログを見ながら調査・分析しなければなりませんが、ログが適切に保存されているとしてもアクセスするためのインターフェース（コンソール）が分断されていると、検索や分析に支障がでます。経験したことがある方はわかるかもしれませんが、複数のコンソールをいったりきたりしながら様々な可能性を検証するという作業はかなりのストレスになります。また、作業が煩雑になり見るべきログを見逃したりログの相関関係を読み間違えることもありえます。これに対して、統一されたコンソールが用意されていれば同じキーワードで全てのログを一括して検索可能になりますし、データが正規化されていればまとめて分析することもでき、分析にかかる負担を大きく減らすことをできます。
ログの保全管理が容易になる: セキュリティ関連のログは監査の目的であったり、後から発覚したインシデントを調査するため、一定期間保全しておく必要があります。通常、各サービスのログもしばらくの間保全しておく機能を備えていますが、多くの場合は保全する期間がばらばらだったり、保全のポリシーが異なります。そのため管理が煩雑になり、必要な時にあるべきログが無いといったミスが発生しやすくなります。これを防ぐため、統一管理されたストレージにログを保全することで、保全の期間やポリシーの制御が容易になります。

この記事ではセキュリティ監視をするにあたって、実際にログの収集をどのように実施しているかを紹介し、さらに集めたログをどのように利用しているのかについても簡単に紹介したいと思います。

ログの収集

セキュリティに関連するログとして、主にインフラ（AWSサービス周り）のログ、オフィスネットワークのログ、スタッフが使う端末のログ、そしてスタッフが使うクラウドサービスのログという4種類を収集しています。こちらの資料でも少し触れていますが、全てのログは原則としてAWSのS3に保存し、その後S3から読み込んで利用するよう流れになっています。全てのログをS3に経由させるという構成は、以下の3つのポイントをもとに判断しました。

可用性が高く、スケールアウトするか: ログに限りませんが大量のデータを継続的にストレージ入れる際、一時的に流量がバーストするというのは稀によくあることであり、ストレージ側はそれに対応するような構成になっている必要があります。特にDBなどは負荷をかけすぎるとそのままサービスが死んでしまうこともありえますし、かといって普段から余分にリソースを割り当てるとお金がかかります。一方、AWSのS3は投入しただけだと何もできませんが、高い可用性とスケールアウトを実現しているストレージサービスです。「ひとまず保存する」という用途ではスケールアウトを気にする必要もほとんどなく、安定して利用できるというメリットがあります。
ログ送信元と疎結合な構成にできるか: ログの収集・処理ではログの送信元からログを処理し終えるまでの一連のフローを考える必要があります。例えば一気通貫でストリーム処理をするような構成だと途中の処理に失敗したらまたログの送信元からやり直しということになってしまいます。しかし、一度S3に保存しておくことで何かあっても送信元まで遡る必要がなくなります。また、送信元のサービスを開発・運用しているのが別の主体だったとしても「とりあえずS3に保存してもらう」というお願いができれば、セキュリティのチームはそこから先の面倒だけ見ればよくなり容易に責任分解ができます。
遅延が許容範囲に収まるか: 到着したログを順次処理していくシステムを作る場合、処理の目的によってどの程度の遅延まで許容できるかが設計に関わってきます。セキュリティ監視の観点で考えると一定のリアルタイム性が求められますが、その時間単位は必ずしも短くありません。例えば日本で大手のSOCサービスで監視および分析専属のスタッフがいる場合でも、通知や初動対応のSLAは10分〜15分程度となっています。クックパッドでも監視と分析をしていますが、専属のアナリストがいるというわけではないため対応に数分の遅れが出るのは運用上許容できると考えることができます。したがって、S3に一度ファイルを保存してから処理を実行しようとすると数分の遅延が発生する可能性がありますが、上記の理由により問題にはならないと判断しました。

加えて、S3にどのようなログを収集しているのかと、その収集の方法について紹介します。

インフラ（AWSサービス周り）のログ

クックパッドではサービスのためのインフラとして主にAWSを利用しています。インスタンスからのログ収集も必要ですが、それ以外にもAWSが様々なセキュリティ関連のサービスを提供しており、これも同様に収集して活用しています。

インスタンスのsyslog

各EC2インスタンスで発生するログを集約し、これもGraylogへと転送しています。こちらもここからインシデントを発見すると言うよりは、後からの調査に利用しています。インスタンスの種類によって細かい収集方法は様々ですが、基本的にはfluentdに集約され、その後でS3に保存されます。

CloudTrail

AWS上でのアクティビティをログとして記録してくれるサービスです。AWS上でのユーザやサービスの動きを追うことができるため、セキュリティインシデントに関連した分析だけでなく、デバッグやトラブルシュートにも利用されています。

CloudTrailは標準でS3にログを保存する機能があるため、これをそのまま利用しています。

GuardDuty

AWS上で発生した不審な振る舞いを通知してくれるサービスです。不審な振る舞いも深刻度でレベル分けされており、深刻度が低いものはEC2インスタンスに対するポートスキャン行為など、深刻度が高いものは外部の攻撃者が利用してるサーバと通信が発生していることを通知してくれます。

GuardDutyが検知した内容はCloudWatch Eventsとして出力されるため、これをLambdaで受け取ってS3に保存する、という構成で運用しています。

VPC flow logs

VPC内のインスタンスから発生する通信フローのログを保存しています。Flow Logsはインスタンスのネットワークインターフェースから発生した通信のフロー情報を全て記録してくれるため、アラート分析やインシデントレスポンスにおいて攻撃の影響判断や通信発生の有無を確認するのに役立ちます。

Flow logは通常CloudWatch Logsに書き出されるため、S3に格納するためにログデータのエクスポートを利用しています。

オフィスネットワーク関連のログ

NGFWのログ

通常のファイアウォールの機能に加え、通信の中身の一部も検査して脅威を検知・遮断してくれるNext Generation Firewall (NGFW) でオフィスネットワークの出入り口を監視しています。これによって怪しいサイトやマルウェアを配布しているようなサーバへのアクセスが検知され、場合によって自動的にブロックされます。

NGFWからは通信フローのログ、および脅威の検知やブロックのログの両方を収集しています。現在利用しているNFGWはsyslogでログを飛ばせるので、fluentdを経由してS3 output pluginを利用し、S3に保存しています。

DNSキャッシュサーバのログ

弊社で利用しているNGFWは通信のTCP/IPフローのレベルの情報は残してくれますが、IPアドレスとポート番号および通信量などの情報しかわからないので、どのような通信がされていたのかは把握が難しい場合があります。そこで名前解決のためのDNSのログをとっておくことで、分析のための材料を増やしています。IPアドレスだけだと判断が難しくても、どのドメイン名のホストと通信したかがわかることでインシデントを追跡できることがしばしばあります。

オフィスではDNSのキャッシュサーバとして unboundを利用していますが、出力されるログの形式が利用しづらいことから、unboundのログは直接利用していません。代わりにキャッシュサーバ上で packetbeatを動かしてパケットキャプチャし、DNSのログを収集したものを fluentd + fluent-plugin-beatsを経由してS3に保存しています。

DHCPサーバのログ

現在クックパッドではスタッフが使うPCに端末管理のソフトを導入していますが、このソフトは端末がどのIPアドレスを利用していたかを過去にさかのぼって調べられません。そのため、DHCPのログも別途保存しておくことで、後から分析する場合でもそのIPアドレスを使っていたのがどの端末だったのかを追跡できます。

クックパッドでは kea DHCP server を運用しています。標準で出力されるログに必要な情報が載っているので、fluentdのtail input pluginでAWS S3にログを保存しています。現状では kea DHCP server ログを読み込むための成熟した専用 fluentd plugin は無いようだったのでひとまず1行1ログとして扱い、後からパースして必要な値を取り出すようにしています。

スタッフが使う端末のログ

アンチウィルスソフトのログ

クックパッドではアンチウィルスソフトとしてCylance PROTECTを採用しており、マルウェアと疑わしいファイルの検知情報をアラートとして利用しています。

この製品はマルウェアと疑わしいファイルや振る舞いを検知した後にログをSaaS側で収集してくれます。現状ではLambdaから定期的にSaaSのAPIをポーリングし、新しいイベントが発生していることを検出した場合はS3に新たにログファイルを生成するようにしています。

スタッフが使うクラウドサービスのログ

G Suite

書類、メール、カレンダーなどを一通り利用しているG Suiteでは各操作のログを取得しています。これによって何か問題が発生したときにスタッフが業務で利用している書類がどこかへ持ち出された形跡があったかどうかなどを調べることができます。

G SuiteではReports APIが用意されており、これを使ってAdmin activity, Google Drive activity, Login activity, Mobile activity, Authorization Token activityを取得することができます。これらAPIにLambdaで定期的にアクセスし、ログデータとしてS3に保存しています。

Azure AD

Azure Active Directory (AD) は Single Sign On のサービスとして利用しており様々な外部サービスを利用する際の認証のハブになっています。こちらも何か問題があった場合にどの端末からどのサービスへのアクセスがあったかを辿ることができます。

Azure ADも監査APIが用意されており、ログインなどに関連するログを抽出することができます。これをG Suiteと同様に定期的に実行し、新しく取得できたものについてログデータとしてS3に保存しています。

集めたログの利用

本記事のテーマはログの収集ですが、集めた後にどのように利用しているかについても簡単に紹介します。S3に集められたログは現在は主にアラート検出とログ検索・分析の2つに利用されています。

アラート検出

ここでいうアラートとは「影響があったかどうか確定ではないがセキュリティ侵害があったかもしれない」という状況を指します。現在、開発の都合で複数のログを組み合わせたいわゆる「相関分析」まではできていませんが、インシデントの懸念があるログが到着した場合にアラートとしてセキュリティグループのメンバー（担当持ち回り）で発報して対応を促します。具体的には以下のようなログを利用しています。

NGFWがアラートとして不審なサイトなどへのアクセスを捉えた時
Cylanceがマルウェアと疑わしいファイル・プロセスを発見した時
GuardDutyが一定以上の深刻度があるイベントを報告してきた時

これらのログが発見された場合、統一された形式にログを変換した上でアラートとして発報されます。担当のセキュリティグループのメンバーは誤検知か否かを分析し、影響があるかもと判断された場合は然るべき人に協力を仰いだり、PCそのものやログの追加調査を実施します。

f:id:mztnex:20180529104217p:plain

検出されたアラートはPagerDutyによって担当のメンバーに通知される

ログの検索・分析

冒頭で述べた通り、集めたログは横断的にログを検索できることが真価の1つになります。クックパッドではログ検索のために Graylog を導入して検索コンソールを構築しています。現状、VPCのフローログやサービスのログといった劇的に流量が多いログについては投入せずにAthenaで検索できるようにするなど工夫をしていますが、それ以外については概ね先述したログをカバーできるようになっています。

これらのログはセキュリティグループのメンバーだけでなく、スタッフは（一部を除いて）ほぼ全てのログにアクセスできるようになっています。そのため、セキュリティの用途だけではなくインフラなどが関係するトラブルシュートにおいても利用されることがあります。

日常的な運用でこのログをひたすら眺めるというようなことはしていませんが、アラートを検出した時に関連するログを調べるために利用するケースが多いです。そのアラートの前後に発生したログや関連するキーワードが含まれるログを読み解くことで、そのアラートは我々にとってセキュリティ侵害の影響をおよぼすものなのか？ということを判断しており、このような作業をログの分析と呼んでいます。複数のコンソールをとっかえひっかえすることなく、キーワードと時間帯を指定するだけで関連するログの分析ができることで、アラート検出時に必要な作業量・時間を大幅に短縮しています。

例えば、GuardDutyから「あるユーザが普段と異なるネットワークからAPIを操作している」というアラートが発報されたとします。その時、Graylog で該当ユーザ名とその前後の時間帯を検索すると例として G Suite でサービスにログインしたログ、そのユーザ名についてメールでやりとりされたログ、AWSで他のAPIを発行したログを一気通貫で見ることができます。これによって、そのユーザがその時間帯にどのような活動をどのネットワークからしていたのかがワンストップで確認できるようになり、それが正規のユーザの活動だったのか、それとも外部の悪意あるユーザがなりすましていたのかを容易に判断できるようになります。

f:id:mztnex:20180529104231p:plain

関連するキーワードと時刻を入力すると複数種類のログを時系列順に一括して見えるのでスムーズに全体像を把握することができる

実装の構成

ここまで解説したログの収集・分析の基盤は以下の図のような構成になります。

f:id:mztnex:20180529104346p:plain

ログ収集のパートで説明したとおり様々な手段を使っていますが、ログは必ずS3に集約するようになっています。S3のバケットはログの種類やサイズ、他のコンポーネントとの兼ね合いで分かれており、流量が大きいものは専用のバケットを用意して、そうでもないものは1つのバケット内でprefixだけ分けるようにしています。

S3にログが保存されると AWS Simple Notification Service (SNS) にイベント通知が飛び、そこからログの転送やアラート検知に関する処理が実行されます。それぞれの機能はAWS CloudFormation (CFn) によって構成されています。このCFnの中身については別記事にて解説していますので、興味がありましたらご参照いただければ幸いです。

まとめ

今回の記事ではオフィスやSaaS、それにインフラ（AWS）からなぜログを収集するのか、そしてどのようなログをどのように収集しているのかについて事例を紹介させて頂きました。クックパッドでは現在、ログ収集だけでなくアラートの検出やアラート発生時の対応に関する取り組みもセキュリティ監視の一環として進めているため、それらについてもいずれ紹介できればと考えています。