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?

A colleague of mine recently posted a link to an information warfare-related article on an Iranian activism site.  Like-minded Iranian friends, affiliated with the Green movement, seemed to have as a goal to disseminate information about how to counter censorship in Iran by distributing tools, news, and other means of helping dissidents avoid having their communication muzzled and detected by the mullahs.

This particular article lists examples of electronic warfare by regime-friendly groups such as the “Iranian Cyber Army”, recently suspected of numerous attacks against organizations seen as hostile to the Iranian government.  Ironically, these included Chinese search engine baidu.com in retaliation for some perceived slight by the Chinese government — this shortly after several Chinese organizations have become increasingly implicated in online hits against U.S. and other Western government and corporate targets; a recent report in The Associated Press / The Guardian mention the Chinese universities Shanghai Jiaotong and Lanxiang Vocational Institute as sources of the “Aurora” attacks against Google and others.  On a humorous side note, if 1337 xenophobic script kiddies friendly with one totalitarian regime are now going after 1337 xenophobic script kiddies friendly with another totalitarian regime, it might become difficult to figure out who’s on whose side…

That said, there’s not much an outsider with technological know-how can do to help victims of censorship and repression in any country beyond providing them with the education and means to get around official repression of communication with each other and with the outside world, and to avoid being detected by government thugs while doing so.  A friend of mine, when asked to to provide help and information about censorship avoidance to an Iranian group, took a very cautious line, making it very very clear that he was reluctant to offer anything that carried even the slightest possibility of someone being arrested, tortured, or even killed if they were found using it.  I take a bit of a different view — solutions like PGP, TOR, Haystack, anonymous remailers, or SSL enabled CGI proxies, combined with private browsing available on most newer browsers, are powerful stuff, and with a modicum of care on the part of their users, can conspire to throw a hefty wrench into the surveillance machinations of dictatorial spooks.  The best anyone can do is to make users at risk of brutal crackdowns aware of what could possibly go wrong, give them a good head-start on how to use their new toys, and let them be adults about making an educated choice.  After all, in the case of the Iranian protesters, these are people who’re willing to go out on the street and be shot at for what they believe in.

So much for “passive” assistance — giving people better anonymous / encrypted communications tools and the knowledge on how to effectively use them.  What about active help, though?  Beyond the usual low-level stupidity found in IRC channels (e.g. background noise of the “www.bobsautodetailing.com pwn3d by H4X0RZ 4 ALLAH AGAINST 4m3r1kkkAH” variety), attacks on the infrastructure of Western countries and organizations from Russian, Iranian, North Korean, Chinese, and other groups, presumably with at least some tacit blessing from their governments, are pretty common.  Botnets designed to carry out probes and hits on infrastructure, launch DDoS attacks, create economic sabotage, steal sensitive data, and other bad things, are pretty common in the wild.

Cybercrime legislation in most developed countries is designed to pursue and allow prosecution of even casual probes by unauthorized persons.  Whether one agrees with laws or enforcement tactics or not, the goal is to keep anyone, no matter what motivates them, from generally screwing things up by spying, stealing, or vandalizing.  Unless it specifically takes into account intent, the law doesn’t differentiate between amateurs or professionals — it’s all a crime.  Why?   Partially because attacking a person/host/company/government via a network is the technologically easiest, least physically risky way of getting to the goodies, and because it’s often impossible to differentiate between the casual hacker and the much-vaunted bugaboo of organized cybercriminals and government-sponsored electronic espionage.  The idea, I suppose, is that tolerating any intrusion means that the world economic system as we know it will grind to a standstill (or at least your job and mine will be made that much more difficult.)  Maybe, maybe not, but without such laws as a deterrent, I’m sure the barriers to causing grief to legitimate business would be a lot lower.

But what of aiding and abetting attacks against distasteful regimes or their allies / henchmen?  A few years ago, the idea of counter-hacking, or ethical hacking aimed at taking out threats either by sabotaging those responsible or by “cleaning” affected infrastructures when unsuspecting owners could not or would not, was in high discussion.  Most security professionals in my circle of acquaintances seemed to be roundly against this concept, due to the potential for a slippery slope, and for unacceptable collateral damage — plus, what good is it to have and enforce laws against illicit intrusion when the “good guys” themselves are guilty of violating them, even if they are perfectly well-meaning?

Given how hungry my non-technical Iranian friends were for any information about “passive” tools as those described above, I’d imagine groups in opposition to the government (supposedly there’s now a “Green Cyber Army“) would imaginably be equally happy for any assistance from sympathetic types in the West.  As someone strictly in favor of the rule of law, I can’t condone any illegal actions of the sort these guys are indubitably carrying out, but anything that helps cause grief for kiddies hacking in the service of thugs is ok in my book.  A few dozen clicks to waste here and there to waste the bad guys’ bandwidth, a Metasploit download mirror, or an open proxy or TOR gateway probably wouldn’t violate the spirit of the law.  Wink wink.

