ヘルスケア企業、数千件のサイバー攻撃を阻止

お二人とも、ご参加いただきありがとうございます。 もしよろしければ、簡単に自己紹介とそれぞれの役割、所属組織について教えていただけますか。  

Quynn Karsです。ネットワーク・セキュリティ・アーキテクトです。私たちは医療機関で働いています。 Evan Martinezです。ネットワーク・セキュリティ・エンジニアとして、Quynnと緊密に連携しています。今回のような製品の導入などを担当しています。

Akamaiとの関係はどのように始まり、現在、組織内ではどの製品を導入していますか。

主に、Akamai Guardicore Segmentationを利用しています。 私たちは、マイクロセグメンテーション、あるいは水平方向（East／West） トラフィックを制御するファイアウォールソリューションを探していました。 当時は、求めるものがまだ明確に固まっていたわけではありません。そんな中、日頃から緊密に連携しているパートナー企業と一緒に、実際のベンダーイベントに参加していました。そこで幸運にもAkamaiの営業チームの方と知り合い、 私たちの組織で必要としているものや、 業界の動向を踏まえてどのようなメリットが得られるかについて、私の考えをじっくり話し合うことができました。 その結果、Akamai Segmentationを早い段階で候補として検討できるようになりました。 その後、デモやPoCを通じて検証を進め、適切な方向性を見いだし、導入に至りました。

Guardicoreの導入を振り返って、展開方法や組織の改善という点で、どのような変化があったと感じていますか。

プロジェクトを進めていた当時は、長年、さまざまな環境で一般的に使われてきた従来型のファイアウォール構成を検討していました。しかし、同じ目的を達成しつつ、必要な人員を減らせる別のアプローチを取りたいと考えていました。 Guardicoreは、その両方を実現してくれました。 エージェントベースのソリューションなので、導入初日から環境に組み込んで、トラフィックを詳細に可視化し、制御できるようになりました。環境全体で大規模なインフラ変更を行う必要もありませんでした。 

AIを活用したポリシー適用やポリシー推奨については、どのような効果を感じていますか。 組織の改善にどのようにつながっていますか。

GPEは、特にネットワーク・セキュリティ・チームの業務プロセスを大幅に改善してくれました。アプリケーションをポリシー適用モードに移行するまでの時間が大きく短縮されています。 アプリケーションオーナーは、リングフェンシングをより早く実用可能な状態で導入できるようになりましたし、エンジニア側でも、実際の導入作業にかかる工数が大幅に削減されました。 環境内の各アプリケーションに必要な通信を網羅した、適切なファイアウォールルールを構築するための作業時間も大きく減っています。 これが間違いなく、私たちにとって最大の成果でした。

Guardicore Segmentationの導入や、Akamaiとの連携について、 現時点での印象はいかがですか。

とても良いです。Guardicoreは、私たちが求めていた要件をほぼすべて満たしてくれました。  必要だったのは、可視性、簡単な制御、そしてきめ細かな制御です。これらは導入当初から実現できました。 展開も容易でしたし、製品に対する信頼を築くのもとても簡単でした。 必要としていた要件を、これまでのところあらゆる面で満たしてくれています。

ポリシー生成のベータプログラムを利用する前と比べて、AIポリシーエンジンは既存のセグメンテーションソリューションとどのように違うと感じていますか。 特に導入作業の観点から、導入前後の変化を教えていただけますか。

私自身の経験に加え、Quynnと緊密に仕事をしてきた立場から言うと、以前はコアサービスのトラフィックログを解析し、通信の実態をリバースエンジニアリングするために、何時間もかかる作業セッションを何度も行っていました。 そこには相当な工数がかかっていました。 しかも、解析対象となる通信が実際に発生していなければなりません。 つまり、アプリケーションがその通信を生成する必要があるのです。 そのため、数時間に及ぶ作業を一度行うだけでは不十分で、さらに通信データが蓄積されるのを待ちながら、週の間に何度も同様の作業を繰り返していました。 一方、GPEエンジンは、私たちが以前扱っていたようなリアルタイムのデータだけを見ているわけではありません。過去30日間に取り込まれたログも分析します。 そのため、前回アラートポリシーのヒットカウントをクリアしてから、まだ確認できていなかった通信まで検出できます。 自分の作業時間を際限なく増やさなくても、従来よりはるかに広い範囲の状況を把握できるようになりました。

