In the early days of business computing, data was shipped fromcorporate locations to a central server. To spare enterprises thehands-on control of the process, third-party service providers handledthe freight. Today, that same business model for massive off-site datastorage and application delivery has a more nebulous name: cloudcomputing.
A new name, larger server farms, often unknown locations of theso-called clouds — the process is almost like online banking,where you never actually visit a physical location to check on yourdeposits and make hands-on cash withdrawals.
Cloud computing entails more than mere long-distance data storage, however. It also involves the use of Web-based applicationsthat come from someplace beyond a corporate server. Cloud computing,in addition, can carry with it a security risk.
For the cloud customer, it’s often been understood that the service provider andthe application developers take care of safeguarding customers’ data.However, too many major data breach disclosures in recent years have fueledworries about data security.
These security concerns are no longer small worries for companiesthat trust their computing integrity to the clouds. Webapplication security concerns have become the basis of an ongoingdebate for which no clear winning argument has yet resulted.
Developers with an eye on security say the only way toeliminate vulnerabilities in Web applications is to build them fromscratch rather than apply code fixes and third-party security layersto existing applications. However, a major industry of security productshas grown around different ways to plug the security holes found in Webapps, adding justification for the legitimacy of thebuild-it-then-secure-it philosophy.
“Building from scratch is no silver bullet. Developers have to facethe security problem the way it is,” Mandeep Khera, CMO of Cenzic, told TechNewsWorld.
The build-it-from-scratch approach is the stance taken by an industrygroup known as the “Open Web Application Security Project” (OWASP). The group offers a toolbox of kits and sponsoredprojects to help IT workers and app developers find and fix securityholes.
“It is critical that program developers build security in. Theproblem is that most apps already in use are in maintenance mode.Existing apps need to be tested,” arguedKhera.
Not everybody buys into that argument. By the time companiesinvest in a product and have it in use throughout an organization,it is too costly to deal with a hunt for security holes. Manycompanies cannot take the time, effort and risk of taking theirmust-use applications offline.
“I don’t agree that we need to start over and ‘build’ fromscratch. I am confident that Web and more importantlyapplication-based protection will be a driving technology for manyenterprises. They can’t control what’s going on within the cloud, butthey can certainly protect the data that is being passed back andforth,” Ken Pappas, president of True North Security, told TechNewsWorld. .
What to Do?
For companies using a legacy Web app, a Web application firewall(WAF) could be the alternative to the build-it-from-scratch strategy.This is an appliance, server plugin or filter that protects the dataprocessed by the Web app by applying a tailored set of rules totraffic entering and leaving the application.
The rules provide protection against specific types of data attacks.For instance, the WAF can identify and stop cross-site scripting (XSS)and SQL injection. By customizing the rules to your application, manyattacks can be identified and blocked. However, WAFs are notset-it-and-forget-it tools. They must be customized and maintained as theWeb app is modified.
The alternatives seem cut and dry choices. If users or Web appproviders question the security of the product, they can replace it orbolt on a stop-gap measure like a WAF. However, the better solutionmight very well be doing both. That’s the middle ground suggested by thePCI Security Standards Council.
“The answer depends on how critical the app is for the owner.Sometimes doing both is the only real option for security, especiallyfor a large organization,” Georg Hess, CEO and founder of Art ofDefence and OWASP member, toldTechNewsWorld.
Too Little Too Late?
It is somewhat odd that the computing industry is only now focusingon better security as enterprises turn to Web applications. Perhapsthe growing prominence of cloud computing in business will put bettersecurity measures in place.
“Many companies for several years now have been utilizing thistechnology [Web apps from the clouds] without thinking of the securityramifications. Take for example Salesforce.com.This Web-based application and the company’s data have been passing apublic network infrastructure for years with little to no concernregarding data security,” alleged Pappas.
The industry is entrenched with the business practice of Web-basedapplications and data that reside elsewhere beyond its corporatewalls, he added. Even worse, the industry is facing a chicken-or-the-Egg mentality when it comes to Web app security and cloud computing.
“Really now, are businesses concerned with the concept of cloudcomputing or the fact that applications are Web-based? What should bemost important within enterprise networks is the fact that [it] istheir data that transverses and is stored outside the glass house,” he warned.
Cloud and Web-app providers need to build tightnetwork and data protections within their infrastructures, Pappas said.Until then, it will be too risky for any company to leave its assetsat a third-party premise.
Another alternative is to fix what is broken and move on from there,advised Khera. Doing so will involve a two-step process to close theholes in any application.
The first step is finding the holes before the job becomes the equivalentof patching the roof to keep the rain out. The second step isprioritizing the timeline for patching the most critical holes found.
“The issue is too important to ignore. Until all the holes areplugged, the application is vulnerable,” he cautioned. “You can’tavoid the process. The timing is critical.”
Perhaps the ideal place for the built-in security process to begin iswith the app developers themselves. For that to happen, developersneed to consider the software shelf life, according to Hess. Still,more is involved than just shelf life.
“An application is not done with the first version. But code writingexpertise is needed for a company to review the security reliabilityof Web apps. The process has to start with the application developer. It is notcommon to see schooling in Web security,” said Hess.
That is one of the major reasons for the current security troubles — too few have skills in security. A general lack of education in security isat the root of the problem, he said.
Playing Catch Up
“It takes both time and money to build secure apps. That’s thechallenge,” Hess said.
From a security perspective, it is actually better to have somemethods for checking security of the code in the development phase.However, most of the industry is not yet there, Hess complained.
Developers that rush their apps that were in production yesterdayexpose companies that use them today to new attack vulnerabilities.Developers need some reaction time to fix security holes, he noted.
Then they need a timeframe to deploy patches. This process ofdeploying patches can take from two to four weeks.
That brings the debate full circle. With the Web application firewallin place, companies running a hole-ridden cloud app will beable to bolt on a stop-gap measure of security and possibly forestalla damaging data breach.