close search bar

Sorry, not available in this language yet

close language selection
 

2019 CWE Top 25によるアプリケーション・セキュリティの向上

2019 CWE Top 25を使用して、アプリケーション・セキュリティ対策に重点的に取り組むことができます。25の最も危険性の高いソフトウェアの脆弱性リストの詳細をご覧ください。

2019 CWE Top 25によるアプリケーション・セキュリティの向上

最高のリストはよく知られています。ただし、最悪中で最悪のリストが重要なこともあります。

非営利団体MITREが9月にリリースした、最新の共通脆弱性タイプ一覧(CWE)最も危険なソフトウェアのバグTop 25リストがその例です。

2019 CWE Top 25は、エラー、バグ、潜在的な攻撃ベクトルなど、障害につながる可能性がある危険なもののリストです。例には、システムのハイジャック、データ漏洩(それによる秘密データの窃盗)、サービス妨害(DoS)攻撃、システム・クラッシュ、任意コードの実行、ソフトウェアの動作を妨げる攻撃者などが含まれます。

このリストは、現在の最悪なソフトウェアの脆弱性を組織に通知し、これらの妨害行為を回避する上で役立ちます。MITREでは、このリストをソフトウェア業界向けの“コミュニティ・リソース”と呼び、“最も一般的なセキュリティの脅威に対する洞察”を提供しています。

弱点(Weakness)と脆弱性(Vulnerability)の違い

“弱点”は“脆弱性”ではない、少なくともまだそうなっていないということに着目することが重要です。米国国土安全保障省によって設立されたMITREが、2019 CWE Top 25と見なしたのは、“ソフトウェアの深刻な脆弱性につながる最も広く知られている重大な弱点の実証的リストです。”

"弱点"は"脆弱性"ではない、少なくともまだそうなっていません。

言い換えると、これらの弱点はCVEエントリの前兆と考えられます。CVE(共通脆弱性識別子)は、MITREによって管理され、何万もの公表済みのサイバー・セキュリティの脆弱性が定義されている“辞典”です。

Synopsysのシニア・リサーチ・リードであるKsenia Pegueroは、その違いを次のように説明しています。「2つの理由で弱点すべてがCVEに相当するわけではありません。その1つは、コードの弱点はコードベース外の制御によって緩和されます。また、CVEは、特定のソフトウェアおよびそれぞれの特定のバージョンで報告される脆弱性です。対照的に、CWEは脆弱性の種類です。例えば、CWE-20‘不適切な入力妥当性検証’またはCWE-200‘情報漏えい’は、種類が非常に幅広く、多くのアプリケーションでさまざまな現れ方をします。」

Anatomy of an Application Security Weakness(アプリケーションのセキュリティ上の弱点の分析)のeBookをダウンロードする

MITREの外部コミュニケーション・リードであるJennifer Lang氏は、「弱点はソフトウェアのタイプの異なる間違いで、条件が整っていればソフトウェア内に脆弱性を導く一因となります。」と付け加え、

「脆弱性は、1つまたは複数の弱点が具体化したもので、条件が整うと悪用されてソフトウェアが意図しない方法で動作する原因になります。悪用を目的にした条件は存在しないため、弱点のすべてが脆弱性になるわけではありません。」と述べています。

Red Hatの製品セキュリティ保証リードであるChris Robinson氏は、別の方法で解釈しています。「CVEをコンピューターの1つの問題の統一識別子として考えてみましょう。CWEは、脆弱性の背後にある‘なぜ?’、脆弱性が存在するコーディング/プログラミングの理由を記述するのです。」と述べています。

2019 CWE Top 25と他のリストとの違い

MITREが前回CWE Top 25リストをリリースしたのは2011年でした。2019年のリストは、以前のリストとは異なり、調査や面談に基づくのではなく、“データ駆動”です。CVEリストの他に、米国標準技術局(NIST)、NIST内にある脆弱性情報データベース(NVD)、CVEデータベースのエントリにスコアを割り当てる共通脆弱性評価システム(CVSS)からデータを収集します。

And Lang氏は、現在リストを毎年公表するつもりであると述べています。

最大の弱点にはWebページでユーザー入力の制御の欠如が原因となる一般的な脆弱性、メモリー・バッファの境界に関する不適切な制限と、いわゆるクロスサイト・スクリプティング(XSS)が含まれています。

2019 CWE Top 25の目的

2019 CWE Top 25の目的

2019 CWE Top 25は“最悪中で最悪”のリストです。組織が時間を節約し、優先順位を設定できるようにすることを目的としたリストのように見えます。組織は脆弱性のいくつものリストをかきわける必要はありません。代わりに、害になる可能性がある最も高い20数種のリスクに重点を置くことができます。

