Radio Userland Migration Blues
Back when I migrated to my new "desktop replacement" laptop (which is so large that it practically replaces the desk as well as the desktop), I forgot to migrate my userland datastore. I'm sure there is a way to do this more cleanly, but I'm just going to copy-and-paste from Google's cache so that my posts from mid-2004 are not lost.
2004-09-13 - "Doing SOA for years"
Over on William Zentmayer's blog, there is a good discussion of the philosophy of SOA - and I say "philosophy" because Aristotle and Plato have been brought into the discussion.
The following comment from John Cavnar-Johnson strikes a chord with me:
There were some of us (I don't have any feel for how many) who, whether through good sense, luck, or ignorance (and in my case, a bit of all three of those), didn't make those mistakes because we built our distributed systems with other technologies (NFS, EDI, SMTP, FTP, MSMQ, SMB, even a station wagon full of 9-track magnetic tapes). I think we have every right to claim to been doing SOA for years. After all, we got hammered for years by the OO folks about our technology choices, but while they were designing the perfect object model to build into their C++ ORBs, we were getting real work done with our little VB apps ftping those files from the mainframe, processing the data and updating the Oracle (or Sybase or SQL Server) database and then pushing changes over to the VAX where the DCL/VAXBasic apps did their thing.
Why does this strike a chord with me? Well, if you graduated from university in Dublin in the mid-nineties, then you couldn't help noticing that every IT job advertisment in the Irish Times and every Dublin-based recruitment consultant placed CORBA and OO in general very high on their list of priorities. Higher, in fact, than Java, which itself was a very hot technology at the time. Of course, this was because of the presence of Iona in Dublin. Iona, as a bid fish in a small-ish pond, had caused the local job-market to become fixated on CORBA. Skill in CORBA was seen as the most prized skill of all. And, as a student at Trinity College (where Iona came from), I had of course studied Object Orientation.
But after college, I bypassed the CORBA fixation and took a job with an EDI Value-Added Network, writing EDI integration programs which did integration via store-and-forward messaging (X.400 mostly). I took this job because my boss, in the interview, told me about his plans to leverage the Internet for EDI, using cryptography and structured documents (SGML, as it was then). This is what we ended up doing. But it did involve "little C++ apps" (I tried not to use VB as much as possible) shunting files around. And so, it was a lot less academic than what my college buddies were doing. But, these little C++ apps did "get real work done", and continue to be used. e.g. last time I applied for a car loan in Ireland, the loan agent used an application I'd written to check my credit history. This little C++ (and some VB) application worked by "shunting little files around" using FTP, RSA and Triple-DES encryption, and X.509 certificates.
So, was I doing SOA all along, but didn't know it, like the "Bourgeois Gentilhomme" in the Moliere play, who was speaking prose all his life and never knew it? I was certainly doing "document-based integration" (as opposed to RPC-based integration, or Object-Oriented integration). SOA is also a way of doing "document-based integration". But SOA is a superset of what I was doing. So I will not claim to have been "doing SOA for years". But I will feel a bit more happy about not going down the CORBA road back in pre-boom Dublin.
2004-08-17 - "By their Web Services security testing tools shall you know them"
If you want to find out how many people are deploying Web Services and are taking security seriously, what better way than to track the downloads of a Web Services security client. This is what we've been doing here at Vordel.
SOAPbox usage figures reveal that the financial services sector leads the field in Web Services adoption, with 23% of the total. Next is the public sector, with 15%, telecommunications third at 12%, and manufacturing 10%. Other interesting data indicates that when it comes to Web Services, the Europeans are not following the traditional pattern of delaying the adoption of newer technologies. With 48% of SOAPbox users located in Europe, they appear as keen to adopt Web Services technologies as their peers in North America, where 41% of SOAPbox users reside.
[ http://www.xmlmania.com/news_article_1438-Vordel-s-Web-Services-Security-Test-Tool-Reveals-High-Adoption-Rates.php ]
In case you don't know about SOAPbox, here is a screenshot of it below. In the screenshot, I am sending a digitally-signed SOAP message to a Web Service which is exposed by the Microsoft WSE 2.0 toolkit. The SOAPbox highlights (in yellow) the signed content in the SOAP request message, when I click on the "Signature" element.
Using the SOAPbox, I can configure authentication, both transport-level and message-level. I can also import keys for signing XML content, and I can attach attachments to SOAP messages.
Basically, the SOAPbox is a secure Web Services client. If you have set up a security policy at your Web Service using a tool such as VordelSecure, you can use the SOAPbox to test the security from the client side. It is an awful lot easier than coding up a client application, and is much more intuitive than working with Notepad and TCPtrace. And it's free- Check out www.vordel.com for downloads of SOAPbox.
2004-08-03 - "Infoconomy"
I've written a short overview of Web Services Security for Infoconomy magazine - covering the bases of AAA and content-filtering - http://www.infoconomy.com/pages/search/group96614.adp .
2004-07-30 “Is deperimeterization coming to the US?”
Two related stories today.
First this:
Perimeter security has become obsolete, requiring a shift to a new model of "deperimeterization ," Paul Simmonds, CISO of U.K.-based ICI, said in a keynote that kicked off the Black Hat Briefings Wednesday in Las Vegas.
The old hard-shell model of security isn't sustainable in light of the need for businesses to open up their networks to partners, consultants and clients, said Simmonds, one of the founders of the Jericho Forum, a European group of enterprise security chiefs promoting the concept of deperimeterization .
[ SC Magazine ]
And then this:
"Must mention the security here, impressive perimeter stuff, good searching, magnetometers etc. But completely blown by the personal passes that allow you in here. No individual identification whatever. The passes are passed about like confetti. I've even seen people trading them for tickets to various events like James Taylor at the Boston Pops. In other words no one in the world knows exactly who everyone in this place is. Easy prey for anyone who wished the event ill. Post 9/11 America could still learn so much from the Brits and their protective methodology against the IRA."
[ Jon Snow of Channel Four News quoted here - http://www.davosnewbies.com/2004/07/30#security101AndTheDnc ]
By performing security only at the perimeter, but not actually enforcing security at the resources which you are protecting, you have the "hard crunchy shell and soft center" model. Once upon a time, this model was advocated by security professionals in firewall books and manuals. But the problem is that you lose the security context after you've allowed the message (or person) through the perimeter. You no longer know where this message came from or where it was authenticated. Or, in the case of the DNC, who the person is and how they got through the security cordon.
Vordel's products have been built to protect resources which are being exposed using XML (e.g. Web Services) by enforcing security at the protected resource itself. As well as providing perimeter security (an XML Firewall), we also provide security enforcement at the endpoint. We are in good company here - Cisco are also moving in this direction (see pervious post: If firewalls are the problem - can they also be the solution?).
2004-07-23 Java Pro article - "XML and Web Services - are we secure yet?"
This month, Java Pro magazine focuses on security. I've contributed an article entitled "XML and Web Services - are we secure yet?". If you click on the "Get the code" link on the right-hand-side of the article, you can download some sample Java code which uses Vordel's API to generate a SAML Authentication Assertion, sign it, and bind it to a SOAP message using WS-Security. The full article is at: http://www.ftponline.com/javapro/2004_07/magazine/features/moneill/
2004-06-23 03:54:30 “Crypto shenanigans”
Justin Mason has a round-up of the coverage of the Chalabi/Iran/crypto story on this weblog, plus some analysis of his own. Justin mentions the Irish angle on the story - Ireland apparently used Crypto AG machines to encrypt internal discussions about the Anglo-Irish agreement in the mid-80s, the diplomatic equivalent of playing poker with your cards facing outwards. Then the Crypto AG story broke, via the Iranian intervention. Then apparently, during the Good Friday negotiations in the 1990s, Ireland sent its documents between Dublin and the London embassy the old-fashioned way, in diplomatic bags in the cockpits of Aer Lingus Dublin-London flights, guarded by the pilot who would personally hand the bags to the Irish attaché at the far side.
05-17-04 “Stallman in TCD”
On the first day of my first year studying mathematics at TCD, the first lecture was given by Tim Murphy and it began with an explanation of the GNU project and its gcc compiler. Then he drew some lines of C on the whiteboard [causing teenage Amstrad 464 BASIC veterans like me to think "How can that work without line numbers?"].
That lecture was in the MacNeill Theatre in the Hamilton Building. On the 24th May, Richard Stallman is speaking in the same lecture theatre: http://ifso.ie/news.html
04-27-2004 Introducing the XML Security Server
Today, Vordel released VordelDirector, which is an XML Security Server. So what's an XML Security Server? An XML Security Server allows security for XML messages to be deployed as a service. Its architecture allows enterprise-wide security policies for XML traffic to be managed centrally, while enforcement is distributed across the network, whereever XML is being processed. The security enforcement is provided through pre-built security agents which plug into common XML and Web Services platforms, through APIs, and of course through Web Services. Whereas an XML Gateway sits in-line and filters XML traffic in one single location, an XML Security Server manages security rules across multiple network tiers and boundaries. An XML Security Server can support sophisticated identity federation scenarios, including Liberty/SAML and WS-Trust, as well as transactions, by passing security tokens inside XML messages.
An XML Security Server interfaces with IDM infrastructure such as directories, AAA access control, and trust services. It can be used as an “adjunct processor” that offloads XML security processing from an application server, for example allowing XML security processing to be performed on a device optimized for performance and for private key protection.
An XML Security Server is particularly suitable for a Services Oriented Architecture, where many applications are exchanging XML with other applications, with no single "choke point" where an XML Gateway could be placed. The “Security As a Service” model also caters for the “deperimiterization” effect: due to wireless LANs, VPNs, and the widespread use of SSL for encryption, many organizations no longer have a single network access point where they can enforce firewall rules.
In the current Enterprise Architect magazile, I've written a "Whiteboard" article describing how an XML Security Server is used, with a deployment diagram - the article is at: http://www.ftponline.com/ea/magazine/spring/departments/whiteboard/Default.aspx
VordelDirector is a compliment to our existing XML Gateway product, VordelSecure.
04-09-2004 – “XML Security and Web Services Security - the same thing?”
It's common to see the terms "XML Security" and "Web Services Security" used interchangably. So it's reasonable to ask - Are they the same thing? The answer is no.
XML Security refers to the security of XML documents themselves. Specifications such as XML Signature and XML Encryption come under the heading of "XML Security". XML Signature is used for the integrity of an XML document, or portion thereof. XML Encryption is used for the confidentiality of an XML document, or portion thereof. In addition, the XML Security umbrella covers defense against threats such as DTD entity-expansion and XML parser clogging attacks. Finally, "XML Security" includes the "XML-ization" of security tokens - such as licenses (XRML) or assertions (SAML) [but not digital certificates which still remain in ASN.1-land].
When XML is sent from A to B (and on to C and D etc.) it adds a new dimension to XML Security. In the tutorials I give on XML and Web Services Security, I start with an intro to XML and then I talk about XML Security. Often, when I show an XML Security example such as an XML Signature or XML Encryption, I am asked questions about the "XML Message" on the screen - what if it is replayed? where is the timestamp? how can we be sure that that certificate is trusted? Where does that XRML license come from? how do I know who sent this XML message? When that phrase "XML Message", as opposed to "XML Document", is used, we've moved on from "XML Security" and we are into "Web Services Security" territory.
Web Services Security standards and specifications, such as the recently-ratified WSS from OASIS, address the security questions which arise when XML messages are sent - such as timestamping and message-based authentication. Part of this task involves describing how XML Security applies to SOAP messages. The wider Web Services Security roadmap from IBM and Microsoft describes how XML security tokens are passed around, exchanged for tokes of a different type, and used as input to access control decisions. The Liberty Alliance framework describes how Web Services Security maps to individual identity, without compromising privacy and anonymity. Many higher-level Web Services Security specifications address problems which go well beyond XML Security - into the realm of identity and trust. Finally, "Web Services Security" also encompasses the application of Web Services to some of infosec's more knotty interoperability problems: PKI (XKMS) and RBAC (XACML) spring to mind.
So, where are the practical implications of the difference between "XML Security" and "Web Services Security". To use an analogy; applying XML Security to XML documents is like installing an X-Ray screener at company headquarters and then passing each received courier and mail package through it. You can find out if the package includes anything threatening, if it doesn't look like it should, or if it's been tampered with. This is what XML Firewalls do - they do Schema validation, they block application-layer attacks such as SQL Injection, and they detect invalid XML that's designed to clog a parser. They raise alerts if anything suspicious is found in the XML documents. You might think "Isn't that enough?". However, let's take the analogy further. What if one of the packages being passed through the X-Ray screener contains an invoice. You look at the invoice, and you see that it's appropriately formatted [Schema Validation], is sent to a valid recipient [the Accounting Department], doesn't contain any outragous values [content-validation] or have any extra attached pages [SOAP Attachments] which shouldn't be present. Does that mean you automatically enter the Purchase Order into your accounting system? Of course not. You must trust the originator of the purchase order. This is where identity and trust come into play. The security of the document itself is only part of the picture. The entire security context (sender, recipient, security token validity, authorization against company policy stores) goes beyond the document itself. This is also how Web Services Security goes beyond XML Security.
Or to put it another way: A document which passes XML Security checks (validity, integrity, scanning for XML-level threats) may still fail Web Service Security checks because it is not from a trusted originator. And remember, the originator is not necessarily the same as the entity which passed you the message.
One of the great ironies of Web Services Security is that an organization often has more to fear from valid XML documents than from an invalid XML documents, because the valid XML documents will successfully run the target Web Services.
The X-Ray scanner is not a perfect example, because many organizations do not have such a natural "Gateway" into their XML networks, and in any case, experience has shown that many attacks originate internally. This is why the firewall analogy applies for XML security, but breaks down for Web Services Security. Of course you need both XML Security and Web Services Security if you're transacting XML. The only exception is if you're exposing a public Web Service with no authentication and authorization - in that case you can argue that you only strictly need XML Security. But if you care about who is running your Web Services, you need more than just XML Security at the perimeter.
03-24-2004 – Listening to customers
Jon Udell wrote yesterday that he has a hunch that "combination of easy-to-create blogs and easy-to-create narrated screen videos could put users in charge of software marketing, education, and training" (http://weblog.infoworld.com/udell/2004/03/23.html#a951).
I'm just off a webinar (description here) where I listened and watched while Damian Myles, a senior architect from Clerical Medical, described how and why he chose Entrust for identity management, and how he deployed Vordel's products alongside Entrust's Secure Transaction Platform in order to apply access control to his company's Web Services. This webinar is being archived on the Entrust site, so if you want to see first-hand, from a customer, about how Entrust and Vordel secure Web Services, take a look yourself.
22 March - Endpoint security - If firewalls are the problem, can they also be the solution?
This article from InternetWeek reports that Cisco are using their Okena acquisition to augment the Cisco Security Agent - described as a "program that protects so-called 'endpoints,' or individual servers, desktops, and other devices." - with behavioral "learning" capability.
The article points out that security enforcement at the endpoint "aims to close any gaps that might be missed by firewalls".
This tallies with a theme in security at the moment - deperimeterization. Deperimeterization spelt with a "Z" is Googlewhacked by this weblog at the moment. But deperimeterisation spelt with an "S" isn't, indicating the origination of the phrase in the UK.
There are many aspects of deperimeterization which are relevant for Web Services security (I'm in Boston so I'll use the 'Z' spelling). The most obvious is that, as everybody knows, most existing firewalls are oblivious to XML. But, the larger problem is that firewalls have for a long time been oblivious to SSL traffic, and sensitive XML data is almost always encrypted using SSL. This presents a big problem for companies who subscribed to the "crunchy perimeter, soft center" firewall model, because SSL traffic sails through the "cruncy perimeter" encrypted. Another way in which deperimeterization affects Web Services is where XML traffic "hops" through a number of systems in an Services Oriented Architecture, requiring security information (e.g. "Where is this message from?", "Where and how was the sender authenticated?") to be bound to the messages themselves, otherwise the messages lose their security "context".
These are some of the reasons why, in addition to selling an XML Firewall (VordelSecure), Vordel also sells Agent plug-ins which embed into the protected Web Services endpoints themselves. This allows an administrator to deploy Vordel's XML Firewall to perform peer authentication and then sign and "inject" a security token into messages, allowing Vordel's agents to scan for the presence of this token at the endpoints. Without this endpoint protection, an XML message which simply hasn't come through the XML Firewall cannot be blocked. And without endpoint protection, internal-to-internal messages have to be routed up though an XML Firewall, which isn't always a convenient or elegant solution. If you can only "see" the messages in a snapshot as they pass through an XML Firewall, you aren't seeing (or managing) a full view of the security of a Services Oriented Architecture.
One of the ironies of Web Services security is that while everyone is agreed that firewalls are deficient for XML traffic, a similar perimeter firewall model is often presented as the solution. But is the problem with firewalls due to deficiencies in its application awareness, or it is an architectural problem? A firewall certainly is the solution sometimes, which is why we built VordelSecure. But in other cases, securing Web Services also requires endpoint security - which is why we also built endpoint security agents. With Cisco, I think we are in good company on this one.
Vordel wins "Software Oscar"
From the press-release-pasted-into-blog department:
Vordel, the Web Services security company, has been chosen by the readers of the Web Services Journal (WSJ) for a Readers' Choice Award in the category of 'Best Web Services Security Solution'.
The award, known as a "software industry Oscar" was given to Vordel's flagship product, VordelSecure, the XML security server, by readers of the industry-leading WSJ.
"The award is further evidence of Vordel's commitment to excellence," said Vic Morris, CEO of Vordel. "It's also a validation of our drive to further the adoption of Web Services in the business world."
VordelSecure provides content filtering, and identity-based protection and management of XML and Web Services. The product uses open standards to interact with access management tools from major vendors, as well as major application server platforms and security technologies.
VordelSecure shared the category with access management products from IBM, RSA, and Netegrity.
3:24:51 PM 
|
