2019年の最も危険なソフトウェアエラー：歴史が繰り返される証拠が増える

この記事は以下に掲載されました。 インフォメーション・セキュリティ・バズに掲載され、他のいくつかの媒体にも取り上げられました。ここでは、シンジケーションのために更新されています。

昨年末、MITREの素晴らしいコミュニティが、2019年に世界に影響を与えた「CWE Top 25 Most Dangerous SoftwareErrors」のリストを発表しました。このリストは意見に左右されるものではなく、NISTのような組織の活動や、公開されているCVE（Common Vulnerabilities and Exposures）データを活用した多面的な分析の結果です。上位」の欠陥を決定するために、その重大性、悪用可能性、現行ソフトウェアでの普及率に基づいてスコアが付けられています。このようなリストは、積極的な賞賛を得られるようなものではありません。

しかし、一般的な年鑑とは異なり、このリストに登場する多くの作品は、何度も何度も登場しています。これがBillboard Hot 100チャートであれば、ブリトニー・スピアーズの「Baby One More Time」やバックストリート・ボーイズの「I Want It That Way」が初登場以来、毎年登場しているようなものだ。なぜそのような曲を選んだのか？それは、何十年も前に発見されたにもかかわらず、2020年になっても私たちを悩ませている危険なソフトウェアのエラーのように、およそ20年前の曲だからです。

なぜ古いバグは危険なのか？直し方もわからないのか？

現在のMITREのリストの第6位は、SQLインジェクション（SQLi）として知られるCWE-89です。SQLiの脆弱性が初めて発見されたのは1998年のことで、まだ多くの人がGoogleではなくJeevesに切実な質問をしていた頃でした。その後すぐに修正プログラムが公開されましたが、それでも2019年に最も使われているハッキング手法の1つであることに変わりはありません。アカマイの インターネットの現状のレポートでは、ウェブアプリケーション攻撃の3分の2でSQLiが原因となっていることが明らかになりました。

複雑さという点では、SQLインジェクションは天才的なレベルのエクスプロイトとは程遠いものです。ウェブ開発者にとっては簡単な修正方法であり、この脆弱性によって貴重なデータが攻撃者にさらされるのを防ぐ方法は何のためらいもなく知っています......問題は、今日でも多くの開発者にとって、セキュリティは優先事項ではないということです。20年前には簡単だったかもしれませんが、今日、そして未来に作られる膨大な量のソフトウェアを考えると、これはもはや普通のことではありません。

開発者は、（ほとんどの場合）壊れたシステムの中で仕事をしています。

悪い」コードを提供した開発者を非難するのは簡単なことです。しかし実際には、開発者の優先順位はセキュリティチームのそれとは大きく異なります。一般的な開発チームは、美しくて機能的なソフトウェアをできるだけ早く作るように言われます。ソフトウェアに対する社会の飽くなき欲求により、開発チームはすでに疲弊しており、セキュリティは第一に考慮されていませんが、結局のところ、そのためにAppSecスペシャリストが存在しているのではないでしょうか。ソフトウェアエンジニアは、セキュリティとの関係がやや冷え切ったものであることに慣れています。問題が発生したときにのみセキュリティ担当者から連絡を受け、その問題が彼らのハードワークの生産を妨げます。

一方、AppSecのスペシャリストは、スキャンや手動コードレビューのたびに出てくる何十年も前のエラーを修正することにうんざりしています。このような専門家は高価で希少な存在であり、彼らの時間は、よく知られたバグを何度も潰すのではなく、複雑なセキュリティ上の欠陥に費やす方がはるかに良いのです。

これらのチームの間では、暗黙のうちに責任のなすり合いが行われていますが、安全なソフトウェアという同じ目標を持っています（あるいは持つべきです）。開発者は、安全なコーディングを成功させるチャンスがほとんどない環境で仕事をしています。セキュリティのベストプラクティスが高等教育の一環として教えられることはほとんどなく、現場でのトレーニングも頻繁に行われないか、まったく効果がないことが多いのです。セキュリティ意識の向上や関連性の高い詳細な教育は明らかに不足しており、その結果、コミットされたコードの古いバグを修正するための天文学的なコストや、評判を落とすようなデータ侵害の差し迫った脅威が発生しています。

