CISの投稿が続き、今回はControl3についてです。
20まであるので、まだまだ先は長いですが頑張ります。
なお、内容については個人的な見解も含まれていますので、認識が異なる場合はご教示いただけますと幸いです。
CIS Control 3:継続的な脆弱性管理
このコントロール目的としては以下となっています。
また、このコントロールが重要な理由として以下に纏めますと。
・サイバーセキュリティ担当者は脆弱性を理解し管理（ソフトウェア更新、パッチ、セキュリティ勧告、脅威の報告など）することを継続して行わなければならず、多大なリソースが必要。
・攻撃者も同じ情報（脆弱性情報等）を入手可能なため、修正が行われるまでの隙を突かれてしまう可能性がある。（数年前に日本で大きな事件がありましたね。Struts2の脆弱性を使用したやつです。）
・組織が脆弱性スキャン（診断）して発見された不具合に適切な対応が行わなければ、システムやアプリケーションが侵害を受ける可能性が高まる。
・サイバーセキュリティ担当者は修正を組織全体に対して行う場合に、時々発生する副作用（アップデートによる不具合などを指していると思われる）や矛盾した順序でのアクションへの優先付け等の課題に直面する。
※上文について資料の日本語が個人的に変だな～と感じたので、英語の方を見て考えましたが、自信ないです・・・
となっています。
また、上記について実際にどのような対応をすればいいのかについて、以下の表が用意されています。
上表でのSCAPとは「Security Content Automation Protocol：セキュリティ設定共通化手順」を指しています。
次に上記点を踏まえて個人的な考察を行っていきます。
CIS Control 3の検討（考察）
脆弱性診断（クレデンシャルスキャンも含む）の対応について記載されている内容ですね。
私個人的な意見ですが、脆弱性対応については脆弱性が検出されてから対応するパターン（組織）が多いのではないかと思います。
組織で脆弱性の情報収集があまり積極的にできておらず、定期的に行われる外部組織による脆弱性診断の結果を持って対応を検討する場合が多いのではないでしょうか。
報告会で、「危険度の高い脆弱性が検出しました！」と報告があってから、どう対応するかを検討する組織がよくありますが、基本的には自分たちのサーバの管理はまずは自分たちで行うことが理想です。
脆弱性診断で脆弱性を検出したから対応するのではなく、OSやミドルウェアの脆弱性情報やアップデート情報は自組織でまずは仕入れ、そこから対応の優先付けを行っていくことが重要だと考えています。（このControl3でも記載されていますが。。。）
こういうところをちゃんと実施している組織はWebアプリの診断でも脆弱性が少ない場合が多いです。
まあアップデートすると不具合が発生する場合があるので動いているサーバに対して実施するのはキツイのは分かります。
しかし、ここは適切にセキュリティの担当者（部門）に適切な権限があれば対応できる問題と私は考えています。（IT部門下にセキュリティ部署があるのではなく、社長室直下に置く等で対応できるのでは？）
セキュリティ部門の位置付け等についてはControl3の範囲外になりますので、あまり触れませんが、そういったところも脆弱性の修正対応や優先付けをする上では重要になるかと考えています。
不明点や要望、こういったこともやって欲しいとの希望があれば、お問い合わせページやコメント、ツイッターからでも結構ですので、気軽にご連絡ください。
そろそろIPAの試験勉強も始めなければ・・・秋は「ITストラテジスト」を受ける予定です。（2019/7/11から秋試験の受付始まるらしいですよ～）
「ITストラテジスト」はCISやCISA等の資格の勉強、今やっている業務での経験が生かせそうですし楽しみです。
コメント