あなたの立場や役割から見て、AIポリシーエンジンによって、チームのどのような負担が軽減されたと感じますか。 発見の部分です。

プロジェクトを開始した当初、アプリケーションオーナーは、自分たちのアプリケーションが何をしていて、どのシステムと通信しているのかなどを、必ずしも十分に把握しているわけではありませんでした。 ポリシーエンジンを利用することで、アプリケーションの通信状況をマッピングした情報と、どのようなルールを適用すべきかという見通しを、アプリケーションオーナーと共有できるようになりました。 たとえば、過去30日間の通信データを基に、どの通信を許可し、どの通信をブロックすべきと想定しているかを提示できます。アプリケーションオーナーには、その内容を確認してもらうだけで済みます。 これによってプロセス全体が非常にシンプルになり、作業が容易になりました。  最初から最後まで、業務の流れが格段にスムーズになっています。本当に素晴らしいことです。

適用モードに移行する前にポリシーをシミュレーションできることは、誤検知やシステム停止の防止という観点からどの程度重要ですか。 組織にどのような影響を与えましたか。各ポリシールールセットについて、アラートルールを使ってシミュレーションできることで、変更管理委員会から信頼を得るうえで非常に大きな効果がありました。 

適用モードを導入する際には、対象がTier 1、Tier 2、Tier 3のいずれであっても、変更管理委員会での審査を経て承認を得る必要があります。 従来型のファイアウォールで新しいブロックルールを実装しようとする場合と比べて、シミュレーションを利用できるようになってからは、承認者の信頼と安心感を得ることが格段に容易になりました。 これは管理職の方々にとっても大きなメリットです。また、アプリケーションオーナーに対しても、Guardicoreが意図しない通信をブロックすることで、休日にシステムが停止したり、夜中に呼び出されたりするような事態を招かないと、具体的な情報を示して説明できます。 つまり、組織内で信頼を築くという点で、非常に大きな効果がありました。

AIの導入がさまざまなツールに広がり、AIそのものを保護することも求められる中で、ポリシーを適用する根拠となる証拠を示し、なぜそのポリシーが推奨されるのかを説明できる、説明可能なAIがどれほど重要だとお考えですか。 そうすることで、組織全体に安心感をもたらすとともに、AIがポリシーを提案し、その根拠となる情報を提示しながらも、最終的な適用判断は人間が行うという仕組みを維持できます。つまり、すべてを自動的に適用するのではなく、人間が最終判断を担うことについて、どのようにお考えですか。 これはあなたにとってどれくらい重要ですか。

面白いですよね。非常に重要だと思います。 技術的負債を増やしたくないからです。AIが生成するポリシーは、 適切で、組織に実際の価値をもたらすものでなければなりません。 そのため、生成されたルールや、AIがエンジニアやチームに提示する情報について、根拠を説明できることが重要です。 AIが業界でさらに普及するにつれて、今後数年間で、こうした説明可能性への関心は大きく高まっていくと思います。

Evanさん、セキュリティや組織のポスチャの改善につながった提案について教えていただけますか。 何か具体例はありますか。

もちろんです。 GPEの例を挙げると、たとえば、アプリケーション1からアプリケーション2へ、ポート80や443などを介した通信が確認されたとします。それとは別に、まったく同じような通信について、今度は単一のIPアドレスに対するポリシーの推奨が別途出てくることがあります。 私にとって、これはすぐに調査すべき兆候です。エージェントの導入が漏れているか、アプリケーションへのラベル付けが漏れている可能性があるからです。 そこで、そのエンドポイントが何なのか、なぜGuardicore上でラベル付きの資産、  あるいは管理対象の資産として認識されていないのかを調査する必要があります。 そのうえで、アプリケーションチームと連携して対象を特定し、適切なタグを割り当てます。 そうすることで、環境内の資産をきちんと可視化できるようになり、 ポリシーも適切に適用できるようになります。 結果として、管理されていないワークロードが環境内で勝手に稼働するような事態を防げます。

