ある研究者の手記

セキュリティとかゲームとかプログラミングとかそのへん

AWSにおけるお手軽セキュリティ監視運用のはじめかた 2019(Cookpad Tech Bookより)

はじめに

  • この文章は技術書典7で頒布されたCookpad Tech Bookに寄稿させてもらったものの転載になります。基本的に加筆などはしていませんが、一点だけSecurityHubに関する記述に間違いがあった(自動通知の機能がない、という誤った情報を記載していた)のでその点だけ修正しています。
  • 御存知の通り、2019年12月初旬に開催されたAWS re:Invent 2019において色々な新しいサービスが発表されました。なかでもAmazon DetectiveAmazon Fraud Detectionはセキュリティ関連サービスの中で注目すべき存在になっており、今後のAWSセキュリティ監視の中で重要なポジションになる可能性があります。この文書は2019年9月ごろ書かれたものなので当然それらの内容には触れていませんが、それについてはまたいずれ別の形でアウトプットしたいと考えています。

クラウドの時代になってもセキュリティのやっていきは必要です。クラウド上だと多くのマネージドサービスが提供されているためオンプレミスの環境よりもセキュリティの機能を実現しやすい側面はありますが、それでもまだすべてを頼り切ってよいほど進化しているとはいえないのが現状です。やらないといけないセキュリティの機能はさまざまですが、ここではAWS、およびセキュリティ監視(セキュリティ被害の発生の兆候を検知し分析すること)に焦点を当てて、マネージドサービスを活用したセキュリティ監視の小さなはじめかたについて解説したいと思います。また、マネージドサービスの初期設定方法についての解説は世の中に多くありますが、継続的に使っていくためにはどうすればいいか?ということを説明したものはあまりないため、ここではそういった運用に焦点をあてて説明します。

セキュリティ監視

この文章における「セキュリティ監視」とは「自分達が運用しているシステムやサービスに発生しうるインシデントの兆候を検知し、それを分析して監視対象の環境に影響があるかを判断すること」とします。 インシデントとはある人物による作為的な攻撃によって、システムやサービスに何かしら変化が発生し、それによってビジネスや仕事に悪い影響が発生することとします。 わかりやすい例として、業務用PCがマルウェアに感染してしまったり、サービスに侵入されてしまう、という状況を想像してもらえるとよいかと思います。

侵入口を潰したり攻撃そのものを遮断したりする「防御」とは異なり、何かが起きた際にそれを迅速に発見し対応できるようにすることを目的としています。

なぜセキュリティ監視するのか

はじめにそもそもなぜセキュリティ監視が必要なのか?という理由について簡単に説明したいと思います。

  • すべての攻撃を完璧に防ぐのは不可能である: 「監視などするまえにそもそも防いでしまえばいいのでは」という説はありますが、システムに侵入しようとする攻撃の手法やそれをとりまく環境は日々変化し続けており、それに完璧に追従するのは困難です。特に攻撃に利用される脆弱性は次々と新しいものが発見されており、長年使われていたオープンソースのソフトウェアでも例外ではありません。攻撃を防ぐためにはどのような攻撃がくるかということをあらかじめ知っている必要があり、日々状況が更新されていくような環境では防御だけにすべてを頼るのは厳しいといえます。
  • 防御の対策は利便性を阻害しがちである: それでも防御を重要視していこうとすると、今度はユーザーの利便性が阻害されてしまいます。防御とは攻撃と疑われる行為を発見したらそれを止める対策です。防御でなるべく多くの攻撃を止めようとすると、ちょっとでも不審な動きがあればその動きを遮断するような方向に調整しなければなりません。それによって正規のユーザーによる正常な動作も不審とみなされてしまい(これを False Positive と呼びます)システムやサービスへのアクセスを止められてしまいます。極端な例として、パスワードを一度間違えたら1日はアクセスできなくなってしまうサービスを想像してみてください。うかつなパスワードを設定していても突破される可能性は低くなりますが、本来のユーザーによる正規のアクセスも妨げてしまいます。もちろんこのような措置が必要な場合もありますが、多くの場合は利便性とのバランスを考えなければなりません。

