Software Security and SOA: Danger, Will Robinson!


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software Security and SOA: Danger, Will Robinson!

  1. 1. Building Security In Editor: Gary McGraw, Software Security and SOA: Danger, Will Robinson! T he current buzzword of choice among the technical from specific calls to APIs toward larger globs of data+state messaging elite (at least those subject to marketing depart- built out of XML. In some cases, the transmission bus itself does all the ments) is service-oriented architecture, or SOA (pro- necessary data restructuring to allow different services to communicate. nounced “SO-uh”). As SOA moves from hype to What about security? practice, an opportunity exists to do security right, but a similar It almost goes without saying that large enterprises are obsessed with se- J EREMY opportunity exists for disaster if se- useful. However, past architectural curity and securing their critical ap- E PSTEIN curity is done wrong. This article paradigms have had to deal with plications—their essential data are at webMethods describes 13 snares that we must three common problems: stake. Any move toward SOA pre- avoid to end up with SOA security sents a prime opportunity to build se- SCOTT that makes sense. • inability to create composite ap- curity into future applications. MATSUMOTO plications nimbly (with parts But with every opportunity AND GARY SOA what? borrowed from multiple large comes a danger of seriously screwing MCG RAW Getting to the bottom of exactly enterprise applications), things up. Early SOA adopters are al- Cigital what SOA is might seem a bit • difficulty in defining clear services ready falling prey to bad thinking daunting, especially given the based on encapsulating myriad di- about security. The biggest problem acronym-laden, hype-induced hy- verse APIs from large enterprise by far involves confusing software perbole floating around the Inter- applications, and security with security software (note net. The buzz about SOA today • problems in containing and the word order). As this department reminds us of the buzz about Java in managing services in a centrally emphasizes, security isn’t a feature. the mid 1990s—only somehow reasonable way, leading to the pro- Just as you can’t sprinkle crypto fairy even more vague. Will it really clean liferation of closely related but dif- dust on software to make it magically everything up and send it off to col- ficult-to-manage clones. secure, you can’t liberally apply lege? The real question is whether crypto to SOA and end up with se- there’s even a bottom to get to. It SOA promises to address these three curity. Crypto is security software; seems as if SOA amounts to a Web problems in one fell swoop, by what we want is software security. services-based architecture that re- defining language- and hardware- Those considering SOA would lies on a data-driven XML model. independent protocols and repre- do well to give close consideration The notion is to provide various ser- sentations for loose coupling of to the inherent security of the Web vices over an enterprise bus that software components. services platform, as well as to the many diverse applications can access Ultimately, a Web services-based services themselves. SOA presents and use remotely. As you might SOA also seems to be a relevant tar- an opportunity to avoid or other- imagine, doing this right involves get for many enterprises. The differ- wise manage security flaws that knowing plenty about how the bus- ence between a random collection pervade software architecture (ac- iness actually works and thinking of Web applications and a SOA counting for 50 percent of the soft- clearly about what architectural approach lies mainly in the use of a ware security problem).1 components make sense. common XML-based data model In the messy real world of enter- An enterprise information archi- and an intelligent transport/trans- prise applications, vendors typically tecture that’s aligned with business is mission bus. Think of moving from highlight the primary security fea- a good thing, and to the extent that an RPC-centric model to a docu- tures that they offer as a key selling SOA’s adoption helps with this ment-centric model to grok the dif- point. However, outside the list of alignment, the SOA itself will be ference: message granularity shifts mandatory security features, few 80 PUBLISHED BY THE IEEE COMPUTER SOCIETY ■ 1540-7993/06/$20.00 © 2006 IEEE ■ IEEE SECURITY & PRIVACY
  2. 2. Building Security In vendors can attest to the underlying they need to build security in. rity touchpoints1 and thinking security of the product itself. Thus, • Not asking about security at all. Many about security during design and users might have all the security fea- IT organizations (even in large implementation. tures in the world, but they remain companies) have no dedicated in- • Allowing discomfort with the technol- untenably insecure. ternal security staff. Even in or- ogy to overcome the need for software The challenges of insecure soft- ganizations with great network security. Most network security en- ware grow with the move to SOA, security staff, little or no attention gineers feel comfortable with the which by its very definition exposes is paid to software security. Be- bits and bytes of routers, firewalls, software vulnerabilities more widely cause SOA is about software archi- and operating systems, but few than ever. Heck, given the Web Ser- tecture, security might not be know much about the security of vices Description Language (WSDL) something that even comes up. enterprise business applications or and universal description, discovery, • Asking about the wrong kinds of secu- the SOA itself. As a result, they and integration (UDDI), gaining rity things. On one hand, IT secu- tend to ask about the aspects the information you need as a mali- rity personnel are likely to believe they’re familiar with—such as use cious attacker to perform a software in the religion of the firewall; in of SSL—and ignore the harder exploit is now easier than ever. In fact, SOA has already engendered questions like, “How can you this scenario, a variety of standards its own firewall sect. However, re- demonstrate to us that this product might take the place of arbitrary and active approaches haven’t worked is secure?” Getting outside your often-broken home-grown security out very well for security, and technology comfort zone is often features, but the results remain the they’re not likely to start working elucidating and educational. Do it. same because the services themselves soon. On the other hand, software • Relying on a cursory risk assessment. suffer from shoddy construction. people are likely to fall square into Smart organizations know how By understanding the common the “security software” hole. As to manage risks, and they make snares we list in the next section, we said earlier, security features conscious decisions about where those enterprises considering SOA alone don’t make for software se- to focus their limited resources. technology can ask better questions, curity. Building secure software Some believe that even if their such as, “How do I know that SOA means applying the software secu- SOA framework has security product 57 is secure?” and “What kinds of measures have been taken to avoid software security defects?” Thirteen security snares Without further ado, let’s get into that list: • Assuming the vendor will take care of security. When you buy a new car, you don’t ask about the engineer- ing processes used in the design; you assume that Ford or Toyota knows more about how to design cars than you do. Of course, gov- ernment oversight helps with car safety, but because there is no such oversight on software vendors today, you can’t assume that ven- dors will take care of it. They have a propensity to “check off the se- curity box” by throwing in some crypto features and calling it a day. Even SOA security vendors such as Vordel and Reactivity are focus- ing their attention on reactive ap- proaches instead of telling people ■ IEEE SECURITY & PRIVACY 81
  3. 3. Building Security In flaws, the odds of those problems many security problems have Thus, the opportunity to consider being detected and exploited is turned up in a given product and software security is missed. Don’t far lower than the odds of an at- how severe they are. Rather than leave security for later—ever. Iron- tack through an unpatched router asking the vendor directly about ically, the “security as a feature” ap- proach at least opens the door to a discussion of security. Everyone’s heard that old chestnut, ‘We’re • Believing security is somebody else’s job. This could be a variant of safe because we’re behind the firewall,’ and “assuming that the vendor will take care of security,” or it could be in too many organizations, this is treated a symptom of an organization in which security specialists aren’t re- as gospel. sponsible for the security of the development systems in use. Soft- or Web server. Today, evil people security, some security engineers ware security is everybody’s job. are attacking commodity net- incorrectly rely on public metrics By involving development in se- work products more often than such as the number and severity curity, we cut through the myth of customer-specific Web services, of publicly reported bugs to security by firewall. but this is quickly changing. Soft- determine the product’s quality. • Giving up hope. The security spe- ware security is becoming in- Whether these metrics are corre- cialist (if there is one) knows that creasingly important because lated with actual product security he or she can only say “no” so attackers are changing their tar- remains an open research ques- many times and only has a limited gets—risk assessments shift over tion. A better idea is to ask a amount of influence over pur- time to account for an attack’s vendor questions about security chasing decisions. Why spend the probability for a reason. What- assurance in their SDLC: do they time questioning a vendor or ana- ever you do, don’t forget about use the touchpoints?1 lyzing a SOA platform’s security software security and software • Trusting the vendors (too much). Ven- when his or her actions are un- flaws during risk assessments. dors might intentionally or unin- likely to impact the procurement • Believing you’re secure for no apparent tentionally give inaccurate results. or deployment decision? For this reason or for the wrong reasons. A vendor who performs penetra- person, it seems easier and better Everyone’s heard that old chest- tion testing, for example, might to use any silver bullets to influ- nut, “We’re safe because we’re be- not have tested the product or ver- ence a critical piece of security in- hind the firewall,” and in too sion being considered, thus the frastructure. Don’t give up hope. many organizations, this is treated testing’s value might be reduced. The only way we’ll fix the security as gospel. Because Web services But some data are more useful problem we’re in is by building tend to be implemented on than others. Does the vendor better software. servers inside the organization, review code with source-code • Putting too much weight on security worry about their inherent secu- analysis tools such as those from standards and security features. Stan- rity is often discounted, but the Fortify, Secure Software, or dards such as SSL (for Web ser- fact remains that most firewalls Ounce Labs? What kinds of results vers), S/MIME (for email), and will simply pass along a Web ser- can the vendor show you? WS-Security (in the Web services vices request, including any attack • Building a proof of concept that ignores space) are widely perceived to pro- code. SOAP is the attacker’s security “for now.” SOA gurus vide security. Too many organiza- friend, and the age of the firewall recommend the “start small and tions fail to understand that is drawing to a close. The very grow” approach to re-architecture. although these standards are im- idea of SOA is to promote reuse This approach most often results in portant, they don’t actually do and repurposing of common a proof-of-concept application that anything to secure a system. An functionality; it’s about external- acts as a test of some framework or implementation bug or an archi- izing the data schema and thereby collection of vendor products. Fre- tectural flaw in a product can leave further erasing the distinction be- quently, security isn’t a requirement a system that’s completely stan- tween “inside” and “outside.” in this proof of concept, and tech- dards-compliant completely inse- • Misapplying vulnerability metrics. nical issues other than the func- cure as well. Use a discussion of It’s easy enough to search data- tional success of the proof of security features as a flying wedge bases of vulnerabilities (such as concept aren’t revisited before a to talk about more intensive soft- the CVE or BugTraq) to see how procurement decision is made. ware security assurance. 82 IEEE SECURITY & PRIVACY ■ JANUARY/FEBRUARY 2006
  4. 4. Building Security In • Doing it all yourself. To end this list as the touchpoints, that helps iden- vices on top of these platforms on a positive note, some organiza- tify security problems before they should take an equal responsibility tions don’t ask the security ques- occur,1 and and introduce rigor in their design tion because they plan to come to • other third-party reviews. and testing, so that the resulting Web their own conclusions by per- services don’t become the “hack forming their own hard-core Unfortunately, there’s no single an- me” locations of choice. analysis and testing. Good! swer to how much is enough. By asking SOA vendors, “How Should vendors be expected to do you know your product is se- Despite the failure of users to ask meet all or most of them? How do cure?” organizations will raise the bar about software security when it we prioritize between competing for software security. comes to SOA, vendors are actually claims? How should we compare quite willing, able, and, in many two months of security-focused Acknowledgments cases, eager to provide improved se- QA, for example, to a week of auto- We thank John Steven of Cigital for his in- curity in their products. In other matic code analysis? Is a product that sights on SOA security and the 13 SOA se- words, there’s adequate supply. The has undergone a BITS (www. curity snags. An earlier version of this article problem is that there’s insufficient evaluation appeared as “Software Security Supply in demand, at least as expressed in buy- more secure than one in which all Demand,” Web Services J., vol. 5, no. 11, ing decisions. developers are trained on software 2005, pp. 26–27; security touchpoints? WebServices/WSJNov2005.pdf. All for SOA, SOA for all In reality, these questions aren’t Why don’t we ask the security ques- that different from those raised in the Reference tion of every software vendor we procurement cycle, such as the trade- 1. G. McGraw, Software Security: Building interview (SOA or otherwise)? In off between cost and performance, Security In, Addison-Wesley, 2006. many cases, the decision to do so could with one exception: these are the Jeremy Epstein is a senior director of be entirely reasonable. Whenever we criteria that aren’t typically assessed in product security at webMethods, a look at a vendor, we should make an a formal manner as part of the provider of business integration and Web explicit decision whether the product’s process. It’s important to remember services software. His research interests security is important, and if not, docu- that no evaluation process guarantees include methods for improving software quality in commercial software and secu- ment why it’s not. For many organiza- a product’s success, but it does help rity for e-voting systems. Epstein has a BS tions, our 13 SOA security snares improve the odds of success while in computer science from New Mexico could be the right starting point. providing us with additional recourse Tech and an MS in computer sciences For those vendors from whom we should issues arise. Following a from Purdue University. He is a senior member of the IEEE and a member of want and in fact need to know how proof-of-concept exercise, for exam- Usenix. Contact him at jeremy.epstein@ secure the product is, we need to ple, we can feel relatively certain that know what to ask and how to assess we’ve identified reasonable perfor- the answers. Among the measures a mance. By extending a product’s un- Scott Matsumoto is a principal consul- tant at Cigital in the enterprise archi- software vendor might use to increase derlying security to similar scrutiny, tecture practice. His research interests the robustness of their products we can not only improve the likeli- include DSLs and development tools. against security failures, you should hood that a vendor product won’t Matsumoto has a BA in physics from look for some of the following: expose a security breach within the Lawrence University. Contact him at enterprise, but also provide greater • strong security involvement in ar- insight into its security architecture Gary McGraw is chief technology officer chitecture or design, so that we can more readily bolster of Cigital. His real-world experience is • good software engineering prac- any uncovered shortcomings. grounded in years of consulting with tices, major corporations and software produc- ers. McGraw is the author of Software • security-focused quality assurance Security (Addison-Wesley, 2006), and (QA), • penetration testing, • automated vulnerability testing, F or organizations building SOA via Web services, solving the se- curity problem requires both a se- coauthor of Exploiting Software (Addison-Wesley, 2004), Building Secure Software (Addison-Wesley, 2001), Java Security (John Wiley & Sons, 1996), and • manual or automated source code cure SOA framework and securing four other books. He has a BA in philoso- analysis, the Web services themselves. Pur- phy from the University of Virginia and a • defect density prediction, chasers of Web services platforms dual PhD in computer science and cogni- tive science from Indiana University. He’s • developers trained in software can and should ask their vendors also a member of the Board of Governors security, about how they secure their plat- of the IEEE Computer Society. Contact • a development methodology, such forms. And developers of Web ser- him at ■ IEEE SECURITY & PRIVACY 83
  5. 5. DON’T RUN THE RISK. BE SECURE. Ensure that your networks operate safely and provide critical services even in the face of attacks. Develop lasting security solutions, with this peer-reviewed publication. Top security professionals in the field share information you can rely on: • Wireless Security • Securing the Enterprise • Designing for Security Infrastructure Security • Privacy Issues • Legal Issues • Cybercrime • Digital Rights Management • Intellectual Property Protection and Piracy • The Security Profession • Education Order your subscription today. Submit an article to IEEE Security & Privacy. Log onto Manuscript Central at