この調査は、2016年から2017年の期間にNPOエシェロンの試験所で認証試験の対象となったソフトウェアの脆弱性検出に関する統計を提供します。
調査方法
認証試験の一部として試験所（IL）が使用する脆弱性分析方法論は、「一般的な評価方法論」（国際標準ISO / IEC 18045）に基づいており、一般に次の手順で構成されています。
ステージ1.認証オブジェクトの既知の（確認済みの）脆弱性の識別。 この段階で、ILの専門家は、たとえばFSTECロシアの情報セキュリティ脅威データバンク、CVE、NVDリソース、ソフトウェア開発者（ソフトウェア）リソースなど、公開されている情報ソースで既知の（確認済みの）脆弱性を検索します。 脆弱性に関する情報が検出された場合、既知の脆弱性を「閉じる」ソフトウェアアップデートがILに送信されるまで、テストは中断されます。
ステージ2.認証オブジェクトの以前に未公開の脆弱性の識別。 この段階で、ILの専門家は通常、次の手順を実行します。
- ステップ1：さまざまな種類のデータソース（認証オブジェクトのプロジェクトドキュメント、ソースコード、オープンソースからの情報）に基づいて、認証オブジェクトの潜在的な脆弱性のリストを作成します。
- ステップ2：特定された潜在的な脆弱性ごとにテストシナリオ（攻撃）を作成します。
- ステップ3：行われた仮定の正確性を判断するためのテストの実行。
この研究の枠組みでは、ステップ1で、エシェロンIL研究所の専門家は、次の方法を使用して潜在的な脆弱性のリストを作成しました。
- 機能的に類似した製品、認証オブジェクトの他のバージョン（古いなど）、借用コンポーネント、オブジェクトの開発に使用される技術に典型的な典型的な脆弱性に関する既知の脆弱性に関する情報に基づいて潜在的な脆弱性のリストの形成を提供するエキスパートドキュメンタリー方式認証
- ソフトウェアのソースコードの静的分析（認証テストの一環としてソースコードへのアクセスを提供する場合）;
- ファジングテスト。
認証オブジェクトで脆弱性が特定された場合、ILの専門家による結論の確認を取得し、特定された脆弱性を中和するための対策を策定するために、ソフトウェア開発者に詳細な技術情報が提供されます（ソフトウェアを更新するか、操作手順を特定します）。 認証テスト/検査管理中に特定された脆弱性は、銀行を通じてデータセキュリティの脅威をロシアのFSTECに開示するための手順を経なければならないことが想定されています。
研究の対象
研究は2016年から2017年の期間に実施されました。 エシェロンイリノイ州のすべての認証システム（認証テスト、検査管理）の認証システムを通じて76製品をテストする一環として。
タイプ別の調査対象製品の分布を図1に示します。
図1 タイプごとの調査対象製品の分布
（NSDのSZI-不正アクセスに対する保護手段、SZIのソフトウェア-情報保護ツールが組み込まれたアプリケーションソフトウェア、ME-ファイアウォール、SAVZ-ウイルス対策保護の手段、DBMS-データベース管理システム、OS-オペレーティングシステム、SOV-システム侵入検知）
製品開発者は国内外の組織でした。
認証製品の潜在的な範囲によって決定される認証基準に応じて、IL専門家は認証オブジェクトのソーステキストへのアクセスを許可または禁止されました（図2）。
図2。 ソーステキストへのアクセスに応じた調査対象製品の配布
調査結果
この調査結果により、エシェロンイリノイ研究所による81の脆弱性が特定されました（調査した76のうち26の製品で脆弱性が特定されました）。 特定されたすべてのソフトウェアの脆弱性について、ソフトウェア開発者が関連性の確認を受け取り、ソフトウェア開発者は特定された脆弱性を排除するための対策を講じました。
図 図3は、特定された脆弱性の重大度レベル別の分布を示しています（評価はCVSSメソッドバージョン3.0を使用して実行されました）。
図3 重大度に応じて特定された脆弱性の分布
最も一般的な脆弱なソフトウェアは、情報保護ツールが組み込まれたアプリケーションソフトウェアでした（図4）。
図4 タイプ別に特定された脆弱性の分布
調査したソフトウェア
脆弱性の関連性を確認するためにILの専門家によって開発された主な成功した攻撃ベクトルは次のとおりです（図5）。
- クロスサイトスクリプティング（CAPEC-63）;
- クロスサイトリクエストフォージェリ（CAPEC-62）;
- セキュリティバイパスに関連する特権の昇格（CAPEC-233）
- サービス拒否攻撃（CAPEC-2）;
- エラーメッセージでの重要なソフトウェア情報の開示（CAPEC-54）。
- SQLインジェクション（CAPEC-66）。
図5 攻撃ベクトルの種類に応じて特定された脆弱性の分布
攻撃ベクトルのタイプはその他のカテゴリに分類されました：HTTPリクエストでデータを送信することによるオペレーティングシステムコマンドのリモート実行（CAPEC-76）、XMLインジェクション（CAPEC-250）、セッション固定（CAPEC-61）割り当てられたディレクトリ（CAPEC-126）の制限、「Reparse-Point」、「RegSafe / RegRestore」などの攻撃。
脆弱性の原因となったソフトウェアの欠陥の主な種類は次のとおりです（図6）。
- 信頼できないソースから受け取ったデータを悪用してHTMLページを生成する（CWE-79）;
- 要求の承認のための認証データ（Cookieデータ）の使用（CWE-352）;
- セキュリティ機能を実行するときに、信頼できないソースから受信したデータの誤った使用（CWE-807）;
- 重要な操作を実行する際の承認の欠如（CWE-862）;
- 信頼できないソースから受信したデータを不正に使用して、DBMS（CWE-89）へのクエリを生成します。
- 誤ったエラーメッセージの生成（CWE-209）。
図6 ソフトウェアエラーに応じて特定された脆弱性の分布（欠陥）
その他のカテゴリには、プログラムコードで指定された認証データの使用（CWE-798）、バッファオーバーフロー（CWE-120）、セッションを修正するエラー（CWE-384）、不正なデータ使用、 OSコマンド（CWE-22）などを生成するために信頼できないソースから取得
潜在的な脆弱性のリストを作成する方法について言えば、ほとんどの脆弱性は、認証オブジェクトのドキュメントと認証オブジェクトに類似する製品の脆弱性に関するデータを研究することに基づいて行われた仮定により発見されたことに注意する必要があります（図7）。
図7 潜在的な脆弱性のリストを作成する方法に応じて特定された脆弱性の分布
ソフトウェアのエラー（欠陥）と調査したソフトウェアの種類に応じて特定された脆弱性の分布を以下に示します。
重大度と調査したソフトウェアのタイプに応じて特定された脆弱性の分布：
結論
- 国内のソフトウェアで検出された脆弱性のシェアは、外国のソフトウェアで検出された脆弱性のシェアよりもわずかに高いことを認めなければなりません。 これは、国内外のソフトウェア開発者が実装する安全なソフトウェアを開発するライフサイクルのプロセスの成熟度のレベルに大きな違いがあるためだと思います。 この国で安全な開発管理基準が導入されると、この状況が変わることを願っています。
外国製ソフトウェアの調査を実施する際、ほとんどの場合、開発者は調査対象のソースコードへのアクセスを提供しなかったため、プログラムのソーステキストの調査に基づいて潜在的な脆弱性のリストを作成することは基本的に不可能でした。 - 調査で特定された脆弱性のほとんどは、ソフトウェア開発の初期段階で、情報セキュリティの脅威を実現する観点からのソフトウェアアーキテクチャの分析とソフトウェアソースの静的分析を使用して、ソフトウェア開発者によって検出される可能性があります。
- 脆弱性の数を減らすために、ソフトウェア開発者は、ライフサイクルプロセスで安全なソフトウェアの開発を目的とした主な活動（GOST R 56939）を実装することをお勧めします-情報セキュリティの脅威、ソーステキストの静的分析、およびセキュリティテストの観点からのソフトウェアアーキテクチャの分析 私たちの意見では、国内のソフトウェア開発者の慣行にこのような手順を導入すると、作成されたソフトウェアのセキュリティレベルが向上し、その結果、情報セキュリティインシデントの数が大幅に減少します。