以上の理由により、防御となる対策を入れることはもちろん重要なのですが、防御だけですべての攻撃から守ろうとするのはあまり現実的ではありません。監視と併用することによって利便性、安全性、コストのバランスのとれたセキュリティを実現していくことができるようになります。

セキュリティ監視を構成する「検知」と「分析」(と「対応」)

セキュリティ監視というプロセスは主に「検知」と「分析」、そして「対応」という3つのフェイズからなっています。これらはそれぞれがキッチリと分離しているわけではなく、検知と分析が被る部分、分析と対応が被る部分がそれぞれあり、互いに影響しあっていると考えてもらえればと思います。

f:id:mztnex:20191223202935p:plain
aa

セキュリティの製品やサービスでは検知に特化したもの、分析に特化したもの、両方の性質を兼ね備えたものなど、いろいろな種類のものがあります。ただ、今回は特に検知と分析がそれぞれわかれたサービスについて説明します。

用語の定義

  • インシデント : ある人物による作為的な攻撃によって、システムやサービスに何かしら変化が発生し、それによってビジネスや仕事に悪い影響が発生すること
  • イベント : サービスやシステム内で発生する事象を一括にした呼び方。Webサービスへのアクセスからプロセスの起動など、粒度はさまざま
  • アラート : セキュリティ監視のためのプロダクトやサービスが、インシデントの可能性があるイベントを発見し、それについて発報したもの
  • ログ : イベントとして発生した事象の詳細を記録として残したもの

f:id:mztnex:20191223203132p:plain
セキュリティ監視の説明に出てくる要素の関係性。抽象化しているためこのモデルに当てはまらないものもあるが、おおよその関係性ということでご容赦願いたい

検知

監視している対象のサービスやシステム内で発生したイベントの情報から、セキュリティ上問題がある事象をみつけだすことを「検知」とします。たとえばアンチウィルスソフトウェアはディスクに保存されたファイルの内容からマルウェアを検知するというのが分かりやすい事例かと思います。他にもイベントが記録として残ったログを集めて分析し、不審な行動を探し出すSIEM(Security Information and Event Manager)も検知の機能があるといえます。また、機械ではなく人間がログや現在進行中のイベントなどをみて根性で怪しい現象に気づく、というのも検知にあたります(定常的にこれをやるのはあまりお勧めできません)。

しかし、これらはあくまで「可能性」であり実際にサービスやシステムに影響を及ぼしていると断定した形で報告されることは稀です。そこで、発見された事象が本当にインシデントなのかを判断する作業が必要になります。

分析

検知された事象が実際にサービスやシステムに影響を及ぼしたのかを調べるのが「分析」です。検知のためのサービスやプロダクトはインシデントの可能性が高い事象を発見してくれますが、これはあくまで可能性にすぎません。 本来は検知の段階でインシデントであることを確定させてから通知してくれればいいのですが、残念ながら現代のセキュリティ監視のサービスやプロダクトをそのまま使うだけでインシデントを正確に発見するのは困難です。 これはなぜかというと、組織ごとにルールやサービス・システムの運用方法の違い、業務内容の違いがあるからです。

たとえば、AWSのコンソールに普段は見られない国に所属しているIPアドレスからのアクセスがあり、ログインに成功したとします。 後述する Amazon GuardDuty はこういった通常見られない不審なアクセスをアラートとして発報してくれます。 このアラートではIDとパスワードなどの認証情報が盗まれ、第三者が不正にAWSのコンソールにログインした可能性を示唆しています。 では、このアラートがあがった時点でそれをインシデントと断じることができるでしょうか。

