Security Under Contract: Software Security in a For-Hire Development Environment
If you develop software under contract to another organization, you will probably find that you must create a security development lifecycle (SDL) that is different than the in-house model I discussed last week. Security under contract includes custom software development work done by local, as well as offshore software development houses for customers. This is how we developed software for the US Space Program and how many large organizations develop or maintain their critical applications. Developing software for someone else means that you must meet their standards, regardless of your own expectations. If you fail to meet their minimum standards, you may open yourself to legal liability. If you exceed their expectations, you may find that you are underbid by another development shop for future work. How do you reach the right balance?
First you must understand the client’s perspective on software security. Are they risk tolerant or risk averse? Do they know enough to be concerned about the possible vulnerabilities in the application you are developing? Clients often tip their hands about risk tolerance in their initial request for proposal (RFP). Read the entire RFP and look for broad statements about security. Even if the requirements section is thin, you may find that the policy section mandates more security than the specification does. If you see this, you know that you will have to ask additional questions. This is also a good time to educate your client on the specifics of software development security. Explain the risk of poor application security and the cost of building security in.
You will demonstrate the added value of your SDL in your proposal. If you’re already under contract, talk about it anyway. Be sure to show how you can improve the security of your work at a reasonable cost. If you can’t be accurate in your cost estimation process, your SDL and your project will fail. It’s that simple. Your SDL should be efficient and based on a known standard. Clients like it when contractors adhere to independent standards so you should be able to favorably compare your operations to those of other well-known organizations. In that regard, your CSSLP certification should help you to establish your own credibility.
Doing security under contract means that you will spend more time tuning security requirements. Get this right or you will pay for it later. I still remember a government contractor who delivered an unusable application and then blamed it on the customer, saying, “You didn’t provide us with any performance requirements.” In my opinion, this type of behavior borders on professional negligence. If you fail to ask about security requirements and fail to provide feedback on the impacts of those requirements, you should not expect much repeat business. If, however, you ask about security requirements, explain the risk and are told that your client cannot afford the kind of security you offer, define a set that is affordable until both sides understand both the risk and the cost.
Once you have estimated the cost of security, it’s your job to make sure that you can effectively deliver the level of control that your client has specified. Good security design makes all the difference here. Security under contract means that you should optimize your security mechanisms to the client’s environment. Build to their authentication system. Report in a way that is compatible with their auditing standard. Work with their access control system where possible. If you build your software for multiple clients, abstract these interfaces into an API. Doing these things will dramatically improve the psychological acceptability of your system and is often something that they are willing to pay for.
You should build your security mechanisms with the expectation that they will be used and tested by a third party. This is a common feature of many government software projects and you have to be ready for it. It’s harder because a third party may not use the software as you intended it. This will add time to the delivery phase of your application.
Finally, consider security during the system maintenance cycle. Document your security features well and show how the security of the application can be upgraded to stay compatible with evolving technology. If you do things right, you may find yourself under contract for 10 or 15 years. This is not unusual for large contract jobs. However, if you do security poorly, you may find yourself replaced because you don’t have the necessary differentiators to be considered a long-term partner.
The other major delivery model addresses security for Independent Software Vendors (ISVs). ISVs require the most sophisticated and diverse model for an SDL. It’s impossible to address that model in a blog, so I’ll move onto other topics unless I hear of interest from you, the readers.
Jim Molini, CISSP, CSSLP
