For Target, it was the HVAC vendor. For JPMorgan Chase, it was a website run by a third party. Enterprises are becoming even more concerned about the security of their partners as news stories like these get the spotlight: attackers coming in through the digital loading dock. You may think you’ve mapped your attack surface across your own infrastructure, but you could be missing all the back doors that your vendors bring with them.

These aren’t necessarily intentional back doors; they’re usually mistakes or bad practices. Providers using the same administrative passwords across all their customers, support teams demanding more access than is actually necessary, and configuration errors are all common culprits. But these are more easily remedied than the biggest attack surface of all: the applications themselves.

First of all, do you know what third-party software you’re using? How do you define “software”? It could be anything from databases to web services and browser plug-ins. With the right tools — which might include packet captures if you’re desperate — you can discover the third-party PaaS, IaaS and SaaS providers that are being used, either officially or as part of “shadow IT.” But don’t forget open source components, which by some counts make up as much as 80 percent of code produced today. Even if you think your software is being written in-house, the raw materials may be coming from outside.

It can be difficult even to find out what vulnerabilities your third-party software has; some vendors prohibit reverse engineering or other examination of their code. And when you have thousands of partners, it looks like an impossible task to inventory their software, test it all and validate the findings so that you don’t look bad when you complain to them. Then the next question is, how often should you test everything?

The easy answer is that the third-party vendors themselves should be doing the testing; it shouldn’t have to be a game of “catch me if you can.” But that assumes that you trust the vendor’s idea of due diligence.

And finally, you have to persuade the vendor to fix any vulnerabilities that are found. Some won’t or can’t do it on a timely basis; others will want to charge you for it, since “nobody else is asking for this.” If you’re an Enormous Bank, you have more weight to throw around, but what if you’re a smaller enterprise, or a nonprofit? Even if the vendor does update the software, it may cost time and resources on your end to do the integration and regression testing before deploying the new version.

All of these issues are on the table for our roundtable discussion with Chris Wysopal, Eric Leonard from Boeing and Jim Routh from Aetna, who is also chair of the FS-ISAC Product and Services committee. Join us on November 5th at 12pm Eastern time, and bring your hardest questions.

Want to submit questions beforehand? Tweet them to me @451wendy or to Veracode @Veracode to get them included.


About Wendy Nather

Wendy Nather is Research Director, Security, within 451 Research's Enterprise Security Program, providing analysis on the current state of security from the perspective of a veteran CISO. Wendy's primary areas of coverage are application security, identity and access management, threat intelligence, and security services. Follow Wendy on Twitter here.

Comments (0)

Please Post Your Comments & Reviews

Your email address will not be published. Required fields are marked *

Love to learn about Application Security?

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