脆弱性スキャナーによる診断で問題点が見つかったら、対策を検討しよう。やみくもに対策を考えるのではなく、見つかった問題点をきちんと整理・分類して計画的に対処することが大事だ。
* * *
脆弱性診断の結果を見た若葉イロハが、途方に暮れて吉野さんに相談している。
若葉:脆弱性が多すぎてどこから対策すればよいかわかりません…。
吉野:大丈夫!対策には考える順番があるんだ。
* * *
根本的な対策は3パターン
自社のサーバーを脆弱性スキャナーで診断すると、問題点が多数検出される。全部で50個程度検出されるのは普通だが、心配は無用だ。脆弱性の根本的な対策は、「サービス/機能の停止」「OS/ソフトウエアの設定変更」「バージョンアップ/パッチ適用」の3パターンに分類できる。
脆弱性を検出したサービスや機能が不要な場合は、止めてしまおう。これが一番確実な対策になる。インターネットに公開している重要なサービスに緊急性が高い脆弱性が見つかった場合は、利用者に被害が及ぶ可能性を考えてサーバー自体を一時的に停止することもある。
脆弱性がOSやソフトウエアの特定の設定によって生じている場合▼は、設定を変更すればよい。また、サポート期間中▼のソフトウエアに脆弱性が見つかった場合は、新しいバージョンやセキュリティパッチが出ていることが多い。ベンダーの最新情報をチェックして、アップデートしよう。
対策実施の優先度を決める
対策方法がわかっても、すべての脆弱性に対処するには時間がかかる。そんなときは、対策の優先度付けから始めよう。このとき、危険度の高さだけでなく、影響範囲の広さも考慮する。例えば、同じ危険度の脆弱性でも、インターネットに公開しているシステムは、社内だけに公開しているシステムより攻撃を受ける可能性は高い。公開サーバーを先に対策すべきだ。
危険度が低い脆弱性で、特に悪影響がないものであれば、当面は放置して次の計画的なシステム改修時に対策するといった判断もできる。ただし、脆弱性スキャナーが出す危険度は低くても、実は攻撃を簡単に実行できて悪影響がある脆弱性もあるため、脆弱性の内容を慎重に評価したい。
検出した脆弱性に対して毎回優先度を検討するのは大変だし、判断基準もぶれやすい。何度かスキャンして慣れてきたら、対策の要否や期限を定めた脆弱性対策基準を作るのがお勧めだ。脆弱性の危険度やシステムの公開範囲、システムに格納している情報の重要度といった評価項目を考慮した基準を整備しよう。「最優先の脆弱性は3日以内」「次に優先度の高い脆弱性は1カ月以内」など、具体的な対策基準を作って社内の承認を得ておけば、対策計画を立てやすくなる。
例えば、HTTPサービスで使っていないPUTメソッドが原因でアップロードの脆弱性が出たときは、設定ファイルを変更して無効化する。
サポート期間が終了したソフトウエアはそれ自体がリスク。脆弱性情報が公開されないし、パッチも提供されない。