|
|
|
11 April 2002
|
|
| |
Microsoft is slowly killing of Hailstorm according to an article by John Markoff of the New York Times. He claims that MS has been slowly devesting their My Services (formerly Hailstorm) Consumer Web Services platform over the past few months, with a goal of eventually releasing "My Services" as a package for Corporates to use.
I don't know how this will affect Passport yet, but I can't imagine them halting that service for the time being, regardless of its problems. I wonder if the Citibank announcement last month will be affected by it as they were to be the prefered financial services provider for My Services.
1:52:58 PM  comment []
|
|
I haven't had time to read the full whitepaper yet. This Whitepaper describes their new WS-Security proposal.
This document describes a proposed strategy for addressing security within a Web service environment. It defines a comprehensive Web service security model that supports, integrates and unifies several popular security models, mechanisms, and technologies (including both symmetric and public key technologies) in a way that enables a variety of systems to securely interoperate in a platform- and language-neutral manner. It also describes a set of specifications and scenarios that show how these specifications might be used together.
I'll have a quick read and come back with any comments.
1:21:01 PM comment []
|
|
Jon Udell discusses the SOAPAction header and its uses for filtering SOAP requests through a firewall. The concept of the header is that the client making the SOAP Request, places a SOAPAction header in the HTTP request describing what it is they are going to be doing. For example what method they will be invoking. When I first read this a few years back it did send question marks buzzing up through my head, as you cant really on an external description of what is going to happen. Jon put's it great with his analogy of External Underwear:
Did the notion advanced in DevelopMentor's FAQ -- that SOAP packets would declare intent by publishing interface and method names in the HTTP header -- make sense? At the time it seemed reasonable to me. But now, I wonder if a SOAPaction policy isn't rather like the scene in Bananas where the newly-installed dictator declares that "everybody must wear their underwear on the outside, so we can check." The interfaces that a company chooses to expose to the world are, in the end, a policy that will or won't be enforced, regardless of the SOAP toolkits in use or the translations performed in a request pipeline. Enforcement will always require more than checking for underwear on the outside. [Jon's Radio]
Those of us who were writing perl CGI apps way back in the early days of the Web learnt that you can't rely on the format of a request. You really do need to verify all data before you make any assumptions about it, so a http SOAPAction header specifying a Stock ticker lookup interface, can just as easily have a Stock trading message within.
All of this discussion though assumes that you only have one single SOAP gateway/router on your web server. This strikes me as a bit naive from a security standpoint. I think that only interfaces with the EXACT same security properties should be exposed in the same router. This way you can use the underlying web servers security as well as external firewall's to provide access control and authentication. Lets not reinvent the wheel here.
12:13:38 AM comment []
|
|
|
|
|
03 April 2002
|
|
|
|
28 March 2002
|
|
| |
IBM Developer Works are running a good article on XML Encryption. Over the last year or so almost all the new feeds and systems I've linked in with on projects have used XML for interop. XML Security is going to be extremely important over the next year or two. It is particularly useful, because you can encrypt and sign individual elements rather than only full messages. The signatures will ofcourse verify the integrity of a message or element and the element by element encryption is useful for only allowing access to the part of the message you need in your subsystem.
8:57:31 AM comment []
|
|
|
|
|
22 March 2002
|
|
| |
Ravi Razdan has a piece on CNET about the Security of Web Services. This illustrates many of the security Problems people are having with not just Web Services, but with any application that is directly or indirectly available on the Internet:
But in their rush, an important data security issue is being ignored: Confidential information is vulnerable to malicious employees or hackers because customer data, which gets stored in applications or databases operated by the Web services provider, still exist in clear or unencrypted form....
... Most Web service providers deploy several methods to convince customers about the security of their information. These run the gamut, including multiple firewalls, intrusion detection, application and system portioning, encryption, biometrics tools, and even armed guards. In the end, however, they are all but useless since, according to the Internet Security Task Force, about 70 percent of business computer-security breaches are internal.
This is interesting because firewalls are exactly what most companies use to feel safe, but all it really takes is a unhappy employee or a user whithout their knowledge running a BackOrifice variant on their machine for a serious breach to occur. A good hacker who knows what he's doing could work out what's going on on your average CORBA based server and insert transactions into a trading system or perform SWIFT payments. However while no application can ever be made 100% secure, if we stop assuming that the firewall will protect us, it isn't all that hard to actually harden up an application. With the new standards coming into place it is made even easier, but it is our responsiblity as Application Developers to actually use them.
8:18:59 AM comment []
|
|
|
|
|
20 March 2002
|
|
| |
Prior suspect that Liberty will be looking to the Security Assertation Markup Language (SAML), a proposed standard from the OASIS Security Services technical committee, now seems definitive.
I have three independant confirmations from Alliance founders, that SAML indeed is the security information protocol of choice. It is, however, also quite safe to bet that Liberty's specific requirements of operating a shared public identity space with specific focus on merchants, will force extensions upon the standard.
[Digital Identity]
The Liberty Alliance Project counts several Prominent US Financial Services companies such as: American Express, Fidelity, Bank of America and CitiBank (Hmm, what about todays announcement regarding Passport?? Betting on two horses I guess.). The project aims to setup a large federated Identity Service to compete with MS Passport. So far little is concrete, but it sounds like they might be using SAML, which certainly would make sense.
I've seen plenty of anti microsoft alliances before and I must admit I'm a bit sceptical if they actually will get past the vapour ware stage. But I do hope they do, as no one wants to see MS own that market. (Of course they are probably the one company suited to do so).
Financial companies will primarily be interested in Liberty for retail apps. There is little sense in using them for internal applications. I can see larger banks creating SAML interfaces into existing authentication frameworks. Data providers will probably eventually look into using it as well for authentication of their services.
11:46:15 PM comment []
|
|
Security Assertion Markup Language
As a follow up to the CitiBank story below, I had a look at what alternatives are available that would be of interest to the Financial Services Industry. The Oasis Consortium who work on various Business related XML formats have proposed a standard called Security Assertion Markup Language (SAML). The Standard is nearing completion and we should be seeing a V1.0 within the next month or so.
SAML looks particularly useful to Investment Banks. It handles everything from End User Authentication to Service to Service Authentication. Which would be useful for various kinds of feeds. A Standard Java extension will be released from Sun that contains a Java API, hopefully making it easy to plug into existing systems.
I'll post a more detailed analysis of SAML later on.
11:08:47 PM comment []
|
|
CitiBank to use Microsoft Passport
News.Com: "Citigroup has agreed to use Microsoft's Web services technology, including password protection, online authentication and messaging services. The endorsement is significant for Microsoft, which has been struggling to define a business plan for its .Net My Services product." [Scripting News]
While the article talks about the confusion consumers have about the technology, there is a real need for services such as Passport. There are many questions though regarding the technology. Is it too centralized? Do we trust Microsoft with our data? Is Microsoft able to provide the security for such an application? These remain to be seen, however ofcourse this announcement does seem more of an announcement of a joint marketing agreement than anything else. I'd like to know if anyone with CitiBank did a real analysis of the security of Passport before the guys up above decided to do the deal.
9:13:27 PM comment []
|
|
David Orchard at XML.com writes about the pitfalls of Web Services. David argues that most people writing about Web Services don't talk about important aspects such as Security, Contracts, Billing and the potential of a DLL type hell with version mismatch.
Web Services vs Financial Feeds
Web Services are the buzz word of the moment. Of course we have used similar technology for years in Investment Banking, only generally using more robust technologies. So we've already experienced many of the issues David mentions.
In Investment Banking we are already handle many of those kinds of issues. We are used to subscribing to data and providing our own in the shape of feeds: Trade feeds, News Feeds, Payment Feeds, Pricing Feeds etc. These feeds can be external such as Reuters Kondor or internal like a banks internal Swift payment feed.
In most of these cases Contracts and Billing is handled offline as you'd expect. But what about Security and Version mismatches. Version Mismatches are unlikely to happen because of Contractual issues. When a new version is released of a feed, it is generally a big deal in the Investment Banking world. Just look at the current Kondor 2.0 migration happening all over the world right now.
Security and the Information Chain
Security is the big issue here. When we are working with the kinds of sums that we do in the investment banking world it would be disasterous if a service fell victim for a Denial of Service attack or a hacker infiltrated a system somewhere in the information chain and started feeding false information through. Some areas here we are very good in the financial world. For example outgoing payment systems tend to have pretty well thought out security. But what about Informational feeds. It could be equally disastrous if trade or price feeds got tampered with.
So this is what we need to work on. Almost every IT group in investment banking is part of the Information chain. We rely on data from other systems and other systems rely on data from us. This is why every single subsystem and component really needs a security audit. Just think of all those CORBA or RMI orbs that are sitting protected only by a firewall with method names such as "addTrade", "addPayment". It's not just orbs, every bank has a multitude of different message infrastructures such as TIBCO, Swift etc. Are they protected? In most cases poorly. What about Databases? While Oracles highly publicized security bloopers recently highlight that there are still issues in 3rd party software to beware of, many production systems have poorly thought out security frameworks.
If someone manages to break into a trusted link in this information chain, they've essentially broken into the chain as a whole. This makes it our job as Application Developers to think long and hard about the security of not only our applications, but also the infrastructure components we rely on.
7:31:56 AM comment []
|
|
|
|
© Copyright
2002
Pelle Braendgaard.
Last update:
28/03/2002; 09:57:31. < |
|
|
