Tip

Outsourcing security issues: Managing outsourced software development

Both industry and government want to offer increasingly sophisticated Web-based services. To get online as fast and as cheaply as possible, many organisations are using, or thinking of using, outsourced software development

    Requires Free Membership to View

services. There are plenty of benefits to outsourcing software development: access to skilled developers, flexibility and scalability, cost savings, and increased speed to market.

Security can’t be removed in order to hit deadlines, and too few spend time and energy inspecting and testing the code for
Trojans, viruses, or embedded code that performs unspecified or malicious actions.

However, software written by a third party can introduce unacceptable levels of risk in the form of security threats and vulnerabilities. The cost of ensuring the final application is secure, and the organisation’s information assets remain protected, can have a significant impact on the overall cost. In this tip, we'll look at the key controls to put in place to get the most out of the benefits of outsourcing without incurring unforeseen costs or risks.

Assessing applications at risk
As with most security-related initiatives, the first task is to get a handle on what you need to secure. This means creating an inventory of applications that are being developed or maintained by an outsourcing provider. This will require not only talking to the procurement team, but also each business unit, because application sprawl can easily occur when individual groups or departments bypass the approved procurement processes in order to get a new project or idea off the ground!

Each identified application should undergo a risk assessment to understand the risks it poses to the business. The application must also be assigned an assurance level. The assurance level should take into account risk factors such as financial loss, operational risk, sensitive information disclosure, reputational damage and regulatory compliance violations. It should also determine the degree of security testing the application requires, and the acceptable threshold the application must reach in order to be ready for deployment.

These metrics need to be defined in any new outsourcing contracts, along with service-level agreements (SLAs), which explicitly define the organisation's security objectives and requirements as stated in its information security policy, to supplement the standard clauses covering quality, time and costs. Also, define the security environment in which the application is to be used and other resources that could be exposed by a security vulnerability, so everyone is clear about the potential risks.

Include a list of the most critical flaws you deem unacceptable – the OWASP Top 10 for example – that will be included in any checks. By setting thresholds and using standards-based scoring, such as the Common Vulnerability Scoring System (CVSS) or the Common Weakness Enumeration (CWE) standards, you remove any subjectivity regarding unacceptable flaws.

Reviewing partner’s security capabilities
Any outsourcing partner must be able to ensure its facilities and personnel match its customers' own standards regarding the protection of data and other intellectual property. When selecting an outsourcing partner, look for certifications such as ISO 27001 or the use of frameworks like Microsoft’s Secure Development Lifecycle. Ask to be allowed to inspect how closely the partner adheres to its chosen development process and review its security policies. How well an outsourcing partner actually implements its policies, as well as the level of training, skills and security awareness of its development staff, are all good indicators of its true commitment to security.

Before signing a contract, be sure it specifies what security checks and monitoring will take place during the life cycle of the application, and the outsourcing provider’s responsibility for fixing any flaws found at a later date. As security testing is a separate exercise from functional and operational testing, it should be made clear who will conduct these tests and which tools and methods will be used. Testing should certainly cover all the risks identified in the contract. Although the outsourcing provider will run its own security tests to check the robustness of its code, tests using an independent third party specialising in application security are essential to obtain unbiased verification and validation.

Another important area that needs to be covered in the contract is direct network connections between the organisation and the outsourcing provider. Any such link creates several potential vulnerabilities for an enterprise network. Vulnerabilities may include unauthorised access by the partner's personnel, the installation of Trojans or other malicious software, and intrusion by a hacker who has penetrated the partner's network. It is important for an organisation to involve its own network security personnel in all decisions regarding connectivity between the two networks.

While employees may be carefully vetted and strict network and data access controls may be carefully enforced, it's impossible not to lose some control over authentication of users logging in from the outsourcing provider’s network. As software developers are normally given user accounts with broad privileges and access rights, it is vital to check that the partner enforces its security policies and procedures. This is particularly important when it comes to physical security. The enterprise may have access controls on its own network, but it will have no control at all over the physical security of the environment where its application is being developed.

Organisations usually spend a lot of money testing new applications to ensure that they meet their functional requirements. But security can’t be removed in order to hit deadlines, and too few spend time and energy inspecting and testing the code for Trojans, viruses, or embedded code that performs unspecified or malicious actions.

Including clear and comprehensive security requirements in any contracts for  outsourced projects will add to the initial costs but will more than pay for itself in a more robust application. Also, by ensuring the responsibility for fixing any flaws once the application is deployed lies firmly in the hands of the outsourcer, the enterprise protects itself from further expenses or outsourcing security issues, and gives the outsourcer’s developers an additional incentive to write secure code and build an application that can withstand attack.

About the author:
Michael Cobb, CISSP-ISSAP, is a renowned security author with more than 15 years of experience in the IT industry. He is the founder and managing director of Cobweb Applications, a consultancy that provides data security services delivering ISO 27001 solutions. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Cobb serves as SearchSecurity.com’s contributing expert for application and platform security topics, and has been a featured guest instructor for several of SearchSecurity.com’s Security School lessons.

Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in December 2011

 

COMMENTS powered by Disqus  //  Commenting policy

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.