AWSサポートとは？サポート範囲や問い合わせ方法について徹底解説
本コラムでは、AWSのサポートプランの概要や使い方、費用をかけずに技術面の相談ができるサービスの紹介などについて、徹底解説いたします。
COLUMN
NTT東日本でMicrosoft Defender for Endpointを運用してみた
こんにちは！NTT東日本 セキュリティエンジニアのタクヤです。
ゼロトラストセキュリティコラムの6回目になります。
過去のコラムをまだご覧になっていない方は、是非ご覧ください。
第1弾コラム：「NTT東日本で実際に導入しているゼロトラストセキュリティを徹底解説！」
第2弾コラム：「NTT東日本におけるゼロトラストセキュリティの設計と導入」
第3弾コラム：「NTT東日本でゼロトラストセキュリティの運用・監視をやってみた」
第4弾コラム：「NTT東日本でEntra ID・Intuneを活用してみた」
第5弾コラム：「NTT東日本でEntra ID・Intuneを活用してみた(モバイル編)」
今回も引き続き、製品ごとに運用時の困りごとを例に挙げながら、どういう運用を行っているのか、どういう点を工夫しているのかについてご紹介していきます。
本コラムでは近年、益々注目が高まっているEDRについて、NTT東日本が利用しているMicrosoft Defender for Endpoint（以下、MDEという）にスポットを当ててご紹介いたします。
最後までお付き合いいただけますと幸いです。
1. EDRの必要性
本項では、EDRがなぜ求められているのかについて、サイバーセキュリティを取り巻く状況を踏まえてご説明します。
近年、社会のデジタル化がさらに進み、より多くのことがオンラインやWebアプリケーションを介して行えるようになっていることは、このコラムをご覧の皆さまも実感していることと思います。
このようにオンラインサービスやWebアプリケーションが高度化し、多様化したことを背景に、それらを提供するためのソフトウェアの脆弱性を悪用したゼロデイ攻撃も増加しています。
ゼロデイ攻撃とは、脆弱性に対する対策が提供される前に脆弱性を悪用した攻撃で、事前に防ぐことが非常に難しいものとなっています。
このような脆弱性を悪用する攻撃や、Windows等のOSに標準搭載した機能を悪用した攻撃は、既存のウイルス対策製品では検知しづらく、年々従来の対策で防げる攻撃が少なくなってきているのが現状です。
そのような状況下で威力を発揮するのが、今回ご紹介するEDRです。
EDRは、既存のウイルス対策製品であるEPP製品のような既知である特定の攻撃やマルウェアの攻撃パターンにマッチした動作を検知するのではなく、端末上のログをリアルタイムで収集・分析し、攻撃の可能性がある不審なアクティビティを検出すると共に、検知した不審なファイルの検疫や修復、被疑端末をネットワーク上から隔離するなどの対処を行うことができるセキュリティ製品です。
EDRを導入することにより、不審なふるまいを契機に未知の攻撃を即座に検知し、迅速に対応することが可能となります。
下記の表でもわかるように、NTT東日本でもEPP製品による検知は毎月数えるほどであり、EDRによる対策の効果を実感しています。
| 対策ソリューション | 検知件数(件/月) | 全体の割合(%) | |
|---|---|---|---|
|
不審なスクリプト実行
|
EDR | 77 | 35.5 |
| 不審なファイルの作成検知 | EDR | 32 | 14.7 |
| フィッシング 外部アクセスの検知 |
EDR | 22 | 10.0 |
| ・・・ | |||
| 悪性ファイル検知 | ウイルス対策ソフト | 8 | 4.1 |
2. MDE導入時に考えること
本項ではEDR製品として、MDEを実際に導入する際に考慮すべき内容についてご説明します。
まず、社内にどのような端末があるかを把握することが必要です。
MDEの場合、Windows、Mac、Linuxといった主要なOSに対応している一方、一部のOSバージョンがサポート対象外や導入不可となっています。
対応OSは以下をご参照ください。
マイクロソフト社『Microsoft Defender for Endpoint の最小要件』
また、導入可能なOSであっても、MDEを利用するために必要なMicrosoft Enterprise E5ライセンスやMicrosoft Defender for Endpointライセンスの他に購入が必要なライセンス・サブスクリプションがあるので注意が必要です。
ライセンスが購入出来たら、実際にMDEを導入する作業となります。
導入作業を実施する際にも、ライセンスと同じようにいくつか考慮すべきことがあります。
1つ目はOSにより導入手順と必要となる資材が異なる点です。Windows 10/11であればスクリプトの実行のみで簡単に導入を行うことができますが、その他のOSではソフトウェアの追加や設定変更など、追加の作業が必要になります。
2つ目は端末管理方法によって導入手順が異なる点です。
個別管理、Active Directory管理、Intune管理といった端末管理方法に対応した導入方法のほか、サーバーOS向けにEntraID上でのデバイス管理を提供するAzure Arcを利用する方法等、効率的にMDEを導入するためのさまざまな手法を提供しています。
自社の端末管理方法に合わせて、適切なものを選択しましょう。
3. EDR導入後に感じたメリットや運用課題
本項ではNTT東日本で実際にMDEを導入・運用を行ってみてわかったメリットや課題についてご紹介します。
3-1. MDE導入により検知できた脅威
NTT東日本では社内端末へEDRを導入後、すぐに暗号化されたPowerShellスクリプトの実行の痕跡を検知しました。
調査してみると外部と通信する機能を有していることが判明し、急ぎ状況を確認しました。
幸いなことに、スクリプトで指定された転送ルートがプロキシサーバーによって規制されていたため、攻撃者のサーバーへの接続は遮断されていました。そのため、情報漏洩の痕跡は発見されず、検知されたスクリプトファイルの削除を行って対応を完了しています。
この事象からEDRでなければ見つけられない脅威が存在することを実感しました。
3-2. 脅威の進行度がより明確に把握できる
2019年に大流行したEmotetについてもMDEで検知しています。Emotetは、メールに添付されたオフィスファイルのマクロを利用した攻撃を特徴としており、添付ファイルの実行後、マクロを有効化することによってマルウェアに感染するというものです。
MDE上ではユーザのアクティビティを調査した上で、脅威の重大度や進行度を可視化してくれます。調査結果を確認することによって、利用者がファイルを開いたか、メールに添付されたURLをクリックしたか、といった詳細な挙動を把握することができます。よって攻撃の進行度が克明に把握できることになります。
このような従来の対策だけでは気づかない脅威を発見し、即座に脅威の進行度を把握した上で、対応措置や更なる調査を行うことができるのがEDRを導入する利点です。本事例から、社内でも導入してよかったという声が多く聞かれました。
3-3. 短時間で調査・対処できる機能
NTT東日本で導入しているMDEには、調査を効率化するための機能が数多く備わっています。その中でも特に有用性が高いと感じたものをご紹介します。
1つ目はAutomated Investigation(自動調査)です。
この機能はセキュリティオペレーションの初動解析を自動で行う機能です。解析結果から端末上に存在している不審な振る舞いを分析し、脅威度が高いものが存在している場合には自動的に修復を行った上で、監視者に結果をフィードバックしてくれるものとなっています。
この機能を利用することで、プロキシログの確認、ユーザへの詳細なヒアリング、手動による被疑PCのログ収集等、半日から数日程度かかる作業が、1時間程度で完結できるようになりました。
また、調査自体はMDEが自動で実施するため、監視者の稼働を別の調査や監視に振り分けることができるようになり、多数の調査分析を効率的に実施できる環境が整備されました。
2つ目はデバイス隔離機能です。
これはアラート検知後、マルウェアの感染を拡大させないために被疑端末の通信の接続を制限する機能です。
この機能を利用することで、現地で端末のLAN配線を抜くといった初動の物理作業から解放され、遠隔から迅速かつ簡単に対処が行えるようになり、1回のインシデントにかかるユーザ連絡や検知端末への対処時間が1時間程度から数分程度に削減出来ています。
また、初動対処が迅速に行われるようになったことで、同一ネットワーク上にある他の端末への感染リスクも低減できています。
3-4. EDR未導入端末の発見
EDRを導入する際に留意すべきこととして、保護する全てのデバイスにEDRを導入することが挙げられます。もしもEDRが導入できていない端末が攻撃された場合は、攻撃に気づくことができず、被害が広がってしまう恐れがあります。
しかし、端末を完全に管理することは難しいことです。そのような状況を解消するために、MDEにはネットワーク上からMDEがオンボードされていないデバイスを探索する機能が備わっています。
この機能はMDEオンボード済みの端末が、接続する同一セグメントのネットワークに対してスキャンを行うことで、デバイスやIOT機器を探索するというものです。
ただし、MDEが導入されている端末が一台も存在しない別のセグメントのネットワーク上ではこの機能が動作しない点に注意が必要です。
4. EDR運用で困ったこと
本項ではMDEの運用において発生した困りごとについて、具体的な解決策と解決後どのように利便性が向上したかをご紹介します。
4-1. 困りごと①：プロキシサーバーを利用した環境の監視
1点目はプロキシサーバーを用いたトラフィック制御です。
MDEによるログ転送や端末への制御を確実に実施するために、EDR専用のプロキシを配置し、トラフィックを制御することを試みました。
その際に、困ったこととして、少し専門的な話になりますが、MDEに関連する通信を特定のプロキシに誘導するためには、WinHTTPというOS設定を用いる必要がありました。
NTT東日本では、本設定を社内の業務端末に対してグループポリシーオブジェクトを用いて配信しています。しかし、本来誘導したかったMDE関連以外の通信も紛れ込んでいることがわかり、適宜ログを分析し振り分けルールを追加して再配信する等の手間がかかる運用を強いられました。
この工程は完了するまでに半年ほどかかり、運用が安定するまでかなり対応に苦慮しました。
4-2. 困りごと②：アラート検知した端末の利用ユーザの特定
2点目はアラート対応時に起きた困りごとです。
エンドポイントを監視する上で、誰が利用しているデバイスなのかを把握することはとても重要です。
EntraIDやActive Directoryで管理されているデバイスは容易に確認することができますが、管理外端末かつ共有アカウントを利用している場合、利用中のユーザを特定することが出来ません。
NTT東日本ではこのような事象を受けて、共有アカウントの利用を禁止するルールを適用したことに加え、管理外端末にMDEを入れる際には組織名と連絡先を申請した上で端末名の命名規則を統一し、監視者がユーザ特定を行いやすい環境づくりを進めました。
4-3. 困りごと③：誤検知対応
EDRの検知の大半は業務に利用するツールやアプリケーションに起因する誤検知であり、それらの調査や分析に多くの時間が割かれているのが現状です。
NTT東日本でもインシデントと思われる重要度の高い検知は月に数件あるかどうかという状況であり、多くの誤検知を如何に効率よく処理するかという点が非常に大きな課題です。
誤検知を確認した際には、アラートを抑止する設定の利用や過去事例を活用し、調査の省略や簡略化を進めることが重要です。
5. まとめ
今回のコラムではNTT東日本でのEDR導入とトラブル事例についてご紹介させていただきました。
製品を導入する際には社内の環境をよく確認し、事前にどのような対応が必要になるかをよく理解しておく必要があります。
また、実際に導入していく過程では、考慮できていない仕様や運用のネックとなるような困りごとが判明し、対応に苦慮する場面に何度も遭遇します。その際には、製品ベンダと協力しながら自分たちが対応策を検討し、検証した上で改善に取り組むことが重要です。
NTT東日本では今までの社内運用で培ったノウハウを生かしたEDR監視サービスを提供し、多くの企業さまにご利用いただいております。
EDR導入を検討されている方は是非ともご相談ください。
次回は、アカウント(ID)の制御・監視をテーマにMicrosoft Entra IDの活用についてのコラムを予定しております。
アカウントに関するセキュリティ対策に興味のある方は、ぜひご覧いただきたいと思います。
これからゼロトラストセキュリティの導入を考えているが、自分たちではやりきれない、何をしたらいいかわからないという皆さま、是非、NTT東日本へご相談ください！皆さまの新しい働き方を全力サポートいたします！
今後の掲載予定コラム
- 経緯、要求定義について
- 設計、導入について
- 運用、監視について
- EntraID・Intune運用①
- EntraID・Intune運用② 前回
- MDE運用 今回
- アカウント制御監視 次回
相談無料！プロが中立的にアドバイスいたします
クラウド・AWS・Azureでお困りの方はお気軽にご相談ください。