ゼロデイ攻撃は増加の一途をたどっています。そろそろ防御策を練る時期です。

この記事のバージョンは SCマガジン.この記事は修正され、ここにシンジケートされています。
泥棒に入られたことがある人

なら、「何か変だ」という最初の沈んだ気持ちと、その後に「本当に泥棒に入られたんだ」という実感を理解できるはずです。その結果、フォートノックスに匹敵するようなセキュリティ対策に軸足を移すことは言うまでもありません。

今、あなたの家が泥棒に入られたとしましょう。泥棒は自分たちで鍵を作ってしまったのです。泥棒は好きなように出たり入ったりしながら、気づかれないように忍び足で移動します。そしてある日、冷凍庫に隠していた宝石がなくなっていること、金庫が空になっていること、身の回りのものが荒らされていることに気づくのが遅すぎるくらいです。これは、組織がゼロデイサイバー攻撃の犠牲になった場合に直面する現実と同じです。2020年、Ponemon Instituteの調査によると、成功したデータ侵害の80%はゼロデイ攻撃によるものであり、悲しいことに、ほとんどの企業はこの統計値を大幅に改善する能力がないままであることが明らかになりました。

ゼロデイ攻撃は、定義上、脅威の主体が最初に侵入したため、開発者が既存の脆弱性を発見し、パッチを適用する時間をゼロにするものです。被害が拡大すると、ソフトウェアとビジネスへの風評被害の両方を修正するために、猛烈な奔走が必要になります。攻撃者は常に優位に立っており、その優位性を可能な限り閉じることが重要です。 

誰も欲しがらないクリスマスプレゼント「Log4Shell」は、現在インターネット上で爆発的に広まっており、10億台以上のデバイスがこの壊滅的なJavaの脆弱性の影響を受けていると言われています。過去最悪の0day攻撃となりそうで、まだ始まったばかりです。公開の数日前から悪用が始まったとする報道もありますが、2016年のBlack Hat Conferenceで行われたプレゼンテーションによれば、これは以前から知られていた問題であったことが示唆されます。痛そう。さらに悪いことに、この脆弱性は悪用が非常に簡単で、地球上のあらゆるスクリプト・キディや脅威者がこの脆弱性を利用して大金を手に入れようと狙っています。

では、ソフトウェア開発プロセスで見落とされた脆弱性はもちろん、巧妙で邪悪な脅威から身を守るための最善の道とは何でしょうか？それを見てみよう。 

大規模なターゲットに対するゼロデイ攻撃は稀である（そして高価である）

ダークウェブではエクスプロイトの巨大市場が存在し、ゼロデイはかなりの金額で取引される傾向にあり、この記事の例では執筆時に250万ドルで取引されています。Apple iOSの悪用であると報告されている, それはセキュリティ研究者の提示価格が屋根を通してであることは驚くことではありません, 結局, これは確かに何百万ものデバイスを危険にさらすためのゲートウェイかもしれない, 何十億もの機密データの記録を収穫, そしてそれが発見されてパッチを適用する前にできるだけ長くそれを行う.

しかし、そんな大金、誰が持っているのでしょう？一般的に、組織化されたサイバー犯罪組織は、特に人気の高いランサムウェア攻撃など、価値があると判断されれば資金を調達します。しかし、世界各国の政府や防衛省は、脅威のインテリジェンスに利用できるエクスプロイトを求める顧客の一人であり、よりポジティブなシナリオでは、企業自身が災害を軽減できるように、潜在的なゼロデイエクスプロイトを購入する可能性があります。 

2021年にはゼロデイエクスプロイトのライブ発見の記録が更新されましたが、あらゆる弱点を探られる危険性が最も高いのは、大規模な組織、政府部門、インフラストラクチャです。ゼロデイ攻撃の可能性から完全に逃れる方法はありませんが、寛大で体系的なバグバウンティプログラムを提供することで、多少なりとも「勝負に出る」ことは可能です。ダークウェブ・マーケットプレイスであなたのソフトウェアの城の鍵が提供されるまで待つのではなく、合法的なセキュリティ専門家を味方につけ、倫理的な開示と修正の可能性に見合った報奨金を提供しましょう。

