Without further ado, let’s get into that list:
1. Assuming the vendor will take care of security.
When you buy a new car, you don’t ask about the engineering processes used in the design; you assume that Ford or Toyota knows more about how to design cars than you do. Of course, government oversight helps with car safety, but because there is no such oversight on software vendors today, you can’t assume that vendors will take care of it. They have a propensity to “check off the security box” by throwing in some crypto features and calling it a day. Even SOA security vendors such as Vordel and Reactivity are focusing their attention on reactive approaches instead of telling people they need to build security in.
2. Not asking about security at all.
Many IT organizations (even in large companies) have no dedicated internal security staff. Even in organizations with great network security staff, little or no attention is paid to software security. Because SOA is about software architecture, security might not be something that even comes up.
3. Asking about the wrong kinds of security things.
On one hand, IT security personnel are likely to believe in the religion of the firewall; in fact, SOA has already engendered its own firewall sect. However, reactive approaches haven’t worked out very well for security, and they’re not likely to start working soon. On the other hand, software people are likely to fall square into the “security software” hole. As we said earlier, security features alone don’t make for software security. Building secure software means applying the software security touchpoints1 and thinking about security during design and implementation.
4. Allowing discomfort with the technology to overcome the need for software security.
Most network security engineers feel comfortable with the bits and bytes of routers, firewalls, and operating systems, but few know much about the security of enterprise business applications or the SOA itself. As a result, they tend to ask about the aspects they’re familiar with—such as use of SSL—and ignore the harder questions like, “How can you demonstrate to us that this product is secure?” Getting outside your technology comfort zone is often elucidating and educational. Do it.
5. Relying on a cursory risk assessment.
Smart organizations know how to manage risks, and they make conscious decisions about where to focus their limited resources. Some believe that even if their SOA framework has security flaws, the odds of those problems being detected and exploited is far lower than the odds of an attack through an unpatched router or Web server. Today, evil people are attacking commodity network products more often than customer-specific Web services, but this is quickly changing. Software security is becoming increasingly important because attackers are changing their targets—risk assessments shift over time to account for an attack’s probability for a reason. Whatever you do, don’t forget about software security and software flaws during risk assessments.
6. Believing you’re secure for no apparent reason or for the wrong reasons.
Everyone’s heard that old chestnut, “We’re safe because we’re behind the firewall,” and in too many organizations, this is treated as gospel. Because Web services tend to be implemented on servers inside the organization, worry about their inherent security is often discounted, but the fact remains that most firewalls will simply pass along a Web services request, including any attack code. SOAP is the attacker’s friend, and the age of the firewall is drawing to a close. The very idea of SOA is to promote reuse and repurposing of common functionality; it’s about externalizing the data schema and thereby further erasing the distinction between “inside” and “outside.”
7. Misapplying vulnerability metrics.
It’s easy enough to search databases of vulnerabilities (such as the CVE or BugTraq ) to see how many security problems have turned up in a given product and how severe they are. Rather than asking the vendor directly about security, some security engineers incorrectly rely on public metrics such as the number and severity of publicly reported bugs to determine the product’s quality. Whether these metrics are correlated with actual product security remains an open research question. A better idea is to ask a vendor questions about security assurance in their SDLC: do they use the touchpoints?1
8. Trusting the vendors (too much).
Vendors might intentionally or unintentionally give inaccurate results. A vendor who performs penetration testing, for example, might not have tested the product or version being considered, thus the testing’s value might be reduced. But some data are more useful than others. Does the vendor review code with source-code analysis tools such as those from Fortify, Secure Software, or Ounce Labs? What kinds of results can the vendor show you?
9. Building a proof of concept that ignores security “for now.”
SOA gurus recommend the “start small and grow” approach to re-architecture. This approach most often results in a proof-of-concept application that acts as a test of some framework or collection of vendor products. Frequently, security isn’t a requirement in this proof of concept, and technical issues other than the functional success of the proof of concept aren’t revisited before a procurement decision is made. Thus, the opportunity to consider software security is missed. Don’t leave security for later—ever. Ironically, the “security as a feature” approach at least opens the door to a discussion of security.
10. Believing security is somebody else’s job.
This could be a variant of “assuming that the vendor will take care of security,” or it could be a symptom of an organization in which security specialists aren’t responsible for the security of the development systems in use. Software security is everybody’s job. By involving development in security, we cut through the myth of security by firewall.
11. Giving up hope.
The security specialist (if there is one) knows that he or she can only say “no” so many times and only has a limited amount of influence over purchasing decisions. Why spend the time questioning a vendor or analyzing a SOA platform’s security when his or her actions are unlikely to impact the procurement or deployment decision? For this person, it seems easier and better to use any silver bullets to influence a critical piece of security infrastructure. Don’t give up hope. The only way we’ll fix the security problem we’re in is by building better software.
12. Putting too much weight on security standards and security features.
Standards such as SSL (for Web servers), S/MIME (for email), and WS-Security (in the Web services space) are widely perceived to provide security. Too many organizations fail to understand that although these standards are important, they don’t actually do anything to secure a system. An implementation bug or an architectural flaw in a product can leave a system that’s completely standards-compliant completely insecure as well. Use a discussion of security features as a flying wedge to talk about more intensive software security assurance.
13. Doing it all yourself.
To end this list on a positive note, some organizations don’t ask the security question because they plan to come to their own conclusions by performing their own hard-core analysis and testing. Good!
Despite the failure of users to ask about software security when it comes to SOA, vendors are actually quite willing, able, and, in many cases, eager to provide improved security in their products. In other words, there’s adequate supply. The problem is that there’s insufficient demand, at least as expressed in buying decisions.