デスクトップアプリケーションのセキュリティスキャン
当社はWindowsデスクトップアプリケーションを開発しています。カスタム開発ではなく、既製のソリューションを提供します。潜在的な新規顧客が、「アプリケーションスキャン」ツールの使用を要求するセクションを標準契約に追加したいと考えています。彼らは特にIBMのAppScanについて言及しています。ただし、そのツールはデスクトップアプリケーションではなく、Webアプリケーション用のようです。
私たちのアプリケーションは、Delphiを使用して開発されています（Embarcaderoは、以前はBorlandでした）。私たちは小さな2つのデベロッパーショップです。顧客が契約でこのようなことを望んでいる理由は理解できますが、どうすればこれを実際に達成できるのかわかりません。
契約言語が示すように他の「業界標準ツール」はありますか？
これはISVの間で一般的な習慣になっていますか？
この種のセキュリティレビュー要件に準拠するためのISVのガイドラインはありますか？安全なコーディングプラクティス（ユーザー入力の検証、バッファーオーバーフロー、SQLインジェクションなど）を行うサイトはたくさんありますが、プログラマーが行ったことをエンドユーザーに納得させるセキュリティレビューをまとめることについて検討したことはありません。正しく仕事。
以下は、契約に追加したいものです。
x.xソフトウェアのセキュリティレビューとテスト。セキュリティスキャンプロセスは、このようなコンポーネントのメジャーリリースが利用可能になる前に、本契約に従ってライセンシーによってライセンスされたソフトウェアの各製品リリースのアプリケーションコンポーネントに対して実行されます。このようなセキュリティスキャンは、ライセンサーがIBMのAppScanアプリケーションスキャンツールまたは代替の業界標準ツール（「アプリケーションスキャン」）を使用して実行します。ベンダーは、コア製品のメジャーリリースごとに手動の侵入テスト（「侵入テスト」）も実行します。ベンダーは、契約に基づいて適用されるスケジュールに記載されているように、各アプリケーションコンポーネントに対して最低1年に1回アプリケーションスキャンを実施します。ベンダーは、AgWareソフトウェアに対するベンダーの最新のアプリケーションスキャンおよび侵入テストの結果のレポートをライセンシーに提供し、レビューします。
アプリケーション自体は、標準のWindowsアプリケーションです。データストレージとしてAccessデータベースまたはSQL Serverデータベースに接続できます。セキュリティを心配しているユーザーは明らかにSQL Serverを使用します。中間層はありません。アプリケーションからSQL Serverに直接接続します。接続は信頼できる接続を使用して行われ、すべてのデータアクセスはストアドプロシージャを介して行われます。
SQLデータベースで何らかのタイプのセキュリティスキャナーを実行することを理解できます。つまり、テーブルがワイドオープンアクセスで残されていないことを確認するものです。データベースが契約で扱われなかったことは興味深いです。
私はおそらく問題を押して、AppScanをデスクトップアプリケーションで実行することはできず、契約からセクションを削除するようにそれらを得ることができると言うことができます。しかし、それを見ると、デスクトップアプリケーションの開発者が自分のソフトウェアで任意の種類のスキャナーを実行しているかどうか疑問に思いました。
Webアプリケーションスキャナーは、Webアプリケーションのセキュリティのすべてではありません。既成のツールを実行するだけでは、安全でないアプリケーションの問題を解決できません。そうは言っても、デスクトップアプリケーションのセキュリティへの影響は、アプリケーションの動作に大きく依存します。サーバーですか？ネットワーク経由で通信しますか？データベースはありますか？
既製のアプリケーションでこの問題を解決することはできません。このアプリケーションを確認し、（おそらく）手動でテストするには、専門のセキュリティアナリストを雇う必要があります。
これは明らかに、適切にテストされたアプリケーションを宣伝するために書かれています。これについて3つのコメントがあります。
何よりもまず、受け入れテストの一環としてプログラムを実行するためのテストベッドを提供する独自の内部スキャンプログラム（脆弱性評価）が必要です。ソフトウェアベンダーは独自に開発することを選択できますが、プログラムの「n」のバリエーションを要求する「n」の数の契約に基づいて「既製のソリューション」を拡張することは決して期待できません。DoDでもこれを認識します。
このWOULDの悪用の側面は、それが配備される予定の環境で実施する必要があります。そうしないと、合理的な「悪用」の図がありません。悪用分析の目的は、システムの脆弱性を利用して、悪用の結果として生じる痛みを特定することです（つまり、実際の実際の影響と潜在的な損傷を確認します）。もちろん、実際に評価できるのは、展開するシナリオのみです。
彼らは、ソフトウェアの作成者がソフトウェアのテスターであることが彼らの最善の利益であると信じているというこのクライアントによる少し誤った考えです。これは常にQ/Aで発生しますが、真の監査を目的としてセキュリティで許可されることはありません。脆弱性と悪用の分析を実行するには、彼ら自身の人々、あるいはより公平な第三者（私に連絡してもらう:)が必要です。
私はアプリケーションのセキュリティを専門としています。何よりもまず、本番環境でアプリケーションをテストすることはほとんどありません。通常、開発後にアプリケーションがデプロイされるテスト環境で脆弱性を検証します。
IBM AppScanは、デスクトップアプリケーションがHTTPまたはHTTPSを使用している限り、Webアプリケーションのテストに使用されるのと同じように、デスクトップアプリケーションに対してテストを実行するために使用できます。これを行うには、ループバックではなくRFC 1918アドレスでリッスンするようにプロキシを構成し、専用VMにデスクトップアプリを展開します。プロキシをバインドしたアドレスとポートを指すようにWindowsのインターネットオプションを設定します。何よりもBurp Suiteをお勧めします。
始めたい人のための情報は通常OWASPサイトにあります。良い出発点はOWASPテストガイドv4ですが、何らかの標準によってアプリが安全であることを示す何かを探している場合は、ASVSを使用してください。
理想的には、SDLCのすべてのフェーズ全体でセキュリティプラクティスを統合し、Secure-SDLCと呼ばれる実際のSDLCとは別のフレームワークを開発する必要があります。 Secure-SDLCには、必要に応じてSDLCの取り組みに統合する必要があるセキュリティプラクティスの概要が記載されています。
それ以外の場合は、展開前のペンテストを実行できますが、特定された脆弱性を修正するためにSDLCに必然的に追い返されるため、コストが高くなります。 PCIおよびおそらくHIPPAは、脆弱性を特定するために、安全な開発手法の作成と、アプリケーションに対する自動または手動テストの実行に関連する要件を指定します。