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

開発者、侵入テスター、セキュリティ専門家は、専門的な活動の一環として、脆弱性管理 (VM)、(安全な) SDLC などのプロセスに対処する必要があります。
これらのフレーズの下には、ユーザーは異なりますが、さまざまな実践方法や使用されるツールが絡み合っています。

技術の進歩は、人の代わりに XNUMX つのツールでインフラストラクチャやソフトウェアのセキュリティを分析できる段階にはまだ達していません。
なぜそうなるのか、そしてどのような問題に直面しなければならないのかを理解するのは興味深いことです。

Процессы

脆弱性管理プロセスは、インフラストラクチャのセキュリティとパッチ管理を継続的に監視するように設計されています。
Secure SDLC プロセス (「安全な開発サイクル」) は、開発および運用中にアプリケーションのセキュリティを維持するように設計されています。

これらのプロセスの同様の部分は、脆弱性評価プロセス (脆弱性評価、脆弱性スキャン) です。
VM 内でのスキャンと SDLC 内の主な違いは、前者の場合、目的はサードパーティ ソフトウェアまたは構成内の既知の脆弱性を見つけることであることです。 たとえば、Windows の古いバージョンや SNMP のデフォルトのコミュニティ文字列などです。
XNUMX 番目のケースの目標は、サードパーティのコンポーネント (依存関係) だけでなく、主に新製品のコードの脆弱性を検出することです。

これにより、ツールやアプローチの違いが生じます。 私の意見では、アプリケーションの新しい脆弱性を見つけるタスクは、バージョンのフィンガープリンティング、バナー収集、パスワードのブルートフォースなどに帰着しないため、はるかに興味深いものです。
アプリケーションの脆弱性を高品質に自動スキャンするには、アプリケーションのセマンティクス、その目的、特定の脅威を考慮したアルゴリズムが必要です。

多くの場合、インフラストラクチャ スキャナはタイマーで置き換えることができます。 アブレオノフ。 重要なのは、純粋に統計的に、たとえば XNUMX か月間更新しなかった場合、インフラストラクチャは脆弱であるとみなすことができるということです。

ツール

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

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

インフラストラクチャ スキャナ (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 のパラメーターを使用して XNUMX ページを数日間スキャンできます。それらを異なるものとみなしてスキャンすることもできます。 同時に、開発サイクル内で実稼働環境にデプロイするかどうかを迅速に決定する必要があります。
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. スキャナーのカスタマイズ。 多くの場合、スキャナーを変更しないとアプリケーションをスキャンできません。 例としては、すべてのリクエストに署名する必要がある支払いゲートウェイが挙げられます。 ゲートウェイ プロトコルへのコネクタを作成しないと、スキャナは間違った署名を持つリクエストを無意識につついてしまいます。 また、次のような特定の種類の欠陥に特化したスキャナを作成する必要もあります。 安全でない直接オブジェクト参照
7. 危機管理。 さまざまなスキャナーの使用と、資産管理や脅威管理などの外部システムとの統合により、複数のパラメーターを使用してリスクのレベルを評価できるため、管理者は開発またはインフラストラクチャの現在のセキュリティ状態を適切に把握できます。

注目して、脆弱性スキャンを中断しましょう!

出所： habr.com