The following is a guest post by Wendy Nather, Research Director, Security, 451 Research. As a former CISO, I’m always happy to see practical advice for defenders. In increasing order of usefulness, there are these types of advice:
There aren’t enough people in the security industry who are bold enough to step up and say, “Here’s what works.” So when something does come out, we need to pay attention. The Financial Services Information Sharing and Analysis Center (FS-ISAC) formed a working group on third-party software security, and has come out with a white paper on “Appropriate Software Security Control Types for Third-Party Service and Product Providers.” Now, it’s hard to dictate software security to a third-party, and it’s especially hard to frame it in terms that are enforceable in a contract. Like the “cheap, fast and good” saying, you can have software security terms that are unambiguous, objective, and complete – pick two. But the FS-ISAC white paper does a good job at compensating for this problem. The three control types it recommends are process maturity assessment (using vBSIMM as a model), static binary analysis, and policies around the use of open source libraries and components. In the cases of the first and last controls, what the working group is doing is to address how the provider approaches security in its software development, since you can’t always dictate the results. The middle control, binary analysis, is probably the best you can do in most cases to assess the results of the software development lifecycle when you can’t get source code and you can’t stand up an instance of the application to test it dynamically. The Building Security In Maturity Model (BSIMM) is built on the study of dozens of large organizations and what they do to ensure software security; the vendor version (vBSIMM) is tailored to what providers ought to be doing. It has some of the most important security activities, including secure design, threat modeling, automated and manual penetration testing, and handling security issues in production. There is one area that I would add to it -- specific to SaaS providers -- and that’s stack security. Software security doesn’t happen in a vacuum; it also depends on the security of what it’s running on. Penetration testing ought to cover that issue, but only if it’s scoped to include it (see the Penetration Testing Execution Standard for an extensive listing). Monitoring the use of open source components is extremely important, and not enough organizations do it. If you’re a software vendor, and you think you’re not using any open source in your code – check again, just to be sure. Widely shared components can be a big liability, but they can also be a big advantage when it comes to updating security in many applications at once. How are third-party providers going to react to this white paper? Well, I know it’s annoying to be swamped with questionnaires of the kind that are featured there. But this is also an opportunity for providers to fill out this vBSIMM survey once, and then hand it out to customers who request it. Likewise, having security testing done once and sharing the standardized results could go a long way towards shortening the sales cycle. There’s also strength in numbers on the other side of the table: if a group like FS-ISAC shares its assessments of vendors with one another, that will help a software security standard come into focus. I’d like to see a set of controls like these adapted (if necessary) for other industries, and maybe they will spark more discussion on pragmatic steps to take in software security. As a customer, you need to know what to ask for before you can get it. And finding the right questions is the first step towards finding the right answers. Want another perspective on the working group whitepaper? Listen to Veracode CTO and Co-Founder Chris Wysopal discuss the controls in a podcast available here!