ラックによると、中堅・中小企業では、セキュリティの重要性を認識していても、脆弱性診断そのものが後回しになるケースがある。さらに、診断を実施して報告書を受け取った後も、是正の手が止まるケースも含めると、「対策が先に進まない」状況は複数の段階で生じているという。

　背景には、専任人材と予算の不足がある。製品やサービスを作り、予定通りに提供することが優先される中で、脆弱性診断が出荷やリリースの直前に実施するテストの一つとして扱われる場合もある。設計段階からセキュリティを考えるのではなく、開発の最後に問題がないかを確認する位置付けになっているという。

　診断を一度きりで終える企業がある一方、定期的に繰り返す企業もある。ラックは、この違いは企業規模だけでは決まらないとみる。自社が扱う情報の重要性や、インシデントが事業に与える影響を、企業や担当者がどこまで自社の事業リスクとして認識しているかも関係するからだ。

　例えば、過去にセキュリティインシデントを経験した担当者がいる場合や、取引先や業界の基準から対策を求められる場合は、脆弱性診断の優先度が上がりやすい。一方で、外部から明確に求められなければ、必要性を理解していても日々の業務に押されてしまう。

　診断を受けること自体が目的になれば、その後の是正にはつながりにくい。診断を単発のテストではなく、問題の把握から修正、再確認までを繰り返す運用の一部として位置付ける必要がある。

「全部守りたい」では、優先順位を決められない

　人員も予算も限られる中で、発見した全ての脆弱性に同じ速さで対応するのは現実的ではない。では、何を基準に優先順位を決めればよいのか。ラックが最初に確認するのは、「その企業が本当に守りたいものは何か」だという。

　「全部守りたい」という回答は自然だが、全ての情報やシステムを同じ強度で守ろうとすれば、限られたリソースが分散する。まずは自社が扱う情報や資産を確認し、侵害された場合に事業へ大きな影響を与えるものを特定したい。

　優先して守る対象は企業によって異なる。例えば、人命や安全に関わる機能を持つ企業であれば、それが最優先になる。個人情報や顧客情報、取引情報、売り上げに関わる情報なども候補になる。停止すれば事業を継続できないシステムや、漏えいによって顧客からの信用を大きく損なう情報も重要だ。

　事業への影響だけでなく、外部からどの程度アクセスされ得るかという「露出度」も判断材料になるとラックは指摘する。重要な情報を扱うシステムがインターネットに公開されているなど、外部から到達しやすい場合は、対応の優先度も高くなる。

　一方、「守るべきものを聞かれても分からない」という企業もある。その場合は、どのような情報とシステムを持ち、誰が利用し、どこからアクセスできるのかを把握することが出発点になる。

　脆弱性診断の役割は、単に脆弱性を見つけることだけではない。診断対象を決める過程で自社の情報やシステムを整理し、診断結果を基に「自社では何を優先して直すか」という判断基準を作る契機にもなる。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

自社が持つ情報やシステム、業務を把握し、事業への影響と露出・アクセスから優先して守る対象を決める（ラックの回答を基に編集部で作成）

「閉じたつもり」のサーバが残る、資産把握の落とし穴

　優先順位を付けるには、そもそも自社が何を保有しているのかを把握する必要がある。ラックによると、現場では、脆弱性のあるライブラリを使い続けている社内ツールや、業務上の理由からOSを更新できない端末などが、侵入経路や侵入後の横展開の起点になることがあるという。

　外部公開資産にも見落としがある。例えば、古いWebサイトのトップページを削除しても、サーバや入力フォームが残っていれば、外部からアクセスできる可能性がある。「サイトを閉鎖した」「ネットワークから切り離した」と認識していても、本当に到達できない状態になっているとは限らない。

　資産台帳が存在するだけでも十分ではない。誰が所有し、何に利用し、どのソフトウェアやライブラリが稼働し、パッチがどこまで適用されているかを継続的に更新する必要がある。必要に応じて、ASMなどを使って外部から見える資産を確認することも選択肢になる。

価格だけでは見えない、診断後の支援範囲

　脆弱性診断サービスを選ぶ際、価格や診断できる項目数は比較しやすい。ただし、それだけでは、診断結果を受け取った後に自社がどこまで対応できるのかは分からない。ラックは、価格に加えて、診断範囲や報告内容、診断後の支援範囲を確認する必要があると指摘する。

