脆弱性スキャンと安全な開発。 パート1

専門的な活動の一環として、開発者、ペンテスター、およびセキュリティの専門家は、Vulnerability Management（VM）、（Secure）SDLCなどのプロセスに対処する必要があります。

これらのフレーズの下には、消費者は異なりますが、使用されるさまざまなプラクティスとツールが絡み合っています。



技術の進歩は、インフラストラクチャとソフトウェアのセキュリティを分析するための1つのツールに人を置き換えるという点にはまだ達していません。

これがなぜそうなのか、そしてあなたが直面しなければならない問題を理解することは興味深いです。

プロセス

脆弱性管理プロセスは、インフラストラクチャのセキュリティとパッチ管理の継続的な監視を目的としています。

Secure SDLCプロセス（「安全な開発サイクル」）は、開発および運用中のアプリケーションセキュリティをサポートするように設計されています。



これらのプロセスの類似した部分は、脆弱性評価プロセスです-脆弱性評価、脆弱性スキャン。

VMとSDLCのフレームワーク内でのスキャンの主な違いは、最初のケースの目標は、サードパーティソフトウェアまたは構成の既知の脆弱性を検出することです。 たとえば、古いバージョンのWindowsまたはSNMPのデフォルトのコミュニティストリング。

2番目のケースの目標は、サードパーティのコンポーネント（依存関係）だけでなく、主に新製品のコードの脆弱性を検出することです。



これにより、ツールとアプローチに違いが生じます。 私の意見では、アプリケーションの新しい脆弱性を見つけるタスクは、フィンガープリントバージョン、バナーの収集、パスワードのソートなどに要約されないため、はるかに興味深いです。

アプリケーションの脆弱性の高品質の自動スキャンには、アプリケーションのセマンティクス、その目的、特定の脅威を考慮したアルゴリズムが必要です。



avleonovが述べたように、インフラストラクチャスキャナーは多くの場合、タイマーに置き換えることができます。 ポイントは、純粋に統計的に、たとえば1か月間更新しなかった場合、インフラストラクチャが脆弱であると考えることができるということです。

ツール

スキャンおよびセキュリティ分析は、ブラックボックスまたはホワイトボックスとして実行できます。

ブラックボックス

ブラックボックススキャンの場合、ツールは、ユーザーが操作するのと同じインターフェイスを介してサービスを操作できる必要があります。



インフラストラクチャスキャナー（Tenable Nessus、Qualys、MaxPatrol、Rapid7 Nexposeなど）は、開いているネットワークポートを探し、「バナー」を収集し、インストールされているソフトウェアバージョンを決定し、知識ベースでこれらのバージョンの脆弱性に関する情報を探します。 また、デフォルトのパスワードやオープンデータアクセス、弱いSSL暗号などの構成エラーを検出しようとします。



Webアプリケーションスキャナー（Acunetix WVS、Netsparker、Burp Suite、OWASP ZAPなど）も、既知のコンポーネントとそのバージョン（CMS、フレームワーク、JSライブラリなど）を判別する方法を知っています。 スキャナーの主な手順は、クロールとファジングです。

クロール中に、スキャナーは既存のアプリケーションインターフェイス、HTTPパラメーターに関する情報を収集します。 ファジング中に、エラーを引き起こして脆弱性を検出するために、検出されたすべてのパラメーターが変異または生成されたデータに置き換えられます。



このようなアプリケーションスキャナーは、それぞれDASTクラスとIASTクラス（動的および対話型アプリケーションセキュリティテスト）に属します。

ホワイトボックス

ホワイトボックススキャンにはさらに違いがあります。

プロセス全体を通して、VMスキャナー（Vulners、Incsecurity Couch、Vuls、Tenable Nessusなど）は、認証スキャンを実行することにより、システムへのアクセスを許可されることがよくあります。 したがって、スキャナーは、ネットワークサービスのバナーで推測することなく、インストールされたバージョンのパッケージと構成パラメーターをシステムから直接ダウンロードできます。

スキャンはより正確で完全です。



アプリケーションのホワイトボックススキャン（CheckMarx、HP Fortify、Coverity、RIPS、FindSecBugsなど）について話す場合、通常、静的コード分析と、SASTクラスの対応するツールの使用-静的アプリケーションセキュリティテストについて話します。

