CSIRT構築②：脆弱性対応
セキュリティ対策で、まず話題になるのは脆弱性対応でしょう。
最近だとApache log4j のように、深刻な脆弱性は定期的に発見されます。
「脆弱性やバグをなくせッ！」というのは、人間に「病気になるなッ！」と言っているようなモノで、言うだけ無駄というやつです。
必ず脆弱性は発見されます。
大切なことは、脆弱性を発見して、それが自社に影響があるかを判断して、影響がある場合は対応する、というフローをいかにスムーズに行える体制とルールを構築するかいう点にあります。
CSIRT役割の中の脆弱性対応箇所
CSIRTの役割分担表の中だと、今回の話は「脆弱性診断士：脆弱性の診断・評価担当」と「システム運用担当」の箇所になります。
どちらもアウトソース可能なので、大企業の場合は運用を担当しているSIerなどに依頼している内容となるかもしれません。
それでは、具体的な構築の流れを見ていきましょう。
脆弱性を見つける
脆弱性を見つけるためには、定期的にチェックするしかありません。
具体的なチェック方法は以下のような形が一般的でしょう。
まずは、脆弱性チェックする対象を可視化しないといけません。
そのためには、社内で利用しているリソース（NW機器、サーバ、PC、クラウドサービスなど）を一覧にします。
この一覧に記載されていない機器やソフトウェアがあると、そこにセキュリティパッチ適用などが実施されないことになり、大きなリスクを抱えることになります。
いきなり100点のリストを作るのが難しいとしても、定期的な棚卸を繰り返して最新状態を維持していきましょう。
ハードウェア・ソフトウェアの一覧ができたら、セキュリティ運用担当がそのリストを基に調査を行います。
JPCERTやJVNといった有名な情報公開サイトを月次で確認したり、メーリングリストに登録してもらい情報を受け取るようにしておきましょう。
セキュリティ分野で一定の評価を得ている企業のホワイトペーパーやBlogやTwitterなどをチェックするのも効果的です。
メーカーやベンダーと機器やソフトウェアの保守契約を結んでいる場合は、脆弱性が見つかった場合にメールなどで通知してもらうこともできます。
こういった仕組みを利用して、月に1回ぐらいはすべての社内リソースの脆弱性が公開されていないかをチェックするようにします。
脆弱性の対応を依頼する
脆弱性が見つかった場合、セキュリティパッチ適用やファームウェアのアップデートなどを行わなければなりません。
それら対応をセキュリティ担当で実施するのは難しいので、それぞれの担当に依頼することになるでしょう。
まずは、セキュリティ運用担当が行った脆弱性診断結果をセキュリティ責任者に連携します。
セキュリティ責任者は内容を確認し、対応が必要な他の責任者対応を依頼します。
依頼を受け取った各責任者は、運用担当者へ対応を依頼するという形になります
これは、かなり大企業の情シスを想定して書いています。
なので、情報システム部門の規模によっては、いろいろと兼務している場合もあるでしょう。
ただ、①チェック、②確認／実施判断、③実施という流れは変わりません。
誰がチェックするのか、だれが確認と判断をするのか、だれが実施するのかを体制上で合意しておいて、実際に脆弱性が見つかった場合は焦らず迅速に対応できるようにしておきましょう。
次回は脆弱性以外の「情報収集・分析」について考えてみたいと思います。
=================
システム運用設計と運用改善についての本を出してますので、ご興味ある方はぜひ読んでみてください。