　サービスによっては、自動診断ツールによる検出結果の提示を中心とするものもあれば、利用環境を踏まえた対処方法の説明や、修正後の再診断まで含むものもある。脆弱性の名称と深刻度が一覧になっていても、利用者が「自社の環境ではどう直せばよいのか」を判断できなければ、対策にはつながらない。報告書の内容を自社だけで読み解けなければ、修正方法を改めて調査したり、別の専門家に相談したりする必要が生じる。

　特に専任のセキュリティ担当者がいない企業では、「脆弱性が見つかるか」だけでなく、「見つかった後に行動できるか」という観点も欠かせない。ラックへの取材を基に、サービス選定時の確認項目を編集部で整理すると次のようになる。

• 本当に守りたいシステムや資産が診断範囲に含まれているか
• 報告書に具体的な対処方法が記載されているか
• 自社のシステム構成や運用上の制約を踏まえた提案を受けられるか
• 報告後に内容や修正方法を質問できるか
• 修正後に脆弱性が解消したかを再診断できるか
• 自社だけで対応が難しい場合、どのような追加支援を受けられるか

　一般的な対処方法が分かっても、自社の環境では実施できないことがある。例えば、修正プログラムをすぐに適用すると既存システムへ影響が出る場合は、代替策を検討しなければならない。その際、自社の事情を踏まえて次の一手を提案してもらえるかどうかも、サービスを比較するポイントになるとラックは説明する。

　診断の目的が「穴を見つけること」であれば、ツールの実行と結果の提示だけでも目的を達成できる場合がある。一方、診断の目的を脆弱性の是正まで含めて考えるのであれば、報告書を受け取った後の支援範囲もサービス選定の条件になる。

全社で回せないなら、小さな単位で始める

　脆弱性対策を継続するには、役割と対応期限を明確にしておきたい。例えば、誰が脆弱性の優先度を判断し、誰が修正し、誰が進捗を確認するのかを決める。どの程度の深刻度なら、いつまでに対応するのかという基準も必要だ。

　ただし、中堅・中小企業では、ネットワークやサーバ、業務システムなどの担当が分かれていたり、別の業務と兼任していたりする。脆弱性が見つかるたびに関係者全員を集めなければ動かない仕組みでは、継続は難しい。

　ラックが勧めるのは、最初から大規模な運用を作ろうとせず、小さくても回る単位から始める方法だ。全社で一斉に取り組むことが難しければ、特定の部署やシステム、資産群に対象を絞る。小さな範囲で、可視化、優先順位付け、是正、再確認というサイクルを回し、そこから対象を広げていく。

　一度このサイクルを回せば、そこで決めた判断基準や役割分担を、翌年度の見直しや別のシステムの診断にも応用できる。

　確認の頻度も、全ての資産で一律にする必要はない。ラックは、重要な情報を扱う対象であれば月次程度の確認も選択肢になる一方、全ての企業が同じ頻度で実施するのは難しいとする。企業や対象によって異なるとした上で、年1回程度の資産と対応状況の棚卸しを一つの目安として挙げた。

　ある時点で問題が見つからなかったからといって、その後も安全な状態が続くとは限らない。新たな脆弱性は継続的に公表され、システムの構成や利用方法も変化する。診断を繰り返すだけでなく、資産や対応状況も定期的に見直す必要がある。

画像をご覧いただくには会員登録が必要です

会員登録・ログイン

全社一斉の運用が難しい場合は、部署やシステム、資産群に対象を絞り、担当と期限を決めて対策を回す（ラックの回答を基に編集部で作成）

脆弱性管理を「最後の検査」から「設計の土台」へ

　EDRやXDRなどの対策と脆弱性対策は、どちらか一方を選ぶものではない。攻撃の検知や対応を支援する仕組みと、攻撃に悪用され得る弱点を把握して修正する取り組みは役割が異なり、互いに補完する関係にある。

　ラックは、脆弱性管理をセキュリティ運用の「土台」と位置付ける。システムを作り終えた後に安全性を確認するだけでなく、設計や開発の段階から、何を守り、どのようなリスクを減らすのかを考える「セキュリティ・バイ・デザイン」につなげるという考え方だ。

　診断を受け、報告書を受け取ることはゴールではない。自社が守るべきものを確認し、見つかった問題に優先順位を付け、修正し、再び確認する。このサイクルを小さな範囲からでも継続して回すことで、脆弱性診断を実際のリスク低減につなげられる。

　脆弱性管理を単発の経費として捉えれば、売り上げに直結する施策より後回しになりやすい。しかし、脆弱性を放置した結果、事業停止や情報漏えいが起きれば、事業継続に影響を及ぼす可能性がある。診断を単発の検査にとどめず、自社の事業リスクに応じて、予算や体制にどう組み込むかまで考えることが重要だ。