それが目的の1つであると、Lang氏は述べています。「2019 CWE Top 25リストは、公表された膨大な量の脆弱性データから実践的な考察を探り出す1つの方法です。」と述べ、組織はこれを利用して、ベンダーが提供するソフトウェアの品質またはオープンソース・プロジェクトを確認できることにも言及しています。そうすることで、他にもっと良い選択肢があるときに“エラーだらけ”のソフトウェアを購入しないようにできます。

別の方法として、「ソフトウェア・ベンダーやプロジェクトはリストを‘カンニング・ペーパー’として使用して、リリース前に最も蔓延している危険性の高いソフトウェア・バグを除去することができます。」と述べています。

Robinson氏は、リストの使い方はいくつかあると指摘します。「Red Hatのような組織はCWEを使用して、問題の履歴分析を行っています。」と述べ、「特定のパッケージまたはプロジェクトにどのような傾向が見られますか。同じコーディングの欠陥が何度も繰り返されていませんか。もしそうならば、時間を割いて開発者とともに[問題認識]を促し、将来同じ問題を繰り返さないようにします。」と続けています。

2019 CWE Top 25を他のリストに置き換えられるか

Synopsysの製品管理マネージャーであるYatin Patilは、他のリストに代えてCWE Top 25を使用すべきではないと警鐘を鳴らしています。「すべてを網羅したリストはありません。すべてが同じ領域に取り組むわけでもありません。脆弱性のみを取り上げるものもあれば、オープンソースのみを重視するものも、それ以外のものもあります。正しいことは常にあらゆるものを考慮することです。」と述べています。

2019 CWE Top 25を他のリストに置き換えられるか

Robinson氏は同意を示し、異なるリストからは別の支援が得られると指摘します。「CVEはコンピューターの特異な問題です。CVEには、根本原因(CWE)を中心にしたデータや問題がどのように生じるかについての説明(CVSS)も含まれています。CVEが環境に影響を及ぼす場合、3個の識別子を組み合わせるとセキュリティ実務者がリスクを評価する際に役立ちます。」と述べています。

結論:CWE Top 25では、25の方法でソフトウェアのセキュリティを向上させることで大きなメリットが生み出されます。無論、使用しなければメリットは得られません。

2019 CWE Top 25の使い方

市場に出ているすべてのソフトウェア・テストや分析ツールは、バグまたは他のエラーの検出と修正に役立ちます。最もリスクの高いソフトウェアの脆弱性のリストがあれば、必要なツールを見つけやすくなります。

例えば、静的解析セキュリティ・テスト(SAST)は、バッファエラー(No. 1)または“境界外読み取り”(No. 5)などの悪用可能な脆弱性につながるコードの品質エラーを検出できます。ソフトウェア・コンポジション解析(SCA)は、組織がオープンソース・ソフトウェア・コンポーネントでコーディングされた脆弱性やライセンスの競合の可能性を見つけることができるようにします。

CWE Top 25などのリストの監視担当者 組織に必要な対策の決定者

Robinson氏は、「場合によりますが、脆弱性の管理は共同責任です。一般に管理の責任者は、通常はInfoSecチームで、脆弱性の修正の実施/展開の責任者は別にDevOps、Ops、または‘コンピューターの専門家’が担当します。」と述べています。

脆弱性の管理は共同責任です。

ただし、全体として、専門家は脆弱性の管理が最初からソフトウェア開発ライフサイクル(SDLC)に影響を与えることに賛同しています。

これは“シフトレフト”と呼ばれており、Patilはこのリストが開発チームを方向付けてほしいと次のように述べています。

「脆弱性のあるアプリケーションをリリースするコスト、違反による否定的な評判、さらに悪いことは、Equifaxデータへの侵入で目にしたような、ユーザー・データの露出/紛失によるSDLCの下流で発生するコストについて考えてください。」

コードでCWEが検出された場合

Robinson氏の最終的な警告: 弱点(Weakness)と脆弱性(Vulnerability)、両方のリストを評価して、デジタル資産にどのように適用できるかを確認する必要があります。リストは、「諺に言う炭鉱のカナリアのように便利ですが、特定の製品に脆弱性を適用する方法、また消費者向けにオンサイトあるいはクラウドでの脆弱性の展開方法についての最終決定のために用いるべきではありません。

これらのリストは、欠陥のあるパッケージの提供者/所有者/メンテナンス担当者をフォローして、特定の展開に関係している場合の影響について理解を深めるために利用するものです。」と述べています。

Anatomy of an Application Security Weakness(アプリケーションのセキュリティ上の弱点の分析)のeBookをダウンロードする

 
Taylor Armerding

投稿者

Taylor Armerding


More from セキュアなソフトウェアの構築