Feeds

Lone sysadmin fingered for $462 MEEELLION Wall Street CRASH

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

Secure remote control for conventional and virtual desktops

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? ®

Secure remote control for conventional and virtual desktops

More from The Register

next story
Ellison: Sparc M7 is Oracle's most important silicon EVER
'Acceleration engines' key to performance, security, Larry says
Oracle SHELLSHOCKER - data titan lists unpatchables
Database kingpin lists 32 products that can't be patched (yet) as GNU fixes second vuln
Ello? ello? ello?: Facebook challenger in DDoS KNOCKOUT
Gets back up again after half an hour though
Hey, what's a STORAGE company doing working on Internet-of-Cars?
Boo - it's not a terabyte car, it's just predictive maintenance and that
Troll hunter Rackspace turns Rotatable's bizarro patent to stone
News of the Weird: Screen-rotating technology declared unpatentable
prev story

Whitepapers

A strategic approach to identity relationship management
ForgeRock commissioned Forrester to evaluate companies’ IAM practices and requirements when it comes to customer-facing scenarios versus employee-facing ones.
Storage capacity and performance optimization at Mizuno USA
Mizuno USA turn to Tegile storage technology to solve both their SAN and backup issues.
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?
Beginner's guide to SSL certificates
De-mystify the technology involved and give you the information you need to make the best decision when considering your online security options.
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.