Mitigating Software Outsourcing Vendor Security Risks

Assessing 3rd party vendors

I’m probably scratching the surface when it comes to security best practices and by no means am I a subject matter expert, however, I happen to pick up sound suggestions from clients that have found ways to better protect their assets by implementing smarter and safer rules of engagement with their software development vendors.

Companies want to provide contextually robust web experiences to their clients today. To maximize speed-to-market deliverables, some modern organizations are quickly taking advantage of partnering with 3rd party software development vendors. There are many benefits to working with outsourcing vendors such as:

• Quickly accessing niche technology talent
• Reduced costs of engagement
• Able to scale up and down depending on product size
• Align industry experienced experts to maximize product impact
• Prototype ideas without overloading staff while mitigating costs

In today’s global interactive economy, the danger of application security breaches are skyrocketing, and technology executives are shifting focus onto addressing potential gaps.

Some of these gaps can be attributed code developed by 3rd party vendors where lack of physical security and a cultural-misaligned engagement led to product user data breach. The cost of breach per user is over 150 USD, and companies with millions of records that can potentially be breached are prime targets for hackers worldwide.

Below are suggestions to assess and properly align software development vendors to mitigate application security risks.

VALUATE APPLICATION RISK

Just like assessing most security initiatives, the first thing to focus on is what is it that you need to secure. Create a list of all software applications that 3rd party outsourcing vendors are currently accessing, developing and/or supporting. Depending on company size, this may require that you connect with procurement and all departments where these applications are dispersed across, including areas where it could bleed into; sometimes it's easier to take an existing application and build upon to get an idea out quickly (These are the most vulnerable areas of the company).

ASSURANCE LEVELS

For each application added to the list, it needs to be evaluated for risk assurance levels across business areas. The assurance levels assigned to each application needs to address risk factors such as Operational Risk, Monetary loss, private or sensitive information disclosure, brand damage and breach of policy/regulatory compliance; it also should determine how much security testing the application requires and acceptable thresholds before an application can be deployed.

VENDOR CONTRACT

Best practice rule of thumb is to use these type of metrics in MSA’s (master services agreement) and including any SOW”s (Statement of Work) contracts. This also includes all service level agreements (SLA’s) where the organization’s security requirements protocol and objectives are clearly defined; also within its security policies framework to supplement clauses stipulating quality, time and costs. Another practice point is to spell out the type of security environment the application is to be in and other resources that could be a potential gap in security. This helps bring greater awareness of all potential risks to everyone involved in the project.

Try to develop a vendor matrix scorecard to monitor and evaluate vendor compliance. Adding an extra step will add more costs to the project but in return, you are investing in better protecting the organization’s assets.