With almost every software development team now utilizing open source code, outsourced development, commercial-off-the-shelf (COTS) software or some other form of outsourced software, the need to understand proper third-party security has never been greater. The gamut of methods for analyzing third-party software runs from robust solutions that check for true application security to others so simple that, functionally, they're little more than rubber stamps that enable IT departments to claim they have third-party security in place.
In the face of growing attacks against vulnerable apps, it is critical that CISOs ensure their outsourced software is truly secure. Without a comprehensive assessment of the various methods of third-party software analysis, it's impossible to confidently report on overall system security. Here's a closer look at some of the options available for confirming the safety of third-party products:
Vendor Self-Assessments
Vendor self-assessments are fairly standard within the world of third-party development, and while they can be insightful, their results are often given too much weight. Designed to determine the security strength of a piece of software, these assessments involve a list of questions that software vendors have to answer. Questions will normally cover aspects of the code itself, the company and the overall development environment.
Unfortunately, self-assessments have several drawbacks, the foremost of which is that they are supplied by the software producer rather than an independent party. Even if the producer legally attests to the accuracy of its surveys, answers to any subjective questions have to be taken with a grain of salt.
vBSIMM and the SIG
While BSIMM (Build Security in Maturity Model) is an excellent set of security benchmarks, it's an exhaustive process that not every software firm can accommodate. Thus, vBSIMM ("v" for "vendor," in this case) was created as a way of taking several of the most important and objective aspects of BSIMM and applying them to a software vendor. Utilizing vBSIMM won't give explicit insight into any specific piece of software, but it will provide CISOs with valuable information on a company as a whole, indicating when they need to be wary and when they need to push for new vendors.
Similarly, the Shared Information Gathering (SIG) was designed as a way to inject standardization, speed and efficiency into the risk-assessment process. The SIG includes a standardized questionnaire and a set of Agreed Upon Procedures (AUP), which combine to form a "trust, but verify" approach. The questionnaire is updated annually to ensure that emerging risk controls are included, and the AUP allows answers to be verified by an outside party and establishes risk-control areas to be monitored during on-site assessments. While thorough, the SIG is like vBSIMM in that it can only give an overview of the vendor's security policies rather than insight into any specific software vulnerabilities.
Manual Penetration Testing
Manual penetration tests — in which security professionals manually attempt to penetrate an app while it works — are often requirements for third-party applications. That's because there are certain powerful vulnerabilities, such as Cross-Site Request Forgery, that no other means of testing can catch. Manual testing is ideal for testing against very specific flaw categories, but it's too resource-intensive to use for the entire spectrum of possible vulnerabilities.
Dynamic Analysis
A dynamic scan will analyze a piece of third-party software, probing an attack surface and then intentionally supplying malicious data to input fields to find any architectural weaknesses or exploits. These analyses are ideal for finding high-profile vulnerabilities such as SQL injections and Cross-Site Scripting. Since dynamic scans operate while applications are running, they can also find authentication and configuration issues that other types of scans may miss.
Static Testing and Binary Static Testing
Static application testing, sometimes called "white-box testing," scans an application without executing the code. The scan begins by mapping out a model of an application to get an understanding of just how information will flow through it. It then uses this map to test for vulnerabilities that won't necessarily be caught in a scan of the working application. Binary static testing is even more helpful when dealing with third-party software, since it can perform this task without access to the source code. Binary testing is such a large jump forward that influential groups like the Financial Services Information Sharing and Analysis Center (FS-ISAC) have recommended binary static analysis as part of a complete solution for securing third-party code.
Finding the Right Mix
The perfect third-party security solution will combine aspects of assessments, tests and scanning to ensure that software is free from major vulnerabilities before it's put into production. CISOs can't count on third parties to always do the right thing, so due diligence in selecting providers — coupled with a security scanning solution built for outsourced code — is paramount.