エンドユーザーのトラブルシューティングや作業時間の削減など、運用面で測定可能な効果はありましたか。


はい、確かにありました。 運用面では、私はネットワークセキュリティの業務からは少し離れた立場ですが、アプリケーションや自分が管理しているシステムとは関係のない問題であっても、トラブルシューティングやシステム停止への対応に呼ばれることがあります。プロセスレベルで何が起きているかを可視化できるからです。 たとえば、あるアプリケーションサーバーで、SMTPリレーの接続先としてDNSレコードは存在するものの、 実際にはその接続先にサーバーが存在しないケースがあったとします。 一方、同じサーバーファーム内の他の10台は、正常に応答する別の接続先を設定しており、それが正しい構成だったとします。 このようなとき、私はトラブルシューティングに参加し、 プロセスレベルまで掘り下げて調査することで、アプリケーションオーナーが判断するための追加情報を提供できます。

これまでの経験を踏まえて、AkamaiがAIを活用するうえで、他のベンダーとどのような違いがあるのかを同業者に説明することは、どの程度重要だと考えますか。

重要だと思います。多くの組織が自社のシステムにAIを組み込んでいますが、それがエンドユーザーの体験やエンジニアの業務体験に実際の価値をもたらしているのかには、議論の余地があります。 その点で、Akamaiのアプローチは優れた方法の一つだと思います。 実際に価値を提供しているからです。 GPEエンジンは、単に大量の無意味な情報を出力するものではありません。 表現は簡単ですが、エンジンが提示する提案は実用的で、 組織に価値をもたらし、実際の時間削減にもつながっています。他のベンダーにも、こうした取り組みをもっと進めてほしいと思います。

プラットフォーム全体を通じて、組織に最も大きな価値をもたらしたものは何ですか。

間違いなくGPEエンジンです。 Guardicoreが私たちの環境に必要なセグメンテーション機能を提供してくれたことはもちろんですが、製品を購入して利用を開始した後、さらに大きな付加価値となったのがGPE機能の導入でした。 Quynnも私も、常に複数のプロジェクトを同時に進めていますし、 新しい取り組みに関するトラブルシューティング会議にも参加しています。 そのため、経験豊富なユーザーが導入フェーズに費やす時間を少しでも削減できることは、大きなメリットです。その分、効率化が難しい別の業務に時間と注意を向けられるようになります。

セグメンテーションソリューションをいろいろと検討された中で、Guardicoreはリングフェンシングにかかる時間をどのように短縮したと感じていますか。組織全体での導入時間という観点から、どのような効果がありましたか。

それは、組織全体での導入時期の見積もりから、そのメリットをより拡大させたものなのでしょうか。 Akamaiはどのようにしてそれを組織に定着させたと感じますか。 

最も分かりやすく説明すると、水平方向のセグメンテーションには、業界で長年使われてきた標準的な方法がありました。 従来型のファイアウォールを用意し、ネットワーク上の必要な場所に設置してルールを設定するか、スイッチにACLを設定するという方法です。 一方、Guardicoreではエージェントを導入し、ポリシーを配布すれば、すぐに利用を開始できます。この方法によって、導入が大幅に迅速化されました。 当初、私たちは従来型の方法を採用する予定でした。 その場合、停止時間やメンテナンスウィンドウなどを調整し、実際に通信を観測して判断できる段階に至るまで、 何か月もかかったはずです。 しかしGuardicoreでは、展開作業を進め、すべてのマシンにエージェントを導入するまで、およそ1週間で済みました。 もちろん、他の組織と同じように段階的な導入は必要でした。それでも、まず通信を可視化できるようになるまでの時間は、はるかに短縮されました。 その後は、ポリシーを展開し、実際の通信データに基づいて判断を進められます。データをすぐに利用できるので、具体的な対策に移ることも容易です。 非常に役立っていますし、業界全体も今後この方向に進んでいくと思います。

