At the Black Hat Conference
in Las Vegas at the beginning of August – Black Hat focuses upon all
things to do with security of systems – Jeremy Rauch and David
Goldsmith from Matasano Security
stood on the podium and said that the FIX Protocol, used to link most investment markets buy- and sell- side firms, suffers from
fundamental security flaws. Their premise is that the race for reduced
latency has been at the expense of security, with comments such as:
you look at the priorities around trading protocols, performance and
availability are the most important parts. The faster they can
communicate, the better they can capitalize on situations. With
automated trading, microseconds do count. Any kind of security that
introduces latency is going to be frowned upon in these systems." [David Goldsmith]
got computers taking advantage of the sheer quantity of information
available, and they can make enormous amounts of money if they buy and
sell quickly enough. In the name of bigger financial transactions,
speed takes precedence over security." [Jeremy Rauch]
then highlighted that although FIX runs over private networks the fact
that they have total transparency, due to the standard being publicly
available on the internet, means that any employee could team up with
any other person and exploit the FIX Protocol for devious purposes. As
a result, they reckon that applications using the FIX protocol could be
affected by remote denial-of-service, session hijacking and
man-in-the-middle attacks, as well as electronic eavesdropping.
guys at Matasano summarised their presentation with the view that FIX
is "riddled with security holes" and, the way it was reported, anyone
would have thought that FIX had been successfully comprised by
didn’t blog about it straight away when the news came out, as I wanted
to review the comments with some of the London markets’ FIX advocates.
Their general response is: "What’s the difference between this
insecurity and any other internal bank insecurity?" After all, FIX is
only vulnerable if a member of a bank’s or investor’s staff make it so
… just the same as any other bank system vulnerability. This is why,
if you look around the FIX website, there is hardly any focus on
security and, in fact, there is an answer to the security question
already sitting there in this discussion thread titled "How does the FIX protocol address the security issue?"
In this thread, James Bywater of Goldman Sachs writes: "The best place to start is this document: http://fixprotocol.org/documents/581/security.doc.
Despite being over 10 years old it is still very close to what is done
today. However, most integrations I have worked on have used SSL/TLS or
a private line for privacy, authentication, and integrity. SSL/TLS can
be used with server & client authentication required for the best
level of security."
In other words, it’s up to the bank to secure their systems, not the FIX Protocol.
Isn’t this true for any bank system?
Finally, to be fair to them, I asked FIX to give me some commentary and a spokesperson gave me these comments:
views this as an opportunity to document data security considerations
and best practices, and the organisation will be publishing information
to this effect." They went on to say that the "FIX Protocol is
an open and free financial messaging standard, created to deliver a
common, global language for the automated trading of financial
instruments. It is not a piece of software or a product, but a language
specification which software developers can use to create commercial or
open-source software to meet business requirements."
In other words, it is meant to be transparent and out there freely available for firms to build upon. It is not an off-the-shelf solution.
specification is akin to an architect’s blueprint, the blueprint
provides the framework design but you would not expect it to include
the locks on the doors. The builder and home owner have to ensure that
this protection mechanism is in place on the completed building."
If any of you have any keys to those locks, let me know.