Between the two of us, Arjo and I have helped design, set up or run on the order of a dozen public key infrastructures (PKIs). Looking back, not a single one of these was not somehow embroiled in administrative or organizational infighting, bogged down by uncooperative management, or less-than-optimally functional due to design decisions taken for some sort of political reason. To use a colleague’s phrase, these things seem to attract managers like FOS — flies on you-know-what.

We were recently asked to put together a requirements paper for a PKI that was being re-engineered from the ground up. It occurred to me that this might actually be a stellar opportunity to help a client get things right from the start. So, why do we always get bogged down in PKI-related organizational or management issues?

Obviously, the PKI’s main purpose is management of digital certificates for persons, organizations and technical entities. Certificate keys fall into three general categories, which I’ll use Entrust nomenclature to describe: encryption (obvious enough), signing (you can be sure that what you got from me is what I intended to give you) and non-repudiation (you can be sure that I cannot disavow what I gave you.) So, let’s look at what you might actually use these for:

  • User authentication (such as web sites or to workstations via smart cards)
  • Email and file encryption
  • Secure key exchange (e.g. for phase II IPSEC negotiation) between devices
  • Source code, binary and other data signing (e.g. financial transaction information)

Why is this important? Two reasons: first, your certificate templates, which govern the formats of the certificates and their usage, depend on what you intend to do with certificates. In most certificates, for example, there is a key usage flag (a hex value) that is used for this.

Second, and more importantly, your LDAP structure must reflect you organizational structure, certificate usage and a number of other factors from the outset. This is usually the largest bone of contention in PKI design; the classic example is the Jane Doe who marries Bob Smith and changes her last name. So a distinguished name (DN) like C=Albania,O=Bob’s Widgets Inc,OU=Research,CN=Jane Doe is now kind of messy. This can be dealt with by using a friendly name, but you get the idea. Changes in requirements for LDAP attributes and DN structure affect other areas, like host naming, validity of signing and encryption keys, and and and. It gets even more fun when you start doing things like cross-certification, setting up a metadirectory for multiple directories, or integrating existing directory structures.

The upshot of all this is that a PKI affects all aspects of an enterprise that are in some way involved in authentication, security, encryption, verification of data integrity, etc. — and it has to pretty much be done right from the outset, or you run into problems of application integration, user acceptance and overall cost. We know of several directory projects that had their scope drastically cut down after they were built, when it was discovered that they simply wouldn’t work for some of what they were intended for; someone obviously hadn’t done their homework.

Most tragically, sometimes design decisions are taken or changed late in the development phase. I will recount one infamous experience of a client who, based on a few casual observations our team made, called a stakeholder meeting consisting of a room full of 35 people shouting at each other, and reversed his entire enterprise directory strategy _twice_ in the course of two hours. We’d done the underlying design and recommended a certain set of project technology several months previously, but were ignored due to political reasons. In this meeting, our group just tried to remain rational and calm, and to give information when prompted, but in the end we realized there was just nothing to be done and snuck out. It was telling that nobody noticed.

Probably, everyone who’s affected will want a piece of the discussion, and we all know how well design by committee works. Many managers also seem naturally threatened by (or nervous about) any technology that effects a lot of blanket organizational and procedural change — a perfect categorization of an enterprise PKI. It doesn’t help that such products sometimes carry the stigma of taking away autonomy from other groups; at some level, any infrastructure component using PKI certificate must follow certain standards and procedures, there’s just no way around that. This is often seen as a loss of self-determination, or it may require technical effort, and who’s going to pay for that?

So, how does one deal effectively with this? A lot of good PKI design practice involves some pretty common-sense elements:

  • A knowledgeable, strong project manager who can organize management buy-in and support
  • A small design team who’ve done this before and have a clue what they’re doing (good luck!)
  • Individual discussions with potential stakeholders about what they want and how their concerns can be addressed
  • A _lot_ of time spent on research and design — use the “hire a 6-year-old to spot any obvious flaws in your plan” model liberally here
  • A clear idea of budget responsibilities in PKI deployment — but not to the end that every affected team will try to pawn off even minor changes on the PKI budget

And last but defnitely not least, a really good LDAP guy, you won’t regret it.

p.s.:  If you’re interested in reading more about non-repudiation, including how it differs from the usual technical usage of “signing”, have a look at Non-Repudiation in the Digital Environment.

© 2010 Chakraborty Software Suffusion WordPress theme by Sayontan Sinha