When I returned from vacation earlier this month, I heard that Yahoo had suffered a breach while I was away. Apparently, a hacker breached the site with an SQL injection attack that took advantage of a vulnerability hidden in a third-party application on the Yahoo website.
I was going to write about the breach, but I could find very little information beyond the site was hacked. I thought I might have just come to the story too late and it wasn’t as bad as the initial news made it out to be. Instead, thanks to some research by Imperva, the breach exposed something very important: the security risks of third-party code in the cloud. According to Imperva’s January Hacker Intelligence Initiative Report, “Lessons Learned from the Yahoo! Hack”:
From a business perspective, this attack underscores the security problem posed by hosting third-party code – as is often done with cloud-based services. In fact, according to a survey from PricewaterhouseCoopers, 23.6% of respondents say that cloud computing has increased vulnerabilities, and the largest perceived risk is the uncertain ability to enforce provider security policies. In the Yahoo! incident, the vulnerable application was probably not coded by the Yahoo! team, and not even hosted on Yahoo!’s server farm. This left Yahoo! with full responsibility for securing the application on one hand, and a very limited capability to actually control the code, on the other hand.
This is not good news for cloud security, in my opinion. Business decision makers have already been wary of cloud security and have been slow to adopt the technology. Will they blame the weaknesses of the cloud for breaches such as this or will they take a hard look at the risk of using third parties? IT professionals already understand the risk of using third-party applications, according to an IT Business Edge slideshow on 2013’s top security pain points, which stated that 67 percent thought third-party applications were a significant risk to network security.
This is not to say there is anything wrong with reaching out to a third party, whether it is a cloud provider or a coder or an application. It just has to be approached wisely and carefully. Or as Imperva pointed out:
From a business standpoint, executives should always assume third-party code – coming from partners, vendors, mergers and acquisitions – contains serious vulnerabilities. We recommend:
- Put in place legal requirements in a contract for what you will and will not accept from a security perspective.
- Incorporate security due diligence for any merger or acquisition activity.
- Require coding standards and security requirements in every specification between you and the third party.
- Demand metric reports for security of the vendor’s code that are repeatable and verifiable.
- Require that all security requirements are met prior to the first time the code is executed in your environment.