Technical Blog テクニカルブログ
  1. HOME
  2. テクニカルブログ
  3. 新入社員がEDR運用を調べてみた!SOCと比べたNI+Cセキュリティ支援サービスの強みに迫る!~新入社員のセキュリティ備忘録 #07~

新入社員がEDR運用を調べてみた!SOCと比べたNI+Cセキュリティ支援サービスの強みに迫る!~新入社員のセキュリティ備忘録 #07~

投稿者:セキュリティ&ネットワーク事業本部 セキュリティ担当 井上

こんにちは!2年目社員の井上です。

本ブログは、私が学習した情報セキュリティについてのあれこれを備忘録として残していくシリーズ「新入社員のセキュリティ備忘録」第7弾になります。今回も、学習した内容を新入社員目線でまとめていきます。

前回までの備忘録では、EDRが端末上の何を見ているのか、どのように不審な挙動を検知しているのか、そして検知後にどのような対応につなげられるのかを見てきました。

↓↓↓ まだ#05,#06を読んでいない方は、今回の記事とあわせてチェックしてみてください! ↓↓↓

【新入社員がEDRを調べてみた!アンチウイルスと何が違うの?~新入社員のセキュリティ備忘録 #05~】
https://www.niandc.co.jp/tech/20260401_72483/

【新入社員がEDRの動きを追ってみた!アラートは何を見ているの?~新入社員のセキュリティ備忘録 #06~】
https://www.niandc.co.jp/tech/20260430_73233/

EDRは、端末上で起きるプロセスの実行やコマンド、ファイル操作、通信などをもとに、不審な挙動を検知し、アラートとして知らせてくれる仕組みでしたね。

しかし、実際にEDRからアラートが発報されたとき、その内容を正しく理解し、「端末の中で何が起きているのか」「本当に危険な挙動なのか」「どのような対応が必要なのか」を判断するのは、簡単なことではありません。

なぜなら、アラートを読み解くためには、セキュリティの知識だけでなく、その周辺の構成など、さまざまな知見が必要になるからです。普段業務でPCを利用しているユーザが、EDRのアラートを見てすぐに適切な判断をするのは、なかなか難しそうですよね。

そこで重要になるのが、SOC(Security Operation Center) です。

SOCとは、組織内のセキュリティアラートやログを監視・分析し、サイバー攻撃や不審な挙動にいち早く気づき、対応につなげるための専門部隊のことです。EDRなどのセキュリティ製品が出すアラートを確認し、必要に応じて調査を行ったり、社内のセキュリティ維持運営統制組織であるCSIRT(Computer Security Incident Response Team)に対してエスカレーションを行ったりなど、セキュリティ運用の監視面で中心的な役割を担っています。

本記事では、SOCとは何か、なぜ必要なのか、そして実際にどのようなことをしているのかを整理していきます。また、弊社のインシデント・レスポンスを主軸としたサービスである、NI+Cセキュリティ支援サービスのご紹介を行います。

今回もどうぞよろしくお願いします!

目次

1. SOCってなに?アラートを見て「気づきを届ける」仕組み

2. NI+Cセキュリティ支援サービスってなに?気づいた後の「対応を支援する」仕組み

3.おわりに

1. SOCってなに?アラートを見て「気づきを届ける」仕組み

前回の備忘録では、EDRが端末上のさまざまな挙動を見て、不審な動きを検知し、アラートとして知らせてくれる仕組みについて見てきました。

たとえば、端末上で不審なプロセスが実行されたり、普段とは異なる通信が発生したり、攻撃につながりそうな一連の挙動が確認された場合、EDRはそれをアラートとして発報します。

では、実際にEDRからアラートが発報されたとき、その内容をすぐに正しく理解できるでしょうか。


……正直、これはかなり難しそうです。

アラートには、発生した端末名、検知されたプロセス、実行されたコマンド、通信先、検知理由、重要度など、さまざまな情報が含まれます。

しかし、それらの情報を見て、

・何が起きているのか
・本当に危険なアラートなのか
・どの端末に影響があるのか
・すぐに隔離や停止が必要なのか
・それとも誤検知の可能性があるのか

を判断するには、セキュリティの知識だけでなく、OS、ネットワーク、ソフトウェア、攻撃手法など、幅広い知見が必要になります。

…普段業務でPCを使っているユーザが、EDRのアラートを見てすぐに「これは危険」「これは問題なさそう」と判断するのは、なかなか難しいですよね。

そこで登場するのが、SOC(Security Operation Center) です。

SOCとは、組織内で発生するセキュリティアラートやログを監視・分析し、セキュリティインシデントにつながる可能性がある事象を見つけて、関係者へ通知する役割を持つ組織やサービスのことです。

