Security Scanning for Desktop Applications

Question

Our company develops Windows desktop applications. We offer off the shelf solutions - not custom development. A potential new customer wants to add a section to our standard contract that requires us to use an "Application Scanning" Tool. They specifically mention IBM's AppScan. However that tool seems to be for web applications, not desktop applications.

Our applications are developed using Delphi (from Embarcadero formerly Borland a long time ago). We are a small two developer shop. While I can understand the why a customer would want something like this in a contract, I'm not sure how I can really accomplish this.

Are there other "industry standard tools" as their contract language seems to indicate?

Is this becoming common practice among ISVs?

Are there any guidelines for ISVs for complying with these type of security review requirements? I know there are a number of sites for safe coding practices (verify user input, buffer overflows, SQL injection, etc.) but I have never seen anything that discusses putting together a security review that would convince a end user that the programmer did their job correctly.

Here is what they want added to the contract:

x.x Software Security Review And Testing. A security scanning process will be performed on the application components for each production release of the Software licensed by Licensee pursuant to this Agreement prior to making available a major release of such components. Such security scanning will be performed by Licensor using IBM’s AppScan application scanning tool or an alternative, industry standard tool (“Application Scanning”). Vendor will also perform manual penetration testing (“Penetration Testing”) for each major release of the core product(s). Vendor will conduct Application Scanning on each application component as set forth in the applicable Schedule under the Agreement a minimum of one (1) time per year. Vendor will provide to and review with Licensee a report of the results of Vendor’s most recent Application Scanning and Penetration Testing for the AgWare Software.

The application itself is a standard windows application. It can connect to either an Access Database or a SQL Server database for it's data storage. Users worried about security will obviously be using SQL Server. There is no middle tier - I connect directly from the application to the SQL Server. The connection is made using a trusted connection and all data access is via stored procedures.

I can understand running some type of security scanner on the SQL Database. i.e. something that would verify a table was not left with wide open access. It is interesting that the database was not addressed in the contract.

I can probably press the issue and say that AppScan cannot be run on desktop applications and get them to remove the section from the contract. Seeing it though made me wonder if any desktop application developers are running any type of scanner on their software.

Answer 1

Web application scanners are hardly be the be all end all of web application security and simply running an off the shelf tool will not solve the the problem of an insecure application. That being said, the security impact of a desktop application is highly dependent on what your application does. Is it a server? Does it communicate over a network? Does it have a database?

No off the shelf application can solve this problem. You need to hire a professional security analyst to review this application and (most likely) test it manually.

Answer 2

This clearly is being written to promote a reasonably tested application. I have three comments about this:

1. First and foremost, they should have their own internal scanning program (vulnerability assessment) that they would provide a test bed to run your program on as part of their acceptance testing. A software vendor may choose to have and develop their own, but could never be expected to scale an "off the shelf solution" based on "n" number of contracts requesting "n" variations of programs - even the DoD recognizes this.

2. The exploitation aspect of this WOULD have to be conducted in the environment it was to be deployed, otherwise you have no reasonable "exploit" picture. The purpose of exploitation analysis is to take the vulnerabilities of a system and determine upon exploit what the resulting pain can be (i.e., see the actual true effects and potential damage). Which of course can only be truly assessed in the scenario in which it is to be deployed.

3. Their is a bit of faulty thinking by this client in believing it is in their best interest that the creator of the software is the tester of software. This happens all of the time in Q/A, but should never be allowed in security for the purpose of a true audit. They need to have their own people, or even better a unbiased 3rd party (have them contact me :) ) to perform the vulnerability and exploitation analysis.

Answer 3

I specialize in application security. First and foremost, an application is hardly ever going to be tested within a production environment. You typically validate vulnerabilities in a test environment which the application is deployed within, post-development.

IBM AppScan can likely be used to perform testing against a desktop application, the same way it would be used to test a web application, as long as the desktop application is using HTTP or HTTPS. To accomplish this you configure a proxy to listen on your RFC 1918 address not your loopback, and deploy the desktop app in a dedicated VM. Configure the internet options in Windows to point to the address and port you bound the proxy to. I would suggest Burp Suite over anything else.

Information for individuals looking to get started can usually be found at the OWASP site. A good starting point would be the OWASP Testing Guide v4, but if you are looking for something to stamp that an app is secure by some sort of standard use the ASVS.

Ideally you want to integrate security practices throughout all phases of your SDLC and develop a framework separate to your actual SDLC called a Secure-SDLC. A Secure-SDLC will have security practices outlined that should be integrated into the SDLC efforts based on need.

Otherwise, you could just do pre-deployment pen testing but it costs more because your inevitably getting kicked back in the SDLC in order to remediate vulnerabilities identified. PCI and maybe HIPPA specify requirements associated with creating a secure development practices as well as running automated or manual testing against an application in order to identify vulnerabilities.