Cloud security: Third party code

Using third party code in cloud computing can be a security risk for users since the code does not originate from the developer, allowing hackers an easy avenue to breaking into networks.

Greg Hale

Share

With cloud computing becoming more of an entity in the industry, there are dangers involved with using third-party code, a new report said.

Part of the explanation comes back in December when a hacker breached Yahoo! with an SQL injection attack that took advantage of a vulnerability in a third-party application that was provided on the Yahoo! Web site, according to a report from Imperva.

This attack highlights the risk that many Web applications face: Web applications may contain some sort of third-party code, such as APIs, not created by the developers.

“The weak link in the Yahoo! attack was not programmed by Yahoo! developers, nor was it even hosted on the Yahoo! Servers, and yet the company found itself breached as a result of third-party code,” said Amichai Shulman, CTO, Imperva. “The challenge presented by the Yahoo! breach is that Web-facing businesses should take responsibility to secure third-party code and cloud-based applications.”

Technically, security teams should:

• Protect third-party Web applications against SQL injection and other Web attacks: Incorporate security into the software development life cycle, perform penetration tests and vulnerability assessments on the application, and deploy the application behind a Web Application Firewall (WAF).
• Harden your system: When the application goes from development to production, the system configuration needs to harden to disable any irrelevant parts that may help the attacker. In the hardening process detailed error messages should end up disabled, there should be restrictions on excessive file and directory permissions, and you should delete source code leftovers.

From a business standpoint, executives should always assume third-party code – coming from partners, vendors, mergers and acquisitions – contains serious vulnerabilities.

Some recommendations:

• 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 executes in your environment.
• Require a comprehensive review of possible vulnerabilities resulting from new external services operating in conjunction with your current services.
• Require a report specifying security issues and measures taken to address them for every task and deliverable from the vendor.

Click here to download the complete report.