ある組織のルールとして「業務は必ずオフィス内で実施すること」と決まっていたとしたら、自国外からのログインはかなりの確度でインシデントとみていいでしょう。 しかし、リモートワークが前提の組織であったとしたらどうでしょうか。スタッフは場合によっては他の国にふらっと旅行にいって、旅先で仕事をしているかもしれません。 そうした場合、通常と違う国からのアクセスが一概に危険とは言い難いです。また、ルールが厳しい前者の組織であってもたまたま出張にでていて例外としてアクセスしていた可能性もあります。 このように組織のルールや内部事情などによって発見された「インシデントの可能性があるもの」が本当にインシデントなのかを、他のデータと突き合わせながら判断するフェーズを「分析」と呼んでいます。

分析では業務内容などに照らし合わせてアラートの判定をする他に、サービスやシステムのログをみてアラートの内容を精査するというアプローチがあります。 さきほどの例から考えると、直接本人に「今、旅行中ですか」と尋ねる方法もありますが、一方で他の社内システムのログを検索することで「しばらく前からいつもと違う国で仕事していたのだな」ということを確認できます。(もちろん、AWSへのアクセスとその社内システムの認証系が別になっていることが前提ですが) 他にも「ある人物による不審な動きが観測された」というようなアラートがあったときに、具体的にどういった動きがあったのかを確認できれば、それが通常の業務の範囲内なのか、それとも逸脱した行為をしているのかということを判断できます。

こういった判断を重ね、発報されたアラートから本当に自組織に対して被害を及ぼすインシデントを発見する、というステップが必要です。実際にインシデントと判断できるものを発見した場合、「対応」のフェーズに移っていきます。

対応(余談)

「対応」は実際に何かしらの被害が発生した際、被害状況をまとめる、被害を軽減する、被害から回復させるといった行動です。 もちろんこれはサービスやシステムを運用する上で重要な対策ではあります。 ただ、やり方がサービスやシステムの構成に大きく依存しており、さらに直接的にこれを支援するAWSのサービスは(今の所)あまりないようなので、今回の解説からは省きます。

ただ今回ひとつ触れておきたいのは、冒頭で述べたとおり分析と対応はきれいに分離されている訳ではない、ということです。 実際の現場では、インシデントと確証はないがかなり怪しいとなったら影響の少ない範囲ですばやく対応を開始する場合も多いです。 これについては筆者もそこまで経験が豊富ではないためあまり多くは語れませんが、発生している事象のリスクと周りに対する影響などを判断しつつ、バランスをとりながら対応することは必ずしも容易ではありません。

セキュリティ監視に使えるAWSサービスとその役割

前置きが長くなりましたが、今回のテーマである「セキュリティ監視を既存(2019年9月現在)のAWSでどうミニマムに実現できるか?」に話を移していきたいと思います。 「AWS セキュリティ」でググってみていただくと分かると思いますが、当然ながらセキュリティは監視だけにあらずで、さまざまなサービスがでてくると思います。 今回はここまで説明した監視だけに絞り、サービスそのものと構成の例について説明したいと思います。 まず次の4つのサービスについて簡単に説明します。各サービスの詳細についてはそれぞれ公式ドキュメントをご覧ください。

  • Amazon GuardDuty
  • AWS Security Hub
  • CloudTrail
  • VPC Flow Logs

検知に役立つAWSサービス

Amazon GuardDuty

Amazon GuardDuty はAWS上で起こる不審な挙動を検出してくれるサービスです。 詳細な動作について細かなアルゴリズムなどは公開されていませんが、一部設定のセキュリティ上の問題をみつけてくれる他、機械学習を利用して通常と異なる動作(EC2インスタンスによる普段と異なる通信、AWSコンソールへの不審なアクセス)を検知してくれます。 具体的な検知内容については https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html をご覧ください。

