Security

Digg This!

"Let me assert my firm belief that the only thing we have to fear is fear itself - nameless, unreasoning, unjustified terror, which paralyzes needed efforts to convert retreat into advance."
- Franklin Delano Roosevelt
First inaugural address, March 4, 1933

As organizations move to service-oriented architecture (SOA), security becomes one of the key concerns impacting deployment. After all, a company's most sensitive information is frequently stored in the business systems that are now being accessed by the Web services employed within an SOA. As such, security concerns have become part of the enterprise decision-making process relating to the adoption of a SOA. However, these discussions are often exclusively focused on the security features of the Web services implementation, and give little consideration to the inherent security of the Web services platform, or of the services themselves. As Gary McGraw, CTO of Cigital, likes to say, "Software security is not secure software."

Historically, most applications routinely highlight their primary security features as a key selling point. However, outside of the security realm, few actually attest to the security of the application itself. Thus, users may possess all of the security features in the world, but still remain insecure.

These challenges are accelerated by the move to an SOA, which allows these potential vulnerabilities to be more widely exposed as Web services. In this scenario a variety of standards such as SSL, WS-Security, and SAML, often take the place of the product's previously referenced security features, but the results are the same as users remain insecure because the services themselves were not well written.

As the director of product security for webMethods, I speak frequently with both IT generalists and security specialists within hundreds of large companies and government agencies in the US and abroad. These discussions cover a wide range of security-related topics, but most frequently, they relate to security features and standards supported by specific products. To my surprise and consternation, after more than five years of such discussions, I've only had a handful of individuals ask, "So how do you know the product is secure?" Furthermore, even fewer had any idea as to what the right answer to this question would look like.

This point was driven home during a recent presentation I attended at a local security users group, where the speaker was comparing half a dozen XML firewall/gateway products that were to be used in a government SOA project. He explained the procurement criteria used by his company, which included features, cost, ease of maintenance, financial stability of the vendor, and other criteria. Not on his list was "Is it secure," and he seemed genuinely surprised when I asked about this missing question. However perhaps in their environment, this was a reasonable omission.

Having spent some time pondering this question - why so few people ask whether products are secure - I've actually taken the liberty of assembling a list of 13 potential responses.

1. People assume the vendor takes care of it. When buying a new car, I don't ask about the engineering processes used in the design; I assume Ford or Toyota knows more about how to design cars than I do. Why should the purchaser of software be responsible for asking how secure it is?
2. They don't know that they should ask. Some IT organizations (even in large companies) lack a dedicated internal security staff; instead, security is one aspect of everyone's job. No one person has enough background to know what to ask, or how to make sense of the answers.
3. They don't know what to ask for. Sometimes users know that they need security, but have no idea how to measure the results. With no Consumer Reports for software quality, how can a nonspecialist ask useful questions? As for specialists, what questions will help give them the comfort they need?
4. They're uncomfortable with the technology. Most security engineers I know 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 SOAs. Therefore they ask about the aspects they're familiar with - such as use of SSL - and ignore the harder questions such as "Is it secure?"
5. They've made a conscious risk assessment. It's impossible to get everything right, and some organizations make conscious decisions on where to focus their energies. Even if a Web service has a security flaw, the odds of those problems being detected and exploited are far lower than the odds of an attack through an unpatched router or Web server, simply because there are more people attacking the commodity products than the customer-specific Web service.
6. They think they're safe. Everyone has heard the fallacy "we're safe, we're behind the firewall." In many organizations, that's truly believed. Since Web services tend to be implemented by servers inside the organization, their security gets ignored, even though firewalls will simply pass along a Web services request, including any attack code.
7. They use vulnerability metrics. It's fairly easy to search databases of vulnerabilities (e.g., CVE or Bugtraq) to find out how many security problems have turned up in a given product, and how severe they are. Rather than asking the vendor, security engineers may use metrics such as the number and severity of publicly reported bugs to determine the quality of the product. However, these results may or may not tell the whole story.
8. They simply don't believe vendor claims are trustworthy. Vendors may intentionally or unintentionally give inaccurate results. For example, a vendor who performs penetration testing might not have tested the product or version being considered. Thus, users conclude that the value of the testing is minimal.
9. They have reduced security requirements in the POC. Frequently, security isn't a requirement in a proof of concept, and technical issues other than success of the POC are not revisited before the procurement decision gets made. Thus, the opportunity to consider the security of a product is missed.
10. They don't think it's their job. This could be a variant of "the vendor takes care of it," or it could be a symptom of an organization where the security specialists aren't responsible for the security of the systems in use.
11. They know that their organization doesn't care. 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 should he or she spend the time to question the vendor or analyze the security of a Web services application when it's unlikely to impact the buying decision? For that person, it's easier and better to use silver bullets to influence a critical piece of security infrastructure.
12. They think standards take care of the problem. Standards such as SSL (for Web servers), S/MIME (for e-mail), and WS-Security (in the Web services space) are widely perceived to provide security. Too many organizations fail to understand that while these standards are important, they don't actually secure the system. An implementation error in a product can leave a system that is completely standards compliant insecure.
13. They perform their own testing. To end this list on a positive note, some organizations don't ask the question because they're planning to come to their own conclusions by performing their own analysis and testing.

