A pretty fierce debate has broken out on how to do security for Web-applications (REST, WS-*, whatever). I’m gratified that it seems to have started in the comments to S for Simple. The proponents are Gunnar Peterson and Pete Lacey, and what they have to say is interesting. I think Gunnar didn’t do a good enough job of filling in one of the bases of his position, although in private email he sent me a link to a PDF from eBankingSecurity.com which is worth a look. The point is that a significant proportion of Windows PCs are compromised with trojans and keystroke-loggers and other flavors of bad-ware; significant enough that the pretty-decent transport-level security provided by TLS is immaterial. Those of us who are technically-competent and don’t use Windows can feel individually secure, but that doesn’t mean Gunnar doesn’t have a point.
Contributions
Comment feed for ongoing:
From: Gunnar (Dec 04 2006, at 07:20)
Tim - thanks for continuing this discussion. Security in a distributed system is a tricky proposition. Security architects need to deal with attacks at all layers network, host, app, data, and so on. There is no one right answer, and there is no silver bullet. There are many, many tradeoffs to be made.
My initial effort was Service Oriented Security or SOS which can stand for "save our servers" if you like. The software security architecture needs to consider
* Identity - generation, communication, recognition, negotiation, and transformation of identity (this is a big problem in distributed systems as stated here: http://betathoughts.blogspot.com/2006/12/ws-security-simple-enough-to-shoot.html)
* Message security - the service’s message payload, data, and envelope (for my money, this is the best bang for the buck. if you take the time to do message level security you can traverse hostile environments like the internets with a modicum of security. in the same way that pgp and gpg let you send confidential messages without auditing every endpoint in between)
* Service level security - interface, registry, its operations and component parts
* Deployment environment - deals with the defense in depth model: physical, network, host, application, and data (this is typically one place where your concerns about Windows security would be addressed)
It is helpful to look at these from an end to end perspective. I describe in further detail here, I look forward to finding other REST example like Amazon's AWS that deliver some of these services:
http://arctecgroup.net/ISB1009GP.pdf
[link]
From: anjan bacchu (Dec 04 2006, at 10:17)
hi commenter,
the link posted http://betathoughts.blogspot.com/2006/12/ws-security-simple-enough-to-shoot.html)
should actually be
http://betathoughts.blogspot.com/2006/12/ws-security-simple-enough-to-shoot.html
BR,
~A
[link]
From: Don Park (Dec 04 2006, at 16:01)
Gunnar, are you talking about B2B or B2C web services?
SOA today is mostly about B2B where SOAP reigns, not for security reasons, but because a) it's familiar to B2B mindset, b) tools are there, and c) marketing. B2B clients and hosts are typically headless servers managed by IT engineers who are not likely to do all the foolish things consumers are likely to do with their computers that results in malware. So the horror story that eBankingSecurity paper tries to paint doesn't apply to B2B web services. BTW, that paper reads more like a door-to-door salesman's gimmick to scare old ladies than a professional paper.
So that leaves B2C web services. If the consumer's machine is compromised, whether the web service is SOAP or REST-based matters as much as what one should wear to dinner on Titanic IMHO. I don't see how SOS can help here. Well?
[link]
From: Gunnar (Dec 05 2006, at 04:03)
I see quite a bit of B2B2C these days as well. Agents/remote offices working on multi-purpose laptops. In any case we (the industry) need better security models for all three types. So there is some overlap between the B2B and B2C case once these are integrated.
wrt IT engineers: that is fine, but there is also a lot more risk on the server. So if I have, let's say an identity repository w/ 10 million accounts and I synch it a messsaging system over vanilla HTTP w/ no message level security. That is a large bundle of risk. SSL is typically terminated at the very edge of the organization's infrastructure while the message is left to fend for itself.
wrt eBanking security: just one example that occurred to me, several people were downplaying the threat so i thought that was worth posting, Schneier's blog has a million stories like that. The main point is that the threat level is rising and what was thought to be "good enough" in 1995 is not any more.
wrt dinner attire on the Titanic. You might be right, but I hope not. I certainly agree, that with *no* changes to the current infrastructure things are daunting. Two quick examples of why we *might* not be on the Titanic
example 1: a large bank had 750k/month in phishing attacks. They were looking at using a USB dongle for 2 factor authentication. They found that 60% of the customer's desktops where infected with malware. The bank did not want to put "their good stuff into their customer's bad stuff". So what they did was, send a SMS message to the person's phone to authorize their transactions with a PIN code. effectiely taking the communication out of band.
example 2: smart cards have around 128-256k space. they can parse XML. you can use them to make SAML assertions. so the things that seem like "big iron only" type solutions are shrinking rapidly. i do agree with your general point that the consume infrastructure does not support many desirable security mechanisms today.
Two other stories
Message Level Security in Neal Stephenson's Quicksilver
http://1raindrop.typepad.com/1_raindrop/2006/12/neal_stephenson.html
Message Level Security in the LoTR
Aragorn and friends secure the channel for Frodo to pass through, but Bilbo gives Frodo Mithril, because he is the bearer. When things get tight he needs extra protection, if/whenhe is separated from Aragorn.
http://1raindrop.typepad.com/1_raindrop/2005/04/message_view_in.html
[link]
From: Gunnar (Dec 05 2006, at 04:21)
Last part got snipped.
Lastly, strong identity mechanism like SAML which encrypt and sign identity assertions result in increased assurance for a consumer in a B2C-type environment using today's infrastructure. Again, nothing stops REST from using same.
[link]