そして、それがたまたまゼロデイ脅威であった場合、Amazonギフトカード以上の出費が必要になると考えてよいでしょう（そうすることに意義があります）。

ツールは、セキュリティ担当者の責任になる可能性があります。

セキュリティツールの煩雑さは以前から問題視されており、平均的なCISOが管理するセキュリティツールは55から75にものぼります。Ponemon Instituteの調査によると、世界で最も分かりにくい（比喩的な）スイスアーミーナイフであることに加え、企業の53%はそれらが効果的に機能していることにさえ自信を持っていないことが分かっています。また、別の調査では、自社のセキュリティ対策が「完全に有効」と考えているCISOは、わずか17%であることが明らかになりました。

燃え尽き症候群、需要に応じたセキュリティ・スキルの人材不足、俊敏性の必要性などで知られるこの分野で、セキュリティ専門家がデータ、レポート、膨大なツールセットの監視といった形で情報過多の仕事を強いられるのは負担が大きいものです。これはまさに、重要なアラートを見逃す原因となるシナリオであり、Log4jの弱点を適切に評価することになったとき、そうであったかもしれないのです。 

予防的セキュリティには、開発者主導の脅威モデリングが必要です。

コードレベルの脆弱性は開発者によってもたらされることが多く、セキュアなコーディングスキルを構築するためには、的確な指導と定期的な学習経路が必要です。しかし、次のレベルのセキュアな開発者には、ソフトウェア作成プロセスの一環として脅威モデリングを学び、実践する機会が与えられています。

自分たちのソフトウェアを最もよく知っているのは、そこに座ってソフトウェアを作成した開発者であることは、驚くにあたらないでしょう。彼らは、ユーザがソフトウェアをどのように操作しているか、機能がどこで使われているか、そして、十分なセキュリティ意識がある場合には、ソフトウェアが破損したり悪用されたりする可能性のあるシナリオについて強力な知識を持っています。

Log4Shellの悪用に話を戻すと、残念ながら、専門家や複雑なツールセットによる検出を免れた致命的な脆弱性が、ライブラリがユーザー入力をサニタイズするように設定されていれば、全く発生しなかったかもしれないというシナリオが見えてきます。しかし、もしライブラリがユーザー入力をサニタイズするように設定されていれば、このような事態は起きなかったかもしれません。そうしなかったのは、利便性を高めるための不明瞭な機能だったようですが、そのために悪用するのが非常に簡単になってしまいました（SQLインジェクションレベル、確かに天才ではありませんね）。もし、脅威のモデル化が、セキュリティに精通した鋭い開発者のグループによって行われていたなら、このシナリオは理論的に検討されていた可能性が高いでしょう。

優れたセキュリティ・プログラムには感情的な要素があり、人間が作り出した問題を解決するためには、人間の介入とニュアンスが重要な要素となります。脅威のモデル化には共感と経験が必要であり、ソフトウェアやアプリケーションのアーキテクチャレベルで安全なコーディングと設定を行うことも効果的である。これは、開発者に一夜漬けでやらせるべきことではありません。しかし、この重要なタスクについてセキュリティチームのプレッシャーを軽減できるレベルまで開発者をスキルアップさせる明確な経路があれば理想的です（そして、それは両チーム間の信頼関係を築く素晴らしい方法なのです）。 

ゼロの日はイヌの日

ゼロデイに対処する次の段階は、できるだけ早くパッチを配布し、脆弱なソフトウェアを使用するすべてのユーザーができるだけ早く、そして確実に攻撃者に先を越される前にパッチを適用することを必死に願うことです。Log4Shell は、何百万ものデバイスに組み込まれ、ソフトウェアビルドに複雑な依存関係が生じる中で、その耐久性と効力はHeartbleed を凌ぐかもしれません。

現実的には、この種の陰湿な攻撃を完全に阻止する方法はありません。しかし、あらゆる手段を用いて高品質で安全なソフトウェアを作成し、重要なインフラストラクチャと同じ考え方で開発に取り組むことで、私たち全員が戦うチャンスを得ることができるのです。