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

本記事は Information Security Buzz に掲載されたものを転載し、他の複数のメディアでも取り上げられました。本稿はシンジケーション用に更新されています。

昨年末、MITREの素晴らしいコミュニティが、2019年に世界に影響を与えた CWE Top 25 Most Dangerous Software Errors（最も危険なソフトウェアエラー） リストを発表しました。このリストは個人の意見に基づくものではなく、NIST などの組織による研究や、公開されている共通脆弱性識別子（CVE）データなどを活用した多角的な分析の結果です。「トップ」の欠陥を決定するために、深刻度、悪用可能性、現在のソフトウェアにおける普及度に基づいてスコアが割り当てられています。決して喜ばしいリストではないことは確かです。

しかし、多くの年次まとめとは異なり、このリストに載っている項目の多くは、以前にも何度も登場しています。もしこれがビルボードのヒットチャートなら、ブリトニー・スピアーズの「Baby One More Time」やバックストリート・ボーイズの「I Want It That Way」がリリース以来毎年ランクインしているようなものです。なぜこれらの曲を選んだかというと、どちらも約20年前の曲だからです（もうそんなに経ったのかと驚きますよね）。これらは、何十年も前に発見されたにもかかわらず、2020年になっても私たちを悩ませ続けている危険なソフトウェアエラーとよく似ています。

なぜ古いバグがこれほど危険なのでしょうか？私たちは修正方法を知らないのでしょうか？

現在のMITREリストの第6位は CWE-89、いわゆるSQLインジェクション（SQLi）です。SQLiの脆弱性は1998年に初めて発見されました。当時はまだ、Googleではなく「Ask Jeeves」で疑問を検索していた頃です。その後すぐに修正方法が判明したにもかかわらず、2019年においても最も頻繁に使用されるハッキング手法の一つであり続けています。Akamaiの「State of the Internet」レポートによると、SQLiはすべてのWebアプリケーション攻撃の3分の2に関与していました。

複雑さという点では、SQLインジェクションは決して高度な攻撃ではありません。Web開発者にとっては単純な修正であり、この脆弱性が攻撃者に貴重なデータをさらさないようにする方法は、私たちも迷うことなく理解しています。問題は、今日においても多くの開発者にとってセキュリティが優先事項ではないということです。20年前ならまだしも、現在、そして将来にわたって作成される膨大な量のソフトウェアを考えると、これを常態化させるわけにはいきません。

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

「質の悪い」コードを書いた開発者を責めるのは簡単です。しかし実際には、開発者の優先順位はセキュリティチームのそれとは大きく異なります。一般的な開発チームは、美しく機能的なソフトウェアを可能な限り速く作るよう指示されます。ソフトウェアに対する社会の飽くなき需要により、開発チームはすでに手一杯であり、セキュリティは主要な検討事項ではありません。結局のところ、それこそがAppSec（アプリケーションセキュリティ）スペシャリストが存在する理由ではないでしょうか？ソフトウェアエンジニアは、セキュリティ担当者との間にどこか冷ややかな関係を築くことに慣れてしまっています。彼らがセキュリティ担当者から連絡を受けるのは問題が発生した時だけであり、その問題が彼らの懸命な作業の生産を停滞させてしまうのです。

その一方で、AppSecスペシャリストは、スキャンや手動コードレビューのたびに現れる何十年も前のエラーを修正することにうんざりしています。こうしたスペシャリストは貴重な存在であり、彼らの時間は、既知のバグを何度も潰すことよりも、複雑なセキュリティ上の欠陥に対処するために使われるべきです。

両チームの間には暗黙の責任のなすりつけ合いが存在しますが、彼らは「セキュアなソフトウェア」という同じ目標を持っているはずです。開発者は、セキュアコーディングの観点から成功を収めるための環境がほとんど整っていない状況で働いています。高等教育でセキュリティのベストプラクティスが教えられることは稀であり、職場でのトレーニングも頻度が少なすぎるか、全く効果がないことがほとんどです。セキュリティ意識や深く関連性のある教育への重点が明らかに欠けており、その結果、コミットされたコード内の古いバグを修正するための天文学的なコストや、評判を失墜させるデータ漏洩の差し迫った脅威が生じているのです。