GuardDutyは基本的にはCloudTrailのログ、VPC Flow Logs、そして内部DNSの問い合わせデータを利用して検知をしており、それらのデータから見えないイベントは見ることができないようです。 たとえば、インスタンス内部に悪性プログラムが静かに潜んでいるのを検出するといったようなことはできないはずです。(通信が発生すれば別ですが) そのためAWS内で発生するすべてのインシデントを網羅できるわけではないのですが、 それでもCloudTrailから見えるAWSリソースの操作、 およびVPC内部での通信状況に関しては監視できるため、 AWS利用の中でそれなりに大きな部分をカバーできるといえます。 また、利用料金も全体のAWS利用料のおおよそ1%程度になるといわれており、 一般的な商用セキュリティサービス・プロダクトに比べてかなりリーズナブルになっています。

AWS Security Hub

AWS Security Hub はGuardDutyをはじめとするAWS、あるいはサードパーティのセキュリティ監視検知結果を統合する機能を持っています。 また、AWSのベストプラクティスを元にしたCIS(Center for Internet Security)ベンチマークという機能もあり、AWS上のセキュリティ関連設定の不備について通知してくれます。

AWS Security Hub はそれ自身が検知をする機能を提供しているわけではないのですが、サードパーティのセキュリティ監視サービスやプロダクトからのアラートを統合してくれる点に強みがあります。 セキュリティ監視をするうえで手間がかかることのひとつは複数のサービスやプロダクトを利用する際に、ちゃんと統合して使えるようにすることです。 これはSIEM(Security Information & Event Manager)という製品がより上位の機能を提供しているので、状況によってはSIEMを使ったほうがよいかもしれませんが、Security Hubの方が機能が限定的な代わりに多くの場合SIEMより安価なので、今回は Security Hubを軸として説明します。 仮にGuardDutyしか使っていない状況だったとしても、今後セキュリティ監視に利用するサービス・プロダクトを容易に追加するために最初から導入しておくのがお勧めです。

分析に役立つ(データを蓄積してくれる)AWSサービス

AWS上で分析をするにあたり、なるべく多くのログを保存できたほうがいいのはいうまでもありません。 しかしサービスなどから出力されるログは環境によってまちまちで、一概に説明するのは難しいものです。 そのため、ここでは共通して利用したほうがよいサービスについてのみ解説します。

CloudTrail

CloudTrailはAWS上での操作をAPI単位で記録するサービスです。 AWSではコンソールを含むすべての操作がAPI経由で実行されており、そのログを追うことでどのリソースがいつ作成、変更、削除されたのかを追いかけることができます。

CloudTrailはAWS上でのユーザーの挙動を追跡したり、リソースに関する履歴を調べるのに役立ちます。 アラートの分析をしていると「このユーザーは何をしようとしていたのか」「このリソースはいつ誰が作ったのか」などを確認する必要がたびたびあります。 そのユーザーやリソースについて自分達が記憶していたり、すぐに聞いて分かる状態であればいいのですが、ちょっと前のことになると人は記憶を失ってしまうため、ちゃんとログに頼って検証できる状態にしておくのが望ましいです。 CloudTrailは利用しているアカウントの全リージョンに対し一括有効化できる機能があるため、ひとまず有効化しておいてよいサービスかと思います。

VPC Flow Logs

VPC Flow LogsはVPC内の通信を記録してくれるサービスです。 記録と言ってもその名のとおりフローの情報のみ、つまり送信元IPアドレス、宛先IPアドレス、ポート番号、転送データ量、パケット数、といったような通信の一部の情報のみで、通信の内容については取得されません。 もし通信の内容を取得したい場合は、VPC Traffic Mirroringを利用できます(詳しくは @{Webサービスへのログを取得する} で解説します)

VPC Flow Logsは現状だと一括で有効化する方法は提供されておらず、VPCごとに個別に設定をしていく必要があります。 全VPCで設定を有効化したい場合は、AWS Configを使ってFlow Logsが有効になっていないか探すか、(手前味噌ですが)次のようなツールを使って一気に有効化するというのがよさそうです。

AWSにおけるセキュリティ監視の構成例

では、実際にこれらのサービスをどのように使うかを、検知と分析それぞれの観点から説明したいと思います。 それぞれのサービスを有効化する方法などは公式ドキュメントやWeb上の記事に多く解説がありますので、ここでは触れません。 代わりにどのような構成で使うのがよさそうかという、筆者の視点からみたベストプラクティスについて説明します。

