[This message was posted by Ryan Pierce of CME Group <ryan.pie...@cmegroup.com> to the "Information Security" discussion forum at http://fixprotocol.org/discuss/3. You can reply to it on-line at http://fixprotocol.org/discuss/read/810b99e6 - PLEASE DO NOT REPLY BY MAIL.]
Hi Russell, > I think we're both on the same page - I'm also happy to agree with any number > of your points on this. I didn't mean to denigrate anything you had said in > an earlier post - my point is that you are taking a big risk when you rely on > a firm that doesn't specialize in security to provide you with a solution for > a security problem. Ditto to most of the above. I'm likewise not meaning to denigrate anything you say, and I think that this kind of dialogue is particularly valuable in that it is bringing to light quite a lot of issues around FIX and security. > Granted, this hinges on how critical this is for someone - if you just need > to check the 'secure' box to make the lawyers happy and you don't really > care, then anybody's product is going to fit the bill. Again, I agree strongly. Hardware and software encryption both add measurable latency to messaging, and, at least in the pre-trade and trade space, low latency is critical. As was mentioned in the FPL White Paper, many firms will say that a leased line is good enough and not bother with any of this. > Most people don't have the resources to perform in-house audits to determine > the level of security provided by product X, Y, or Z. You have to take a > vendor's word on it, so the key thing here is that if you tell me your > product supports SSL, but I can't audit it and you can't provide me with an > exhaustive audit from a trusted third-party, then I'm really forced to choose > between the known quantity of a product from a reputable security firm and a > product from a guy who assures me everything is ok, but can't really > demonstrate it apart from waving his hands... Ability to audit security is an excellent point. I'm willing to assume for this discussion that the encrypting router is audited and fully 100% secure. But a chain is only as secure as its weakest link. What happens between the FIX engine and the router? This can be difficult to audit. As I've said, networks often use dynamic routing protocols to provide resiliency. I'll admit that the bulk of my networking experience came from over a decade ago. But in that time I've seen my fair share of weird things, where well meaning network admins wanted data to take one path, and it really took another. Or multiple paths. Or asymmetric paths going there and coming back. Or network topology changed, and data suddenly found a new path. In these cases, the application sometimes still worked. How do you go about auditing this? It takes a lot of technical knowledge. And, even if you use traceroute and a packet sniffer on each end of the connection, and make sure the path is right today, who says it will be right tomorrow when network topology and routing tables change? And what if the encrypted link goes down? Will any dynamic rerouting happen, sending the data over a non-secure link? Contrast this with TLS and OpenSSL. FIX is an open standard. There is no guarantee that each side will use the same software. So my counterparty and I configure our FIX engines to accept a TLS session, limited to a particular certificate for ourselves and each other, and allow only certain secure cyphersuites. The act of successfully connecting is a form of audit. Either we both have it wrong, or we're both probably using TLS properly. We can also try replacing both our own certificate, and our counterparty's certificate, with the wrong one, and validate that the connection is refused. Interoperability with other TLS-enabled FIX engines is a very good sign. Yes, none of this is perfect. There still are risks. In a perfect world, should security flaws be found with OpenSSL, my FIX engine provider would send me an urgent software update. Then again, even routers have security vulnerabilities, and network admins need to upgrade firmware from the vendors when they are discovered. Thanks for this interesting discussion. Ryan [You can unsubscribe from this discussion group by sending a message to mailto:unsubscribe+10093...@fixprotocol.org] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to fix-protocol@googlegroups.com. To unsubscribe from this group, send email to fix-protocol+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
