Controls for Outsourcing Software Development

Paladion
By Paladion

October 15, 2004

When you outsource software development, how do you ensure that security has been adequately addressed by the vendor? In this article we look at the controls that you need to be put in place over the vendor regarding the various stages of the development lifecycle

When you outsource software development, how do you ensure that security has been adequately addressed by the vendor? In this article we look at the controls that you need to be put in place over the vendor regarding the various stages of the development lifecycle.

  1. While signing the contract, remember to ensure the following:
    • Require the vendor to provide the results of a 3rd party application security audit as part of software acceptance.
    • Reserve the right to perform a process audit of the vendor’s adherence to software development processes This is to see compliance with security processes.
    • Agree on turnaround times for the release of patches when a vulnerability is discovered.
  2. In the Software Requirements Specification (SRS), explicitly state the security requirements:
    • Identify the business risks as perceived by the end user.
    • Specify the security requirements that are part of your Information security policy and relevant to the application.
  3. As part of the testing phase, require that the security test cases for all the risks identified in the SRS be documented and shared.
  4. During deployment and maintenance, ensure that only security tested and approved code is deployed.

Let’s look more closely at two of the more involved guidelines.

The SRS should identify the security risks the business owner is concerned about. Not only does this improve the clarity of the security requirements for the vendor, it also ensures that a third party assessment effectively considers the risks perceived by the business owner. The SRS should also specify desired password requirements, how to handle forgot passwords and also identify the data that should be encrypted at the client and the server. For instance, if it is required that the application should not allow multiple concurrent logins for a user, the SRS should explicitly state that – this leaves no ambiguity for the designers, and also ensures that the product gets more meaningfully audited.

Require that the security test cases for all the risks identified in the SRS be documented and shared. Let’s take an example of a test case for testing that multiple concurrent logins are disallowed. The security test cases should describe how an exploit level test would be perpetrated and verified. (“After successfully logging into the application, manipulate the account number while retaining the session id and username: check if the details of the new account number can be accessed”.) By sharing the exploit level test cases, a vendor can assures you of the sufficiency of the security testing.


Tags: Best Practices

About

Paladion