1 Raindrop

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.

Times they are a changin

Well, it was not too long ago, all the security pundits were telling us how bad web services are for security, and some are still saying this right? Of course when someone tells you some technology is "bad" for security, the proper response is always: compared to what? So SOAP is somehow worse for security than DCOM or RMI-IIOP? Remind me all the great security tools that shipped with those protocols again?

Funny, but when all the big vendors and standards bodies have to sit down and work interop, they sometimes get something pretty nice. Rickard Oberg on SAML, XACML (emphasis added):

There are many other crucial technologies today, which are important for integrating webapps into a portal. It is curious to read forums where people bash things like portlets and WSRP and XACML and such. "Why would we want to run portlets in two servers? My Struts app works just fine on one Tomcat instance". Amazing. When you have been exposed to real-life DMZ environments a couple of times you start to wonder how the heck we get anything done *without* stuff like WSRP and security integration specifications like XACML and SAML. The conclusion appears to be that developers that don't get it simply aren't exposed to the realities of actually running the apps. For development it might make no sense to have several servers, or integration technologies like SAML and WSRP, but for real deployments they are essential. As long as application developers are in the dark with regard to these basic realities systems integrators are going to keep using hack upon hack in order to make house-of-cards type integration of apps.

Precisely the point, not only are Web Services not turning out to be "bad" for security, but the standards that they are generating - SAML, XACML, WS-* - are giving developers better security tools than they have ever had before.

John Quarterman on Life in the Slow Lane

American corporations spend more on tort litigation than R&D. Full stop. John Quarterman elaborates on US News article "Can American Keep Up?":

In academics, America's mediocrity is a familiar story, one factor in President Bush's call, in this year's State of the Union address, for rigorous new training for 70,000 high school teachers. The reading literacy rate for 15-year-olds in the United States is barely above the average for western countries. American eighth graders rank ninth worldwide in science scores--and 15th in math, behind students in Estonia, Hungary, and Malaysia. And for years, U.S. students have been migrating away from hard sciences--which tend to be the source of cutting-edge new products and other innovations--toward business, law, and liberal arts degrees. "We had more sports-exercise majors graduate than electrical-engineering grads last year," lamented General Electric Chief Executive Jeffrey Immelt in a January speech. "If you want to be the massage capital of the world, you're well on your way." US News and World Report

Hey, Estonia, no fair they have Ross Mayfield advising them. Why can't we get people like that here? Oh wait a second Ross is a Californian...maybe we should listen?

The article also quotes Axalto on the limited ability of the US to adopt smart cards. Bruce Sterling and World Changing talk about the leap frogging phenomenen quite a bit and this is something to watch for where our legacy baggage is a liability. Supply lines get longer, speed is reduced.

John Quarterman:

But industries where the U.S. used to hold the lead it is losing. New programming languages used to come almost solely from the U.S., but one of the hottest new ones in a while, Ruby, hails from Japan. In telecommunications, Japan, Korea, and even Malaysia are far ahead, along with smaller countries such as Finland and Hong Kong. This telecommunications lag applies to wireless voice, land-based broadband, video over IP, and voice over IP. Back at the ranch, almost everyone I mention this to, in that industry or without, makes kneejerk facile excuses: those countries have higher population densities; they're more urbanized; etc. The old U.S. can-do attitude does still pop up here and there, such as in some rural wireless initiatives started by entrepeneurs.

As Bill Gates is supposed to have said when targeting IBM in the early MS days: "success is a menace." Tort litigation can be viewed as a spend since it protects existing assets, R &D is a speculative investment, what is the right balance?

REST v SOAP debate impact on security services architecture

Mark O'Neill's RSA Presentation on Security for REST Web Services makes an important point for security architects who are dealing with developing security services for budding SOA initiatives - how will your security services (which rely on WS-* functions and SOAP) be able to deal in a RESTful web services paradigm? This is not a trivial question because while enterprise architects may design and purchase solutions that rely and mandate the former, developers can easily circumvent with a HTTP Get. Part of this gets back to a framework versus roll your own debate that I blogged awhile back.

Security architects cannot afford to take enterprise architect's whiteboard and Visios mandating a WS-* (or any technology) world at face value instead they must engage developers, BAs and other stakeholders to deal with the reality of runtime as opposed to policy and design time. XML in and XML out may be the design, but the runtime reality could well be HTTP Get in and XML Out under REST rendering the shiny new XML security based solution blind to large amounts of traffic.

Maximum flexibility to deal with different tactical deployment realities is an important property in security tools, not just compliance with Visio drawings. The ability to enable security protocols in integration scenarios composed of hetergeneous technologies and usage paradigms yields the widest risk management coverage. In this case it pays for security architects to be the fox not the hedgehog.

This is also why I think STS technology will be very successful, because the security protcols that STS and WS-Trust integrate: SAML, X.509, Kerberos, are generally putting arbitrary boundaries around technical domains while the business reality is the opposite - more integration not less. Protocols which continue to enforce isolation ultimately fail when their subjective, isolated concepts meets up with the integration objectives reality rendering the system as a whole less secure.

Ident-ebonics

Identity projects, like any other integration project, yield confusion because of disparate stakeholder needs and understanding of definition. This is a new discipline for security projects which are typically nowhere near as customer-facing as software development projects, but with identity management security team are exposed directly to lots of stakeholders. On top of that identity projects are laden with lots of legacy terminology baggage like roles. If you ask 5 IT people about roles you will get (at least) 6 different answers, managers talk about functional roles, BAs talk about domain roles, developers talk about user principal roles, and directory architects...of course know what roles really are...er..talk about LDAP roles. This makes this word harmful to building up understanding, it is this way with many concepts in identity and access management. Vendors make the problem even worse. Start with an identity architecture that defines the entities and their relationships. Publish prescriptive, positive definitions and examples help to reduce confusion. Fight ident-ebonics misunderstanding with use cases to generate shared understanding of the space, structure, and behavior. You cannot integrate what you cannot agree on.