人的要因、別名「なぜツールを使ってもデータが安全にならないのか？」

もう一つの頻繁な問題は、トレーニングの代わりに、ソフトウェアが世に出る前に問題を特定するために膨大なセキュリティツールが導入されていることです。アプリケーションスキャンや保護ツール（SAST/DAST/RASP/IAST）の数々は、確かにセキュアなソフトウェア制作を支援できますが、それらには特有の問題があります。これらに完全に依存してもセキュリティは保証されません。理由は以下の通りです。

• 「単一」のツールですべてのフレームワーク、すべてのユースケースにおけるすべての脆弱性をスキャンすることはできない
• 特に静的解析と動的解析を組み合わせて実行する場合、動作が遅くなる可能性がある
• 誤検知（フォールスポジティブ）が依然として問題であり、生産を停止させ、アラートを解釈するために不要な手動コードレビューが必要になることが多い
• ツールが問題を拾ってくれるという期待からセキュアコーディングの優先順位が下がり、誤った安心感を生み出してしまう

ツールは確かに修正可能なセキュリティ上の欠陥を掘り起こしてくれますが、すべてを見つけ出せるでしょうか？100%の検出率を保証することは不可能であり、攻撃者はたった一つの開いたドアを見つけるだけで侵入し、あなたの日常を台無しにすることができるのです。

幸いなことに、多くの組織がソフトウェアの脆弱性における人的要因の重要性に気づき始めています。ほとんどの開発者はセキュアコーディングのための適切なトレーニングを受けておらず、全体的なセキュリティ意識も低いのが現状です。しかし、彼らはソフトウェア開発ライフサイクルの最上流に位置しており、脆弱性がコードに混入するのを防ぐための絶好のポジションにいます。もし彼らが最初からセキュアにコーディングを行えば、毎年何十億ドルもの損失を生む壊滅的なサイバー攻撃に対する最前線の防御となるはずです。

開発者には、彼らの言語で語られ、仕事に関連し、セキュリティに対して積極的に取り組めるようなトレーニングを提供し、成功するチャンスを与える必要があります。機能的に優れたものを作ることが仲間からの尊敬を集めるように、バグのないコードを書くことも誇りであるべきです。

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

開発チームが自力だけで全社的なセキュリティ意識を向上させることは不可能です。ソフトウェア開発の初期段階からセキュリティを組み込むためには、適切なツール、知識、そして組織的なサポートが不可欠です。

MITREのリストに依然として古いセキュリティ脆弱性が多く掲載されていることからも、従来のトレーニング手法が機能していないのは明らかです。新しいアプローチを検討しましょう。次のようなトレーニングソリューションを探すことが重要です。

• 実践的であること：開発者は動画で講義を視聴するよりも、「実際に手を動かして学ぶ」ことを好みます
• 関連性が高いこと：Javaを日常的に使用している開発者にC#のトレーニングを強いるべきではありません
• 魅力的であること：短時間で学べる学習形式は消化しやすく、知識を積み上げやすくなります
• 測定可能であること：単に受講済みとしてチェックを入れるだけでなく、トレーニングの効果を検証し、改善に向けた道筋を作りましょう
• 楽しいこと：セキュリティ意識の向上とポジティブなセキュリティ文化の醸成を両立させ、チームの一体感を高める方法を模索しましょう。

セキュリティは組織全員が常に意識すべき優先事項であり、CISOはデータをより安全に保つための取り組みを、あらゆるレベルで可視化し透明性を持って示す必要があります。同じことの繰り返しは誰も望んでいません。今こそ、古い脆弱性を根本から排除するために真剣に取り組むべき時です。