Skip to main content
October 23, 2014

A Neglected Threat

This post was jointly authored by Ed Jennings, Chief Marketing Officer and Anne Nielsen, Product Marketing Manager at Veracode.

Enterprises everywhere — not just the biggest banks — are ignoring a major gap in their approach to security

The recent breach at JPMorgan Chase compromised some of the personal account information of 76 million households and 7 million small businesses. This breach, along with those at Target, Home Depot, Lowes and others, highlights the issue of vendor security: if you are buying something, are you also responsible for securing it?

Benjamin Lawsky, New York State's first superintendent of financial services, sent a letter to dozens of banks earlier this week looking to better understand their third-party vendors’ information security risks.

Unfortunately, many of those banks won’t have answers to these questions – not because they aren’t interested or don’t care, but because they leverage thousands of vendors and don’t yet have a scalable, efficient and reasonably priced approach to addressing vendor risk.

This current approach is a cobbling-together of many processes to form a patchwork of protection that — unsurprisingly — attackers have been able to poke through. The process for vendor security is dominated by the manual collection of questionnaires about the vendor’s security practices. These questionnaires are generally filled out at the time of purchase of a product and not revisited again. The most ambitious enterprises resend these questionnaires annually, collect artifacts to substantiate that the responses are accurate and honest, and potentially even perform on-site visits to validate the answers to those questionnaires. If the product being purchased is software, the highest level of testing — a manual penetration test — is reserved only for the most critical of applications due to time and resource constraints.

I have spoken with enterprises that struggle to thoroughly review questionnaire responses and artifacts, much less to validate accuracy or – if the product is software – test their instance of the product.

Understanding the security of products being purchased is a major challenge for every enterprise as they look to take advantage of the latest and greatest innovative technology, be it SaaS, mobile, open-sourced or internet-enabled.

Conversely, this is a major challenge for producers of software. Answering unique questionnaires, preparing customized artifacts, facilitating on-site assessments and handling customer-specific manual penetration tests is cumbersome and time-consuming at best. In the worst case, findings from these tests can throw off production schedules as products need to be reworked to address one-off requirements from a vocal customer.

A new, standardized approach to vendor risk is needed

What can an enterprise do to address vendor risk? A group of leading organizations in financial services put together recommendations for addressing this issue last year. While limited to software security, this paper, “Appropriate Software Security Control Types for Third Party Service and Product Providers,” documents an approach that many enterprises are taking by evaluating the vendor and evaluating the product. Aerospace and defense manufacturer Boeing takes a similar approach; if a vendor fails a secure development evaluation, then testing of the vendor’s software product is required through a cloud-based self-service model – which is also much more scalable.

Essentially, the enterprise has three options to address vendor risk:

Option 1: Evaluate the vendor’s ability to produce a secure product

If the vendor has a system in place to appropriately produce a secure product, then more onerous controls and understanding the security of the product itself may not be required.

When it comes to software, there are a number of competing methods to validate the development process, be it an ISO 27034 or NIST 800-53 compliance evaluation, a Shared Assessment’s SIG questionnaire or a vBSIMM (Build Security in Maturity Model) audit. However, putting together a system for developing secure software – much less other products – can be extremely expensive. Setting up a secure development lifecycle along the lines of the Microsoft SDL can cost software producers millions. Secure development may be prohibitively expensive to small and even medium-sized software producers.

Option 2: Evaluate the security of the vendor’s product

This seems to be the most obvious and offer the most comprehensive security assurance for a purchasing enterprise: if you want to ensure that the product you are purchasing is secure, then test that product.

When it comes to software, this means a penetration test. But contracting, conducting and remediating the results of a pen test are expensive and time-consuming, both for the enterprises funding the penetration test and for the software supplier than needs to facilitate the test and pull developers away from working on the product in order to address findings.

The FS-ISAC recommends instead binary static analysis – an automated code audit of the software binaries. This protects the IP of the software vendor and is much less expensive and time-intensive. Findings will still need to be addressed, but preferably integration of this audit into the software development lifecycle will reduce the number of findings and the time for remediation in the future.

Also recommended is the use of software composition analysis software: in order to protect enterprises from the future #HeartBleeds and #ShellShocks of the world, security leaders must not only understand what third-party and open source components internal teams are leveraging, but what their vendors are using. Automated governance for third-party and open source components used by commercial software vendors is an important aspect of evaluating the security of the vendor’s product.

Option 3: Use a trusted third-party rating system

There must be an easier way — a standardized way to comprehend the accreditation of the vendor or the product itself. For vendors, there is the Better Business Bureau. For some hardware and software products, there is Consumer Reports and CNET. But none of these avenues are security-specific.

A model system would enable an enterprise to – at a glance – understand which of its vendors is doing something to address the security of their products and prioritize for further inspection and testing those vendors that are not doing anything. This would enable vendors that have invested in security – like Veracode’s VerAfied customers – to skip through the process when it comes to a security assessment, while those that are doing nothing receive greater inspection.

Ideally, an enterprise should incorporate all three of these options into their approach to managing their vendor risk. Veracode can certainly help when it comes to addressing software security through automated code audits and software composition analysis of third-party software, but enterprises will need to take on the fundamental issue of how they manage vendor risk as a whole in order to truly address this threat.

To learn how two security leaders are taking on this exact issue, join Wendy Nather, 451 Research; Eric Leonard, Boeing; Jim Routh, Aetna and FS-IASC; and Chris Wysopal, Veracode, for the webinar, “Strategies for Third-Party Software Security that Actually Work.”

Related Content

Senior Product Manager for Veracode’s application security platform including reporting, analytics and API feature sets as well are Veracode’s technology evolution from a monolithic architecture into MicroServices. Anne partners with Veracode customer’s to manage application security risk through new product features and functionality while enabling Veracode’s best in class scanning technologies.

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.