Akamai Guardicoreは、組織にゼロトラストモデルを適用するうえで、どのような役割を果たしていると感じますか。 また、運用面でも、Guardicoreを東西トラフィックのファイアウォール制御以外にも活用できることに気づき、可能性が広がったと感じることはありましたか。 当初想定していた用途以外に、新たなユースケースや価値を見いだすことはできましたか。 

はい、もちろんです。使い始めたころは、製品で何ができるかを理解したうえで、導入計画を立てていました。 ただ、おっしゃるように、製品を使い込んで経験を積み、実際に何ができるのかが分かってくるにつれて、その計画も変わっていきました。 詳しい内容は控えますが、当初はリングフェンスを設定するだけで十分だと判断していたアプリケーションについても、導入の第2フェーズで改めて見直すようになりました。  その中では、特に機密性の高いシステムにも目を向けています。 たとえば、セキュリティ更新プログラムが提供されなくなったシステムに対して、代替となる保護策を講じることもあります。また、プロセスベースのルールを、より厳格に適用するようにしています。つまり、リングフェンスの適用範囲をさらに狭めているのです。たとえば、環境内のアプリケーション全体を対象にリングフェンスを設定するのではなく、単一のサーバークラスターにまで対象を絞り、そのクラスターがワークステーションやメールサーバーなどと通信できないように制限するといった対応を行っています。

現在、導入はどの程度進んでいますか。およそ何個のアプリケーションを保護していますか。

現在は100を少し超えるアプリケーションを保護しています。組織の拡大に伴って、その数も増え続けています。 導入プロセスは非常に簡単になりました。

インシデント対応について理解を深めるには、どのくらいの期間が必要だと思いますか。また、MTTR（平均復旧時間）の短縮にもつながっていますか。 たとえば、組織内での調査対応という面でも、何か改善は見られましたか。

そうですね。Evanと私を含め、SOCのアナリストやインシデント対応チームも、この機能を活用しています。 何が起きているのかを、迅速に特定できるようになりました。 プロセスレベルで状況を確認できるため、 たとえばXDRからプロセスに関するアラートが発生した場合、そのアラートのログを調べて情報をつなぎ合わせるだけではなく、そのマシンが過去7日間にどのシステムと通信していたか、具体的に何をしていたかまで確認できます。 そのプロセスがネットワーク通信を行っていたかどうかも分かります。Guardicoreによって、XDRツールでは得られない、あるいは十分に得られないレベルの可視性を確保できるようになりました。

マイクロセグメンテーションとリングフェンシングを導入する中で、設定ミスや悪性の活動をどの程度発見していますか。Akamai Guardicore Segmentationがなければ見逃していたと思われる事例はありますか。

ほぼすべてのアプリケーション、少なくとも2つに1つ程度で、何らかの問題を発見していると思います。すべてがセキュリティ上の問題というわけではありませんが、設定ミスは確実に見つかっています。 よくあるのは、ポート443ではなくポート80でリクエストを送信していたり、重要なシステムからFTPでジョブを実行していて、本来使うべきSFTPが使用されていなかったりするケースです。  こうした問題は、GPEを利用するか、ログを直接確認することで、プロセスレベルまで簡単に把握できます。 ネットワークログをエクスポートしてアプリケーションオーナーに渡し、たとえば「今後1か月以内に修正してください」といった改善タスクを割り当てることも容易です。 期間内に対応できない場合は、相談してもらい、実現可能な対策を一緒に検討します。 このように、可視性が向上したことで、問題を発見し、修正するための大きな手がかりが得られています。本日は以上です。

お二人とも、お時間をいただきありがとうございました。パートナーシップとご協力に感謝いたします。 視聴者の皆さまも、ご覧いただきありがとうございました。