Navigating Cloud Application Security: Myths vs. Realities

Chris Wysopal, CTO, Veracode

Developers and IT departments are being told they need to move applications to the cloud and are often left on their own to navigate the challenges related to developing and managing the security of applications in those environments. Because no one should have to fly blind through these uncertain skies, it’s important to dispel the myths, expose the realities and establish best practices for securing cloud-based applications.

Inherent Threats

Whether we are talking about IaaS (Infrastructure as a Service), PaaS (Platform as a Service) or SaaS (Software as a Service), perceived security vulnerabilities in the cloud are abundant. A common myth is that organizations utilizing cloud applications should be most concerned about someone breaking in to the hosting provider, or an insider gaining access to applications they shouldn’t. This is an outdated, generic IT/infrastructure point of view. What’s more important and elemental is to examine if the web application being used is more vulnerable because of the way it was built, then deployed in the cloud – versus focusing on cloud security risks from an environmental or infrastructure perspective.

It’s imperative to understand the inherent (and non-storied) threats facing applications in virtualized environments. Common vulnerabilities associated with multi-tenancy and cloud provider services, like identity and access management, must be examined from both a security and compliance perspective. Obviously in a multi-tenant environment, hardware devices are being shared among other companies – potentially by competitors and other customers, as well as would-be attackers. Organizations lose control over physical network or computing systems, even local storage for debugging and logging is remote. Additionally, auditors may be concerned about the fact that the cloud provider has access to sensitive data at rest and in transit.

Inherent threats are not only present in the virtualized deployment environment, but also in the way applications for the cloud are developed in the first place. Consider the choices many architects and designers are forced to make when it comes to developing and deploying applications in the cloud. Because they are now in a position where they are relying on external controls put in place by the provider, they may feel comfortable taking short cuts when it comes to building in application security features. Developers can rationalize speed time to market advantages related to by being able to use, and test, less code. However, by handing external security controls to the provider, new attack surfaces quickly emerge related to VM, PaaS APIs and cloud management infrastructure.

Security – Trust No One

Security trust boundaries completely change with the movement of applications from internal or DMZ, to the cloud. As opposed to traditional internal application infrastructures, in the cloud the trust boundary shrinks down to encompassing only the application itself, with all the users and related storage, database and identity management systems becoming “external” to that application. In this situation, “trust no one” takes on great significance to the IT organization. With all these external sources wanting access to the application, how do you know what request is legitimate? How can we make up the lack of trust? It boils down to establishing an additional layer of security controls. Organizations must encrypt all sensitive data stored or transmitted and treat all environmental inputs as untrusted in order to protect assets from attackers and the cloud provider itself.

Fasten Your Seatbelts

Best practices aimed at building protection must be incorporated into the development process to minimize risks. How can you help applications become more secure? It starts with a seatbelt – in the form of application level security controls that can be built into application code or implemented by the cloud services provider itself. Examples of these controls can include encryption at rest, encryption in transit, point-to-point and message contents, auditing and logging, or authentication and authorization. Unfortunately, in an IaaS environment, it may not be an option to have the provider manage these controls. The advantages of using PaaS APIs to establish these controls, for example, is that in most cases the service provider has tested and debugged the API to speed time to market for the application. SaaS environments offer no choice to the developer, as the SaaS provider will be totally in control of how data is secured and identity managed.

Traditional Application Security Approaches Still Apply

Another myth that must be debunked is the belief that any approach to application security testing – perhaps with a slightly different wrapper on it - can be used in a cloud environment. While it is true that traditional application security issues still apply in the cloud, and that you still need to take advantage of established processes associated with requirements, design, implementation and testing, organizations can’t simply repackage what they know about application security. Applications in the cloud require special care. IT teams can’t be content to use mitigation techniques only at the network or operating system level anymore.

Security testing must be done at the application level, not the environmental level. Threat modeling and design phases need to take additional cloud environmental risks into account. And, implementation needs to use cloud security aware coding patterns in order to effectively eliminate vulnerability classes such as Cross-Site Scripting (XSS) and SQL Injections. Standards such as OWASP Top 10 and CWE/SANS Top 25 are still applicable for testing IaaS and PaaS applications, and many SaaS extensions.

Overall, dynamic web testing and manual testing are relatively unchanged from traditional enterprise application testing, but it’s important to get permission and notify your cloud provider if you plan to do dynamic or manual testing, especially on a SaaS extension you have written, so it doesn’t create the appearance that your organization is attempting an attack on the provider.

It’s also important to note that cloud design and implementation patterns are still being researched, with efforts being led by organizations like the Cloud Security Alliance and NIST. Ultimately, it would be valuable for service providers to come up with a recipe-like implementation for APIs.

Pre-Flight Checklists

After applications have been developed, application security testing has been performed according to requirements of the platform, and you are presumably ready to deploy, how do you know you are ready? Each environment, IaaS, PaaS or SaaS, requires its own checklist to ensure the applications are ready for prime time. For example, for an IaaS application, the organization must have taken steps such as securing the inter-host communication with channel level encryption and message based security, and filtered and masked sensitive information sent to debugging and logging functions. For a PaaS application, threat modeling must have incorporated the platform API’s multi-tenancy risks. For SaaS, it’s critical to have reviewed the provider’s documentation on how data is isolated from other tenants’ data. You must also verify the SaaS provider’s certifications and their SDLC security processes.

Future Threats

Myth: just because you are prepared for a safe flight, doesn’t mean it will be. Even with all the best preparation and safety measures in place, there is no debating the nascent nature of this deployment environment, leaving much more research that needs to be done. One effective approach it to use threat modeling to help developers better understand the special risks of applications in the cloud. For example, using this approach they can identify software vulnerabilities that can be exploited by a “pause and resume” attack where a virtual machine becomes temporarily frozen. A seemingly innocent halt to end-user productivity can actually mean a hacker has been able to enter a system to cause damage by accessing sensitive information or planting malicious code that can be released at a future time.

As a security community, with security vendors, cloud service providers, research organizations and end-users who all have a vested interest in secure deploying applications in the cloud, we have the power establish guidelines and regular best practices aimed at building protection into the development process to prevent deployment risks. Fasten your seatbelts, it’s going to be a fun ride.

As co-founder and CTO of Veracode (www.veracode.com), Chris Wysopal is responsible for the security analysis capabilities of Veracode technology. He’s a recognized expert and well-known speaker in the information security field. His groundbreaking work while at the company @stake was instrumental in developing industry guidelines for responsibly disclosing software security vulnerabilities. Chris is co-author of the award winning password auditing and recovery application @stake LC (L0phtCrack), currently used by more than 6,000 government, military and corporate organizations worldwide.