検知のための構成

f:id:mztnex:20191223204328p:plain
検知のための構成

検知をするためのお勧めの最小構成が上記の図です。 Security Hubを中心として、GuardDutyを有効にし、さらに他のセキュリティ監視サービスやプロダクトを使っており、Security Hubとの統合機能が提供されているのであれば、それも統合していきます。 GuardDutyは有効化されていれば自動的に統合されるはずですが、念のためSecurity HubのSummaryページから統合されているか確認してみてください。 これによって検知に関する情報がSecurity Hubに集約され、Security Hubのダッシュボードを見るだけで、対応すべきアラートの一覧を確認できます。 セキュリティ監視サービス・プロダクトが2、3程度だと実感しにくいかもしれませんが、コンソールが別々に分離しているとサービスやプロダクトの数が増えることで作業の手間が指数関数的に煩雑化していきます。 セキュリティ監視の対応(特にアラートの分析まで)は日常のルーチンワークになりがちなので、こういったコストを低減できるうちに取り組んでおくことに価値があります。 Security HubのFinding(本文書でいうところの「アラート」)はCloudWatch Eventsからイベントを発行できるため、Lambdaでそれを受信し各所に通知するなどの自動対応に繋げることができます。

分析のための構成

f:id:mztnex:20191223203527p:plain
分析のための構成

分析のための構成はよりシンプルです。 ここまでで説明したCloudTrail、およびVPC Flow LogsをそれぞれS3 Bucketに保存します。 図中では同じS3 Bucketに保存していますが、監視対象の規模が大きい場合はオブジェクト数が多くなるため別Bucketにするのがよいでしょう。 それぞれ、標準でS3 Bucketに直接ログを出力する機能があるので、それを利用してください。

そして保存したログを検索する方法についてですが、まずはAmazon Athenaを利用することをお勧めします。 詳しい説明は公式ドキュメントなどに譲りますが、簡潔に説明するとS3 Bucket上にあるログデータなどを並列で一気に読み込み、記述したSQLのような命令にしたがって検索、集計、表示をするサービスです。

このサービスが今回のセキュリティ監視に適している理由として、サービスの料金が読み込んだデータ量の従量課金である、ということが挙げられます。 セキュリティ監視における分析は重要なタスクですが、業務時間において四六時中発生している状態は望ましくありません。(もしアラートがひっきりなしに発生している、という状況であれば @{対応するアラートを選別する} をご参照ください) そのため事業内容のデータ分析などと違い、特定の瞬間のみログを検索できるような仕組みのほうがリーズナブルです。 Athenaはこういった要件によくマッチしていることもあり、まずセキュリティ監視の仕組みを作る初期段階にお勧めできます。 具体的な検索の手順などについては次のドキュメントをそれぞれご参照ください。 特に「S3パスの日付を指定して、ある特定の日付からのみ検索する」というテクニックを使うことで、検索範囲を狭め(=読み込むデータ量を減らし=安い料金で)検索結果もより高速に取得することができるようになります。

さらに一歩進んだ監視をしたい場合

今回紹介したのはあくまで最初に取り組む、いわば初期装備とでもいうべき構成となっています。 いずれ何らかの形で改めて紹介したいと考えていますが、セキュリティ監視をより充実させるためにできそうな取り組みのポイントだけ取り上げたいと思います。

また、解説という体になってはいますが、筆者もまだ試行錯誤を続けている段階のものが多くあるため、よい解決方法などをお持ちの方がいたらぜひご教示ください。

Webサービスへのログを取得する

AWSを利用する目的として、かなり多くの方々が「Webサービスの提供」を挙げられるのではないかなと想像しています。 Webサービスを提供している場合「攻撃のための侵入口」としてWebサービスそのものが利用されるのは現代においては自明といってもいいでしょう。 そのため、自分達が提供しているWebサービスまわりのリソースについてのアラートが発報された場合、Webサービスでどのようなことが起こったのか調査できるように、ログを取得・保管しておくことが望ましいです。