問題

スキャンには多くの問題があります！ セキュリティ分析作業を行うときだけでなく、スキャンプロセスの構築と安全な開発のためのサービスを提供するフレームワークで、それらのほとんどに個人的に対処する必要があります。



さまざまな企業の情報セキュリティサービスのエンジニアやマネージャーとの会話によって確認された3つの主要な問題グループを選び出します。

Webアプリケーションスキャンの問題

1. 実装の複雑さ。 スキャナーは、アプリケーションごとに展開、構成、カスタマイズし、スキャン用のテスト環境を割り当て、CI / CDプロセスに実装して有効にする必要があります。 さもなければ、それは役に立たない正式な手順になり、偽陽性のみを出します
2. スキャン期間。 スキャナーは、2019年であっても、インターフェイスの重複排除が不十分であり、それぞれ異なる10のパラメーターを使用して10日間、数千ページをスキャンできますが、同じコードが原因です。 同時に、開発サイクル内で運用環境に展開する決定を迅速に行う必要があります
3. 不十分な推奨事項。 スキャナーはかなり一般的な推奨事項を提供しますが、開発者は常にリスクレベルを減らす方法を最も簡単に理解できるわけではありません。最も重要なことは、今すぐ行う必要があるのか​​、怖がらないのか
4. アプリケーションへの破壊的な影響。 スキャナーは、アプリケーションに対してDoS攻撃を実行する可能性があります。また、多数のエンティティを作成したり、既存のエンティティを変更したりすることもできます（たとえば、ブログに何万ものコメントを作成します）。
5. 低品質の脆弱性検出。 スキャナーは通常、固定ペイロード配列を使用し、既知のアプリケーション動作シナリオに適合しない脆弱性を簡単に見落とす可能性があります。
6. スキャナーは、アプリケーションの機能を理解していません。 スキャナー自体は、「インターネットバンキング」、「支払い」、および「コメント」が何であるかを知りません。 彼らにとっては、リンクとパラメーターのみが存在するため、ビジネスロジックの潜在的な脆弱性の巨大な層が完全に発見されたままであり、IDで他の人のデータを二重に書いたり、覗き見したり、丸めによってバランスをとったりすることはありません
7. ページのセマンティクスに対するスキャナーの誤解。 スキャナーはFAQの読み方がわからず、キャプチャを認識する方法もわからず、登録方法を推測することも、ログインする必要もありません。「ログアウト」をクリックできないこと、パラメーター値を変更する際にリクエストに署名する方法もあります。 その結果、ほとんどのアプリケーションがまったくスキャンされない場合があります。

ソースコードスキャンの問題

1. 誤検知。 静的解析は、多くの妥協に頼る必要がある解決において困難なタスクです。 多くの場合、精度を犠牲にする必要があり、高価なエンタープライズスキャナーでさえも大量の誤検知が発生します。
2. 実装の複雑さ。 静的分析の精度と完全性を高めるには、スキャンルールを改良する必要があり、これらのルールの作成には時間がかかりすぎる場合があります。 そのようなケースを検出するためのルールを記述するよりも、コード内のある種のバグを見つけて修正する方が簡単な場合があります
3. 依存関係のサポートの欠如。 大規模なプロジェクトは、プログラミング言語の機能を拡張する多数のライブラリとフレームワークに依存しています。 スキャナーのナレッジベースにこれらのフレームワークの「シンク」に関する情報がない場合、これは盲点になり、スキャナーはコードを理解することさえできなくなります。
4. スキャン期間。 コード内の脆弱性を見つけることは、アルゴリズムの観点から難しい作業です。 そのため、プロセスが遅れることがあり、かなりのコンピューティングリソースが必要になります。
5. 低カバレッジ。 リソースの消費とスキャンの期間にもかかわらず、SASTツールの開発者は依然として妥協に頼らなければならず、プログラムが存在する可能性のあるすべての条件を分析する必要はありません。
6. 検索結果の再現性。 脆弱性につながる特定の回線と呼び出しスタックを指すことは問題ありませんが、実際には、スキャナーは外部の脆弱性をチェックするのに十分な情報を提供しないことがよくあります。 結局のところ、欠陥はデッドコードにある可能性もあり、これは攻撃者にとっては達成不可能です

