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.
Comments