“Web and cloud as platforms are both realizations of the distributed application,” he says. “I touch an application from somewhere offsite, gather a certain body of information, then touch something else and access other data.”
To determine what weaknesses attackers would attempt to exploit before an application is even developed, the application must be looked at from the point of its components, as a whole, and its interactions with other applications. This is commonly referred to as the attack surface, says Dan Cornell, CTO of the Denim Group, an application/portal development consultancy that also provides resources and training in this area.
Tools, libraries and APIs provided by OWASP, SAFECode, the Cloud Security Alliance and others can help developers model threats to their applications and discover where code, calls, interactions and functional aspects of the application could be made to fail.
Start by determining the value of the data the application will contain or access, Cornell says. For example, if it involves personally identifiable information (PII), health care or financial information, the application will be a target. Then model threats against that data by looking at the individual components of the application and its communication channels to pre-identify potential vulnerabilities at design time.
“It's much easier, cheaper and faster to repair vulnerabilities found during design rather than at implementation,” Cornell says. “But quite honestly, a lot of organizations we talk to are terrified of old legacy applications that they can't change, and are concerned about connecting them to other cloud and web-based applications.”
Cornell advises that organizations design secure workarounds, like connectors, APIs and hardening around the system that cannot be made secure. Or, if possible, use the new application design as a chance to upgrade old, insecure systems with new systems that can scale securely to web production, mobile access and cloud environments.
“It's critical to think about the type of applications customers run on the web and in the cloud – as an extension of their intranet, collaboration system, or a retailer's entire e-commerce site,” says Omar Khawaja (left), director of security solutions for Terremark, Verizon's cloud services subsidiary. “How are these applications, systems and clouds configured? And, more importantly, how are they securely accessed?”
As an example, Khawaja points to a customer facing web application that processes financial transactions. During the design phase, trust boundaries must be established between the web and transaction servers to protect the data. This seems like an obvious design point, but in virtual and cloud environments, these trust zones are more overlooked than they should be, say experts.
When designing to commercial cloud services providers, secure zones also encompass how customers are segmented from one another in the cloud, adds Phillips from Symantec.
“Ten years ago we wouldn't have put data from the KGB and CIA on the same RAID array of a storage service provider,” he says. “Today, cloud vendors need to deal with that same security challenge when hosting applications belonging to competing organizations in the same shared hardware and virtual infrastructure. You need to work this out at design and support separation rules with service level agreements.”
Identity federations, along with authentication and access standards – like OAUTH, XACML, SCIM and SAML – are being designed today to meet access needs, according to Eric Olden, CEO of identity and access management vendor, Symplified. “Access control, authentication, audit and administration all apply to cloud and web applications,” says Olden.
Encryption of sensitive data should also be tied to authorization, say industry experts. However, according to a survey by the Cloud Security Alliance released in November, encryption offerings in the cloud are not as robust as they should be. The report, sponsored by Trend Micro, recommends several layers of encryption for data in transit and in storage, and the need for key management.