A planned Black Hat talk on High-Frequency Trading (HFT) vulnerabilities was recently pulled from the 2010 Black Hat conference, ostensibly at the request of one of the authors’ clients who probably felt that the planned disclosures hit a little close to home.
HFT is a hot topic in circles ranging from regulatory and compliance discussion forums, over smaller traders, to conspiracy wingnuts. Despite the fact that it’s just one technological tool among many to give exchange participants an edge over competitors, I tend to side with the conspiracy theorists, especially insofar as it’s an approach to transactions that by its very definition gives an edge to larger market actors — thus skewing the idea of a “fair market”. Various individuals have claimed that this goes so far as to allow participants to manipulate prices using fake orders, but I don’t know enough about trading technology to comment on this.
Due to the very technologically intricate and detailed nature of HFT platforms, very few people understand how they work — and overtaxed regulators and security & compliance organizations thus are left in the dust when it comes to ensuring that such solutions do not present a security and operational risk, not just to the companies who run them, but to overall market stability. Remember, complexity is almost always bad if you can’t reliably understand it with a reasonable grasp of the subject matter.
The article has one particular paragraph that rings very true:
While applications are combed for typical application vulnerabilities like SQL injection or cross-site scripting, they’re not examined for operational vulnerabilities: A rogue trader could, for instance, change a single variable to allow far more risky trades than a bank or its clients intend–the sort of trick that Société Générale trader Jerome Kerviel may have used to make unauthorized trades in 2008 that cost the firm $7 billion.
Yeah, basically. Many of the people who use these toys are very bright autodidacts, creating customer tools for exotic, structured products. Even off-the-shelf software is frequently written using what I like to call “functional programming” — i.e. a very smart person with a Visual Basic book coding a solution to an operational requirement without paying attention to best practices that may, in any case, be outside of the scope they care about. Investment firm management is likely to turn a blind eye to even obvious flaws in such software, due to the fact that traders (a) bring in massive amounts of revenue and (b) are increasingly the only people who understand certain market types.
The rise in black pools and other off-exchange trading will only increase the latter phenomenon; I’ve seen trading floors where it was pretty common for one person to be responsible for a particular exotic product; frequently, this person might even have been the one who helped create the actual market. Remember, you can trade pretty much anything, as long as you have a willing counterparty…
How do you deal with such issues as a security professional? To many who are not trained in the black arts of financial transactions, much technological innovation in modern markets is the driving force behind an increased complexity that regulators cannot hope to oversee effectively. Analyzing security issues in such tools also becomes difficult, even from the inside, even when a company is willing to implement controls — the line between legitimate exploitation of a weaker player’s market position and an actual security intrusion blurs to the point where traditional technical vulnerability analysis is no longer an option.
I don’t have a solution, beyond an innate distrust of anything I don’t understand in detail, but I believe that companies’ willingness to reduce their exposure to security issues stemming from overly complex trading software is more a philosophical than a policy or technical question — how far are we willing to go to exploit loopholes in the spirit of market regulation? Are we willing to sacrifice potential high risk + high profit combinations in order to remain in more staid trading areas?
And most importantly, if management won’t listen, as a security guy, can you sufficiently CYA to avoid being caught up in a potential technical or regulatory failure of one of your employer’s systems that’s just too intricate to reliably review for risk?

Recent Comments