Feeds

Lone sysadmin fingered for $462 MEEELLION Wall Street CRASH

'Knightmare' traced to forgotten server upgrade, shoddy software and risk management

Top 5 reasons to deploy VMware with Tegile

On August 1st, 2012, high-frequency equities trader Knight Capital lost $US462 million after automated trading systems went haywire, a mess that has now been traced to a mistake by a single sysadmin.

The incident saw the company place orders for many more shares than its clients wanted to buy. Knight ended up holding the baby, to the tune of $462m in an event that came to be known as the “Knightmare”.

Knight Capital floundered in the aftermath of the error and has since merged with another company. It's also been slapped with a $12m fine, and the US Security Exchange Commission's order (PDF) explaining why offers a look at just what went wrong in the IT department on and before that fateful day.

An application called “SMARS” was the main culprit. One of SMARS' functions was to receive “parent” orders to buy equities, which it then turned into “child” orders that actually bought the equities. Helping things along was a feature called “Power Peg” that hadn't been used for years, but hadn't been removed from SMARS either.

During 2012, Knight Capital upgraded SMARS so it could interface with a new “Retail Liquidity Program (RLP)” offered by the New York Stock Exchange. That upgrade, the SEC says, “repurposed a flag that was formerly used to activate the Power Peg code”. The plan was for the new RLP code to supersede Power Peg.

When the new version of SMARS was introduced, “Knight deployed the new RLP code in SMARS in stages by placing it on a limited number of servers in SMARS on successive days.”

During that process, a staffer made the critical error, described by the SEC as follows:

“During the deployment of the new code, however, one of Knight’s technicians did not copy the new code to one of the eight SMARS computer servers. Knight did not have a second technician review this deployment and no one at Knight realized that the Power Peg code had not been removed from the eighth server, nor the new RLP code added. Knight had no written procedures that required such a review.”

Here's what happened when the server that missed the SMARS update went live:

“On August 1, Knight received orders from broker-dealers whose customers were eligible to participate in the RLP. The seven servers that received the new code processed these orders correctly. However, orders sent with the repurposed flag to the eighth server triggered the defective Power Peg code still present on that server.”

The un-patched server therefore kept making "child" orders for more shares than Knight or its customers wanted. So many orders, in fact, that some stock prices fluctuated wildly and Knight was left holding shares nobody wanted that it had acquired at prices nobody was willing to pay. By the time the market had moved on, it was left with $462m of losses.

The SEC's document scorches Knight Capital for its lax risk management practices and poor systems to detect dodgy-looking trades. It also lashes its poor software development and deployment process, as follows:

“Knight did not have written code development and deployment procedures for SMARS (although other groups at Knight had written procedures), and Knight did not require a second technician to review code deployment in SMARS. Knight also did not have a written protocol concerning the accessing of unused code on its production servers, such as a protocol requiring the testing of any such code after it had been accessed to ensure that the code still functioned properly.”

Elsewhere, the document suggests Knight Capital could have foreseen the problem. Previous disaster recovery tests found related problems, and the SEC points out that “a written procedure requiring a simple double-check of the deployment of the RLP code could have identified that a server had been missed and averted the events of August 1.”

The Reg feels for the sysadmin who conducted the server upgrade, because while they made a mistake the consequences that flowed from it can be attributed to the sloppy software development practice that left Power Peg in place years after anyone stopped using it. Knight's lack of risk management rigour left him or her horribly exposed.

Failures on this scale usually end up being used as examples of how not to do IT. How long do you think it will be before your boss issues a new policy manual about how you work and who checks your activities? Or have you asked them to do it already? ®

Internet Security Threat Report 2014

More from The Register

next story
Azure TITSUP caused by INFINITE LOOP
Fat fingered geo-block kept Aussies in the dark
NASA launches new climate model at SC14
75 days of supercomputing later ...
Yahoo! blames! MONSTER! email! OUTAGE! on! CUT! CABLE! bungle!
Weekend woe for BT as telco struggles to restore service
You think the CLOUD's insecure? It's BETTER than UK.GOV's DATA CENTRES
We don't even know where some of them ARE – Maude
DEATH by COMMENTS: WordPress XSS vuln is BIGGEST for YEARS
Trio of XSS turns attackers into admins
Cloud unicorns are extinct so DiData cloud mess was YOUR fault
Applications need to be built to handle TITSUP incidents
BOFH: WHERE did this 'fax-enabled' printer UPGRADE come from?
Don't worry about that cable, it's part of the config
Astro-boffins start opening universe simulation data
Got a supercomputer? Want to simulate a universe? Here you go
prev story

Whitepapers

Why and how to choose the right cloud vendor
The benefits of cloud-based storage in your processes. Eliminate onsite, disk-based backup and archiving in favor of cloud-based data protection.
Getting started with customer-focused identity management
Learn why identity is a fundamental requirement to digital growth, and how without it there is no way to identify and engage customers in a meaningful way.
10 threats to successful enterprise endpoint backup
10 threats to a successful backup including issues with BYOD, slow backups and ineffective security.
High Performance for All
While HPC is not new, it has traditionally been seen as a specialist area – is it now geared up to meet more mainstream requirements?
The hidden costs of self-signed SSL certificates
Exploring the true TCO for self-signed SSL certificates, including a side-by-side comparison of a self-signed architecture versus working with a third-party SSL vendor.