What to consider in an SLA to ensure secure software when outsourcing software development?

Question

To ensure secure development in the off shore team what are considerations to be taken into account in the SLA?

I got this as a reference: http://www.it-director.com/enterprise/technology/content.php?cid=10427

Does anyone have any templates and sample documents to refer to?

Answer 1

As @Lucas said, a lawyer should be your first port of call, however from a high level I can give some guidance on areas to look at - these are a small subset:

• How does the organisation test their own security?
• Do they use approved testers, internal teams, or both?
• Will you have a right to audit using your own staff or consultants?
• How do they manage incidents, vulnerabilities and exceptions?
• Will you have visibility of incidents, vulnerabilities and exceptions during the development lifecycle?
• Do they use a framework such as OpenSAMM?
• What responsibilities do they retain after delivery?
• How rapidly can they respond to advisories, whether from you, a CERT or a vendor?
• Do they have an escrow agreement in the event of financial collapse?
• Who will own the code - could it end up being published without your approval?
• How do they screen or check their employees prior to employment?
• Within what jurisdiction do they operate?

And so on...

Get a lawyer who knows this stuff!

Answer 2

Excellent question. Dealing with security issues early on -- when finding a contractor, writing a contract, during requirements definition, and when defining the architecture -- will ultimately reduce the costs of producing secure software for developers, and reduce risks and associated costs for clients. Win-win.

There is a great scenario of how badly things can go wrong at Secure software contracting hypothetical case study - OWASP.

I suggest looking to the OWASP Secure Software Contract Annex as a starting point for the kind of language you want to put in your contract. That page starts of with a quick FAQ discussing thorny questions like "But who should pay for all these activities?" and how to deal with third-party code. If your threat environment is not severe, and your requirements are not as strict, you can relax some of it. Or if you're dealing with really valuable assets and the threats are big, you can extend it.

It covers these areas:

1. Introduction
2. Philosophy
3. Lifecycle Activities
4. Security Requirement Areas
5. Personnel And Organization
6. Development Environment
7. Libraries, Frameworks, And Products
8. Security Reviews
9. Security Issue Management
10. Assurance
11. Security Acceptance And Maintenance

Otherwise you and your contractor may end up spending lots of money on lawyers debating the legal application of res ipsa loquitur.

Answer 3

IANAL, but based on my experience in Y2K where with the software I looked after there were a huge number of issues, there is little scope in practice for restitution of issues - the best outcome for the client is by resolving issues with the full cooperation of the provider. The only ones whom will be better off in such disputes are the lawyers.

What this means in this context is that your security concerns are best addressed in your selection of a provider - which should be reiterated in your contract. But the existence of requirements in the contract does not in any way reduce your obligation to ensure compliance with the contract before and during the development of the service - waiting until after the service to be deployed before you discover that the provider did not have the code auditing controls in place makes it your fault in my opinion, even though the provider would be in breach of the contract.

But with the best will in the world, vulnerabilities can still be introduced in code, by accident or by design - so it's certainly worth planning for this in terms of turnaround on resolution, defining scope of liability and ensuring that the provider will be able to make restitution in the event of culpability. Since the potential costs resulting from software vulnerability can massively exceed the cost of the software itself, there is no scope for (e.g.) using escrow.

Indeed, if you look at the article the points it makes about security (except for references to specific legislation) apply to all the functionality of the service.

At the risk of venturing off topic, IMHO the best solution is to manage the code auditing and testing (for all aspects of quality) independently of the provider even if your just replicating what they say they are already doing.

Going further, the security of the service also means the continued availability. Both this and the point raised in the previous paragraph show a clear requirement that you have access to the source code of the application. While financial escrow has a lot of benefits, IMHO, source code escrow does not, in practice, serve the interest of the client. NB that ownership of the intellectual property is not dependant on access to the source code - and specifically by providing the client access to the source code in no way erodes the clients responsibilities nor the providers IP rights.

However there are significant benefits to the client in owning copyright over the developed code, and where there is some assurance of the quality provides a useful bargaining position to trade off against future liability for the developer.