インフラストラクチャスキャンの問題

1. 在庫不足。 特に地理的に離れた大規模なインフラストラクチャでは、多くの場合、どのホストをスキャンする必要があるかを理解するのが最も困難です。 つまり、スキャンタスクは資産管理タスクと密接に関連しています
2. 優先度が低い。 ネットワークスキャナーは多くの場合、実際には悪用できない欠点を伴う多くの結果をもたらしますが、正式にはリスクレベルは高くなります。 消費者は解釈が困難なレポートを受け取りますが、何を最初に修正する必要があるかは明確ではありません
3. 不十分な推奨事項。 多くの場合、スキャナーのナレッジベースには脆弱性とその修正方法に関する非常に一般的な情報しか含まれていないため、管理者はGoogleで武装する必要があります。 修正する特定のコマンドを発行できるホワイトボックススキャナーの場合、状況は少し良くなります。
4. 手仕事 インフラストラクチャには多くのノードが存在する可能性があります。つまり、潜在的に多くの欠点があり、レポートを各反復で手動で分解および分析する必要があります。
5. 悪いカバレッジ。 インフラストラクチャスキャンの品質は、脆弱性とソフトウェアバージョンに関する知識ベースの量に直接依存します。 同時に、市場のリーダーでさえ包括的なデータベースを持っていないことがわかり、無料のソリューションのデータベースにはリーダーが持っていない多くの情報があります
6. パッチの問題。 インフラストラクチャの脆弱性に対する最も一般的なパッチは、パッケージの更新または構成ファイルの変更です。 ここでの大きな問題は、システム、特にレガシーが、更新の結果として予測できない動作をする可能性があることです。 本質的に、製品の生活インフラストラクチャーで統合テストを実行する必要があります

アプローチ

どうする？

次のパートでは、例とこれらの問題の多くに対処する方法について詳しく説明しますが、ここでは、作業できる主な領域を示します。

1. さまざまなスキャンツールの集約。 複数のスキャナーを正しく使用することで、知識ベースと検出の品質を大幅に向上させることができます。 個別に起動されたすべてのスキャナーよりもさらに多くの脆弱性を見つけることができますが、リスクのレベルをより正確に評価し、より多くの推奨事項を与えることができます
2. SASTとDASTの統合。 それらの間で情報を共有することにより、DASTカバレッジとSASTの精度を高めることができます。 ソースから既存のルートに関する情報を取得でき、DASTを使用して脆弱性が外部から見えるかどうかを確認できます
3. 機械学習^™ 。 2015年に、統計情報を使用してハッカーにスキャナーの直感を与え、高速化することについて （そしてまだ ） 話しました。 これは間違いなく、将来の自動化されたセキュリティ分析の開発のための食料です。
4. IASTと自動テストおよびOpenAPIの統合。 CI / CDパイプラインのフレームワーク内で、HTTPプロキシとして機能するツールとHTTPで機能する機能テストに基づいてスキャンプロセスを作成することができます。 OpenAPI / Swaggerテストとコントラクトにより、スキャナーにデータストリームに関する欠落情報が提供され、さまざまな状態でアプリケーションをスキャンできるようになります。
5. 正しい構成。 アプリケーションとインフラストラクチャごとに、使用するインターフェイス、テクノロジの数と性質を考慮した適切なスキャンプロファイルを作成する必要があります。
6. スキャナーのカスタマイズ。 多くの場合、アプリケーションは、スキャナーをファイナライズしないとスキャンできません。 例は、各リクエストに署名する必要がある支払いゲートウェイです。 ゲートウェイプロトコルへのコネクタを記述することなく、スキャナーは間違った署名を使用して、要求に気付かずに勝ちます。 Insecure Direct Object Referenceなど、特定のタイプの欠陥に特化したスキャナーを作成する必要もあります。
7. リスク管理。 さまざまなスキャナーを使用し、Asset ManagementやThreat Managementなどの外部システムと統合すると、多くのパラメーターを使用してリスクのレベルを評価できるため、管理者は開発またはインフラストラクチャの現在のセキュリティステータスを適切に把握できます

引き続きご注目いただき、脆弱性スキャンを中断しましょう！