ベースで行うと、その作業量は非常に多くなるという話をします。脆弱性データベースを使うと、ソフトウェアベンダーが提供する「パッチ」に基づいた情報が「管理単位」となるため、結果的に現場SEの対策のための工数が大幅に縮減されます。ベースに行っています。発表されていることに拠るものです。ベースで引用する手段しかないのが現状です。今まで、脆弱性の「情報」を管理することに主眼が置かれていたことは否定できません。高い脆弱性の「CVE情報」を拠り所にして「ピンポイント」でその対策の管理を行って良しとした背景があります。脆弱性「情報」があれば管理できたという考え方です。ベースの脆弱性対策の対象範囲が一気に増加します。これは、組織にどういった問題を引き起こすのでしょうか?組織は、脆弱性の「情報」を管理することではなく、その「対策」を管理するもの対策作業を行うのは、「セキュリティ運用管理者」ではなく「現場SE」となります。対応するベンダー・パッチ情報を探すといった一連の重作業が待ち構えています。増加すると、そのパッチを探すだけでも大きな負担となり、真剣に対策を施す組織ほど、「現場SE」の疲弊が始まります。件もあり、非常に多いことがお分かりかと思います。対策を行う対象は、組織のITシステムとなります。システムの位置づけや重要度に応じて対策作業レベルは異なりますが、現在は、セキュリティ脅威に対する予防的意味合い(セキュリティ・ハイジーンという衛生管理面)を重視する傾向があり、対象となる脆弱性に対して、ほとんどのシステムにパッチを適用する作業が必要となってきております。このような状況下では、「現場SE」がベンダーパッチを特定し、効率的に作業ができる情報提供環境を提供する必要があります。ベースで対策作業を行うことは無理があると言えましょう。脆弱性対策のための管理システム設計を行う際には、PDCAサイクルが破綻しないように注意が必要です。その管理の根源となる「情報データベース」の組成がその後の対策作業に大きく影響することは、皆さんが知っているようで知らない事実なのです。方式と較べてみてください。脆弱性データベースや管理ツールを使用すると、「現場SE」のこうした負担をなくします。脆弱性データは、各ソフトウェアベンダーの正式なセキュリティ・アドバザリ情報(=パッチ情報)を「一単位」として作成されています。纏めて修正する形となっております。いった管理ツール製品では、この単位で「脆弱性チケット」が作成されます。「脆弱性チケット」内から参照できる情報として「パッチ情報」がタイアップされており、チケット内から直接、パッチを参照できます。パッチの在り処情報、脆弱性の評価指標などが全て纏められて閲覧できるようになっています。以下の例を見て下さい。脆弱性情報単位(1チケット)の表示例です。ものが含まれています。個の脆弱性を修正するものとして、表示されているパッチファイルを適用するといったような情報の見え方となります。管理チケットを発行し、それぞれのパッチの在り処を調査し、多数のチケット管理を行う必要があります。これは大幅な時間を費やすことになります。脆弱性の管理単位は、以下のようなアドバンテージがあります。脆弱性データは、ソフトウェアベンダーのセキュリティ・アドバザリ情報(=パッチ情報)を「一単位」として組成されています。ベースで管理される環境に較べ、「対策作業に掛かる手間」を大幅に削減する効果があります。現在、市場に存在する他社の脆弱性管理システムは、脆弱性スキャナーによって脆弱性を検出するアプローチを取っています。ベースで検出されます。ベースで管理する際の問題点に直面することになります。管理を行う際の問題について具体的に説明します。まとめて修正する形でパッチや更新プログラムを提供しています。毎に脆弱性の管理を行う場合、次のようなプロセスになると考えます。作業に無駄が多いのではないかと考えます。評価を独自に行っていることがあります。元に脆弱性の管理を行っていくのは、危険性を評価していく上でも不合理であるように考えます。した例は、他にも数多く存在します。非常に多く登録されます。ごとにハンドリングしていくのは既に現実的ではないのではないかと考えます。よる脆弱性の管理は、ゼロデイの脆弱性など特定の危険性の高い脆弱性には有効な部分もありますが、実際のデイリーワークとしての脆弱性管理にはあまり有効ではないと考えます。割り当てられないことがあります。割り当てが行われなかった代表的な製品は、次のとおりです。割り当てられないことが多いです。Node.jshttps://nodejs.org/en/blog/vulnerability/december-2019-security-releases/現在も割り当てられていないように見えます。そのうち割り当てられると思います。割り当てられていません。元に脆弱性をハンドリングした場合、こういった情報は存在しないこととなります。スコアの登録まで時間がかかることがあります。スコアを脆弱性の危険度判定に使用している場合に、脆弱性への対処をタイムリーに実施することができないという大きな隙を生み出します。スコアが登録されるまでその脆弱性は無いものと扱うしかありません。スコアが無いため、対処を決めそこねる可能性があります。必要なタイミングで危険度の高い脆弱性であることを評価できなければ、脆弱性を管理する上では危険度評価としての意味がありません。スコアは、タイムリーな脆弱性の危険度評価という意味において判定基準としての役割を果たしません。指標を使用することにより、こうした問題を回避できます。Impact)指標も同時に登録されます。等の脆弱性チケットでは、それが発行された時点で、脆弱性の危険度が特定されます。評価値との比較を含めて、以下のブログでも説明しています。管理対象のホストで使用するソフトウェアで新しく報告された脆弱性のピックアップを行い、影響判定や対策工程の把握まで、脆弱性管理をトータルでカバーいたします。脆弱性の調査やパッチ探しは一切不要!脆弱性対策を自動化できるので工数大幅削減!さらに自社の脆弱性状況を全て可視化できるので管理がグッと楽になる!それらを全て実現するサービスがあります。各種サービスの使用法や購入において気になる点などお気軽にお問い合わせ下さい。実際に無料で使ってみてください。