もう少し簡単に言うと、SOCは、EDRやファイアウォール、IDS/IPS、プロキシ、メールセキュリティ製品など、さまざまなセキュリティ製品から出てくるアラートを確認し、

「これは注意したほうがよさそうです」

「この端末で不審な動きがありました」

といった“気づき”を届けてくれる仕組みだと言えます。

SOCでは、たとえば次のようなことが行われます。

・セキュリティ製品から発生したアラートの監視
・アラート発生時の記録
・アラート内容の確認
・ログや検知内容をもとにした一次分析
・発生した事象の整理
・指定された連絡先への報告

こうして見ると、SOCは「アラートをただ転送するだけ」の仕組みではなく、発生したアラートを確認し、必要な情報を整理したうえで、担当者に知らせる役割を持っていることが分かります。

特に、セキュリティ製品を導入していても、アラートを誰も見ていなかったり、見ても意味が分からなかったりすると、せっかくの検知を対応につなげることができません。その意味でSOCは、セキュリティ製品が発するアラートを、人が判断できる形に整理し、必要な対応へつなげるための重要な役割を担っています。

一方で、ここで注意したいのが、SOCがすべての対応を代わりに実施してくれるとは限らないという点です。

SOCという名前を聞くと、アラートの確認から原因調査、端末の復旧、脅威の排除まで、すべてを任せられるようなイメージを持ってしまうかもしれません。しかし、一般的なSOCサービスの主な役割は、あくまでセキュリティアラートの監視・一次分析・通知であることが多いです。

つまり、SOCはアラートを確認し、「セキュリティリスクのある事象が発生している可能性があります」と知らせてくれるものの、その後の詳細な調査や、端末利用者への確認、脅威の排除、復旧対応までを実施するかどうかは、サービスの範囲によって異なります。

ここで出てくるのが、IR(Incident Response:インシデントレスポンス) という考え方です。

IRは、発生した事象が本当にセキュリティインシデントなのかを判断し、必要に応じて隔離、調査、影響範囲の確認、脅威の排除、復旧などを行う対応のことです。

ざっくり整理すると、次のような違いになります。

項目 主な役割
SOC アラートを監視・分析し、リスクの可能性を通知する
IR 発生した事象を詳しく調査し、必要な対応や復旧につなげる


もちろん、SOCサービスの中には、IRに近い対応まで含むものもあります。

ただし、一般的には「SOCを契約すれば、アラート発生後の対応がすべて自動的に完了する」というわけではありません。


ここを勘違いしてしまうと、SOCから報告を受け取ったあとに、

・この報告書をどう読めばいいのか分からない
・結局、何をすればいいのか分からない
・自社の環境では、どの対応が適切なのか判断できない
・端末利用者に何を確認すればいいのか分からない
・脅威をどう取り除けばいいのか分からない

といった悩みが残ってしまうことがあります。

つまり、SOCはとても重要な仕組みですが、主な役割は「アラートを見て、リスクの可能性に気づかせてくれること」です。

その後の具体的な対応や判断には、別途インシデント対応の知識や体制が必要になる場合があります。

では、アラートに気づいた後の「どう判断するか」「どう調査するか」「どう対応するか」まで支援してほしい場合には、どのようなサービスが必要になるのでしょうか。

次章では、SOCとの違いを意識しながら、NI+Cセキュリティ支援サービスについて見ていきます。

2. NI+Cセキュリティ支援サービスってなに?気づいた後の「対応を支援する」仕組み

前章では、SOCサービスについて見てきました。

SOCは、EDRなど、さまざまなセキュリティ製品から発生するアラートを監視・分析し、セキュリティリスクのある事象が発生している可能性を知らせてくれる仕組みでした。

つまりSOCは、セキュリティアラートを見て、「何か起きているかもしれません」という“気づき”を届けてくれる役割を持っています。

これは、セキュリティ運用においてとても重要です。

どれだけEDRなどのセキュリティ製品を導入していても、発生したアラートに気づけなければ、対応につなげることができないからです。

一方で、実際にアラートの通知を受け取る側の立場で考えると、もう一つ大きな課題があります。
それは、「SOCからの通知を受け取った後、具体的にどう対応すればよいのか」 という点です。

たとえば、SOCから報告を受け取ったとしても、次のような判断が必要になります。

・このアラートは本当に危険なのか
・端末を隔離すべきなのか
・ユーザに何を確認すればよいのか
・ほかの端末にも影響があるのか
・脅威を取り除くには何をすればよいのか
・誤検知だった場合、次回以降どう抑制すればよいのか

…こうして見ると、アラートに気づいた後にも、考えるべきことがたくさんありますね。