ヒューマンファクターとは、「なぜこれらのツールは我々のデータをより安全にしてくれないのか」ということです。

もう1つの問題は、トレーニングの代わりに、膨大な数のセキュリティツールを使用して、ソフトウェアが公開される前に問題を発見するというものです。アプリケーションスキャンおよび保護ツール（SAST/DAST/RASP/IAST）の配列は、確かにソフトウェアを安全に製造するのに役立ちますが、これらには問題があります。それらに完全に依存することは、セキュリティを保証するものではないからです。

• すべてのフレームワーク、すべてのユースケースにおけるすべての脆弱性をスキャンできる「1つの」ツールはありません。
• 特に、静的・動的コード解析を同時に行う場合は、時間がかかることがあります。
• 誤検知は引き続き問題となります。これらはしばしば生産を停止させ、警告の意味を理解するために不必要な手動のコードレビューを必要とします。
• このようなツールを使うことで、安全なコーディングが優先され、何か問題があってもツールが解決してくれるのではないかという誤った安心感が生まれます。

これらのツールは、パッチを当てることができるセキュリティ上の欠陥を確実に発見してくれますが、すべてを発見してくれるでしょうか。100％のヒット率を保証することは不可能ですし、攻撃者はたった1つのドアが開いているだけで侵入し、あなたの一日を台無しにしてしまいます。

ありがたいことに、多くの企業が、ソフトウェアの脆弱性には人的要因が絡んでいることを認識しつつあります。多くの開発者は、セキュアコーディングのための十分なトレーニングを受けておらず、全体的なセキュリティ意識も低くなっています。しかし、開発者はソフトウェア開発ライフサイクルの最前線に位置し、脆弱性がコミットされたコードに混入するのを阻止する絶好のポジションにいます。もし彼らが最初からセキュアなコーディングを行えば、毎年何十億もの犠牲を出している壊滅的なサイバー攻撃に対する防御の最前線に立つことができるのです。

開発者には、彼らの言葉で話し、彼らの仕事に関連し、セキュリティについて積極的に興奮させるようなトレーニングを受けて、成功するチャンスを与える必要があります。バグのないコードは誇りであり、機能的に優れたものを作れば同僚から尊敬されるのと同じです。

最新のセキュリティプログラムは、ビジネスの優先事項であるべきです。

開発チームは、自分たちの力で会社全体のセキュリティ意識を向上させることはできません。ソフトウェア開発プロセスの初期段階からセキュリティを組み込むためには、適切なツール、知識、サポートが必要となる。

MITREのリストに古いセキュリティバグが多数掲載されている場合は、古いトレーニング方法は明らかに機能しませんので、新しいものを試してみてください。なトレーニングソリューションを探しましょう。

• ハンズオン：開発者は、ビデオで話している人を見るのではなく、「やってみて学ぶ」ことが好きです。
• 関連性：日常的にJavaを使用している人にC#のトレーニングをさせてはいけない
• エンゲージメント：一口サイズの学習は消化しやすく、開発者は以前の知識を継続して利用することができます。
• 測定可能であること。単にボックスにチェックを入れて次に進むだけではないこと。トレーニングが効果的であることを確認し、改善のための道筋を作る
• 楽しい。ポジティブなセキュリティ文化をサポートするだけでなく、どのようにしてセキュリティ意識を高めることができるのか、それによってどのようにして団結力のあるチーム環境を作ることができるのかを見てみましょう。

セキュリティは、組織の全員にとって最優先事項であり、CISOは、データをより安全に保つためのあらゆるレベルの取り組みを可視化し、透明性を確保する必要があります。つまり、誰もが同じ古い歌を繰り返し聞きたいとは思わないのです。今こそ、古いバグを永久に潰すことに真剣に取り組む時です。