One of the many items I need to deal with is security relating to products being developed off-shore. The expectations of the businesses concerned is that the quality of the work being delivered will be as good as, or better, than work produced in-house.
Sometimes however, the delivered product might be functionally correct but the security leaves a lot to be desired. If it’s a key product in your portfolio then that might mean one whole lot of risk that you could do without.
What do I mean by security issues? In this instance we are talking about vulnerabilities such as weak authentication and authorisation routines, a lack of validation, poor error handling, and most of the rest of the OWASP top ten.
Let’s be clear, these problems are not unique to offshore work. The same problems are just as likely to crop up within your own development groups, or using third party vendors here in the UK. And I want to cast aside any dispersions that I might not rate the ability of offshore developers: the knowledge and ability of software developers in many of the offshore regions in use – India being the predominant one – is exceptional.
So, why does it sometimes go wrong with regards to security? I’ll give you the answer, and it’s a single word: requirements.
Setting out detailed requirements is the single most important thing that you can do to mitigate risk relating to work that you send overseas. Sure, you can offset some of the rest of the risk through checking that the chosen vendor has a good standard of security themselves (see yesterdays blog) and you can offset some more by having a good process in place to check and verify the work once it is delivered, but if you don’t get the requirements right in the first place then you can have no expectation that the end product will be anything like you expect it to be.
In addition, don’t forget the SLA. This needs to contain language setting out expectations beyond the functional correctness of the product and make it clear that the agreement includes security. Make it easier for the vendor by giving them the same documented standards and requirements that your own developers work with (assuming that you have any…). Manage the vendor: talk to them regularly, reconfirm requirements, and check work throughout the SDLC, don’t wait until D-Day.
Lastly, perform a full and thorough risk assessment of the vendor, onsite and in person. The work they are producing for you is your intellectual property and you need assurance that it is being protected. The onsite visit will also provide you with the opportunity to chat with development staff. In my experience the vendors will relish the opportunity to demonstrate the quality of their processes. Revisit regularly and solicit developers for their opinion on the work being requested of them. Ask the question: “are the requirements you are receiving good enough?” Don’t always expect the answer to this question to be offered – go out and find out!