通常、セキュリティ監視が目的でなかったとしてもWebサービスに関連するログの一部は取得している場合が多いのではないかと想像しています。 特に次の3点については監査やトラブルシューティングのために何らかの形で保管していることが多いと思われるため、それらをセキュリティ監視の分析でも使えるようにするというのが最初のステップかと考えられます。

  • Reverse Proxy、Load BalancerなどWebアプリの手前の中継機能のログ
  • HTTPサーバなどのミドルウェアのログ(あれば)
  • Webアプリ本体のログ

多くの場合、これらのログは送信元のIPアドレスやリクエストが送信された対象のホスト、URI、一部のクエリなどが含まれており、分析に最低限必要な情報は取得できます。 しかし一方でPOSTリクエストなどに含まれるBodyのデータは見えなかったり、リクエストのヘッダ部分の情報が一部欠落しているケースが多く、そういった部分に攻撃コードが含まれるような場合は追跡が難しくなってしまいます。 (これらの欠落してるデータはデータ量が多い、センシティブなデータが含まれる、というケースがあるので当然といえば当然なのですが) これについては筆者も最適解はまだわかっていませんが、現状AWSサービスで解決するとしたら次の2つを検討します。

  • AWS WAFを使う: AWS WAF(Web Application Firewall)は防御の機能だけでなく、どのようなリクエストが発生してどのルールにマッチしたか・しなかったのか、をログとして残すことができます。ログを残す目的だけ(=トラフィックを止めないの)であればAWS WAFはCloudFront、あるいはALBに関連付けするとすぐ使えるようになるので、既存Webサービスがこれらを使っていた場合は非常に容易に展開ができます。ただし現状(2019年9月現在)はリクエストのBodyの内容は取得できないため、POSTなどによる攻撃の追跡は難しいという欠点があります。
  • VPC Traffic Mirroringを使う: VPC Traffic Mirroring機能はWebサービスに限らずEC2インスタンスなどENI(Elastic Network Interfaces)の通信をパケットレベルですべてコピーし、別のインスタンスなどに送信できるサービスです。完全な通信のコピーを取得できますが、パケット単位で通信が送られてくるため、HTTPリクエストの形に直すためにはツールなどでうまくTCPセッションを復元してあげる必要があります。また通信量も莫大になるため、よりシビアにコスト計算をしたり、運用時のパフォーマンスを考えねばならず、全体的に負荷は高めといえます。

どちらの方法もかなりの量のデータを取り扱うことになるため、どの程度の料金が発生するかなどを事前によく試算してから利用することを強くお勧めします。

その他使えそうなAWSサービス

今回は紹介しませんでしたが、その他セキュリティ監視に利用できそうなサービスをご紹介します。

  • Amazon Macie: S3上に個人情報などセンシティブなデータが保存されていないかをチェックしてくれるサービスです。セキュリティ監視の文脈では有効なサービスではあったのですが、残念ながら2019年9月現在では us-east-1 (バージニア)と us-west-2 (オレゴン)のみでしか利用できないので今回は対象外にしました。
  • Amazon Inspector: EC2インスタンスにインストールされている脆弱なパッケージなどを報告してくれるサービスです。どちらかというと予防の側面が強かったため今回は取り上げませんでしたが、これも利用できると分析時に「この攻撃に対して対象のEC2インスタンスは脆弱だったか?」という検証がしやすくなるため、セキュリティ監視に取り込む検討をしてもよさそうです。

インスタンス内部の情報を取得する

