脆弱性対応フローが明確化されていなかった組織事例 #

商社系のA社では、小規模なシステムを管理していますが、脆弱性対応について明確なポリシーはありませんでした。ニュースなどで報道されるものについて対応する、という状況でした。
自社のサイバーセキュリティ対策を強化することになり、脆弱性トリアージや対応について判断基準を決め、対応の標準化を行うことを決定しました。

まず、対応の全体像を決定しました。1章の「脆弱性対応の判断フロー」において、どのタイミングで何を行うのか、その際の判断根拠となる社内規定等はあるのか/なければ整備する必要があるのかを検討しました。

次に、脆弱性対応の優先度判断となる脆弱性トリアージ基準を策定しました。脆弱性トリアージを組織として行うことに慣れていないため、まずはCVSS BaseScoreを基準に設定しました。まずは、複雑ではなく単純化し、運用に慣れてきたら判断基準を変更していくという戦略です。

9.5以上(重大度:Critical)：1週間程度以内で対応し、場合によっては業務を止める
8.0以上(重大度:High)：なるべく早く対応する（2週間程度以内）
8.0未満：早急に適用する必要はないが、定期メンテナンス等で適用を検討する

その後、脆弱性対応に対する基準を策定しました。例えば更新プログラムを適用することを想定した場合、どのようなプロセスが必要なのか、その為の準備はできているかなどを確認し、整備しました。テスト環境が本番と同じ状態か、更新後の稼働テストは何を確認するのか、等です。

そして、脆弱性情報の取得方法や、対象システムの現状把握を行いました。1章の「脆弱性対応の判断フロー」にもある通り、脆弱性の認知と影響分析が必要です。
まずは対象システムの構成を把握し、利用しているソフトウェアの棚卸を行いました。これにより、脆弱性を把握すべきソフトウェアが特定され、情報収集がやりやすくなります。また、これらを自動化するために、脆弱性管理ソフトウェアを入れました。

これらにより、脆弱性認知速度が上がり、より早く対応が必要かを判断することができるようになりました。今までは被害影響が出たニュースを基に対応していましたが、脆弱性情報が出たタイミングで自システムが対象になるのかを判断できる状況になりました。

上記運用をしばらく続けた中で、“対応すべきと判断される脆弱性の数"が多いと感じる点が、課題となっています。これは脆弱性トリアージでCVSS BaseScoreのみを利用しており、実際のリスクでの判断とはなっていない点が関連しています。今後、攻撃される可能性の評価として、EPSSやKEVカタログなどを取り入れることで、トリアージ基準を脆弱性自体の危険度から事業へのリスクに変えていく方針としています。

今回の事例では、以下が言えると思います。

まずは小さく始める
- 脆弱性トリアージでは、最初から複雑な基準を盛り込むと、破綻する可能性があります
- 理想論は一旦置いておき、「現実に対応できる/しきれる基準」を設定します
実際に脆弱性トリアージを行って、課題を感じたら変更していく
- 課題を感じた時点で、現状のフローや基準を見直し、自組織の体力に合わせて調整することが望ましいと考えられます
- 状況により、人員の増強やソフトウェアの導入も検討が必要です