When information warfare experts want to set the proper base line for whats “secure,” they point out that the only completely protected machine is one thats disconnected from the network and preferably turned off. Application development security begins from an equally useless zero point: The only completely secure application is one that accepts no input from the outside and offers no access to data.
Everything beyond that null-and-void level of IT system function demands a balance between business benefit and information risk. That balance is getting more difficult to define, let alone achieve, as the expectations of application users rise while the risk environment becomes continually more dynamic.
Two factors intensify the hazards facing enterprise development professionals. First, the growing dominance of Web-enabled applications exposes developers finished products to a vastly larger army of attackers. Second, the rapid development cycles of customer-facing or supply-chain-partnering software mean that most new code is never really finished at all.
“People are continuously updating the code—theres no way to do a full code review,” said John Dickson, a partner in Denim Group Ltd., a development consultancy based in San Antonio. “Youd have three or four reviews every week.”
Past development practices—with almost seasonal cycles of code specification, design, development and review—do not have a sterling reputation for producing secure results, but at least they presented only a few discrete points each year at which new vulnerabilities might be expected to appear. The continuous development of a Web site—or the kaleidoscopic, continual reshuffling of Web services constellations—must fundamentally change the security posture of the enterprise development team.
Security must be built into applications from the lowest level upward, rather than applied as a hard outer shell, because a focus on perimeter security ignores the fact that many intruders are already on the inside.
In fact, more than 80 percent of companies have detected system penetrations of internal origin, according to data compiled by insurance brokerage and risk management company Arthur J. Gallagher & Co., in Itasca, Ill. This means that applications performing their normal function, at the behest of authorized internal users, must be viewed as dwelling in hostile territory rather than in trusted environments.
Next Page: The front door is open.
The front door is
open”>
“People just dont realize how vulnerable their applications are,” said Denim Group partner Dan Cornell. “Theyve been looking at the host level so long, and they dont realize that its not their back door—its their front door thats wide open.”
Security practices that have grown up from a network-centric view, with a focus on concrete IT assets to be protected, must be turned sideways and inside-out to focus instead on protecting business function and efficiency. Close attention must also be paid to satisfying a growing list of stakeholders, as IT security becomes both a political football and a public relations hot potato.
“Everyone has their own set of security requirements,” said Richard Tracy, chief security officer at Xacta Corp., in Ashburn, Va. A modern security posture, Tracy said, differs from mere vulnerability scanning because “it starts with the question, What are you measuring against?” Xactas IA Manager product “forces you to account for requirements: We calculate a risk posture based on a variety of parameters,” he said.
When development teams play expanded security roles, their first obstacle may be as simple as differing definitions of familiar terms.
When a firewall vendor talks about protecting “applications,” said John Amaral, chief technology officer at Network Engines Inc., in Canton, Mass., “theyre talking about the seventh layer of the [OSI] model—things like HTTP.” To the enterprise developer, those so-called applications are mere protocols, Amaral said. Protecting them does nothing to protect the enterprise against vulnerabilities at the higher levels of business process that a development team seeks to enable.
Protecting the most value-adding levels of the enterprise application stack has to mean something that most network-oriented security tools arent designed to address, Amaral said. “Do they protect what goes in and out? Do they protect the traffic?” he asked. “Or do they protect the sequence of actions or the settings in which the application is conceived or the inherent vulnerabilities in how the application was coded?”
The latter question, he said, is by far the most important to be answered by the security-oriented development team.
When a team allows its focus to drift downward into the plumbing of the network, instead of remaining at the level of the business mission, the result is not merely ineffective but actually detrimental.
“Good security at the application layer knows who you are and where youre supposed to go,” said Ken Evans, product management vice president at Fortress Technologies Inc., in Oldsmar, Fla.
Security wrapped around the application can actually have a counterproductive effect, Evans added. When everyone knows that an application is not itself secure, the result is that security is added at the level of the network connection to that application, he said.
When security is defined by the characteristics of the connection rather than by the needs and privileges of the user, then a single user may encounter different application capabilities depending on whats supposed to be a transparent choice among different modes of access.
“This user today is less trusted because theyre coming in on wireless? Thats unnecessary paranoia, and it leads to the user not using the application as it was intended,” said Evans.
A user who cant perform data entry from the field without going through a cumbersome added security process may very well decide to wait and perform that task back at the office, said Evans. The result, he suggested, often may be the loss of the improved accuracy or timeliness that was sought by making a wireless investment.
The guiding principle for application architects should be “one system, one security,” Evans said.
Based on eWEEK Labs observations of how users behave and how attackers exploit that behavior, we would agree: A properly authenticated user interacting with an application that has properly limited access to enterprise data should have the same privileges regardless of the type of connection being used.
Wireless connections must be adequately secured, to be sure, to offset the ease of access that a potential eavesdropper enjoys without the need to tap a wired link. Perversely, though, said Evans, the awareness of wireless vulnerability often can lead to a situation in which wireless users are more effectively authenticated—and their interactions more carefully bounded—than wired users. “People need to start looking at a converged network,” Evans said.
Next Page: Guarding against guided attacks.
Guarding against guided attacks
Developers may also fail to understand the demands of application configuration management when the enemy is not mere chaos but an actively guided attack. Developers may feel that theyre doing their job, for example, by carefully maintaining a traceable record of application versions, while failing to appreciate the open book that an older and insecure version of an application may provide to a successful snooper.
“Configuration management for Web-based applications is terrible, by and large,” said Denim Groups Cornell. “In a file-based application environment, people will leave an old file in place and just rename it.”
A current application may now be much more securely designed, but an earlier version—perhaps accessible in a poorly secured archive—may give an attacker all the information needed to overcome that improvement.
Death before disclosure
One of the notable positive trends in application development is increasing attention to data validation, in rigorous terms, at every stage of application function.
“You need a validation function for everything that comes in,” said Adam Kolawa, co-founder and CEO of Parasoft Corp., in Monrovia, Calif. “And that represents a security policy.”
Makers of coding aids, including Parasofts Jtest and Agitator Software Inc.s Agitator, have joined in urging developers to adopt the conservative doctrine of test-first development. This approach defines every aspect of application behavior by an explicit test that is intentionally failed—to ensure that its catching the possible problem—before the code thats needed to pass that test is added to a work in progress.
Typically, one of the language constructs thats used to strengthen an application in this way is an exception-triggering test that fires if data is other than whats expected. However, this can backfire, so to speak, on the developer.
“The first thing crackers do is try to put the application into a funny state and see what it prints,” said Parasofts Kolawa. “Whenever you throw any exceptions, make sure that you control the information thats sent up—not just print the entire stack trace.”
The border of validation must also be pushed further outward, Kolawa said, because applications rely on external logic components such as XML parsers. Older parsers, or parsers built on open-source foundations and optimized for particular tasks, may be vulnerable to “XML bombs” (sometimes called SOAP bombs to reflect their abuse of Simple Object Access Protocol mechanisms). These attacks overwhelm a machine with a carefully malformed data structure that essentially explodes into a hugely resource-consuming result as its processed on its way into an application.
The effect may be as benign, relatively speaking, as a simple DoS (denial of service) attack. A more carefully constructed attack may create a specific buffer-overflow state in which malicious code can be inserted to hijack an entire system. XML-level protection must therefore become part of the development teams arsenal. Relevant products include the Reactivity Gateway appliance from Reactivity Inc. and the Forum XWall from Forum Systems Inc.
Whatever the battleground, warned Kolawa, its essential as a matter of developer productivity to place the emphasis on prevention rather than detection. “These are very well defined, logical errors,” he said. “You can fix them, but its better practice to prevent them. Finding errors is very difficult to do—its difficult to inject something and see where it comes back. Its easier to prevent it.”
Next Page: Hiding problems is not prevention.
Hiding problems is not
prevention”>
A warning, however, came from a separate conversation eWEEK Labs had with Network Engines Amaral, whose experience suggests that developers may have a dysfunctional idea of what it means to “prevent” a security problem. Its not prevention, he said, when developers adopt practices that hide problems rather than kill them.
For example, developers use S-HTTP (Secure HTTP) “to ease deployment, to avoid creating added work, and use a protocol thats generally not inspected,” Amaral said. “Theyve leveraged an exploit.”
Early last month, though, three application firewall vendors—Teros Inc., NetContinuum Inc. and Imperva Inc.—threw down a challenge to other security vendors to submit their products to independent testing by International Computer Security Association Labs (a division of TruSecure Corp.) to determine their effectiveness against application-level attacks. Theres considerable room for confusion in this space, and eWEEK Labs tends to eye with approval anything that condenses the vapor of marketspeak into the substance of proven capability.
Old-code growth rings
Another serious threat to dynamically evolving applications is the long-lived presence of code remnants, each perhaps the contribution of a different generation of development team and technique.
“One line of code can make an application vulnerable,” said Denims Cornell.
“[In] a bank portal that was ready to go into production, there were three or four pages in an obscure subdirectory that had SQL statements that would admit actual code. We saw them using stored procedures and figured that theyd be mostly OK, but when we ran the tool, we found obscure pages that werent high-value targets but that had very serious flaws,” he said.
“Even if theres 40,000 lines of code and you just change one, it could create a SQL injection opening,” said Denims Dickson. “Conventional quality assurance approaches wont catch that.”
Denim employs an application-level vulnerability scanner, ScanDo, from Kavado Inc., to automate its end-to-end analysis of complex systems. Cornell acknowledged the conventional wisdom that “its 100 times cheaper to catch a mistake at design time” but said that with Web applications, often its not possible to say that a vulnerability exists until the entire system is running front to back.
An automated scanner also helps developers avoid the blind spot that comes from knowing what an application is supposed to do and what kinds of input it expects to receive. “Most of these hacks are definitely unexpected behavior,” said Jeannine Bartlett, Kavados vice president of strategy.
Most developers dont make adequate use of the Common Vulnerabilities and Exposures data at www.cve.mitre.org. “I was speaking to a group the other night,” said Gary Miliefsky, CEO of PredatorWatch Inc., in North Chelmsford, Mass., “and I said, Raise your hand if you know what a CVE is. No one raised their hand. A developer needs to know when a product is opening a port or using any other resource what vulnerabilities its opening.”
Network Engines Amaral offered another perspective on why there will almost always be a need to seek out rotten code in even the latest release of an application. “Id bet that 50 percent of all the leading applications had their origin in a startup company at one time or another. Its a new idea, and your goal is to build share, and you write software without appreciating its deficiencies.”
Throwing away the “startup code” may feel like throwing away the startup capital, but sometimes it may be a necessary step on the way to offering customers and clients a truly secure application foundation.
Technology Editor Peter Coffee can be reached at peter_coffee@ziffdavis.com.
Security—Developing An Applications View
Accept nonzero risk
- All nontrivial applications grant access to assets
- Web-enabled applications have large attack surface and small opportunity for code review
- Security must be built in at the level of development practice, not added as a network-level embellishment
Agree on terms and goals - What networkers call “applications,” enterprise developers term mere “protocols”
- Casual configuration management practices may leave networks sown with useful clues for attackers
- Hiding application traffic inside protocols such as HTTPS virtually guarantees future breaches
Have the right kind of paranoia - Assume that attackers will confuse applications into bizarre modes of failure
- Minimize leakage of internal application details during any failure scenario
- Dont give users incentive to bypass inconvenient security or do without useful application capabilities
Source: eWEEK Labs
Web resources
- Taxonomy of application threats www.kavado.com/products/threat-protection.asp
- World Bank Technology Risk Checklist www.cyberpartnership.org/world%20bank%20techchecklist.pdf
- Web application security patterns and practices msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/threatcounter.asp
- Error-prevention processes www.devx.com/security/article/20678
- Firewall design considerations loop.introp.com/comments.php?id=226_0_1_0_C
Check out eWEEK.coms for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzers Weblog.