“Outsourcing of application security requirements to specialist security vendors doesn’t translate to a completely hands-off proposition for product teams. Successful completion of Application Security (AppSec) engagements require continued engagement between both parties”
Application Security Testing is an important part of any mature security program. A large part of this security testing is outsourced by product teams as it’s difficult to find the necessary bandwidth to execute these practices in-house. Additionally, the value of getting a fresh perspective from specialist security vendors is being increasingly recognised. Seen in this light, it’s therefore not surprising that a study(see "IT Outsourcing Statistics - Computer Economics") by Computer Economics found that IT security outsourcing is increasing at the fastest rate of all outsourced functions in terms of the percentage of work outsourced, with 48% of respondents reporting that they will increase the amount of security work that they outsource.
However, the lesser known fact is that a considerable proportion of these application security service engagements fail, with both the client and vendor left frustrated over wasted time and resources. This is because a security team, developer, executive or a CISO’s approach to security outsourcing is well structured, thoroughly researched and highly engaged only upto the point of ‘selecting the right’ vendor (see “5 Things to Look For While Choosing an Application Security Testing Vendor”) . Truth is, outsourced security arrangements need clearly defined goals and deliverables with ardent participation from both parties throughout the project timeline to be successful. Which is why we wish to put forward an application security outsourcing guideline to enable digital businesses get the best out of their application security vendor.
Breadth vs Depth
The first consideration must always be to identify the scope, goal and limitation of the project under consideration. To determine whether you need a breadth based engagement or a depth based one.
If you’re someone whose needs are triggered by compliance compulsions that mandate meeting stringent regulatory requirements or by a desire to outsource internally executed assessments for validation then what you need is a breadth based engagement where a topical level assessment of a target application is made. Such an engagement would typically have minimal involvement of product development teams, who need to do little beyond providing security vendors a walk-through of the basic functionality of the application that is to be tested. A depth based engagement however, is a lot more demanding of both parties. With product development teams required to provide clarity on workflows, edge cases and code logic to vendors who would then try to use advanced test cases to uncover any hidden vulnerability. This type of engagement is usually chosen by businesses that house sensitive information and are therefore associated with a high incident risk(like banking, finance or healthcare) or by proactive companies that recognise the importance of a manual penetration test in finding high severity logic flaws that are unique to specific applications (see “7 Myths of AppSec Automation”).
Communicating the maturity of your security needs in such a manner will help save both you and your vendor’s time and resources, all the while establishing a clear end goal for the entire exercise.
Never Shorten Deadlines
Once you’ve clearly defined the ambit of the engagement and its associated goals you’d need to decide on a timeline for delivery. It’s 2018, but even today third party assessments are typically brought in near the end of the product development life-cycle, when changes are expensive and have a large impact. If you’re part of the group that wasn’t prescient enough to buck this trend, then be prepared to accommodate security assessments even at the cost of a slight delay in product releases, especially if you’ve opted for a depth based engagement where there is continued dialogue between security teams and product designers. This doesn’t necessarily mean that a breadth based engagement is spontaneous, there is still a lot of effort that goes into them, especially the ones involving automation, where a lot of effort goes into the initial set up, before bearing the fruits of scale.
Irrespective of what type of security assessment you select, be sure to set a deadline for delivery that agrees with your application release velocity and security budget. Further, be sure to do so before the commencement of work so you never put yourself in a position where you have to hurry your vendor into moving a deadline, as this might compromise the efficacy of the whole exercise.
Collaboration over Scrutiny
Often times product teams decide to outsource security assessments that have been already executed internally or by another external security team. This additional step is intended as an extra sanitisation check that is to be carried out by a fresh set of eyes. But it becomes an unnecessary delay in your SDLC, when product development teams withhold all knowledge of previous security assessments performed on the same target application from their vendors. Development teams find it hard to resist the temptation to scrutinise the competency of their vendor by comparing their findings with previous reports, in effect undermining the objective of the entire engagement - finding and fixing vulnerabilities early. Avoid suffering such needless delays, share reports of all relevant previous security assessments with your vendor. This is especially beneficial in the case of grey box assessments where an informed vendor is able to build on your findings and define test cases that best supplement it. Adopt a culture of collaboration where you consider your security vendor as an extension of your in house team that helps augment your capabilities. This is an important aspect of a proactive security program where the objective of risk and security assessment take precedence over all others.
This guideline of sorts stems from the initial exchanges I’ve had with inbound customers within the AppSec services domain. Large number of whom complained of having a fractious end with their previous vendor. It’s my opinion that these unpleasant experiences can be avoided by establishing open and lucid communication between both parties. Which is why I’ve penned down actionable considerations that help promote the same. If you want to share a consideration I missed from your experience, drop me a line about it in the comments below.
