1 Raindrop

SOA Security @ OWASP App Sec Seattle 2006

I am teaching a one day class on SOA, Web Services, and XML Security at the OWASP App Sec conference which is in two weeks in Seattle. The conference agenda looks very good, Michael Howard is giving the first day keynote. I always enjoy the OWASP conferences because there is a lot technical depth in the presentations and a lot of key areas in web security are covered that I do not see addressed at any other conferences. On the second day I am chairing a panel on application security. Looking forward to it.

plaintext virus - Sam Ruby destroys the Internet

via Tim Bray - Sam Ruby implements the plaintext HTML tag which was deprecated in 1995:

NOTE - In a previous draft, HTML included a <PLAINTEXT> element
      that is similar to the <LISTING> element, except that there is no
      closing tag: all characters after the <PLAINTEXT> start-tag are
      data.

Tim's post points to the impact of this virus:

His use of <plaintext>, which turns out to be an obsolete HTML tag (I’d never seen it, and I’ve been doing this shit since 1994), has exploded Bloglines (no biggie, Bloglines is basically unmaintained these days) and demolished PlanetApache (scroll down a bit). PlanetJava has silent data loss, and del.icio.us is barfing angle-brackets.

Using deprecated tags to break numerous systems, reminds me of a principle Richard Thieme brought up at last year's Def Con which was that systems are built based on assumptions, but you cannot query the system about the assumptions it makes on your behalf.

SOA and Security

Gary McGraw, Jeremy Epstein, and Scott Matsumoto have posted their recent article on Software Security and SOA.The paper cuts through a lot of the SOA reality-distortion, and gets to some key points. First, and most important, security should look at SOA and Web Services as an opportunity for security improvement not solely a security problem. Schneier, et. al. had great fun at the onset of Web Services deriding SOAP's claim as a firewall-friendly protocol by saying that it is like saying we invented a "skull-friendly bullet." Good line, but misses the point. I posted this to Cryptogram in 02:

One thing that I have heard you mention before that I disagree with is that Web Services and things like SOAP are bad for security.

First off, any technology will have some security issues and Web Services are no different, but this does not mean that they are "bad," because you have to look at what they are replacing. If I am writing a distributed app today that needs to traverse the firewall or WAN my choices are RMI-IIOP (J2EE or CORBA) or DCOM (Microsoft) or some type of proprietary messaging system.

As you have often said, complexity is the enemy of security...well...Web Services represent a much more simplistic approach to distributed app development. For one thing I can use SOAP in either a J2EE or .Net app, so the security team only needs to understand this one protocol to be useful to either style of development team (for the distributed programming part of the project).

For another thing, Web Services and SOAP are a shift away from code and towards semantic meaning (as Don Box says) and this also aids the understanding of a complex system. Given a good architect, development, and security team, a Web Services-based system has a better chance at being secure in development and production than RMI-IIOP- or DCOM-based apps.

So I would say that Web Services and SOAP are an imperfect yet incremental improvement over the current situation.

Additionally, the payloads in SOA and Web Services are typically XML which you have half a chance at parsing and running detection and integrity checks on. Anybody seen any good IDS tools for RMI-IIOP and DCOM lately?

Back to our friends- McGraw, Epstein, and Matsumoto. The paper lists 13 security snares, the theme of which is that security must roll up their sleeves and work to build security in, e.g. don't wait to get started, don't blithely ascribe all solutions to things like SSL, and don't assume the vendor will do it for you. Timing is important. SOA and Web Services are what is being built right now, this means the lava has not hardened and security cna get involved before it does. I have some specific guidance on security architecture for SOA and Web Services here and here. Security needs to get out of the ivory tower and into the source and data.

The last part of the article describes some keys to security in SOA:

strong security involvement in architecture
or design,
• good software engineering practices,
• security-focused quality assurance
(QA),
• penetration testing,
• automated vulnerability testing,
• manual or automated source code
analysis,
• defect density prediction,
• developers trained in software
security,
• a development methodology,as the touchpoints, that helps identify
security problems before they
occur,1 and
• other third-party reviews.

This is a very good list, but one thing that is missing from the document is the impact of new security standards. One of the things that makes SOA and Web Services exciting from a security standpoint is the emerging security standards that address age-old security problems like interoperability, portability, and data level security. These are a large part of the enhanced security that comes with SOA and should form an important part of the architecture and design part of building security in.

Web Services and XML Security Training at OWASP Europe (Belgium)

I will be teaching a one day course on Web Services and XML Security at the OWASP Europe conference. I enjoy the OWASP conferences, there is a good mix of security folks, developers, and architects, plus it is vendor neutral, many different industries are represented, and usually in a nice location.

The focus areas of my class are:

• Web Services attack patterns
  
• Common XML attack patterns
  
• Data and XML security using WS-Security, SAML, XML Encryption and XML Digital Signature
  
• Identity services and federation with SAML and Liberty
  
• Hardening Web Services servers
  
• Input validation for Web Services
  
• Integrating Web Services securely with backend resources and applications using WS-Trust
  
• Secure Exception handling in Web Services
  

The class explores standard secure coding and application security issues and looks at new risks and countermeasures that are present in Web Services, SOA, and XML paradigms.

Defense in Depth Forecast Trending Better: Web App Firewall Eval Criteria 1.0 released

One problem that enterprises face is understanding how all the security tools fit together, each of the security tools has their own niche. Vendor hype can make these spaces more difficult to analyze. Web App Firewalls can add some useful security properties to Web Apps. The Web Application Security Consortium has now released the Web Application Firewall Evaluation Criteria version 1. This document helps organizations methodically cut through the hype and fud to make a good decision on what WAF works for them. The doc has the following sections: Deployment Architecture, HTTP and HTML Support, Detection Techniques, Protection Techniques, Logging, Reporting, Management, Performance, and XML

Mainly through the efforts of Ivan Ristic this doc has gone through numerous revisions so it now has a well rounded coverage that addresses technical, runtime, operational, and security issues. There are many considerations when looking at WAFs, with many decisions and tradeoffs to be analyzed, this guide is a great start to analyzing the space.

WAFs are not as static as network firewalls, at this article states

"It's not the type of solution you can buy, put in and never make changes again. It has to adapt to new threats," [IT executive for the mid-West financial firm]

Instead WAFs collaborate much more directly with development, which is another growth opportunity for security industry.