この詳細なガイドでは、セキュリティチームが脆弱性に圧倒される理由、脆弱性の二重報告の背後に隠れている危険性、およびKernelCareなどのライブパッチツールを使用してそのような脆弱性を軽減する方法について説明します。
サイバーセキュリティの脅威が増大しており、脅威とそれに関連するコストを軽減するための取り組みがそれに合わせて増大していることを私たちは知っています。しかし、証拠は、緩和が十分に迅速に進んでいないことを示唆しています。
共同の分析によると マカフィーが実行 および戦略国際問題研究所 、2020年には、サイバー犯罪の世界的なコストが $ 1tnを超えて上昇するでしょう。 初めてマーク-2018年の合計よりも50％の大幅な増加。これは、GDP成長率やIT支出の増加率など、同等の指標を明らかに上回っている変化率です。
意識は問題ではありません。結局のところ、企業はサイバー脅威から身を守るために莫大な金額を費やしています。
代わりに、この記事では、サイバーセキュリティプレーヤーは、直面している課題に本質的に圧倒されていると主張します。明確な証拠として、既知の脆弱性の二重報告が最近発生したことを指摘します。
セキュリティチームが脆弱性に圧倒される理由、パッチへの影響、および脆弱性とエクスプロイトの絶え間ない猛攻撃に直面して一貫してパッチを適用するためにチームができることを確認するために読み続けてください。
さらに別の脆弱性？
昨年の後半に、Linuxカーネルの脆弱性が発見され、報告されました。 Cが割り当てられました オモンV 脆弱性とE xposures（CVE）番号、 CVE-2020-29369 、および脆弱性は予想どおりにパッチが適用されました。これまでのところ、異常なことは何もありません。
脆弱性自体についても、通常を超えるものは何もありませんでした。どのOSでも、カーネルはメモリを慎重に管理する必要があります。アプリケーションが必要とするときにメモリスペースを割り当て（マッピング）、アプリケーションが不要になったときに割り当てを正しく削除して空きメモリを再割り当てします。
ただし、メモリスペースを管理するこのプロセスは、グリッチが発生しやすい可能性があります。必要な注意を払わずにコーディングすると、カーネルメモリ処理プロセスがサイバー犯罪者に機会を与える可能性があります。 CVE-2020-29369の場合、Linuxのメモリマッピングに使用されるmmap関数で問題が発生しました。
この脆弱性の性質上、2つの異なるアプリケーションが同じメモリ空間へのアクセスを要求し、カーネルがクラッシュする可能性がありました。
攻撃者がカードを正しくプレイした場合、つまりエクスプロイトを設計した場合、攻撃者はカーネルによって保護されているデータを取得できるようになります。完全に無害なデータ、または貴重な個人データやパスワードなど、より価値のあるものである可能性があります。
2つの脆弱性レポートの話
したがって、典型的な脆弱性が報告され、通常の手順に従って受け入れられたことがわかります。しかし、次に何か戸惑うことが起こりました。
ほんの数か月後、まったく同じ脆弱性が報告されました。ここでも、CVE番号が割り当てられました。今回は CVE-2020-20200 。ただし、新しい脆弱性アラートは別の脆弱性（CVE-2020-29369）の複製であることがすぐに判明しました。
何らかの理由で脆弱性を2回目に「発見」した研究者は、発見したものについて別のCVE予約を要求する前に、脆弱性の最初のインスタンスを見つけることができませんでした。 CVEデータベースの主な目的の1つは二重報告を回避することですが、この特定の例では、それでも別のCVEが要求されました。
「二重報告」と呼ばれるこのケース 脆弱性が2回報告された最初または唯一のインスタンスではありません。さらに悪いことに、脆弱性の調査がCVEが割り当てられた時点に達すると、その脆弱性はすでに多くの高度な訓練を受けたセキュリティ専門家によってレビューされています。
セキュリティ研究者でさえそれを混同する可能性があります
この二重報告の例では、セキュリティ研究者が既存の脆弱性を認識していたか、新しいCVE番号を要求する前に「新しい」脆弱性を十分に調査した場合に既存のCVEを見つけたはずであることは明らかです。
気になる思いです。このメモリマッピングの脆弱性はLinuxカーネルのコアにありますが、セキュリティ研究者は明らかにそれを認識していなかったため、二重にリストされています。さらに悪いことに、各リストが10年または数年離れているわけではありません。同じ脆弱性の個々のリストは、2020年8月と2020年11月に1つずつ、わずか数か月離れて作成されました。
セキュリティ研究者は怠慢ですか？いいえ。セキュリティ研究者は、サイバーセキュリティの課題の膨大な量に完全に圧倒されています。そのため、この例では、Linuxカーネルセキュリティの専門家は、潜在的に重大な脆弱性に関する既存のレポートを見逃していました。
脆弱性の二重報告の背後にある隠れた危険
サイバーセキュリティの脅威が増大しているという明確な証拠は、セキュリティの専門家でさえ間違っている例と相まって、二重の報告が一見したところよりも大きな影響を及ぼしていることを示唆しています。
Linuxのセキュリティ専門家がエラーや見落としを起こしやすいことを示唆するものではありません。これは、セキュリティの脆弱性を管理する作業が非常に困難になり、専門家でさえも追いつくのに苦労していることを示唆しているにすぎません。
包括的な権限を持つ典型的な社内テクノロジーチームについて少し考えてみてください。セキュリティを含みますが、メンテナンス、運用、その他の無限の責任もカバーしています。
エンタープライズチームに専任のセキュリティ専門家がいる場合でも、専門知識をさまざまな脅威やテクノロジツールに適用する必要がある可能性があります。大企業でさえ、Linuxカーネルのセキュリティ専門家を雇うことは非常にまれです。そして、たとえそうだったとしても、これまで見てきたように、これらのセキュリティ専門家はそれを誤解する可能性があります。
ITチームはこれから厳しい時期にあります
オンサイトチームは、常にある程度のセキュリティの脆弱性を管理します。たとえば、主要なエクスプロイトのニュースに対応し、それに応じてパッチを適用します。ベンダーからの警告も行動を促す可能性があり、ほとんどの優れたIT部門には、パッチが設定された間隔で適用されることを保証するある種のパッチ適用体制があります。
しかし、ITチームは、Linuxディストリビューション全体に影響を及ぼし、日々増え続けるCVEの山に現実的に対応するにはどうすればよいでしょうか。たとえば、四半期ごとのパッチ適用体制は本当に十分なセキュリティを提供しますか？はい、パッチ適用は重要です 、しかし、それは他のすべてを犠牲にして活動を支配する必要があります-パッチの量を考えると簡単に発生する可能性がありますか？
ITチームが、増え続ける脆弱性のリストを先取りするのが難しいことに気付くのは簡単です。
パッチ適用体制を正しくする
パッチ適用体制を形式化することは、CVEの山に対処しようとする最初のステップです。警戒すべきニュースレポートに基づくアドホックパッチは、進むべき道ではありません。脆弱性が多すぎて、広く知られるようになることは比較的少なく、危険をもたらす無数の隠れた脆弱性と関連するエクスプロイトを残しています。
それでも、パッチ適用レジームを作成する際の重要なステップの1つは、パッチの優先順位付けです。重大で広く知られている脆弱性は、遅延なく、必要に応じて可用性を犠牲にして、迅速にパッチを適用する必要があります。中リスクおよび低リスクの脆弱性に対するパッチは、技術チームの作業負荷に合わせて、または可用性の問題を回避するようにスケジュールできます。
もう1つの重要なステップは、パッチ適用が必要なハードウェアとソフトウェアの十分に完全なインベントリを作成することです。パッチの適用対象の中にはすぐに明らかになるものもありますが、他のターゲットは簡単に見落とされる可能性があります。
インベントリを作成する際に、標準化の範囲を特定することもできます。つまり、ソフトウェアを同じバージョンにアップグレードしたり、ベンダーを統合してパッチの管理を容易にしたりすることもできます。
最後に、パッチ適用体制を正式なパッチ適用ポリシーに体系化することは価値があります。パッチを適用することは一貫して行うのが難しく、必要なのは災害への扉を開くための1回の失敗だけです。体系化されたパッチ適用レジームは、チームがパッチ適用を順調に進めるのに役立ちます-年中、年中。
パッチ適用とのトレードオフ
どのパッチ適用方式でも、通常、可用性とセキュリティの間でトレードオフが発生します。はい、非常に安全な方法でパッチを適用できます。パッチはリリースされるのと同じ速さで適用されます。ただし、パッチ適用にはサーバーの再起動が必要になることが多いため、パッチ適用は必然的に可用性に影響を与えます。
実際、一部の企業は、重要なCVEが表示された場合でも、サービスやサーバーを停止してパッチを適用できないようにする特定のビジネス要件を持っている可能性があります。これにより、サービスが新しいエクスプロイトに対して脆弱になる可能性があります。
メンテナンスのためにサーバーをオフラインにできる場合でも、サービスが低下し、その結果、エンドユーザーエクスペリエンスが低下します。たとえば、何千もの顧客がオンラインで突然サーバーの半分をメンテナンスのためにオフラインにしているオンライン小売業者を考えてみてください。
次に、パッチ適用に時間を費やすために他のタスクに費やす時間を必然的に犠牲にしている技術チームの浪費もあります。セキュリティチームは、パッチ適用の負担に完全に圧倒される可能性があります。ただし、別の方法があります。
自動パッチツールを検討する
標準のパッチ適用レジームの背後にある2つの重要な問題を特定しました。それは、パッチ適用に必要な時間と労力、およびパッチ適用に関連する中断です。検討する価値のあるソリューションの1つは、自動パッチです。再起動なしの自動パッチの場合は、さらにそうです。 サーバーを再起動せずにパッチを適用します。
自動パッチツールは、パッチリリースを継続的に監視し、介入なしでこれらのパッチを自動的に適用します。サーバーフリートにパッチを適用するために人的資源を費やす必要がなくなります-パッチ適用はバックグラウンドでシームレスに行われます。自動パッチ適用により、技術チームは無数のパッチ適用タスクに圧倒されることはなく、技術チームはどのパッチが最も重要であるかを予測する必要もありません。代わりに、すべてのパッチがシームレスに、均等に、そして一貫して適用されます。
KernelCareなどの一部の自動パッチツール オンザフライでパッチを適用できます-マシンの実行中に、再起動を必要とせずにライブでパッチを適用します。ライブパッチは、パッチを処理するためにマシンがオフラインにならないため、中断を制限します。中断のリスクが最小限の場合、パッチ適用の一貫性が向上する可能性があります。
言い換えれば、適切な自動パッチ適用ツールは、企業がパッチ適用で直面する2つの最大の問題、つまり必要な労力と中断を解決できます。
どのようにパッチを選択しても、パッチは重要です
あなたの会社がパッチを当てるために自分自身をカバーするために何をするにしても、あるいはあなたがパッチを適用する体制をどのように調整するにしても、確実なのはパッチが重要であるということです。パッチを適用する必要がありますが、パッチを適用する頻度とパッチを適用する方法について決定する必要があります。
サイバーセキュリティの脅威の大きさを考えると、自動パッチ適用には強い議論があります。技術チームとセキュリティ研究者は同様にますます圧倒され、自動パッチ適用はリソースと可用性の問題を埋めています。
パッチ適用の課題により多くの人員を適用することは常にオプションであり、一部のワークロードではそれが唯一のオプションである可能性があります。しかし、ほとんどの場合、自動化された再起動なしのパッチ適用は、今日の巨大なサイバーセキュリティの課題に対して大きな勝利をもたらすことができます。
おすすめの記事：
- Raspberry Pi LinuxカーネルをKernelCareで無料でパッチ！
- UCheckerを使用してメモリ内の古い共有ライブラリを検出する