SCS評価取得に急ぐ企業が見過ごす「運用の脆弱性」とは──今見極めるべき“有事の自走力”

エンドポイントの視点から考える「SCS評価制度」のねらい

　経済産業省を中心に整備が進められている「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」。サプライチェーンを構成する企業が講じるべきセキュリティ対策を示し、その実施状況を共通の枠組みで可視化する仕組みだ。企業に求める対策水準は段階別に示され、各水準で定められた要求事項／評価基準への適合に応じて「★」の段階が示される。一般的なサイバー脅威への対処を想定する★3は、専門家の確認をともなう自己評価による登録だ。より高い水準を対象とする★4は、第三者評価を経て登録される。経済産業省は、★3／★4について、2026年度末頃の申請受付開始を目指している。

　もっとも、同制度は特定の製品やソリューションの導入を一律に求めるものではない。端末対策、ID／アクセス管理、脆弱性対応、インシデント対応などを、自社の規模や事業上の重要性に応じて整え、適切に運用できているかが重要となる。こうした中、端末上の不審な挙動を検知し、調査や初動対応につなげるEDRは、同制度で明示的に求められていないものの、エンドポイント対策における有力な選択肢の1つであることはいうまでもない。

　一方で、制度の受け止め方を誤れば、評価取得そのものが目的化しかねない。経済産業省からは、SCS評価制度は任意の仕組みであり、未取得企業を一律に取引から排除するものではないと注意喚起がなされている。発注側が取引先に対策を求める場合も、企業規模、扱う情報、業務上の重要性、必要なコストや体制を踏まえ、求める水準と負担のあり方を協議する必要がある。

　クラウドネイティブ社で情報セキュリティ部門を中心にセキュリティの課題解決を支援する吉田浩和氏は、「サプライヤーに対して、ビジネス上のリスクを顧みずに一律の対策を強要することは、セキュリティ原理主義につながります。必要なのはビジネス上の必要性に応じた相互の対話と、適切な報酬の合意です」と話す。

　評価の取得や製品の導入が目的化されてしまうと、セキュリティツールの運用は形骸化しやすい。設定の見直しやアラート分析が十分に行われず、担当者の異動／退職後に運用の意図が引き継がれない例も見られる。また運用を外部ベンダーに委ねた結果、自社の業務やリスクに合わない設定が残る場合も少なくない。

　「EDRは導入しただけでは防御力になりません。アラートを分析し、設定を調整し、侵害の兆候を検知した際に誰が何を判断／実行するかを定めて初めて、端末防御の基盤として機能します」（吉田氏）

Falconか、Microsoft Defenderか──見極めるべきは「運用」に

　EDRを選ぶ際には、検知機能の多さや市場での評価だけでなく、自社の人員や体制で継続的に運用できるかを見極めたい。製品比較／選定の段階で見積もるべきなのは、導入費用だけではないと吉田氏は指摘する。端末への展開、OSや業務アプリケーションの更新時に必要な検証、ポリシーの見直し、アラートの分析、誤検知／過検知の調整、インシデント時の初動対応まで含めた運用負荷についても検討することが重要だ。

　国内の大手企業で候補に挙がりやすいEDR製品として「CrowdStrike Falcon」と「Microsoft Defender for Endpoint」があるが、「単純に優劣を決められるものではない」と同氏は語る。CrowdStrike Falconは多種かつ高度な機能を活用できる反面、使いこなすにあたっての習熟が欠かせない。一方、Microsoft 365やIntuneなどを既に利用する企業では、ID、端末、メール、クラウドサービスを含むMicrosoft製品群の運用と連携させやすい点が特徴となる。既存ライセンスに含まれる場合には、追加投資を抑えられる可能性もある。ただし、いずれも環境に応じた導入検証と継続的なチューニングが必要だ。

　「CrowdStrike FalconとMicrosoft Defender for Endpoint、どちらが良い悪いではなく、自社のOS構成、既存の管理基盤、担当者のスキル、求める監視／対応水準を踏まえて選ぶべきです」（吉田氏）

　加えて、製品選定と同時に見直したいのが「運用の脆弱性」だ。ここでいう運用の脆弱性とは、ソフトウェアに存在する脆弱性そのものではなく、「導入後に設定を見直していない」「アラートの判断基準やエスカレーション先が共有されていない」「例外設定が積み重なっている／放置されている」「検知後の隔離／連絡／復旧の手順が定まっていない」といった運用プロセス上の弱点を指す。

　このような運用上の弱点は、脆弱性スキャンや設定監査だけでは把握しにくい。規程と実務の乖離、アラート対応の停滞、利用部門の業務に起因する例外運用などは、アラート傾向と個々の検知内容を自社の業務／設定に照らしてチェックをかけ、低／中重要度を含むアラートを分析し、検知ルールや設定の調整、運用改善を繰り返すなかで見えてくるからだ。