Despite the failure of users to ask, vendors are actually quite willing, able, and eager in many cases to provide and demonstrate the improved security in their products. In other words, there is adequate supply. The problem is that there is insufficient demand, at least as expressed in buying decisions.

So what can be done?

We should first consider why we don't ask the question of every vendor we interview. In many cases, the decision may be entirely reasonable. Whenever we look at a vendor, we should make an explicit decision whether the security of the product is important, and if not, document why not. For many organizations, the aforementioned list may be the right starting point.

For those vendors of whom we want and in fact need to know how secure the product is, we need to know what to ask, and how to measure the answers. Some of the measures by which a user might evaluate a software vendor are:

• Strong security involvement in architecture/design
• Good software engineering practices
• Security-focused QA
• Penetration testing
• Automated vulnerability testing
• Manual or automatic source code analysis
• Defect density prediction
• Training developers in security "best practices" (e.g., OWASP)
• Formal criteria-based assessments (e.g., BITS, Common Criteria)
• Using a development methodology, such as CLASP, that helps identify security problems before they occur
• Other third-party reviews

Unfortunately, there is no single answer to how much is enough. Should vendors be expected to meet all of these criteria? Should they be expected to meet most of them? How do we prioritize among competing claims? For example, how should we evaluate two months of security-focused QA in comparison with a week of automatic code analysis? Is a product that has undergone a BITS evaluation more secure than one for which all developers are trained in the OWASP top 10?

In reality, these questions are scarcely different from the other issues raised in the procurement cycle, such as the trade-off between cost and performance, with one exception: these are the critical criteria that are not typically assessed in a formal manner as part of the process.

It's important to remember that no evaluation process guarantees the success of a product; however, it does help to improve the odds while providing users with additional recourse should issues arise. For example, following a proof of concept, we can feel relatively confident that we've obtained the best performance, but not totally certain in this knowledge because the product has yet to be deployed in the field. By also extending the product's underlying security to this scrutiny, we can improve the likelihood that it will not expose a security breach within the enterprise. This approach will also provide users with greater insight into the product's overall security architecture so that proactive steps can be taken to remediate any uncovered shortcomings.

Summary
Ultimately, organizations building SOAs need to recognize that securing their Web services requires both a secure Web services platform and securing the Web services themselves. Purchasers of Web services platforms can and should ask the vendor about how they secure their platform. Also, developers of Web services on those platforms need to take an equal responsibility to introduce rigor in their design and testing, so that the Web services do not become the attack point.

By asking Web services vendors the question "how do you know your product is secure," organizations will raise the bar for security, and thereby protect their information. We must not be afraid of complex answers, and by doing so, we will prove that "The only thing we have to fear is fear itself."