前章でも触れたように、一般的なSOCサービスは、アラートの監視・一次分析・報告を主な役割としていることが多く、アラート発生後の詳細な調査や、端末利用者への確認、脅威の排除、復旧に向けた支援まで含まれるとは限りません。

つまり、SOCによって「気づく」ことはできても、実際の現場では、

「結局、この後どう動けばいいの?」

という悩みが残ってしまうことがあります。

そこで登場するのが、NI+Cセキュリティ支援サービスです。

NI+Cセキュリティ支援サービスは、一般的なSOCのようにアラートを見て通知するだけではなく、IR(インシデントレスポンス)を主軸に、アラート発生後の対応を技術面から支援するサービスです。

つまりNI+Cセキュリティ支援サービスは、単に「アラートが出ています」と知らせるだけではなく、

「では、そのアラートをどう見て、どう判断し、どう対応していくか」

という、現場で本当に悩みやすい部分まで支援するサービスだと言えます。

具体的には、セキュリティセンサーやEDRなどから発生したアラートをもとに、事象の把握や一次解析を行い、必要に応じてエンドポイントの状況確認、端末利用者への確認、潜在的な影響範囲の調査、過検知抑制などの対応を支援します。

…こうして見ると、一般的なSOCサービスが主に「アラートを見て知らせる」役割であるのに対し、NI+Cセキュリティ支援サービスは、「アラートを受け取った後の判断や対応まで支援する」ところに大きな特徴があることがわかりますね!

改めて、一般的なSOCサービスとNI+Cセキュリティ支援サービスを少し整理すると、次のようになります。


項目 一般的なSOCサービス NI+Cセキュリティ支援サービス
主な役割 アラートの監視・一次分析・通知 アラートの監視・一次解析・通知

アラート後の調査・判断・対応支援
主軸 アラート対応 アラート対応

インシデントレスポンス
支援の中心 リスクの可能性を知らせる リスクの可能性を知らせて、
その後の対応を技術面から支援する
対応範囲の例 アラート内容の確認、一次分析、報告 アラート内容の確認、一次分析、報告

被疑端末の状況確認、ヒアリング、
影響範囲確認、暫定対処、過検知抑制など
解決する悩み アラートに気づけない、
一次確認が追いつかない
アラート後に何をすべきか分からない、
対応判断や技術対応に不安がある

 

…この違いは、実際のセキュリティ運用ではかなり大きいと感じました。

なぜなら、セキュリティ担当者が本当に困るのは、アラートを受け取る瞬間だけではないからです。

…前章でもあった通りですが、「こんなアラートが検知されたよ!」という報告自体も非常に重要です。しかし、セキュリティ担当者の本当の悩みとは、「むしろその後に報告内容を読み解き、自社環境に合った対応を判断し、端末利用者への確認や影響範囲の把握、脅威の排除、再発・過検知の抑制・・・まで、様々なことを考える必要がある」ということではないでしょうか。

NI+Cセキュリティ支援サービスは、このような「アラートに気づいた後」の技術的な悩みに寄り添い、セキュリティ担当者が対応を進めやすくなるよう支援するサービスです。特に、セキュリティ担当者が少ない組織や、EDRなどのセキュリティ製品は導入しているものの、アラートの読み解きや対応に不安がある組織にとっては、非常に心強い仕組みだと思いました!

以上が、一般的なSOCサービスとNI+Cセキュリティ支援サービスの違いになります。

3.おわりに

今回の備忘録 #07 では、SOCとは何か、そして一般的なSOCサービスとNI+Cセキュリティ支援サービスでは何が違うのかを整理してみました。

前回までの記事では、EDRの概要から、端末上の不審な挙動を検知し、アラートとして知らせてくれる仕組みについて見てきました。

一方今回は、アラートを「誰が見て、どう扱うのか」という、セキュリティ運用の部分に目を向けてみました。

調べてみて感じたのは、セキュリティ対策は、製品を導入して終わりではないということです。

どれだけ優れたセキュリティ製品を導入しても、アラートを見て判断し、対応につなげる体制がなければ、十分に効果を発揮できない可能性があります。

逆に言えば、EDRのようなセキュリティ製品と、NI+Cセキュリティ支援サービスのような運用・対応支援の仕組みを組み合わせることで、検知した後の対応まで含めた、より実効性のあるセキュリティ対策につなげられるのだと思います。

セキュリティ対策では、アラートを出す仕組みだけでなく、そのアラートをどう活かすかまで考えることが大切なのですね!

今回の記事が、同じようにEDRを理解していく方たちにとって、少しでも参考になればうれしいです。
今後も引き続き、学んだことをまとめていきたいと思います。

また、EDRやNI+Cセキュリティ支援サービスに興味を持たれた方は、以下のリンクからお気軽にお問い合わせください。

最後まで読んでいただき、ありがとうございました!

ページのトップへ