Total security of applications is probably a pipe dream. However, starting a secure design framework today will markedly improve applications in the future, reports Deb Radcliff.
Applications are anything but static. They may start out with one set of functions, then elements are added on and merged with other applications. As they grow more complex, their vulnerability density increases – a particular problem for applications hosted on the web and migrating to the cloud.
“Web applications are the top attack target because they're so difficult to protect,” says Jim Manico, volunteer connections committee chair for the Open Web Application Security Project (OWASP), and VP of security architecture for WhiteHat Security. “Today, cloud deployment is all web driven, meaning cloud and web application vulnerabilities are on a direct collision course.”
Developing a “secure by design” framework for these technologies is challenging enough, says Michael Coates, volunteer OWASP chair and director of security assurance for Mozilla. Once developing organizations get their new applications under a trusted framework, the next hurdle is maintaining a safeguard posture as those applications change over time and move into the cloud.
Already struggling to ensure their web applications are protected, the majority of security and compliance professionals believe the current trend of deploying to the cloud invites further vulnerabilities, according to a 2011 data security in the cloud survey of 1,000 security and compliance by the Ponemon Institute and encryption vendor Vormetric. In the survey, less than 40 percent of respondents trust their own technologies to secure their sensitive data in the cloud – and less than one-third encrypt their sensitive data in the cloud.
Further, encryption is a cornerstone design point that should be considered in applications with sensitive data, yet it is one of the most difficult processes to achieve in the cloud, say experts.
What other elements are needed in a secure design plan? It depends on who you ask, what vertical industry they are in, what type of cloud or web services they're designing, and so much more, say Manico and Coates at OWASP.
However, there are several common design areas to focus on that apply to both web and cloud applications. This includes gathering business requirements; development and testing; access, authentication and data protection; configuration and zoning; visibility; and maintenance and continuity.
Development
Applications are written and upgraded by different coders at different times, and usually with no master plan, say experts. They contain a patchwork of code, objects and platforms with known vulnerabilities, such as might be found in HTML5, various flavors of Java, PHP, Ruby on Rails, iFrames, and more.
With these applications going virtual, into the cloud and even mobile, secure design must include ways to test the application before it's even developed, then during and after development, says Gary Phillips (left), board member for SAFECode, and senior director of technology assurance research at Symantec.
SAFECode, which stands for Software Assurance Forum for Excellence in Code, is supported by other large developers (including Microsoft, Adobe, SAP, Juniper Networks and Nokia) to advance best practices for more reliable software, hardware and services.
According to Phillips, secure code development practices are on the rise among commercial vendors. And, this is substantiated by a decrease in web application vulnerabilities, according to the latest “IBM X-Force 2011 Mid-year Trend and Risk Report.” For the first time in six years, the number of web application vulnerabilities declined, from 49 percent to 37 percent, of all vulnerabilities reported in the first half of 2011, compared to the same time frame the previous year.
On the other hand, the number of vulnerabilities listed as critical tripled, while the report authors expect mobile exploits to double in 2012. SQL injections, XSS, input validation and numerous traditional attack methodologies are still prevalent in web applications, says Jack Danahy (right), director of advanced security at IBM. These, he adds, should not be migrated into the cloud.
“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.
Configuration
“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.
“Any design plan must take the posture that the system will be breached and that the data inside will be accessed,” says Mark Bower (right), VP of product management at Voltage Security. “This is particularly true for payment transactions, which are essentially cloud-based services to merchants.”
According to Bower, authentication should be tied to data encryption to limit exposure of the full live data – especially with new techniques, like format-preserving encryption.
“Encryption should also be used to protect live data from authorized users,” he says. “For example, to verify a transaction or to match a customer to an account, an operator may only need to see the last four digits of a Social Security number or the last section of a credit card number versus the complete field.”
By now, most organizations should be encrypting their sensitive information in a datacentric manner, which means sensitive material stays encrypted at rest, in transit and in use. If organizations are migrating to an IaaS where they're responsible for their applications, it may suffice to replicate the same technology in the cloud through standards-based APIs.
If purchasing software-as-a-service, organizations should discover how the provider will help them carry their encryption and, in particular, key management over into the cloud. For example, Voltage manages keys in the cloud for Voltage Cloud Service-based file and email encryption customers. Alternatively, enterprises may want to control their keys themselves with on-premise key servers for their applications in the cloud.
When considering application deployment to the cloud, the specific type of hosting environment will determine who and how security capabilities such as encryption and monitoring will be supported, says OWASP's Manico.
For example in the IaaS model, the organization acquiring the service is responsible for its own applications. With SaaS (software-as-a-service), the provider manages the applications for the consuming organization. SaaS also can manage security applications in the cloud for the consumer, as well as offer new security services to the consumer.
Visibility and maintenance
Fuzzing, static analysis and functional testing are also critical during key stages of development and after the application has been put into production. So design must include stages for testing the application during design, development and post-production to maintain the application's security posture.
That means design must include basic monitoring support, such as producing usable logs and registering changes to data and access, says Symantec's Phillips. “To build trust, monitoring is very important, so you must have a close view of your system and access logs, as well as activity that occurs around the data,” he says.
There are numerous tools and services to test web applications for SQL injections, XSS and other code-based and functional vulnerabilities. However, when it comes to visibility into applications in the public cloud, organizations must rely on monitoring tools supported by their cloud provider to monitor their own data, say experts. To keep an eye on their provider's network, they will need to rely mostly on contracts and annual audits.
Getting to secure design will take planning, time and coordination between business, development and security units. But the task is not impossible, many say.
“No one says secure by design is a quick architecture change that makes an application ready for the web or the cloud,” IBM's Danahy says. “If it were easy, there would already be a common secure design template that everyone can use.”
[sidebar 1]
Secure design resources
Finding guidelines that apply to developers is easier than finding guides for designers and planners, but they do exist. Here are some examples:
The Cloud Security Alliance has many helpful guides for developing and implementing to the cloud at , including:
Security Guidance for Critical Areas of Focus in Cloud Computing – delineates cloud types and components and a means to map risk around key focal areas of architecture, government and operations
A Cloud Controls Matrix spreadsheet listing control areas, specifications, and architectural components for providers and consumers of cloud services
Toolkits to assess public, private and hybrid cloud environments
The Open Web Application Security Project (OWASP) has a popular code review guide that connects the dots between security, design and business contexts. Other popular resources include:
- Security cheat sheet for developers
- Threat modeling guidance
- Secure coding and testing guidelines
The Software Assurance Forum for Excellence in Code (SAFECode) has recently published the second edition of its Fundamental Practices for Secure Software Development. Other resources, include:
- Software assurance for supply chain applications
- An overview of software integrity controls
- Software security engineer training
[sidebar 2]
Secure design points
No matter where the application resides, basic design frameworks apply. In the case of Symantec, development teams follow these basic design principals:
1. Data re-validation and protection at trust boundaries
Data transfer across trust boundaries, such as between two processes at differing privilege levels or two separate computers, must be protected. Data must be validated for type, range of values, size and semantics at both the client as well as the server. Data protection can be implemented using a tamper evident mechanism such as digital signatures.
2. Mutual authentication of service and user agent
Because many untrusted entities are involved in the interaction between a user agent and a service, the user agent and service must establish mutual authentication, which is best achieved through PKI and multi-factor authentication.
3. Prevent eavesdropping - strong encryption
Sensitive and critical data can be exposed by the untrusted entities between the user agent and the server. FIPS 140-2 compliant encryption algorithms must be used for data in transit. Sensitive data must be encrypted even when at rest. Passwords must be securely hashed to make brute-force decryption more difficult.
4. Short session timeout and one-time passwords
Long lasting sessions can lead to replay attacks and session hijack. Especially for cloud-based applications, one-time passwords and short session timeouts significantly mitigate this type of vulnerability.
5. Least privileges
Multiple components making up the application must be granted the minimum set of permissions and resources to perform the task to reduce risk of an attacker escalating privileges.
6. Compartmentalization
Tasks requiring different sets of permissions and resources must be isolated to mitigate resource exhaustion and denial of service vulnerabilities.
