20 March 2002

Novell report: Looking for corporate single sign-on. A report made to order for Novell Denmark, reports that 73% of corporate users daily use more than 5 different logins to access company resources. Yet another reason that Novell is not alone in the space, with solutions from Oblix, Netegrity and Microsoft (Active Directory) as highlights. [Digital Identity] I'm sure every single bank has plans for this, but with all the different applications out there it's going to be costly to implement. 11:58:56 PM      comment []   Liberty: betting on SAML?. 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 []   The Register reports: Setback for security through obscurity scheme A proposal on the "responsible disclosure of security vulnerabilities" has been withdrawn from consideration by the Internet Engineering Task Force (IETF), after criticism that the issue was too political to be decided by the Net's prime technical standards body. I agree that it doesn't belong in IETF. It's obvious that the Software Vendors don't want exploits publicized, but for those of us who have to develop and maintain systems based on their software, it is vital to know about the exploits the minute they are available so we can protect our systems against them. It is ofcourse also important to keep the vendors on the toes. Lists like Bugtraq have been vital in forcing vendors like Microsoft, Oracle and Sun to take security seriously. 11:43:49 AM      comment []   David Orchard on the Web Services Pitfalls 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 []   Welcome to my new Financial Security Weblog. You wont be hearing much about firewalls, anti virus software etc. but instead I will make the assumption that the bad guys are already inside the building. In which case our responsibility as Application Developers is to harden all aspects of our applications. This means identifying ALL the different components of our J2EE systems, our CORBA infrastructures and our Databases to find out how they communicate with each other and how to secure those individual components. A benefit of doing this is that it makes it easier for us to open our apps outside our individual groups, divisions or banks. The services we supply inside our group can now easier be supplied outside our group without exposing us to a greater security risk. In my weblog I will bable on a bit, but also try to keep up with the latest standards, software and policies affecting the security of financial applications. 12:22:26 AM      comment []

© Copyright 2002 Pelle Braendgaard. Last update: 20/03/2002; 02:14:19. <