Privacy, subcontracting, and Web Services Security
Quick - what's interesting about this Website privacy policy? Give up? Well, notice that it's a superclass of Amazon.com's privacy notice - the customer is asked to refer to Amazon.com's privacy policy. Most people don't read privacy notices, let alone think about them. But in this case, they might think "hmm... my browser says www.shopforpowertools.com not www.amazon.com , why is Amazon.com's privacy notice relevant here?".
So what's happening? Answer in two words: Web Services. www.Shopforpowertools.com uses Amazon.com's Web Services. In effect, as has been noted before, Amazon.com are being smart and are outsourcing their user interface development.
A user browsing through www.shopforpowertools.com is actually browsing through Amazon.com's catalog, indirectly, via Web Services. XML and HTTP are being used to communicate between Shopforpowertools.com and Amazon.com's Web Services.
At the business level, there is nothing new about the sub-contracting business relationship between Shopforppowertools and Amazon.com . Legal and privacy frameworks for subcontracting exist today, most topically for managing IP in subcontracted software development and for managing customer data in subcontracted customer service centers. But the technology used in this new case, Web Services, is new.
The only commentator who I've heard talk about Web Services security in these subcontracting terms is Whitfield Diffie, CSO at Sun, last year at ISSE Europe in Vienna. Part of this comments are in this interview :
Interviewer: There are experts who are saying that, as we move to a world of web services, serious near-future threats will come further up the stack than at the network level. What’s your take on this?
Whitfield Diffie: I believe in web services. They will work. And they will lead to a computer-to-computer information economy that will parallel the economy as a whole. Right now corporations sub-contract many kinds of work, from advertising to cleaning, and the same thing is entailed by the ‘network is the computer’ idea. At present, computers reach out of themselves in limited ways. We distibute storage around the network, almost invisibly. Standalone computers will become rare, and many operations will be outsourced to specialists. The big challenge for security in the next decade or so is that of providing the security mechanisms necessary for that.
[ Sun's CSO Hails the Future, Compsec Online, October 2003]
One of the "security mechanisms" is privacy. Another "security mechanism" that's required is the ability to make an access control decision on a per-user level, even though the end-user is at least "one step away" from the Web Service itself. [ Remember: The W3C Web Services glossary defines a User as "A natural person who makes use of resources for application purposes". It defines a Client as "A system entity making use of a Web service." This difference between client and user is very important in Web Services security. http://www.w3.org/TR/2002/WD-ws-gloss-20021114 ] . This all sounds academic, until you see it in real life situations such as Website privacy notices.
Much of the hype about Web Services security concentrates on content-filtering of XML itself - generalizing threats from the "Web Application Security" world to XML traffic, including browser-to-Website threats such as cross-site scripting which have no relevance for Web Services. But just as the "big idea" of a SOA (Services Oriented Architecture) is the *architecture*, while enabling technologies such as XML and SOAP are more "a good excuse to implement a SOA now" rather than the reason why SOA exists; in the same way XML content-filtering is only part of the security picture, the real issue for Web Services security is the *architecture*, which requires new security mechanisms. You need content-filtering, *as well as* an awareness of the overall security architecture.
|