Webサービスに対するリクエスト同様に、今回のセキュリティ監視の構成で取得できていないものとしてインスタンス内部のイベントに関するログがあります。 GuardDutyは「あるインスタンスで不審な活動があった」ということまでは教えてくれますが、インスタンスの中のどのプロセスがその不審な活動をしたか、までは教えてくれません。 (このあたりについて詳しく知りたい場合はAWSの責任共有モデルを調べてみることをお勧めします) そのため、インスタンスの中のイベントのログは自分で取得しないと、どのプロセスが不審な活動をしたのかがわからず、それがインシデントなのか判断できずじまい、ということになりがちです。

これを解決するような製品やOSSは近年増えてきています。 osquery、sysdig、auditbeatなどのOSSも、本格的な運用の話は国内であまり聞こえていませんが、開発も盛んになってきている印象です。 この領域については筆者もいまだ試行錯誤しているため、明確な構成や運用のベストプラクティスなどを語れる立場にありません。 ただ、実際にこのようなログを取り込んだいた場合のアラート分析は著しく捗ることはわかっているため、今後も取り組みを続けたいと考えています。

対応するアラートを選別する

検知の仕組みを入れた後に起こりがちなのが、アラートが大量すぎて対応しきれなくなるというものです。 冒頭でも述べたようにセキュリティ監視は監視する対象のサービス、システム、業務によってやり方が大きく変わってくるため多くの監視サービスやプロダクトは多様なアラートを発報します。 「セキュリティ」というものに取り組んでいると、どうしてもセキュリティ監視サービスやプロダクトが発報したアラートについてひととおり目を通して安全であることを確認しないと気がすまない、という状況に陥りがちです。 確かに些細に見えるアラートが大きなインシデントの兆候を示していた、というケースもありえなくはありません。 しかしそれを理由にすべてのアラートをこと細かに分析してチェックしようとしはじめると現場が疲弊してしまい、本来見るべきだったものを見逃してしまうリスクの方が大きくなります。 これを回避するためには必ずアラートのチューニングをしていく必要があります。 アラートのチューニングにおいて重要になることを2つほど説明させてください。

  1. アラートの内容を機械的に判断して要・不要を判断する: アラートのリスクを判断するときは基本的に人間の直感などに頼らず、判断するための根拠があるはずです。その根拠は同種類の別のアラートにも適用できるはずであり、それをちゃんと言語化しルールとして次のアラートに活かしていかなければなりません。たとえばいつもと違う国からアクセスがあった、というアラートがあってもそれが本人が持っているデバイスからであるという確認がとれれば、それがアメリカからでもイギリスからでも大差はないはずです。(緊張関係にある国だった場合はまた別かもしれませんが、それも言語化すべきルールといえます)このルールをできれば監視のシステム自体に組み込めれば担当者の負荷も劇的に下がると思われますが、それができないシステムも多いので、その場合は基準を作って担当者間で共有するだけでも機械的に対処できることになり、負荷は下げられると考えられます。
  2. 機械的な判断に必要な情報を(なるべく自動的に)揃える: アラートの内容を機械的に判断するためには、ログをはじめとしてアラート外の情報との組み合わせが必要になるケースが多くあります。これらの外部情報の取得作業をいかに簡易化できるかというのも、ある意味チューニングの一部といえます。アラートが発生した際、何を基準に判断するかが明確になっていれば、その判断に必要な情報は何か?という問いの答えも明確になるはずです。何が必要かわかっているなら、あとは機械的(自動的ならなおよし)に取得できるはずで、これによって自動的にアラートの判断ができないまでも、担当者の負荷を下げることにはつながるはずです。

まとめ

AWSをはじめとするクラウドサービスではセキュリティのマネージドサービスが多く提供されており、セキュリティを向上させるための土台はオンプレミス環境より豊富になっていると思います。 しかし一方で、マネージドサービスの個別の使い方についての説明は多く世の中に出回っているものの、運用まで含めた統合的な使い方の説明はあまりないなと常々思っていたため、今回文章にしてみた次第です。 まだ拙い内容なのでわかりにくい部分なども多いと思うのですが、今後もこうした情報発信をしていきたいなと思いますので、ぜひお気持ちのある方々と一緒にやっていければなと思う今日この頃です。